> 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.

Reply via email to