Come posso misurare e prevenire la deriva dell'orologio?

15

Su diverse piattaforme di produzione abbiamo osservato sintomi che sembrano suggerire che l'ora dell'orologio sta saltando periodicamente in avanti o indietro. I salti sono in genere di circa 1 secondo, in genere si annullano (saltano avanti e indietro molto poco dopo) e si verificano circa 50 volte al giorno. Questa deriva è più evidente durante i periodi di massimo utilizzo delle applicazioni e durante i periodi di operazioni di I / O del disco elevate come i backup giornalieri. Queste derive stanno influenzando la nostra delicata applicazione sensibile in tempo reale.

I sistemi sono server Oracle Netra X4250 e Netra X4270 con SLES 11SP2 con kernel 3.0.58-0.6.6-default.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Abbiamo disabilitato NTP , ma ciò non ha avuto alcun effetto sulle derive. Esistono strumenti che misurano la deriva dell'orologio? Come possiamo evitarlo?

Queste sono piattaforme di produzione e non possiamo ricreare il problema nei nostri laboratori, quindi la mia capacità di sperimentare è limitata. Se lasciato ai miei dispositivi, scriverò uno strumento per misurare la deriva e forse sperimenterò una sorgente di clock HPET .

linux sles clock

— brett
fonte

5

La disabilitazione di NTP rende gli orologi molto più instabili ... l'unica ragione per cui NTP non riesce a mantenere l'orologio in linea è che l'orologio è fuori uso e NTP si rifiuta di aggiornarlo (vedi ntpdate(8)o ntpd(8)).

— vonbrand

1

NTPD tiene traccia e corregge la deriva dell'orologio, ma ciò che hai non è deriva. La deriva è costantemente nella stessa direzione all'incirca la stessa quantità nel tempo. Se salta casualmente avanti e indietro, non c'è modo di prevederlo e adattarlo.

— Patrick

1

Quello che @Patrick ha detto è giusto, il problema che descrivi è un salto discontinuo nel tempo avanti e indietro, più volte al giorno. NTP funziona bene alla deriva ma non ti aiuterà molto con questo. È probabile che qualcosa stia reimpostando la data del sistema su una fonte di tempo esterna che forse ha solo una risoluzione di 1 secondo. Se i tuoi server sono x86 * l'RTC hardware potrebbe essere l'origine e alcuni cron job il colpevole. Per quanto riguarda la misurazione dell'offset dell'orologio, la risposta ntpdate di Bratchley è un approccio ragionevole a condizione che venga utilizzato un buon riferimento di clock dello strato 1: esegui una volta al minuto e gnuplot il risultato per un'immagine.

— duanev,

1

La valutazione di NTP è stata avviata su un nuovo server ( drdobbs.com/embedded-systems/… ). Ci vogliono ore NTP per imparare un nuovo cristallo. Per cristalli davvero cattivi, NTP dovrà "aumentare" il tempo di quantità significative più volte durante l'allenamento (vedere le figure 4 e 5 in quell'articolo). Un valore finale in deriva ntp di 118 ppm è 10 secondi al giorno o 208 ms ogni 30 minuti. Anche se questo non è ciò che l'OP stava vedendo, NTP può inizialmente causare notevoli salti nel tempo.

— duanev,

8

Esistono strumenti che misurano la deriva dell'orologio?

Gli unici strumenti di cui sono a conoscenza sono gli strumenti NTP che dovrebbero essere sufficienti. Non è necessario configurare ntpd per la sincronizzazione con una determinata sorgente di clock, è sufficiente utilizzare l' -dopzione ntpdateper recuperare l'offset calcolato.

Esempio:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d è l'opzione di debug che fa funzionare l'NTP senza toccare l'orologio di sistema.

Qualche consiglio su come possiamo evitarlo?

Non sono troppo sorpreso dal fatto che non sei in grado di riprodurlo in ambienti di sviluppo / test poiché probabilmente è solo a causa dell'orologio hardware. Se hai supporto hardware con qualcuno, proverei a far riparare le tue macchine. Una possibilità è quella di scambiare una delle macchine di sviluppo per questa macchina di produzione, riparare i precedenti sistemi PROD e reintrodurla come macchina di sviluppo per sostituire quella che è in PROD ora.

