ntp.ttwagner.com
This is the status page of the ntp.ttwagner.com (66.197.144.101) NTP server. (That host is actually a different IP, and this webpage is served from a virtual machine; I'll elaborate in a subpage some day.)
Current Time Sources:
remote refid st t when poll reach delay offset jitter
==============================================================================
*clock.nyc.he.ne .CDMA. 1 u 67 1024 377 12.005 -4.107 1.330
+nist1-ny.ustimi .ACTS. 1 u 746 1024 377 16.396 -3.362 0.166
-rackety.udel.ed .PPS. 1 u 1005 1024 377 13.885 -6.508 0.617
+64.236.96.53 .ACTS. 1 u 92 1024 377 13.987 -2.345 0.821
216.14.97.75 .CDMA. 1 u 216d 1024 0 29.292 0.905 0.000
-ntp0.usno.navy. .USNO. 1 u 588 1024 377 27.568 0.600 1.715
Client Graphs
These are based on the data here.
Total Clients
Active Clients
Average Requests per Second (Current rate)
Abusive Clients
Quality Graphs
These are generated every 5 minutes using RRDTool and the scripts here. Note that NTP doesn't necessarily update every 5 minutes (it's usually every 1024 seconds, or ~17 minutes.), so these graphs might look 'blocky' as a result.
Offset: The most recent change to the clock:
Jitter: The 'difference of the differences' in readings (a shoddy explanation for now)
Root Dispersion: The maximum error range, summed across all hosts in the chain
This is an interesting effect... It seems that NTP increases this in a linear (or almost-linear) fashion, until the next sync, at which point it's recalculated, causing it to drop back down quickly... Hence the curious sawtooth pattern.
Noise: Yeah.
Frequency: The error of the system (hardware) clock, in parts-per-million. (This is what's stored in the NTP drift file.)
Stability: In parts-per-million
Delay: Latency to the current server; wild variations probably indicate switching to a different clock...
