Hi Whatever you do on the server, the same impacts will be felt on the client side. You may be able to do this or that on a server to allocate resources. On a client workstation, resource allocation is likely to be a bit more difficult. You may not even have control over which OS is being used. ( = other factors may dictate it’s Windows 10, or OS-X or …). When a big video processing blob comes along, the workstation likely ignores NTP for a while.
Bob > On Feb 16, 2017, at 7:05 AM, Mike Cook <michael.c...@sfr.fr> wrote: > > >> Le 16 févr. 2017 à 04:09, MLewis <mlewis...@rogers.com> a écrit : >> >> On 15/02/2017 1:17 PM, Chris Albertson wrote: >>> Why set up a dedicated NTP server if you only have two computers that will >>> use it? ... You could save some money and just run NTP on the two >>> computers. ... NTP is almost zero load on the CPU and the best thing is the >>> NTP accuracy is not effected by CPU load… > > This is not strictly true in all scenarios as the NTP thread has to be able > to get to a cpu to be able to do its thing. Higher priority, or CPU intensive > threads can starve it. > > Here is the result of a little test on a 700MHz clocked 4 core uP running > linux with usual utilities NTP, cron whatever, but no apps . No priority or > core dedication implemented. > The uP is running NTP with two GPS sync’d servers at stratum 1 on the LAN > plus 5 stratum 2 pool servers. poll time 64 secs for all. > > 1. Check the clock offset of the DUT as reported by ntpdate -d with the DUT > idle. > mike@muon /usr/home/mike $ ntpdate -d rasp3b1 2> /dev/null | grep adjust > 16 Feb 11:17:46 ntpdate[11566]: adjust time server 192.168.1.157 offset > -0.000086 sec > 16 Feb 11:19:32 ntpdate[11569]: adjust time server 192.168.1.157 offset > -0.000085 sec > 16 Feb 11:21:18 ntpdate[11587]: adjust time server 192.168.1.157 offset > -0.000082 sec > 16 Feb 11:23:05 ntpdate[11590]: adjust time server 192.168.1.157 offset > -0.000054 sec > 16 Feb 11:24:51 ntpdate[11593]: adjust time server 192.168.1.157 offset > -0.000028 sec > 16 Feb 11:26:37 ntpdate[11611]: adjust time server 192.168.1.157 offset > 0.000008 sec > 16 Feb 11:28:24 ntpdate[11614]: adjust time server 192.168.1.157 offset > 0.000026 sec > 16 Feb 11:30:10 ntpdate[11632]: adjust time server 192.168.1.157 offset > 0.000059 sec > 2. Start up 4 cpu soaker threads - in this case calculating pi to 10000 > places. > 11:31:00 4 cpu soakers started on rasp3b1 > 3. Continue checking clock offsets. > 16 Feb 11:33:42 ntpdate[11638]: adjust time server 192.168.1.157 offset > -0.000089 sec > 16 Feb 11:35:29 ntpdate[11656]: adjust time server 192.168.1.157 offset > -0.000235 sec > 16 Feb 11:37:15 ntpdate[11659]: adjust time server 192.168.1.157 offset > -0.000393 sec > 16 Feb 11:39:01 ntpdate[11662]: adjust time server 192.168.1.157 offset > -0.000512 sec > 16 Feb 11:40:48 ntpdate[11680]: adjust time server 192.168.1.157 offset > -0.000547 sec > 16 Feb 11:42:34 ntpdate[11683]: adjust time server 192.168.1.157 offset > -0.000492 sec > 16 Feb 11:44:20 ntpdate[11686]: adjust time server 192.168.1.157 offset > -0.000438 sec > 16 Feb 11:46:07 ntpdate[11704]: adjust time server 192.168.1.157 offset > -0.000397 sec > 16 Feb 11:47:53 ntpdate[11709]: adjust time server 192.168.1.157 offset > -0.000393 sec > 16 Feb 11:49:39 ntpdate[11712]: adjust time server 192.168.1.157 offset > -0.000357 sec > 16 Feb 11:51:26 ntpdate[11730]: adjust time server 192.168.1.157 offset > -0.000206 sec > > As you can see the reported clock offset increases to a max 0,5ms due to the > load on the DUT. That is within the OPs limit so he should be ok but for > others that may be too much of a hit. > > 4. wait till the processes stop > They all ended normally at Thu 16 Feb 12:04:36 UTC 2017 > 5. While continuing to check the offsets as reported by ntpdate > 16 Feb 12:00:17 ntpdate[11775]: adjust time server 192.168.1.157 offset > 0.000153 sec > 16 Feb 12:02:03 ntpdate[11778]: adjust time server 192.168.1.157 offset > 0.000188 sec > 16 Feb 12:03:50 ntpdate[11781]: adjust time server 192.168.1.157 offset > 0.000203 sec > 16 Feb 12:05:36 ntpdate[11799]: adjust time server 192.168.1.157 offset > 0.000126 sec > 16 Feb 12:07:22 ntpdate[11802]: adjust time server 192.168.1.157 offset > 0.000092 sec > 16 Feb 12:09:09 ntpdate[11805]: adjust time server 192.168.1.157 offset > 0.000096 sec > 16 Feb 12:10:55 ntpdate[11823]: adjust time server 192.168.1.157 offset > 0.000051 sec > 16 Feb 12:12:41 ntpdate[11826]: adjust time server 192.168.1.157 offset > 0.000008 sec > 16 Feb 12:14:28 ntpdate[11829]: adjust time server 192.168.1.157 offset > 0.000002 sec > 16 Feb 12:16:14 ntpdate[11847]: adjust time server 192.168.1.157 offset > -0.000016 sec > 16 Feb 12:18:00 ntpdate[11852]: adjust time server 192.168.1.157 offset > 0.000007 sec > 16 Feb 12:19:46 ntpdate[11855]: adjust time server 192.168.1.157 offset > 0.000009 sec > 16 Feb 12:21:33 ntpdate[11873]: adjust time server 192.168.1.157 offset > 0.000012 sec > > back to normal status. > > The test is not supposed to be an all inclusive and YMMV. > There are probably methods, such a configuring detected cores for NTP , > increasing its priority, and maybe increasing the poll interval that can > mitigate the effect. > I’ll try that to see what I get. > >> >> To be able to move forward with my original application: >> By going to a separate box running NTP and a GPS reference, I will have a >> reference time that is entirely independent from whatever is going on with >> my working box. With microsecond accuracy and precision, it will be more >> than sufficient for my needs. With a dedicated ethernet connection between >> the working box and the NTP box, NTP on the working box should be able to >> have system time within 1 ms of that reference. If it's observed that isn't >> happening, then I'll remove NTP from the working box and I already have code >> than can monitor the system time against the NTP box and reset it every time >> it lags more than 1 ms. Brute and crude, but it will work for keeping my >> application within 1ms. > > Toi should be ok if you see a similar profile. > Just to note that on my DUT prior to the 100% load the clock drift as > reported by NTP was -6,5ppm . Without NTP or other disciplining a 1ms offset > would have been reached in 108 secs. > >> >> Or, so I think... >> I've been surprised and changed direction enough times since I headed down >> this time rabbit-hole. >> >> Michael >> >> _______________________________________________ >> 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. > > "The power of accurate observation is commonly called cynicism by those who > have not got it. » > George Bernard Shaw > > _______________________________________________ > 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.
