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.
