Ядро Linux виявляє неправильну частоту процесора

Після холодного завантаження сервера Debian 6.0.8 (HP ProLiant) ntpdграє хаос із системним часом: зміщення та тремтіння щодо звичайних та надійних серверів еталонного часу, що ростуть без обмежень. (Зауважте, що у ідентичного сервера-близнюка взагалі не було проблем.) Після багатьох невдалих спроб виправити проблему на ntpdстороні, я вирішив спробувати перезавантажити, і все пішло нормально.

Для того, щоб дослідити проблему, я виявив цю невідповідність, яка могла б пояснити мої проблеми з годинником:

root@n1:~# zgrep Detected /var/log/dmesg*
/var/log/dmesg:[    0.004000] Detected 2400.110 MHz processor.
/var/log/dmesg.0:[    0.004000] Detected 2383.579 MHz processor.
/var/log/dmesg.1.gz:[    0.004000] Detected 2400.036 MHz processor.
/var/log/dmesg.2.gz:[    0.004000] Detected 2400.298 MHz processor.
/var/log/dmesg.3.gz:[    0.004000] Detected 2400.165 MHz processor.
/var/log/dmesg.4.gz:[    0.004000] Detected 2400.410 MHz processor.

Зауважимо, що в другому останньому завантаженні (проблемному) виявлена ​​частота процесора є чіткою стороною. Без зовнішнього вигляду похибка та стандартне відхилення виявленої частоти щодо номінальної становить +0,15 МГц ± 0,25 МГц. Для проблемного завантаження у мене помилка -16,4 МГц, що приблизно в 100 разів більше, ніж очікувалося.

Мої запитання:

1. Чи може помилка такого типу зробити ntpдисципліну часу нестабільною / непридатною для використання? Це причина моїх годинникових проблем?

2. Чи такий тип поведінки є симптомом в'ялого обладнання? Чи повинен сервер перейти до обслуговування hw?

Оновлення

Деякі корисні дані:

• ядро 2.6.32-5-amd64 (Debian 2.6.32-48squeeze4)
• current_clocksource є tsc
• помилка для lpj(звичайно) відповідає помилці на частоті процесора

Деякі рядки контексту для вищезазначеного grep

[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.004000] Detected 2400.110 MHz processor.
[    0.000008] Calibrating delay loop (skipped), value calculated using timer frequency.. 4800.22 BogoMIPS (lpj=9600440)

Я переконав себе, що проблема полягала у неправильній ідентифікації частоти лічильників часу (TSC).

Мабуть, ядро ​​калібрує TSC проти програмованого інтервалу таймера (PIT). Зазвичай ідентифікована частота процесора становить 2400,204 ± 0,134 МГц, що відповідає точності приблизно 56 ppm. Після проблемного завантаження частота процесора була оцінена як 2383,579 МГц, що відповідає помилці близько 6900 проміле, яку ntpdне вдалося компенсувати. Фактично, протягом перших 10h30m функціонування системний годинник набрав приблизно 4m30s, що становить близько 7000 ppm.

Оскільки помилка частоти TSC відповідає дрейфу в системному тактові частоти, я б зробив висновок, що аномальна поведінка тактового сигналу була викликана неправильною калібрування TSC.

Однак я ніколи не бачив такої великої проблеми: я все ще цікавлюсь можливими причинами (hw, sw?) Цього неправильного калібрування.

Такий тип поведінки нетиповий. Хорошим перевіркою було б відслідковувати значення ntp.driftфайлу, щоб побачити, чи відбулися значні зміни під час виявлення поведінки. Якщо це все сильно змінювалося, NTP намагався перекрутити проблему. Якщо це було так, це знак того, що ядро ​​неправильно визначило справжню тактову частоту при запуску, або ж тактова частота була повільною для неправильних частин завантаження. На жаль, ця одна подія не є явним сигналом апаратних проблем.

Якщо це повториться, перегляньте цей файл ntp.drift.