DTS 4135.TIMESERVER

Oscillator type:	TCXO (DTS 4135) / OCXO (DTS 4136)
1 LAN port (RJ45) / RPS:	provides NTP (< 3'000 requests/s)
Outputs:	2x DCF/pulse/frequency output, 2x IRIG-B / AFNOR, 2x serial output, 1x DCF current loop output
High precision time:	Time reception from GPS
Redundancy:	master-slave operation with automatic switch over in case of an error

Configurazione IP	DHCP, static IPv4, IPv6
Power supply	AC input: 90 to 240 VAC / 50 - 60 Hz / 0.25 A, 2 x DC input: 24 VDC +20 % / -10 % / 20 W
Accuratezza	GPS (DCF input) to NTP server: typical < ± 100 µs / GPS (DCF input) to DCF 77 / pulse output: typical < ± 10 µs
Operation	Serial terminal via RS 232 (front side, sub-D 9p male) / Via LAN: MOBA-NMS, Telnet, SSH, SNMP
Time-keeping	Synchronized with GPS

What is the difference between NTP and SNTP?
Qual è la differenza tra NTP e SNTP?

SNTP (Simple Network Time Protocol) e NTP (Network Time Protocol) descrivono esattamente lo stesso formato di pacchetto di rete, le differenze possono essere trovate nel modo in cui un sistema gestisce il contenuto di questi pacchetti per sincronizzare il proprio tempo. Sono fondamentalmente due modi diversi di gestire la sincronizzazione dell'ora.
Mentre un server o client NTP completo raggiunge un livello molto elevato di precisione ed evita il più possibile timestamp improvvisi utilizzando diversi metodi matematici e statistici e regolazioni fluide della velocità di clock, SNTP può essere consigliato solo per applicazioni semplici, dove i requisiti per precisione e affidabilità non sono troppo impegnative.
Ignorando i valori di deriva e utilizzando metodi semplificati di regolazione dell'orologio di sistema (spesso semplici passaggi temporali), SNTP ottiene solo una sincronizzazione temporale di bassa qualità rispetto a un'implementazione NTP completa. SNTP versione 4 è definita in RFC2030, dove si legge:
“Si consiglia vivamente di utilizzare SNTP solo alle estremità della sottorete di sincronizzazione. I client SNTP devono funzionare solo alle foglie (strato più alto) della sottorete e in configurazioni in cui nessun client NTP o SNTP dipende da un altro client SNTP per la sincronizzazione. I server SNTP dovrebbero funzionare solo alla radice (strato 1) della sottorete e solo in configurazioni in cui non è disponibile altra fonte di sincronizzazione oltre a un servizio orario radio o modem affidabile. Il pieno grado di affidabilità normalmente atteso dai server primari è possibile solo utilizzando le fonti ridondanti, i diversi percorsi di sottorete e gli algoritmi predisposti di un'implementazione NTP completa."
Pertanto il termine “time server NTP” o “client compatibile NTP” può – per definizione – descrivere un sistema con un NTP completamente implementato così come qualsiasi altro prodotto che utilizza e comprende il protocollo NTP ma raggiunge livelli molto peggiori di affidabilità, precisione e sicurezza.

Perché hai bisogno del tuo server NTP anche se su Internet sono disponibili server NTP?

Se una connessione Internet funziona correttamente, NTP può determinare e tenere conto dei ritardi di trasmissione dei pacchetti in modo abbastanza affidabile. Tuttavia, se la connessione Internet è al limite della capacità, la sincronizzazione dell'ora può essere notevolmente ridotta a causa dell'elevata dispersione dei ritardi di trasmissione dei pacchetti. Le ragioni potrebbero essere gli attacchi degli hacker, che non devono colpire la vostra rete, oppure nuovi virus che provocano un'enorme ondata di e-mail, come è già accaduto in passato. Un proprio server NTP non può essere facilmente compromesso fuori da Internet

Quali meccanismi esistono a livello del dispositivo DTS per gestire in sicurezza questi secondi intercalari?

Esistono fondamentalmente due modi per tenere conto del secondo intercalare nel proprio sistema temporale IT. La prima soluzione (DTS4160, DTS4210) è che il secondo intercalare venga letto automaticamente tramite il ricevitore GPS e il time server possa implementarlo nel timestamp NTP emesso. Alla base di questo automatismo dei dispositivi c'è il fatto che gli operatori dei satelliti GPS di solito tengono conto delle specifiche IERS, il che è garantito dal preavviso e dallo stesso secondo intercalare. Solo sulla base di entrambi i componenti i ricevitori GPS e i time server possono elaborare il secondo intercalare correttamente e esattamente al momento giusto e implementarlo anche in termini di tecnologia di sistema.

Alcuni gestori di infrastrutture critiche preferiscono invece la procedura manuale perché esiste un certo rischio residuo per quanto riguarda la ricezione sicura di entrambi i componenti sopra menzionati e il secondo intercalare deve essere solitamente conteggiato separatamente per altri sistemi IT Comunque. Inoltre, la definizione dei secondi intercalati non è una procedura standard, quindi ciò può anche parlare di un processo consapevole, quindi manuale, da parte dell'utente. Con questa soluzione alternativa di impostazione manuale potete effettuare tempestivamente un'impostazione corrispondente sui nostri dispositivi DTS, ad esempio tramite MOBA NMS o Telnet SSH, per cui il server temporale DTS elabora quindi in modo sicuro il secondo intercalare e lo implementa di conseguenza.

Qual è il tempo di risposta tipico quando un client richiede l'ora da un dispositivo DTS?

Tipicamente è < 1ms, quando non vengono presi in considerazione la rete e il numero di richieste client al secondo.
Il ritardo della rete può variare notevolmente a seconda del carico di traffico. Ecco perché i pacchetti NTP contengono due timestamp (pacchetto in uscita e pacchetto in ingresso). Quindi il tempo di risposta può essere calcolato e compensato.

Conclusione:
Per NTP standard il ritardo di rete (tempo di risposta) non è rilevante per la precisione della sincronizzazione del client.
Tuttavia, quando il ritardo dovesse essere molto elevato, la raggiungibilità del server NTP potrebbe risultare ridotta.
SNTP (Simple Network Time Protocol) and NTP (Network Time Protocol) are describing exactly the same network package format, the differences can be found in the way how a system deals with the content of these packages in order to synchronize its time. They are basically two different ways of how to deal with time synchronization.
While a full featured NTP server or -client reaches a very high level of accuracy and avoids abrupt timestamps as much as possible by using different mathematical and statistical methods and smooth clock speed adjustments, SNTP can only be recommended for simple applications, where the requirements for accuracy and reliability are not too demanding.
By disregarding drift values and using simplified ways of system clock adjustment methods (often simple time stepping), SNTP achieves only a low quality time synchronization when compared with a full NTP implementation. SNTP version 4 is defined in RFC2030, where it reads:
“It is strongly recommended that SNTP be used only at the extremities of the synchronization subnet. SNTP clients should operate only at the leaves (highest stratum) of the subnet and in configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization. SNTP servers should operate only at the root (stratum 1) of the subnet and then only in configurations where no other source of synchronization other than a reliable radio or modem time service is available. The full degree of reliability ordinarily expected of primary servers is possible only using the redundant sources, diverse subnet paths and crafted algorithms of a full NTP implementation."
Therefore the term “NTP time server” or “NTP compatible client” can – by definition – describe a system with a fully implemented NTP as well as any other product which uses and understands the NTP protocol but achieves far worse levels of reliability, accuracy and security.

Why do you need your own NTP server although there are NTP servers available on the internet?

If an internet connection is working properly then NTP can determine and account for the packet transmission delays quite reliable. However, if the internet connection is at its capacity limit, time synchronization can be significantly degraded due to high dispersion in packet transmission delays. Reasons for this may be hacker attacks, which must not address your own network, or new viruses causing a huge flood of emails, like it has already happened in the past. An own NTP server cannot easily be compromised out of the internet

What mechanisms are there at the DTS device level to safely deal with these leap seconds?

There are basically two ways to take the leap second into account in your own IT time system. The first solution (DTS4160, DTS4210) is that the leap second is automatically read in via the GPS receiver and the time server can implement this in the NTP time stamp that is output. The background to this device automatism is that the GPS satellite operators usually take the IERS specification into account accordingly, which is guaranteed by advance notice and the actual leap second itself. Only on the basis of both components can GPS receivers and time servers process the leap second correctly and at exactly the right time and also implement it in terms of system technology.

Some operators of critical infrastructures, on the other hand, prefer the manual procedure because there is a certain residual risk with regard to the secure reception of both of the above-mentioned components and the leap second usually has to be tracked separately for other IT systems anyway. Also, the definition of leap seconds is not a standard procedure, so that this may also speak for a conscious, then manual, process on the part of the user. With this alternative solution of manual setting, you can make a corresponding setting in good time with our DTS devices, for example via MOBA NMS or Telnet SSH, whereby the DTS time server then safely processes the leap second and implements it accordingly.

What is the typical response time when a client requests the time from a DTS device?

Typically it is < 1ms, when the network and the number of client requests per second is not taken into consideration.
The network delay can differ very much, depending on the traffic load. That’s why NTP packets contain two time stamps (packet output and packet input). So the response time can be calculated and compensated.

Conclusion:
For standard NTP, the network delay (response time) is not relevant for the precision of the client synchronization.
Except, when the delay should be very high, then the reachability of the NTP server could be degraded.