-------- In message <calvmchlqrgr0-j6w-8u11g-o94ouk7eamdys2x2079+nhkh...@mail.gmail.com>, Michael Shield s via LEAPSECS writes:
>> 3) Speed of smearing? >> The existing approaches have two broad groups - fast (under an hour - >> Bloomberg/UTC-SLS) and slow (20 hours or more - Google/Amazon) with >> QTnet an outlier towards the fast end. > >I expect a smear of 2000 s or less would be challenging for NTP >clients, because of the 500 ppm max slew rate, which would be entirely >consumed by tracking the smear. Clients that have backed off to 1024 >s polling would also have trouble noticing that a smear was happening >when the smear is only 1000 s or 2000 s long. It is much worse than that: You need to account for the delay in the median filter, which on straight slopes is typically 4 poll intervals. For a well-running client, that means it won't even start to pay attention to the smear from the server until after 4096 seconds, at which time it will start to look at a 1024 or 2048 second old sample. Once fully on the slope of the smear, the median filter will run 4096 seconds "behind" and once the smear is over, it will overshoot in similar fashion. >Besides being easier for NTP clients to track, a slow smear has the >advantage [...] Ohh, and don't forget: DCF77 only announces the smear one hour in advance. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
