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

Thu Feb 16 08:46:25 EST 2017

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.cook at sfr.fr> wrote:
> 
> 
>> 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
> 
> _______________________________________________
> 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.