[time-nuts] Serial port server .. any interest in a write up on using ?

Bob Camp lists at rtty.us
Thu May 24 00:35:55 UTC 2012


Hi

Ok, at least now we are down to some numbers. Ever taken a look at NTP on a Windows box running serial? It's not anywhere near a microsecond….

Bob


On May 23, 2012, at 6:47 PM, Chris Albertson wrote:

> On Wed, May 23, 2012 at 2:59 PM, Bob Camp <lists at rtty.us> wrote:
>> Hi
>> 
>> Ok, to be 1000: 1, you would take the 0.2 to 0.5 ms that you see on the LAN and take it up to 200 to 500ms. That's *way* worse than anything I have ever seen for a serial server over a LAN.
> 
> Yes, 200 ms would be insanely poor.  NTP with a direct connected GPS
> can run the micro second level.  The 100x to 1000x worse I'm talking
> about puts NTP at the 0.5 to 1.0 ms level.
> 
> With PPS connected directly to the DCD line on a Linux based server
> the hardware counter is captured with a typical error of 1 micro
> second.    Over the LAN or USB we see this error at about 1 or 2
> milliseconds     So what I'm saying is by using the LAN you give up
> micro seconds for milliseconds or about a factor of 1000.    You are
> right.  It is never anything at all like 200 ms.   We get better than
> 200 ms error over the Internet from servers 1,000 miles away.
> 
> In general you should expect a 1 uSec level error from a direct
> connect to from a GPS's PPS to the DCD line of a serial port and a
> mSec level error from USB or LAN and tens of ms error from an Internet
> connection.
> 
> Where NTP really shines is extracting 10ms level timing from an
> unreliable connection that has much longer then 10ms delay.   It
> really is not so impressive that it can get u-sec level performance
> from a directly connected Trimble Thunderbolt.  The bottle neck is the
> PC hardware.   You really never can do better then 1 uS with a generic
> PC.
> 
> 
> 
>> 
>> Bob
>> 
>> On May 23, 2012, at 5:15 PM, Chris Albertson wrote:
>> 
>>> On Wed, May 23, 2012 at 2:02 PM, Bob Camp <lists at rtty.us> wrote:
>>>> Hi
>>>> 
>>>> What ever degradation the serial stream sees on the LAN, the resulting NTP
>>>> output will see once it's on the same LAN. It's unlikely you will see more
>>>> than a 2:1 net degradation no matter what is going on. The flywheel in the
>>>> NTP algorithm will likely help you in this case to actually improve things a
>>>> bit.
>>> 
>>> Have you actually tried this and measured?  2:1 is very optimistic.
>>> Typically it is 1000:1 or worse
>>> 
>>> But you are right that it may not matter.  For most uses if the
>>> computer's clock is correct at the 0.1 second level they are happy.
>>> but this is a "time nut" mailing list and some of us like to get NTP
>>> to run at the uSecond level.  Useless as that might be.
>>> 
>>> 
>>> 
>>> Chris Albertson
>>> Redondo Beach, California
>>> 
>>> _______________________________________________
>>> 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.
>> 
>> 
>> _______________________________________________
>> 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.
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> 
> _______________________________________________
> 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.





More information about the Time-nuts_lists.febo.com mailing list