5. Implementation Model (Modello di implementazione)
La Figura 2 mostra l'architettura di una tipica implementazione multithread (multi-threaded implementation). Include due processi dedicati a ciascun server, un processo peer (peer process) per ricevere messaggi dal server o dall'orologio di riferimento, e un processo di polling (poll process) per trasmettere messaggi al server o all'orologio di riferimento.
.....................................................................
. Remote . Peer/Poll . System . Clock .
. Servers . Processes . Process .Discipline.
. . . . Process .
.+--------+. +-----------+. +------------+ . .
.| |->| |. | | . .
.|Server 1| |Peer/Poll 1|->| | . .
.| |<-| |. | | . .
.+--------+. +-----------+. | | . .
. . ^ . | | . .
. . | . | | . .
.+--------+. +-----------+. | | +-----------+. .
.| |->| |. | Selection |->| |. +------+ .
.|Server 2| |Peer/Poll 2|->| and | | Combine |->| Loop | .
.| |<-| |. | Cluster | | Algorithm |. |Filter| .
.+--------+. +-----------+. | Algorithms |->| |. +------+ .
. . ^ . | | +-----------+. | .
. . | . | | . | .
.+--------+. +-----------+. | | . | .
.| |->| |. | | . | .
.|Server 3| |Peer/Poll 3|->| | . | .
.| |<-| |. | | . | .
.+--------+. +-----------+. +------------+ . | .
....................^.........................................|......
| . V .
| . +-----+ .
+--------------------------------------| VFO | .
. +-----+ .
. Clock .
. Adjust .
. Process .
............
Figura 2: Modello di implementazione
Questi processi operano su una struttura dati comune, chiamata associazione (association), che contiene le statistiche descritte sopra insieme a vari altri dati descritti nella Sezione 9. Un client invia pacchetti a uno o più server e quindi elabora i pacchetti restituiti quando vengono ricevuti. Il server scambia gli indirizzi di origine e destinazione e le porte, sovrascrive determinati campi nel pacchetto e lo restituisce immediatamente (in modalità client/server) o in un momento successivo (nelle modalità simmetriche). Quando viene ricevuto ogni messaggio NTP, viene calcolato l'offset (offset, theta) tra l'orologio del peer e l'orologio di sistema insieme alle statistiche associate delta, epsilon e psi.
Il processo di sistema (system process) include gli algoritmi di selezione (selection), cluster e combinazione (combine) che mitigano tra i vari server e orologi di riferimento per determinare i candidati più accurati e affidabili per sincronizzare l'orologio di sistema. L'algoritmo di selezione utilizza i principi di rilevamento dei guasti bizantini (Byzantine fault detection principles) per scartare i candidati presumibilmente errati chiamati "falsetickers" dalla popolazione incidente, lasciando solo i buoni candidati chiamati "truechimers". Un truechimer è un orologio che mantiene l'accuratezza del cronometraggio rispetto a uno standard precedentemente pubblicato e affidabile, mentre un falseticker è un orologio che mostra un tempo fuorviante o incoerente. L'algoritmo di cluster utilizza principi statistici per trovare l'insieme più accurato di truechimers. L'algoritmo di combinazione calcola l'offset dell'orologio finale facendo la media statistica dei truechimers sopravvissuti.
Il processo di disciplina dell'orologio (clock discipline process) è un processo di sistema che controlla il tempo e la frequenza dell'orologio di sistema, qui rappresentato come un oscillatore a frequenza variabile (variable frequency oscillator, VFO). I timestamp ottenuti dal VFO chiudono il ciclo di feedback (feedback loop) che mantiene il tempo dell'orologio di sistema. Associato al processo di disciplina dell'orologio c'è il processo di regolazione dell'orologio (clock-adjust process), che viene eseguito una volta al secondo per iniettare un offset temporale calcolato e mantenere una frequenza costante. La media RMS delle differenze di offset temporale passate rappresenta l'errore nominale o il jitter dell'orologio di sistema (system clock jitter). La media RMS delle differenze di offset di frequenza passate rappresenta la stabilità della frequenza dell'oscillatore (oscillator frequency stability) o la deriva della frequenza (frequency wander). Questi termini ricevono un'interpretazione precisa nella Sezione 11.3.
Un client invia messaggi a ciascun server con un intervallo di polling (poll interval) di 2^tau secondi, come determinato dall'esponente di polling (poll exponent) tau. In NTPv4, tau varia da 4 (16 s) a 17 (36 h). Il valore di tau è determinato dall'algoritmo di disciplina dell'orologio per corrispondere alla costante di tempo del loop (loop-time constant) T_c = 2^tau. In modalità client/server, il server risponde immediatamente; tuttavia, nelle modalità simmetriche, ciascuno dei due peer gestisce tau come funzione dell'offset di sistema corrente e del jitter di sistema, quindi potrebbero non concordare sullo stesso valore. È importante che il comportamento dinamico dell'algoritmo di disciplina dell'orologio sia controllato con attenzione per mantenere la stabilità nella sottorete NTP in generale. Ciò richiede che i peer concordino su un tau comune uguale all'esponente di polling minimo di entrambi i peer. Il protocollo NTP include disposizioni per negoziare correttamente questo valore.
Il modello di implementazione include alcuni mezzi per impostare e regolare l'orologio di sistema. Si presume che il sistema operativo fornisca due funzioni: una per impostare il tempo direttamente, ad esempio, la funzione Unix settimeofday(), e un'altra per regolare il tempo in piccoli incrementi avanzando o ritardando il tempo di un importo designato, ad esempio, la funzione Unix adjtime(). In questo e nei seguenti riferimenti, le parentesi che seguono un nome indicano un riferimento a una funzione piuttosto che a una semplice variabile. Nel design previsto, il processo di disciplina dell'orologio utilizza la funzione adjtime() se la regolazione è inferiore a una soglia designata, e la funzione settimeofday() se superiore alla soglia. Il modo in cui ciò viene fatto e il valore della soglia sono descritti nella Sezione 10.