remote           refid      st t when poll reach   delay   offset jitter

Sorry, I conflated terms. NTP uses offset and delay differently. In NTP speak "delay" is the round trip time. "offset" is the difference from local system clock to reference clock after accounting for delay. It is like cause by asymmetric trans time. But still, I think my main point is correct: what you care about in the uncertainty in the process, not the numbers like delay and offset, it's the error bars in those numbers On Sat, Feb 18, 2017 at 9:14 AM, Chris Albertson <albertson.chris@gmail.com> wrote: > You are plotting "offset". This is simply the communications path > delay. It does not measure your system's deviation from UTC. NTP > takes into consideration the offset. > > Here is the way to understand what NTP does with offset. Let's say > we lived 200 years ago and wanted to set a grandfather clock to match > the one in your friend's house and you have no other clocks. Let's > say the friend lives one mile away. .... The best option is to walk > round trips to your friend's house and measure the time and standard > deviation of the round trip time. Divide this time in half and call > it "offset". Then walk to your friend's house, write down the time > and take it home. Set your clock to this time PLUS the offset. > > What you care about is the uncertainty of this process NOT the offset > but the standard deviation of the offset. > > > > On Sat, Feb 18, 2017 at 1:53 AM, David J Taylor > <david-taylor@blueyonder.co.uk> wrote: >> Hi, >> >> I was wondering whether there is some data/information available on the >> claimed +/- 100 ns jitter? >> >> Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I >> plotted, using some lines of Python, the time offset as attached. Just >> to get an overview how it is 'worst case', i.e., user program, python, >> etc. The 1PPS signal comes from a GPS rx. >> Looks like a standard deviation of around 150 us. >> y-axis: measured pps offset from full second (computer time) in us, >> x-axis pps pulse number. >> >> On the long term it looks interesting (while measuring I played with the >> NTP server on this computer) >> Until ca. second 10000: ntpd synchronization via internet >> Until ca. second 17000: made an additional LAN NTP server (GPS) available >> Until the end: replaced ntpd with chrony (still using internet and local >> servers) >> >> Interesting points: >> -It looks surprisingly bad with using the normal ntpd (especially, there >> is not really an improvement having an local GPS based server >> available, did I do something wrong? Only the offset changes by ca. 3 >> ms.) >> -It looks surprisingly good with chrony. But there are continuously >> outliers of up to 4500 us, is this a result of the chrony control loop? >> The time is wandering around with ntpd, but has less jitter. >> >> Conclusion: >> Despite the 150 us stddev, the using PPS over USB gives some interesting >> inside of what the local ntp server is actually doing. It looks to me >> like it would be an improvement to use it when using ntpd, but not when >> using chrony. >> >> Best regards, >> Thomas >> DK6KD >> SA6CID >> >> PS: >> Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS >> offset in us) >> http://petig.eu/pps-usb.txt >> ================================================= >> >> Thomas, >> >> I've done some tests with PPS over USB with Windows some time back, which >> showed that PPS?USB could be better than LAN-sync alone, but that also >> included a reduction of the poll interval from possibly 64 seconds for LAN >> sync to 16 seconds for PPS sync, which may have influenced the results. >> >> <pet-peeve>It would be helpful to have some units on the axes - 10000 what? >> I'm guessing microseconds....</pet-peeve> >> >> For comparison, here is a Raspberry Pi running NTP, with the reported offset >> plotted against time. >> >> http://www.satsignal.eu/mrtg/raspi14_ntp_3.html >> >> This Raspberry Pi (running a seismic detector) is using an Ethernet >> connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a >> couple of switches to a very good stratum-1 server. I would estimate from >> your graph that the jitter in offset is about 1 millisecond peak-to-peak, >> but it seems that I get less than that - perhaps 100 microseconds >> peak-to-peak with occasional excursions outside that. This is with the >> latest reference version of NTP. >> >> remote refid st t when poll reach delay offset jitter >> ============================================================================== >> *192.168.0.20 .GPS. 1 u 17 32 377 12.351 0.000 0.428 >> +192.168.0.11 .uPPS. 1 u 2 32 377 12.432 -0.106 0.824 >> -192.168.0.3 .kPPS. 1 u 13 32 377 21.366 -4.524 0.804 >> +192.168.0.83 .kPPS. 1 u 27 32 377 21.614 -4.511 1.206 >> uk.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.001 >> -193.150.34.2 133.150.251.233 3 u 38 64 137 32.343 2.738 1.477 >> -80.87.128.17 94.125.129.7 3 u 30 64 375 53.337 -1.225 1.516 >> -192.146.137.13 82.148.230.254 2 u 56 64 377 46.089 2.220 2.535 >> -129.250.35.250 249.224.99.213 2 u 169 64 214 42.499 -3.015 >> 12.507 >> -213.130.44.252 145.238.203.14 2 u 487 64 200 37.210 -0.725 >> 13.232 >> >> 73, >> David GM8ARV >> -- >> SatSignal Software - Quality software written to your requirements >> Web: http://www.satsignal.eu >> Email: david-taylor@blueyonder.co.uk >> Twitter: @gm8arv >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > > -- > > Chris Albertson > Redondo Beach, California -- Chris Albertson Redondo Beach, California