Re: [time-nuts] TimeKeeper?
On Mon, Feb 22, 2010 at 5:03 PM, Hal Murray hmur...@megapathdsl.net wrote: That said NTP is very conservative in validating the stability of clock sources. I have not delved into the code, but it is obvious that even a refclock like a GPS receiver doesn't get any favours. Why should it? Who knows whether the clock is dodgy or not? The NMEA strings from low cost GPS units have a lot of noise/jitter. In particular, the SiRF units are horrible. (They are also low cost and widely available.) The time offset has a sawtooth pattern with a long time constant that would be nasty to filter out. Think of hanging bridges. http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif However the times he was reporting for the offsets to drop to less than 1ms did look excessive. I've seen lots of comments about ntpd being slow to converge. I haven't investigated carefully, but they seem credible. One way to get in trouble is to have a bad drift file. You can get that if you have a warm system, shut it down, wait for it to cool off, then restart it. I was not trying to start a fire and I personally don't have experience with TimeKeeper which seems to be a framework to make use of the TSC as we all would like to use it (despite P/C-state invariants, there have been countless threads on all the major *NIX kernel lists that have argued to use and not use TSC for ticking). Bad drift files aside, I have now played around with both an Endrun Technologies CDMA receiver as well as some other proprietary units and I have found that no matter what ntpd reference drivers I used (Palisade/Trimple come to mine), I have seen *many* instances of ntpd doing wacky things and taking several hours to converge. I never really investigated why this was so and without looking at source code attributed to ntpd doing exactly what you described Hal: Using a very conservative approach to validate the stability of the clock. Also, TimeKeeper seems to predict time a bit if I understand what they are doing (which I don't fully) while ntpd tries to skew toward absolute time (UTC). -aps ___ 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.
Re: [time-nuts] TimeKeeper?
Le 22/02/2010 03:02, Alexander Sack a écrit : Has anyone seen this: http://www.drdobbs.com/linux-open-source/223000197;jsessionid=LEYQTVQD4D24TQE1GHPCKH4ATMY32JVN?pgno=1 Excuse if its been talked about but I don't see it in my mail archives. I thought some of the ntpd'ers on this list might be interested. -aps ___ 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. Am I cynical in thinking that the article is just product sales pitch? The writer has not been objective in using realistic NTP configurations and practices by taking the worst case , where neither the local oscillator drift is known (deleting the drift file)nor the local clock value at NTP startup is near reality (deliberate offset ). No one is going to either remove their drift file without good reason, nor allow arbitrairy local clock values at startup. That said NTP is very conservative in validating the stability of clock sources. I have not delved into the code, but it is obvious that even a refclock like a GPS receiver doesn't get any favours. Why should it? Who knows whether the clock is dodgy or not? However the times he was reporting for the offsets to drop to less than 1ms did look excessive. Anyway, just to see if I was seeing a similar profile, I did a stop/start on a Soekris server/client pair . I don't have the same software/hardware config but that shouldn't make a huge difference. ntp is 4.2.0 on FreeBSD 6.2 no fancy hardware. Motorola Oncore UT+ on COM2 reset server conf to sample JUST its UT+ PPS receiver. using the oncore driver out of the box. stopped daemons backed up then removed the /etc/ntp/drift file removed all the loopstat/peerstat logs shifted the system clock down 500ms on both client and server restarted the server daemon wait 30s restart the client daemon Then checked how long client / server got back to a 1ms offset From this test it took the server approx 600secs to get to an offset less than 1ms. The client, started 30secs after the server was sync'd to the same offset shortly afterwards. Not brilliant, but not as bad as those stats shown in the article for linux. I then did a restart with the original drift files and a clock estimate from ntpdate directed at NIST. This is a more realistic event. since even in the event of a system crash, that data is available. Even then, it is a bit unusual for both client and server to be restarted at the same time. In this case, the ntp server was serving with an offset of less than 1ms after 2 mins and the client sync'd just about as fast. So in more realistic ;), one refclock scenario NTP can still get down to a reasonable accuracy in good time after a restart and in a similar timeframe to Timekeeper. ___ 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.
Re: [time-nuts] TimeKeeper?
That said NTP is very conservative in validating the stability of clock sources. I have not delved into the code, but it is obvious that even a refclock like a GPS receiver doesn't get any favours. Why should it? Who knows whether the clock is dodgy or not? The NMEA strings from low cost GPS units have a lot of noise/jitter. In particular, the SiRF units are horrible. (They are also low cost and widely available.) The time offset has a sawtooth pattern with a long time constant that would be nasty to filter out. Think of hanging bridges. http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif However the times he was reporting for the offsets to drop to less than 1ms did look excessive. I've seen lots of comments about ntpd being slow to converge. I haven't investigated carefully, but they seem credible. One way to get in trouble is to have a bad drift file. You can get that if you have a warm system, shut it down, wait for it to cool off, then restart it. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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.
Re: [time-nuts] TimeKeeper?
Hi If the objective is convergence to 1 ms any timing optimized gps receiver will do just fine. Non-timing receivers are going to do all sorts of bizarre things every so often. I don't think we can blame this all on the GPS. The NTP setup he's running in the article is broken. Setting the proper time offset for the GPS you have is part of basic configuration. He alludes to several other setup issues in his distribution. NTP is deliberately damped when things are messed up. Looking at the data, Timekeeper is going to do some really strange things when varying asymmetric delays are involved. That's what NTP is trying to *not* do Bob -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Hal Murray Sent: Monday, February 22, 2010 5:03 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] TimeKeeper? That said NTP is very conservative in validating the stability of clock sources. I have not delved into the code, but it is obvious that even a refclock like a GPS receiver doesn't get any favours. Why should it? Who knows whether the clock is dodgy or not? The NMEA strings from low cost GPS units have a lot of noise/jitter. In particular, the SiRF units are horrible. (They are also low cost and widely available.) The time offset has a sawtooth pattern with a long time constant that would be nasty to filter out. Think of hanging bridges. http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif However the times he was reporting for the offsets to drop to less than 1ms did look excessive. I've seen lots of comments about ntpd being slow to converge. I haven't investigated carefully, but they seem credible. One way to get in trouble is to have a bad drift file. You can get that if you have a warm system, shut it down, wait for it to cool off, then restart it. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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. ___ 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.
Re: [time-nuts] TimeKeeper?
Just to add a little fuel...Did I count the leading zeros incorrectly? He often stated Timekeeper was better than 1 uSec, yet many of his graphs were 10 uSec per division, and he barely made that. Regards, Tom Holmes, N8ZM Tipp City, OH EM79xx -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob Camp Sent: Monday, February 22, 2010 5:22 PM To: 'Discussion of precise time and frequency measurement' Subject: Re: [time-nuts] TimeKeeper? Hi If the objective is convergence to 1 ms any timing optimized gps receiver will do just fine. Non-timing receivers are going to do all sorts of bizarre things every so often. I don't think we can blame this all on the GPS. The NTP setup he's running in the article is broken. Setting the proper time offset for the GPS you have is part of basic configuration. He alludes to several other setup issues in his distribution. NTP is deliberately damped when things are messed up. Looking at the data, Timekeeper is going to do some really strange things when varying asymmetric delays are involved. That's what NTP is trying to *not* do Bob -Original Message- From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On Behalf Of Hal Murray Sent: Monday, February 22, 2010 5:03 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] TimeKeeper? That said NTP is very conservative in validating the stability of clock sources. I have not delved into the code, but it is obvious that even a refclock like a GPS receiver doesn't get any favours. Why should it? Who knows whether the clock is dodgy or not? The NMEA strings from low cost GPS units have a lot of noise/jitter. In particular, the SiRF units are horrible. (They are also low cost and widely available.) The time offset has a sawtooth pattern with a long time constant that would be nasty to filter out. Think of hanging bridges. http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif However the times he was reporting for the offsets to drop to less than 1ms did look excessive. I've seen lots of comments about ntpd being slow to converge. I haven't investigated carefully, but they seem credible. One way to get in trouble is to have a bad drift file. You can get that if you have a warm system, shut it down, wait for it to cool off, then restart it. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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. ___ 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. ___ 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.
