[time-nuts] ``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards

[Mike Cook]

> Le 16 févr. 2017 à 04:09, MLewis <mlewis000 at 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 at 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 at 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