A parte questo, cambiare la sorgente del clock hardware è tutto ciò che puoi fare. Se non riesci o non riesci a fare la cosa di scambio, ti suggerisco di seguire il percorso di HPet. È possibile verificare se la modifica dell'origine dell'orologio è in conflitto con i servizi di sistema e quindi distribuirla in produzione come grandine.

— Bratchley
fonte

Per "misurare la deriva dell'orologio", non intendevo la deriva da una fonte temporale di riferimento, come NTP ti offre. Intendevo uno strumento in grado di rilevare "salti" nell'ora del giorno in un intervallo di tempo continuo. Ad esempio, prendere campionamenti dell'ora del giorno ogni 50 ms e segnalare se la differenza rispetto all'ultimo campionamento è troppo distante da 50 ms. Un tale strumento mostrerebbe se l'orologio del giorno sta andando alla deriva dall'orologio hardware sottostante per qualsiasi motivo.

— Brett

1

La presenza di un tale intervento non causerebbe probabilmente un peggioramento delle prestazioni di quanto speri di risolvere? Con ogni probabilità, tuttavia, è un problema hardware, quindi dovrai riparare l'hardware o utilizzare una sorgente di clock senza questo problema. tscè basato sulla CPU, quindi ha senso che una maggiore attività della CPU provocherebbe comunque un problema con l'orologio hardware. Se hpet è abbastanza veloce per te, allora potresti semplicemente provarlo, farti riparare o fare lo scambio. Queste sono le uniche opzioni che posso vedere per te.

— Bratchley

3

Una soluzione è usare HPET

Vedi anche Timer eventi ad alta precisione

Per impostarlo come parametro di avvio, utilizzare

clocksource=hpet

Su hardware più vecchio TSCera spesso instabile ed era disabilitato dal kernel.

Con l'avvento di CPU multi-core / hyper-thread, sistemi con più CPU e sistemi operativi in letargo, non è possibile fare affidamento sul TSC per fornire risultati accurati ...

Wikipedia: Contatore timestamp

Su un sistema di produzione che mostrava i sintomi del jitter dell'orologio ho impostato l'origine dell'orologio su hpet. Ciò non ha avuto alcun effetto sui sintomi di jitter dell'orologio osservati.

— Brett,

HPET è un timer hardware esterno e non può jitter. Quindi questa soluzione sembra essere una strada sbagliata. Ci sono stati molti problemi di temporizzazione con l'hardware precedente, specialmente quando si utilizza la virtualizzazione. Hai controllato anche questo con software diverso?

1

Ho scritto uno strumento più dettagliato per correlare le misurazioni dell'orologio con i sintomi di latenza mostrati dalla nostra applicazione. Questo strumento sembra escludere ciò che in precedenza sospettavo come jitter nell'orologio Linux dell'ora.

Per farla breve, la mia ipotesi iniziale non era valida. Ma ho imparato molto sugli orologi Linux dalle risposte e dai collegamenti, quindi grazie a tutti coloro che hanno risposto!

— brett
fonte

3

(...) la mia ipotesi iniziale non era valida Potresti dirci qual è stata la vera causa, allora?

— Piotr Dobrogost

0

L'orologio non dovrebbe essere monotono a meno che qualcuno non lo cambi? I salti all'indietro non dovrebbero essere possibili. Deve esserci qualcosa che imposta l'orologio: un cron job o qualche altro demone (ad esempio una chiamata a hwclock --adjust). Ricordo che ntp stesso aggiorna le statistiche per la deriva e la compensa regolarmente e se non si esegue ntp per lungo tempo e si ottiene un enorme offset, si incasina il tempo per giorni dopo se non si ripristina /etc/adjtime. Potresti avere qualcosa del genere - qualcosa che riaggiusta periodicamente il tempo (e provoca salti).

ntp è in realtà destinato a contrastare questo problema.

— Orion
fonte

Questo è quello che ho pensato anche io. La mia lettura delle fonti di clock hardware suggerisce che il contatore dovrebbe aumentare monotonicamente. Se ciò fosse vero, nel peggiore dei casi dovremmo osservare tassi di tick errati, ma non tornare mai indietro. Su un sistema multiprocessore, capisco che tsc deve essere sincronizzato tra i processori - forse questo è ciò che sta causando salti all'indietro?

— Brett,