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

[Chris Albertson]

You are plotting "offset".  This is simply the communications path
delay.   It does not measure your system's deviation from UTC.   NTP
takes into consideration the offset.

Here is the way to understand what NTP does with offset.   Let's say
we lived 200 years ago and wanted to set a grandfather clock to match
the one in your friend's house and you have no other clocks.  Let's
say the friend lives one mile away.    The best option is to walk
round trips to your friend's house and measure the time and standard
deviation of the round trip time.  Divide this time in half and call
it "offset".   Then walk to your friend's house, write down the time
and take it home.  Set your clock to this time PLUS the offset.

What you care about is the uncertainty of this process NOT the offset
but the standard deviation of the offset.



On Sat, Feb 18, 2017 at 1:53 AM, David J Taylor
 wrote:
> Hi,
>
> I was wondering whether there is some data/information available on the
> claimed +/- 100 ns jitter?
>
> Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
> plotted, using some lines of Python, the time offset as attached. Just
> to get an overview how it is 'worst case', i.e., user program, python,
> etc. The 1PPS signal comes from a GPS rx.
> Looks like a standard deviation of around 150 us.
> y-axis:  measured pps offset from full second (computer time) in us,
> x-axis pps pulse number.
>
> On the long term it looks interesting (while measuring I played with the
> NTP server on this computer)
> Until ca. second 1: ntpd synchronization via internet
> Until ca. second 17000: made an additional LAN NTP server (GPS) available
> Until the end: replaced ntpd with chrony (still using internet and local
> servers)
>
> Interesting points:
> -It looks surprisingly bad with using the normal ntpd (especially, there
> is not really an improvement having an local GPS based server
> available, did I do something wrong? Only the offset changes by ca. 3
> ms.)
> -It looks surprisingly good with chrony. But there are continuously
> outliers of up to 4500 us, is this a result of the chrony control loop?
> The time is wandering around with ntpd, but has less jitter.
>
> Conclusion:
> Despite the 150 us stddev, the using PPS over USB gives some interesting
> inside of what the local ntp server is actually doing. It looks to me
> like it would be an improvement to use it when using ntpd, but not when
> using chrony.
>
> Best regards,
>   Thomas
>   DK6KD
>   SA6CID
>
> PS:
> Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
> offset in us)
> http://petig.eu/pps-usb.txt
> =
>
> Thomas,
>
> I've done some tests with PPS over USB with Windows some time back, which
> showed that PPS?USB could be better than LAN-sync alone, but that also
> included a reduction of the poll interval from possibly 64 seconds for LAN
> sync to 16 seconds for PPS sync, which may have influenced the results.
>
> It would be helpful to have some units on the axes - 1 what?
> I'm guessing microseconds
>
> For comparison, here is a Raspberry Pi running NTP, with the reported offset
> plotted against time.
>
>  http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
>
> This Raspberry Pi (running a seismic detector) is using an Ethernet
> connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a
> couple of switches to a very good stratum-1 server.  I would estimate from
> your graph that the jitter in offset is about 1 millisecond peak-to-peak,
> but it seems that I get less than that - perhaps 100 microseconds
> peak-to-peak with occasional excursions outside that.  This is with the
> latest reference version of NTP.
>
> remote   refid  st t when poll reach   delay   offset jitter
> ==
> *192.168.0.20.GPS.1 u   17   32  377   12.3510.000 0.428
> +192.168.0.11.uPPS.   1 u2   32  377   12.432   -0.106 0.824
> -192.168.0.3 .kPPS.   1 u   13   32  377   21.366   -4.524 0.804
> +192.168.0.83.kPPS.   1 u   27   32  377   21.614   -4.511 1.206
> uk.pool.ntp.org .POOL.  16 p-   6400.0000.000 0.001
> -193.150.34.2133.150.251.233  3 u   38   64  137   32.3432.738 1.477
> -80.87.128.1794.125.129.7 3 u   30   64  375   53.337   -1.225 1.516
> -192.146.137.13  82.148.230.254   2 u   56   64  377   46.0892.220 2.535
> -129.250.35.250  249.224.99.213   2 u  169   64  214   42.499   -3.015
> 12.507
> -213.130.44.252  145.238.203.14   2 u  487   64  200   37.210   -0.725
> 13.232
>
> 73,
> David GM8ARV
> --
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To 

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

[Chris Albertson]

Sorry, I conflated terms.   NTP uses offset and delay differently.  In
NTP speak "delay" is the round trip time.  "offset" is the difference
from local system clock to reference clock after accounting for delay.
   It is like cause by asymmetric trans time.

But still, I think my main point is correct:  what you care about in
the uncertainty in the process, not the numbers like delay and offset,
it's the error bars in those numbers

On Sat, Feb 18, 2017 at 9:14 AM, Chris Albertson
 wrote:
> You are plotting "offset".  This is simply the communications path
> delay.   It does not measure your system's deviation from UTC.   NTP
> takes into consideration the offset.
>
> Here is the way to understand what NTP does with offset.   Let's say
> we lived 200 years ago and wanted to set a grandfather clock to match
> the one in your friend's house and you have no other clocks.  Let's
> say the friend lives one mile away.    The best option is to walk
> round trips to your friend's house and measure the time and standard
> deviation of the round trip time.  Divide this time in half and call
> it "offset".   Then walk to your friend's house, write down the time
> and take it home.  Set your clock to this time PLUS the offset.
>
> What you care about is the uncertainty of this process NOT the offset
> but the standard deviation of the offset.
>
>
>
> On Sat, Feb 18, 2017 at 1:53 AM, David J Taylor
>  wrote:
>> Hi,
>>
>> I was wondering whether there is some data/information available on the
>> claimed +/- 100 ns jitter?
>>
>> Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
>> plotted, using some lines of Python, the time offset as attached. Just
>> to get an overview how it is 'worst case', i.e., user program, python,
>> etc. The 1PPS signal comes from a GPS rx.
>> Looks like a standard deviation of around 150 us.
>> y-axis:  measured pps offset from full second (computer time) in us,
>> x-axis pps pulse number.
>>
>> On the long term it looks interesting (while measuring I played with the
>> NTP server on this computer)
>> Until ca. second 1: ntpd synchronization via internet
>> Until ca. second 17000: made an additional LAN NTP server (GPS) available
>> Until the end: replaced ntpd with chrony (still using internet and local
>> servers)
>>
>> Interesting points:
>> -It looks surprisingly bad with using the normal ntpd (especially, there
>> is not really an improvement having an local GPS based server
>> available, did I do something wrong? Only the offset changes by ca. 3
>> ms.)
>> -It looks surprisingly good with chrony. But there are continuously
>> outliers of up to 4500 us, is this a result of the chrony control loop?
>> The time is wandering around with ntpd, but has less jitter.
>>
>> Conclusion:
>> Despite the 150 us stddev, the using PPS over USB gives some interesting
>> inside of what the local ntp server is actually doing. It looks to me
>> like it would be an improvement to use it when using ntpd, but not when
>> using chrony.
>>
>> Best regards,
>>   Thomas
>>   DK6KD
>>   SA6CID
>>
>> PS:
>> Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
>> offset in us)
>> http://petig.eu/pps-usb.txt
>> =
>>
>> Thomas,
>>
>> I've done some tests with PPS over USB with Windows some time back, which
>> showed that PPS?USB could be better than LAN-sync alone, but that also
>> included a reduction of the poll interval from possibly 64 seconds for LAN
>> sync to 16 seconds for PPS sync, which may have influenced the results.
>>
>> It would be helpful to have some units on the axes - 1 what?
>> I'm guessing microseconds
>>
>> For comparison, here is a Raspberry Pi running NTP, with the reported offset
>> plotted against time.
>>
>>  http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
>>
>> This Raspberry Pi (running a seismic detector) is using an Ethernet
>> connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a
>> couple of switches to a very good stratum-1 server.  I would estimate from
>> your graph that the jitter in offset is about 1 millisecond peak-to-peak,
>> but it seems that I get less than that - perhaps 100 microseconds
>> peak-to-peak with occasional excursions outside that.  This is with the
>> latest reference version of NTP.
>>
>> remote   refid  st t when poll reach   delay   offset jitter
>> ==
>> *192.168.0.20.GPS.1 u   17   32  377   12.3510.000 0.428
>> +192.168.0.11.uPPS.   1 u2   32  377   12.432   -0.106 0.824
>> -192.168.0.3 .kPPS.   1 u   13   32  377   21.366   -4.524 0.804
>> +192.168.0.83.kPPS.   1 u   27   32  377   21.614   -4.511 1.206
>> uk.pool.ntp.org .POOL.  16 p-   6400.0000.000 0.001
>> -193.150.34.2133.150.251.233  3 u   38   64  137   

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

[Bob Camp]

Hi

The point is that some chip sets have better access to timer / counters than 
others do.
One of the Soekris (sp?) boards is an example of this. We also are moving into 
an era where
fairly fancy ARM CPU’s are grafted onto FPGA’s. Once you have that, you are no 
longer
dependent on somebody else to brew up the peripheral you need. 

Bob



> On Feb 18, 2017, at 10:45 AM, Thomas Petig  wrote:
> 
> Hi Bob,
> 
> On Sat, Feb 18, 2017 at 08:36:51AM -0500, Bob Camp wrote:
>> Hi
>> 
>>> On Feb 18, 2017, at 4:53 AM, David J Taylor  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> I was wondering whether there is some data/information available on the
>>> claimed +/- 100 ns jitter?
>> 
>> 
>> I guess the previous was not complete enough.
>> 
>> I routinely measure PPS jitter on GPS modules down well below 10 ns on a 
>> 53131.
>> That’s after sawtooth correction is applied. Without sawtooth correction, 
>> the +/- 24
>> or +/- 12 or +/- 1.25 ns of the sawtooth adds into that.
>> 
>> The reference used is an HP 5071 with a high performance tube option.
> 
> I agree, in this setup we get this performance. I also agree that using
> timers in capture mode on microprocessors will give this performance, as
> you wrote before.
> 
> But as we where discussing the performance between capturing some PPS
> via PCIe, serial i/o from the chipset, or some USB cable. The reference
> clock is here the clock of the CPU, or OS. This clock is of course not
> very precise, but the reason for capturing the PPS might be we want to
> run some NTP server.
> 
> So, I thought actually of the jitter added on the way between our
> accurate source (GPS rx), until we can capture our timer. How much can
> this be? As far as I see we don't have a capture mode for the HPET. But,
> if we have to do it in software, we get more than 100 ns jitter. I just
> measured 60-80 ns for a instruction cache miss, with Intels mlc software.
> Overall I would guess > 500 ns, are there measurements on this?
> 
> This then defines some lower bound of what can be archived for
> synchronizing the clock off the OS. Also hardware time stamping on a
> dedicated PPS card (or PTP ethernet card) does not help unless the clock
> on the card is synchronized to the clock used by the OS.
> 
> So, can we do better?
> 
> Best regards,
>Thomas
>DK6KD
>SA6CID
> 
>> 
> 
>> Bob
>> 
>>> 
>>> Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
>>> plotted, using some lines of Python, the time offset as attached. Just
>>> to get an overview how it is 'worst case', i.e., user program, python,
>>> etc. The 1PPS signal comes from a GPS rx.
>>> Looks like a standard deviation of around 150 us.
>>> y-axis:  measured pps offset from full second (computer time) in us,
>>> x-axis pps pulse number.
>>> 
>>> On the long term it looks interesting (while measuring I played with the
>>> NTP server on this computer)
>>> Until ca. second 1: ntpd synchronization via internet
>>> Until ca. second 17000: made an additional LAN NTP server (GPS) available
>>> Until the end: replaced ntpd with chrony (still using internet and local
>>> servers)
>>> 
>>> Interesting points:
>>> -It looks surprisingly bad with using the normal ntpd (especially, there
>>> is not really an improvement having an local GPS based server
>>> available, did I do something wrong? Only the offset changes by ca. 3
>>> ms.)
>>> -It looks surprisingly good with chrony. But there are continuously
>>> outliers of up to 4500 us, is this a result of the chrony control loop?
>>> The time is wandering around with ntpd, but has less jitter.
>>> 
>>> Conclusion:
>>> Despite the 150 us stddev, the using PPS over USB gives some interesting
>>> inside of what the local ntp server is actually doing. It looks to me
>>> like it would be an improvement to use it when using ntpd, but not when
>>> using chrony.
>>> 
>>> Best regards,
>>> Thomas
>>> DK6KD
>>> SA6CID
>>> 
>>> PS:
>>> Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
>>> offset in us)
>>> http://petig.eu/pps-usb.txt
>>> =
>>> 
>>> Thomas,
>>> 
>>> I've done some tests with PPS over USB with Windows some time back, which 
>>> showed that PPS?USB could be better than LAN-sync alone, but that also 
>>> included a reduction of the poll interval from possibly 64 seconds for LAN 
>>> sync to 16 seconds for PPS sync, which may have influenced the results.
>>> 
>>> It would be helpful to have some units on the axes - 1 what? 
>>> I'm guessing microseconds
>>> 
>>> For comparison, here is a Raspberry Pi running NTP, with the reported 
>>> offset plotted against time.
>>> 
>>> http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
>>> 
>>> This Raspberry Pi (running a seismic detector) is using an Ethernet 
>>> connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a 
>>> couple of switches to a very good stratum-1 server.  I would estimate from 
>>> 

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

[Thomas Petig]

Hi Bob,

On Sat, Feb 18, 2017 at 08:36:51AM -0500, Bob Camp wrote:
> Hi
>
> > On Feb 18, 2017, at 4:53 AM, David J Taylor  
> > wrote:
> >
> > Hi,
> >
> > I was wondering whether there is some data/information available on the
> > claimed +/- 100 ns jitter?
>
>
> I guess the previous was not complete enough.
>
> I routinely measure PPS jitter on GPS modules down well below 10 ns on a 
> 53131.
> That’s after sawtooth correction is applied. Without sawtooth correction, the 
> +/- 24
> or +/- 12 or +/- 1.25 ns of the sawtooth adds into that.
>
> The reference used is an HP 5071 with a high performance tube option.

I agree, in this setup we get this performance. I also agree that using
timers in capture mode on microprocessors will give this performance, as
you wrote before.

But as we where discussing the performance between capturing some PPS
via PCIe, serial i/o from the chipset, or some USB cable. The reference
clock is here the clock of the CPU, or OS. This clock is of course not
very precise, but the reason for capturing the PPS might be we want to
run some NTP server.

So, I thought actually of the jitter added on the way between our
accurate source (GPS rx), until we can capture our timer. How much can
this be? As far as I see we don't have a capture mode for the HPET. But,
if we have to do it in software, we get more than 100 ns jitter. I just
measured 60-80 ns for a instruction cache miss, with Intels mlc software.
Overall I would guess > 500 ns, are there measurements on this?

This then defines some lower bound of what can be archived for
synchronizing the clock off the OS. Also hardware time stamping on a
dedicated PPS card (or PTP ethernet card) does not help unless the clock
on the card is synchronized to the clock used by the OS.

So, can we do better?

Best regards,
Thomas
DK6KD
SA6CID

>

> Bob
>
> >
> > Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
> > plotted, using some lines of Python, the time offset as attached. Just
> > to get an overview how it is 'worst case', i.e., user program, python,
> > etc. The 1PPS signal comes from a GPS rx.
> > Looks like a standard deviation of around 150 us.
> > y-axis:  measured pps offset from full second (computer time) in us,
> > x-axis pps pulse number.
> >
> > On the long term it looks interesting (while measuring I played with the
> > NTP server on this computer)
> > Until ca. second 1: ntpd synchronization via internet
> > Until ca. second 17000: made an additional LAN NTP server (GPS) available
> > Until the end: replaced ntpd with chrony (still using internet and local
> > servers)
> >
> > Interesting points:
> > -It looks surprisingly bad with using the normal ntpd (especially, there
> > is not really an improvement having an local GPS based server
> > available, did I do something wrong? Only the offset changes by ca. 3
> > ms.)
> > -It looks surprisingly good with chrony. But there are continuously
> > outliers of up to 4500 us, is this a result of the chrony control loop?
> > The time is wandering around with ntpd, but has less jitter.
> >
> > Conclusion:
> > Despite the 150 us stddev, the using PPS over USB gives some interesting
> > inside of what the local ntp server is actually doing. It looks to me
> > like it would be an improvement to use it when using ntpd, but not when
> > using chrony.
> >
> > Best regards,
> >  Thomas
> >  DK6KD
> >  SA6CID
> >
> > PS:
> > Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
> > offset in us)
> > http://petig.eu/pps-usb.txt
> > =
> >
> > Thomas,
> >
> > I've done some tests with PPS over USB with Windows some time back, which 
> > showed that PPS?USB could be better than LAN-sync alone, but that also 
> > included a reduction of the poll interval from possibly 64 seconds for LAN 
> > sync to 16 seconds for PPS sync, which may have influenced the results.
> >
> > It would be helpful to have some units on the axes - 1 what? 
> > I'm guessing microseconds
> >
> > For comparison, here is a Raspberry Pi running NTP, with the reported 
> > offset plotted against time.
> >
> > http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
> >
> > This Raspberry Pi (running a seismic detector) is using an Ethernet 
> > connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a 
> > couple of switches to a very good stratum-1 server.  I would estimate from 
> > your graph that the jitter in offset is about 1 millisecond peak-to-peak, 
> > but it seems that I get less than that - perhaps 100 microseconds 
> > peak-to-peak with occasional excursions outside that.  This is with the 
> > latest reference version of NTP.
> >
> >remote   refid  st t when poll reach   delay   offset jitter
> > ==
> > *192.168.0.20.GPS.1 u   17   32  377   12.3510.000 0.428
> > 

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

[Bob Camp]

Hi

> On Feb 18, 2017, at 4:53 AM, David J Taylor  
> wrote:
> 
> Hi,
> 
> I was wondering whether there is some data/information available on the
> claimed +/- 100 ns jitter?


I guess the previous was not complete enough.

I routinely measure PPS jitter on GPS modules down well below 10 ns on a 53131. 
That’s after sawtooth correction is applied. Without sawtooth correction, the 
+/- 24 
or +/- 12 or +/- 1.25 ns of the sawtooth adds into that.

The reference used is an HP 5071 with a high performance tube option. 

Bob

> 
> Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
> plotted, using some lines of Python, the time offset as attached. Just
> to get an overview how it is 'worst case', i.e., user program, python,
> etc. The 1PPS signal comes from a GPS rx.
> Looks like a standard deviation of around 150 us.
> y-axis:  measured pps offset from full second (computer time) in us,
> x-axis pps pulse number.
> 
> On the long term it looks interesting (while measuring I played with the
> NTP server on this computer)
> Until ca. second 1: ntpd synchronization via internet
> Until ca. second 17000: made an additional LAN NTP server (GPS) available
> Until the end: replaced ntpd with chrony (still using internet and local
> servers)
> 
> Interesting points:
> -It looks surprisingly bad with using the normal ntpd (especially, there
> is not really an improvement having an local GPS based server
> available, did I do something wrong? Only the offset changes by ca. 3
> ms.)
> -It looks surprisingly good with chrony. But there are continuously
> outliers of up to 4500 us, is this a result of the chrony control loop?
> The time is wandering around with ntpd, but has less jitter.
> 
> Conclusion:
> Despite the 150 us stddev, the using PPS over USB gives some interesting
> inside of what the local ntp server is actually doing. It looks to me
> like it would be an improvement to use it when using ntpd, but not when
> using chrony.
> 
> Best regards,
>  Thomas
>  DK6KD
>  SA6CID
> 
> PS:
> Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
> offset in us)
> http://petig.eu/pps-usb.txt
> =
> 
> Thomas,
> 
> I've done some tests with PPS over USB with Windows some time back, which 
> showed that PPS?USB could be better than LAN-sync alone, but that also 
> included a reduction of the poll interval from possibly 64 seconds for LAN 
> sync to 16 seconds for PPS sync, which may have influenced the results.
> 
> It would be helpful to have some units on the axes - 1 what? 
> I'm guessing microseconds
> 
> For comparison, here is a Raspberry Pi running NTP, with the reported offset 
> plotted against time.
> 
> http://www.satsignal.eu/mrtg/raspi14_ntp_3.html
> 
> This Raspberry Pi (running a seismic detector) is using an Ethernet 
> connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a couple 
> of switches to a very good stratum-1 server.  I would estimate from your 
> graph that the jitter in offset is about 1 millisecond peak-to-peak, but it 
> seems that I get less than that - perhaps 100 microseconds peak-to-peak with 
> occasional excursions outside that.  This is with the latest reference 
> version of NTP.
> 
>remote   refid  st t when poll reach   delay   offset jitter
> ==
> *192.168.0.20.GPS.1 u   17   32  377   12.3510.000 0.428
> +192.168.0.11.uPPS.   1 u2   32  377   12.432   -0.106 0.824
> -192.168.0.3 .kPPS.   1 u   13   32  377   21.366   -4.524 0.804
> +192.168.0.83.kPPS.   1 u   27   32  377   21.614   -4.511 1.206
> uk.pool.ntp.org .POOL.  16 p-   6400.0000.000 0.001
> -193.150.34.2133.150.251.233  3 u   38   64  137   32.3432.738 1.477
> -80.87.128.1794.125.129.7 3 u   30   64  375   53.337   -1.225 1.516
> -192.146.137.13  82.148.230.254   2 u   56   64  377   46.0892.220 2.535
> -129.250.35.250  249.224.99.213   2 u  169   64  214   42.499   -3.015 12.507
> -213.130.44.252  145.238.203.14   2 u  487   64  200   37.210   -0.725 13.232
> 
> 73,
> David GM8ARV
> -- 
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-tay...@blueyonder.co.uk
> Twitter: @gm8arv 
> ___
> 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.

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

[David J Taylor]

Hi,

I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?

Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis:  measured pps offset from full second (computer time) in us,
x-axis pps pulse number.

On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 1: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
servers)

Interesting points:
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
ms.)
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.

Conclusion:
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
using chrony.

Best regards,
  Thomas
  DK6KD
  SA6CID

PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt
=

Thomas,

I've done some tests with PPS over USB with Windows some time back, which 
showed that PPS?USB could be better than LAN-sync alone, but that also 
included a reduction of the poll interval from possibly 64 seconds for LAN 
sync to 16 seconds for PPS sync, which may have influenced the results.


It would be helpful to have some units on the axes - 1 what? 
I'm guessing microseconds


For comparison, here is a Raspberry Pi running NTP, with the reported offset 
plotted against time.


 http://www.satsignal.eu/mrtg/raspi14_ntp_3.html

This Raspberry Pi (running a seismic detector) is using an Ethernet 
connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a 
couple of switches to a very good stratum-1 server.  I would estimate from 
your graph that the jitter in offset is about 1 millisecond peak-to-peak, 
but it seems that I get less than that - perhaps 100 microseconds 
peak-to-peak with occasional excursions outside that.  This is with the 
latest reference version of NTP.


remote   refid  st t when poll reach   delay   offset 
jitter

==
*192.168.0.20.GPS.1 u   17   32  377   12.3510.000 
0.428
+192.168.0.11.uPPS.   1 u2   32  377   12.432   -0.106 
0.824
-192.168.0.3 .kPPS.   1 u   13   32  377   21.366   -4.524 
0.804
+192.168.0.83.kPPS.   1 u   27   32  377   21.614   -4.511 
1.206
uk.pool.ntp.org .POOL.  16 p-   6400.0000.000 
0.001
-193.150.34.2133.150.251.233  3 u   38   64  137   32.3432.738 
1.477
-80.87.128.1794.125.129.7 3 u   30   64  375   53.337   -1.225 
1.516
-192.146.137.13  82.148.230.254   2 u   56   64  377   46.0892.220 
2.535
-129.250.35.250  249.224.99.213   2 u  169   64  214   42.499   -3.015 
12.507
-213.130.44.252  145.238.203.14   2 u  487   64  200   37.210   -0.725 
13.232


73,
David GM8ARV
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv 


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

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

[Christopher Hoover]

>
> The Intel guys have some *very* fast timers flying around their cpu’s.
> They would laugh
> at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab
> the data off those timer, you
> have way better than 100 ns at the timer.


We're most certainly getting off topic, but the errata on TSC [1] and HPET
[2] are long and  mostly not public.   There be dragons with DVFS [3] and
power/idle states.

On Linux you can tell what you have available and what you are using by
looking in /sys/devices/system/clocksource/clocksource0, e.g.

ch@asus-ch:~$ cat
/sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet
acpi_pm ch@asus-ch:~$ cat
/sys/devices/system/clocksource/clocksource0/current_clocksource tsc
ch@asus-ch:~$

Linux usually disqualifies egregiously bad clock soureces.

-christopher
73 de AI6KG


[1] https://en.wikipedia.org/wiki/Time_Stamp_Counter
[2] https://en.wikipedia.org/wiki/High_Precision_Event_Timer
[3] https://en.wikipedia.org/wiki/Dynamic_voltage_scaling




On Fri, Feb 17, 2017 at 4:48 PM, Bob Camp  wrote:

> Hi
>
> Roughly speaking, if you have a 10 MHz clock driving a timer and the pin
> latches data
> from that timer, you get 100 ns “buckets and +/- 100 ns “jitter”.  You can
> find MCU’s that
> will do this for < $1. If you go crazy, you can spend < $10 and still get
> a very fancy MCU
> on a board with all the support “stuff”. That would get you into > 100 MHz
> clocks driving
> counters that might be 32 bits wide.
>
> The Intel guys have some *very* fast timers flying around their cpu’s.
> They would laugh
> at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab
> the data off those timer, you
> have way better than 100 ns at the timer. The trick is writing a driver
> that does that. How
> easy that is to do depends a *lot* on your OS and the chipset you are
> running. It may
> be trivial or it may be impossible.
>
> At some point one might ask: Is a $1 MCU a “system” or is it a peripheral?
>
> Bob
>
>
> > On Feb 17, 2017, at 5:58 PM, Thomas Petig  wrote:
> >
> > Hi,
> >
> > I was wondering whether there is some data/information available on the
> > claimed +/- 100 ns jitter?
> >
> > Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
> > plotted, using some lines of Python, the time offset as attached. Just
> > to get an overview how it is 'worst case', i.e., user program, python,
> > etc. The 1PPS signal comes from a GPS rx.
> > Looks like a standard deviation of around 150 us.
> > y-axis:  measured pps offset from full second (computer time) in us,
> > x-axis pps pulse number.
> >
> > On the long term it looks interesting (while measuring I played with the
> > NTP server on this computer)
> > Until ca. second 1: ntpd synchronization via internet
> > Until ca. second 17000: made an additional LAN NTP server (GPS) available
> > Until the end: replaced ntpd with chrony (still using internet and local
> > servers)
> >
> > Interesting points:
> > -It looks surprisingly bad with using the normal ntpd (especially, there
> > is not really an improvement having an local GPS based server
> > available, did I do something wrong? Only the offset changes by ca. 3
> > ms.)
> > -It looks surprisingly good with chrony. But there are continuously
> > outliers of up to 4500 us, is this a result of the chrony control loop?
> > The time is wandering around with ntpd, but has less jitter.
> >
> > Conclusion:
> > Despite the 150 us stddev, the using PPS over USB gives some interesting
> > inside of what the local ntp server is actually doing. It looks to me
> > like it would be an improvement to use it when using ntpd, but not when
> > using chrony.
> >
> > Best regards,
> >   Thomas
> >   DK6KD
> >   SA6CID
> >
> > PS:
> > Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
> > offset in us)
> > http://petig.eu/pps-usb.txt
> >
> > On Tue, Feb 14, 2017 at 07:26:23AM -0500, Bob Camp wrote:
> >> Hi
> >>
> >> A direct port might be a +/- 100 ns sort of thing most of the time and
> a +/-10 us
> >> thing every so often under some OS’s. Most desktop operating systems
> are not
> >> designed to prioritize random pin interrupts. A dirt cheap MCU coded
> with a few
> >> (hundred) lines of assembly code may be a better option than a typical
> desktop.
> >> Complicating this further is the degree to which some OS’s can be
> directly or
> >> indirectly optimized. Install *this* package and it all goes nuts.
> Install that package
> >> and not much happens ….
> >>
> >> Bob
> >>
> >>> On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin 
> wrote:
> >>>
> >>> Hi, generally speaking, what are the performance differences between
> the following: 1. direct RS-232 (i.e., what I believe is a standard PCI
> card offering RS-232---essentially UARTs interfaced more-or-less directly
> to the PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might
> also have an IRIG input or even 

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

[Bob Camp]

Hi

Roughly speaking, if you have a 10 MHz clock driving a timer and the pin 
latches data 
from that timer, you get 100 ns “buckets and +/- 100 ns “jitter”.  You can find 
MCU’s that
will do this for < $1. If you go crazy, you can spend < $10 and still get a 
very fancy MCU
on a board with all the support “stuff”. That would get you into > 100 MHz 
clocks driving
counters that might be 32 bits wide. 

The Intel guys have some *very* fast timers flying around their cpu’s. They 
would laugh
at the idea of a 10 or 100 MHz clock. If you can configure the pin to grab the 
data off those timer, you
have way better than 100 ns at the timer. The trick is writing a driver that 
does that. How 
easy that is to do depends a *lot* on your OS and the chipset you are running. 
It may 
be trivial or it may be impossible.

At some point one might ask: Is a $1 MCU a “system” or is it a peripheral? 

Bob


> On Feb 17, 2017, at 5:58 PM, Thomas Petig  wrote:
> 
> Hi,
> 
> I was wondering whether there is some data/information available on the
> claimed +/- 100 ns jitter?
> 
> Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
> plotted, using some lines of Python, the time offset as attached. Just
> to get an overview how it is 'worst case', i.e., user program, python,
> etc. The 1PPS signal comes from a GPS rx.
> Looks like a standard deviation of around 150 us.
> y-axis:  measured pps offset from full second (computer time) in us,
> x-axis pps pulse number.
> 
> On the long term it looks interesting (while measuring I played with the
> NTP server on this computer)
> Until ca. second 1: ntpd synchronization via internet
> Until ca. second 17000: made an additional LAN NTP server (GPS) available
> Until the end: replaced ntpd with chrony (still using internet and local
> servers)
> 
> Interesting points:
> -It looks surprisingly bad with using the normal ntpd (especially, there
> is not really an improvement having an local GPS based server
> available, did I do something wrong? Only the offset changes by ca. 3
> ms.)
> -It looks surprisingly good with chrony. But there are continuously
> outliers of up to 4500 us, is this a result of the chrony control loop?
> The time is wandering around with ntpd, but has less jitter.
> 
> Conclusion:
> Despite the 150 us stddev, the using PPS over USB gives some interesting
> inside of what the local ntp server is actually doing. It looks to me
> like it would be an improvement to use it when using ntpd, but not when
> using chrony.
> 
> Best regards,
>   Thomas
>   DK6KD
>   SA6CID
> 
> PS:
> Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
> offset in us)
> http://petig.eu/pps-usb.txt
> 
> On Tue, Feb 14, 2017 at 07:26:23AM -0500, Bob Camp wrote:
>> Hi
>> 
>> A direct port might be a +/- 100 ns sort of thing most of the time and a 
>> +/-10 us
>> thing every so often under some OS’s. Most desktop operating systems are not
>> designed to prioritize random pin interrupts. A dirt cheap MCU coded with a 
>> few
>> (hundred) lines of assembly code may be a better option than a typical 
>> desktop.
>> Complicating this further is the degree to which some OS’s can be directly or
>> indirectly optimized. Install *this* package and it all goes nuts. Install 
>> that package
>> and not much happens ….
>> 
>> Bob
>> 
>>> On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin  
>>> wrote:
>>> 
>>> Hi, generally speaking, what are the performance differences between the 
>>> following: 1. direct RS-232 (i.e., what I believe is a standard PCI card 
>>> offering RS-232---essentially UARTs interfaced more-or-less directly to the 
>>> PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also 
>>> have an IRIG input or even an onboard GNSS receiver).
>>> 
>>> Thanks in advance,
>>> Ruslan
>>> ___
>>> 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.
>> 
> ___
> 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.

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

[David]

On Tue, 14 Feb 2017 10:31:30 -0500, you wrote:

>On 14/02/2017 7:26 AM, Bob Camp wrote:
>
>> A direct port might be a +/- 100 ns sort of thing most of the time and a 
>> +/-10 us
>> thing every so often under some OS’s. Most desktop operating systems are not
>> designed to prioritize random pin interrupts. A dirt cheap MCU coded with a 
>> few
>> (hundred) lines of assembly code may be a better option than a typical 
>> desktop.
>> Complicating this further is the degree to which some OS’s can be directly or
>> indirectly optimized. Install *this* package and it all goes nuts. Install 
>> that package
>>   and not much happens ….
>>
>> Bob
>
>Hence, wouldn't Best Practice be boxes loaded with only the bare OS and 
>software for the time-related tasks?
>As in:
>- a dedicated machine/box for unencumbered acceptance of PPS, and
>- for systems with a business need, a dedicated NTP server/box 
>disciplined by the PPS source (with dedicated communication), while 
>maintaining internet NTP sources as backup for when the PPS source fails?
>Is there a better way?
>Other considerations?
>
>Michael

When I was doing this many years ago with PC hardware the big problem
was not the OS or load on the OS but the x86 processor's SMM (system
management mode).  Some motherboards and BIOS revisions were
completely unusable.  It was always fun to use a low level I/O port to
monitor interrupt latency with an oscilloscope; with some practice it
was possible to identify the various peaks in the histogram at a
glance.

Eventually I gave up running real time tasks on PC hardware and moved
everything to dedicated hardware in one form or another.
___
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.

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

[Christopher Hoover]

On Thu, Feb 16, 2017 at 10:42 AM, Christopher Hoover 
wrote:

> Ntp has support to pick up hardware packet timestamps from the Linux
> kernel.   I wrote the patch; it was merged years ago.
>
>
I'm wrong about this.

The patch I wrote added support for SO_TIMESTAMPNS (see [1]).With
SO_TIMESTAMPNS, the kernel puts the timestamp on the packet just after the
driver hands it to the receive path.

There's a newer interface, SO_TIMESTAMPING, for access to NIC hardware
timestamps.There's no support it on the ntp head for this AFAICT.
 The necessary patch looks straightforward, but I don't think I have the
hardware to test it.

-- Christopher
73 de AI6KG.

[1] https://www.kernel.org/doc/Documentation/networking/timestamping.txt



-c73 de AI6KG
>
>
>
> On Thu, Feb 16, 2017 at 9:59 AM, Denny Page  wrote:
>
>> If your Ethernet chipset (mac or phy) has timestamping capabilities, you
>> can use Chrony which has hardware timestamp support. This greatly improves
>> accuracy, and generally eliminates the CPU loading issue.
>>
>> Denny
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/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.

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

[Chris Albertson]

Yes,  that is the normal "best practice case".   But the OPand myself
some years go
both have a difference use case. In this case no other machine
needs to know the time.
I only care about one computer.

The reason I used NTp back then and he is using it now is to calibrate
the rate of a real-time process running on that one computer.   In
this special case it makes sense to connect GPS PPS to the computer
and use no other source of time.



On Thu, Feb 16, 2017 at 10:58 AM, Gary E. Miller  wrote:
> Yo Chris!
>
> On Wed, 15 Feb 2017 23:48:39 -0800
> Chris Albertson  wrote:
>
>> An ntpd that is running as
>> strum one that has no other ntpd connected to it has VERY little to do
>
> That would be a marginal configuration.  I have yet to see a GPS that
> did not lose sat lock, or lep second, or UTC offset now and then.  Best
> practice is to have at least 3 other network chimers configured.
>
> RGDS
> GARY
> ---
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> g...@rellim.com  Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
> ___
> 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.



-- 

Chris Albertson
Redondo Beach, California
___
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.

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

[Mike Cook]

> Le 16 févr. 2017 à 13:05, Mike Cook  a écrit :
> 
> 
>> Le 16 févr. 2017 à 04:09, MLewis  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.
> 
< snipped>

> 
> 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.  
  detected should have been dedicated of course 
- damned spell checker
> I’ll try that to see what I get.
> 
  As I thought the issue can be worked around by tweaking scheduling and cpu 
affinity.
 When I fixed ntpd on cpu 0 and put it in the fifo real time scheduling class 
there was no change in reported clock offsets when running the same test load.

>> 

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

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

[Hal Murray]

shouldbeq...@gmail.com said:
> I run PTP on a Raspberry Pi using its onboard USB connected NIC, and onboard
> NICs on HP and Dell servers, I see +- 5 microsoconds jitter in the one way
> delay across 4 fanless HP switches, ...

Could you please say more?

USB 2 has a 125 microsecond polling interval.  Is that averaging over a 
batch?  If so, how many? ...

Have you seen any hanging bridges?




-- 
These are my opinions.  I hate spam.



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

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

[Chris Albertson]

sub Millisecond is EASY.   my Apple 27" iMac is doing that right now
using just Internet pool servers.   Yes I have a very good Internet
connection.  100 Mbit fiber and then the last meter is 1000BaseT

But still, milliseconds are really EASY.  It is sub microseconds that
requires things like PTP and special hardware.   It's at the uS level
where you have to work hard

If anyone needs to break a millisecond, just run the PPS to the
machine that needs it edit /etc/ntp.conf and you are now in the "few
uS" level.  It costs nothing (if PPS is available.)  But breaking that
uS barrier is not easy


On Thu, Feb 16, 2017 at 9:59 AM, shouldbe q931  wrote:
> On Thu, Feb 16, 2017 at 7:55 AM, Chris Albertson
>  wrote:
>>
>> But PTP requires special hardware.   You may not have this.
>>
>
> I have to disagree.
>
> I run PTP on a Raspberry Pi using its onboard USB connected NIC, and
> onboard NICs on HP and Dell servers, I see +- 5 microsoconds jitter in
> the one way delay across 4 fanless HP switches, and when PTP is
> running on a Pi with a GPS hat with PPS, I see +50 -30 microseconds
> jitter in the reported offset from master across the slaves.
>
> If the requirement is for sub millisecond then PTP on commodity
> hardware is a _workable_ solution.
>
> If sub microsecond accuracy is required, then the NIC, Ethernet switch
> and time source hardware requirements change.
>
> Cheers
> ___
> 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.



-- 

Chris Albertson
Redondo Beach, California
___
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.

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

[Gary E. Miller]

Yo Chris!

On Wed, 15 Feb 2017 23:48:39 -0800
Chris Albertson  wrote:

> An ntpd that is running as
> strum one that has no other ntpd connected to it has VERY little to do

That would be a marginal configuration.  I have yet to see a GPS that
did not lose sat lock, or lep second, or UTC offset now and then.  Best
practice is to have at least 3 other network chimers configured.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
___
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.

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

[Gary E. Miller]

Yo Chris!

On Wed, 15 Feb 2017 23:55:02 -0800
Chris Albertson  wrote:

> On Wed, Feb 15, 2017 at 11:48 PM, Chris Albertson
>  wrote:
> > On Wed, Feb 15, 2017 at 10:30 PM, Ruslan Nabioullin
> >  wrote:  
> >> On 02/15/2017 01:17 PM, Chris Albertson wrote:  
> >>>
> >>> Why set up a dedicated NTP server if you only have two computers
> >>> that will use it?Your server will be accurate to a few
> >>> microseconds but your two computers will only by good to a few
> >>> milliseconds because ethernet is not nearly as good as PPS.  
> >>
> >>
> >> Well Ethernet can be *extremely* accurate if PTP is used (a
> >> whitepaper specifies <= 100 ns accuracy if the LAN is optimized
> >> for it).  
> 
> But PTP requires special hardware.   You may not have this.

No, PTP works optimally with special hardware, it can work with any
ethernet port.

I will give you that software mode PTP is no more accurate than 
plain NTPv4.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
___
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.

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

[Christopher Hoover]

Ntp has support to pick up hardware packet timestamps from the Linux
kernel.   I wrote the patch; it was merged years ago.

-ch
73 de AI6KG


On Thu, Feb 16, 2017 at 9:59 AM, Denny Page  wrote:

> If your Ethernet chipset (mac or phy) has timestamping capabilities, you
> can use Chrony which has hardware timestamp support. This greatly improves
> accuracy, and generally eliminates the CPU loading issue.
>
> Denny
>
> ___
> 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.

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

[shouldbe q931]

On Thu, Feb 16, 2017 at 7:55 AM, Chris Albertson
 wrote:
>
> But PTP requires special hardware.   You may not have this.
>

I have to disagree.

I run PTP on a Raspberry Pi using its onboard USB connected NIC, and
onboard NICs on HP and Dell servers, I see +- 5 microsoconds jitter in
the one way delay across 4 fanless HP switches, and when PTP is
running on a Pi with a GPS hat with PPS, I see +50 -30 microseconds
jitter in the reported offset from master across the slaves.

If the requirement is for sub millisecond then PTP on commodity
hardware is a _workable_ solution.

If sub microsecond accuracy is required, then the NIC, Ethernet switch
and time source hardware requirements change.

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

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

[Denny Page]

If your Ethernet chipset (mac or phy) has timestamping capabilities, you can 
use Chrony which has hardware timestamp support. This greatly improves 
accuracy, and generally eliminates the CPU loading issue.

Denny

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

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

[Bob Camp]

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  wrote:
> 
> 
>> Le 16 févr. 2017 à 04:09, MLewis  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.86 sec
> 16 Feb 11:19:32 ntpdate[11569]: adjust time server 192.168.1.157 offset 
> -0.85 sec
> 16 Feb 11:21:18 ntpdate[11587]: adjust time server 192.168.1.157 offset 
> -0.82 sec
> 16 Feb 11:23:05 ntpdate[11590]: adjust time server 192.168.1.157 offset 
> -0.54 sec
> 16 Feb 11:24:51 ntpdate[11593]: adjust time server 192.168.1.157 offset 
> -0.28 sec
> 16 Feb 11:26:37 ntpdate[11611]: adjust time server 192.168.1.157 offset 
> 0.08 sec
> 16 Feb 11:28:24 ntpdate[11614]: adjust time server 192.168.1.157 offset 
> 0.26 sec
> 16 Feb 11:30:10 ntpdate[11632]: adjust time server 192.168.1.157 offset 
> 0.59 sec
> 2. Start up 4 cpu soaker threads - in this case calculating pi to 1 
> 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.89 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.92 sec
> 16 Feb 12:09:09 ntpdate[11805]: adjust time server 192.168.1.157 offset 
> 0.96 sec
> 16 Feb 12:10:55 ntpdate[11823]: adjust time server 192.168.1.157 offset 
> 0.51 sec
> 16 Feb 12:12:41 ntpdate[11826]: adjust time server 192.168.1.157 offset 
> 0.08 sec
> 16 Feb 12:14:28 ntpdate[11829]: adjust time server 192.168.1.157 offset 
> 0.02 sec
> 16 Feb 12:16:14 ntpdate[11847]: adjust time server 192.168.1.157 offset 
> -0.16 sec
> 16 Feb 12:18:00 ntpdate[11852]: adjust time server 192.168.1.157 offset 
> 0.07 sec
> 16 Feb 12:19:46 ntpdate[11855]: adjust time server 192.168.1.157 offset 
> 0.09 sec
> 16 Feb 12:21:33 ntpdate[11873]: 

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

[Mike Cook]

> Le 16 févr. 2017 à 04:09, MLewis  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.86 sec
16 Feb 11:19:32 ntpdate[11569]: adjust time server 192.168.1.157 offset 
-0.85 sec
16 Feb 11:21:18 ntpdate[11587]: adjust time server 192.168.1.157 offset 
-0.82 sec
16 Feb 11:23:05 ntpdate[11590]: adjust time server 192.168.1.157 offset 
-0.54 sec
16 Feb 11:24:51 ntpdate[11593]: adjust time server 192.168.1.157 offset 
-0.28 sec
16 Feb 11:26:37 ntpdate[11611]: adjust time server 192.168.1.157 offset 
0.08 sec
16 Feb 11:28:24 ntpdate[11614]: adjust time server 192.168.1.157 offset 
0.26 sec
16 Feb 11:30:10 ntpdate[11632]: adjust time server 192.168.1.157 offset 
0.59 sec
2. Start up 4 cpu soaker threads - in this case calculating pi to 1 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.89 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.92 sec
16 Feb 12:09:09 ntpdate[11805]: adjust time server 192.168.1.157 offset 
0.96 sec
16 Feb 12:10:55 ntpdate[11823]: adjust time server 192.168.1.157 offset 
0.51 sec
16 Feb 12:12:41 ntpdate[11826]: adjust time server 192.168.1.157 offset 
0.08 sec
16 Feb 12:14:28 ntpdate[11829]: adjust time server 192.168.1.157 offset 
0.02 sec
16 Feb 12:16:14 ntpdate[11847]: adjust time server 192.168.1.157 offset 
-0.16 sec
16 Feb 12:18:00 ntpdate[11852]: adjust time server 192.168.1.157 offset 
0.07 sec
16 Feb 12:19:46 ntpdate[11855]: adjust time server 192.168.1.157 offset 
0.09 sec
16 Feb 12:21:33 ntpdate[11873]: adjust time server 192.168.1.157 offset 
0.12 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 
> 

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

[Bob Camp]

Hi


> On Feb 16, 2017, at 1:30 AM, Ruslan Nabioullin  wrote:
> 
> On 02/15/2017 01:17 PM, Chris Albertson wrote:
>> Why set up a dedicated NTP server if you only have two computers
>> that will use it?Your server will be accurate to a few
>> microseconds but your two computers will only by good to a few
>> milliseconds because ethernet is not nearly as good as PPS.
> 
> Well Ethernet can be *extremely* accurate if PTP is used (a whitepaper 
> specifies <= 100 ns accuracy if the LAN is optimized for it).

PTP single shot over ethernet is not at the < 100 ns level, even with proper 
cards. In real world settings, the traffic level for sub
100 ns PTP can be pretty high. Some situations appear to require > 100K 
transactions per second. I’ve never seen anything quite that
extreme myself. 

Bob


> 
> Well, the assumption here is that one would render this service available to 
> the public, registering the server(s) with the NTP website and/or the NTP 
> Pool Project; n.b. this is still possible for connections lacking a static IP 
> address, by means of an IPv6 tunnel, available at no cost from at least one 
> vendor.  Otherwise yes, by some perspectives it can be considered quite 
> pointless and wasteful to operate dedicated servers, standards, receivers, 
> etc. with no means of time transfer to customers.
> 
> > NTP is almost zero load on the CPU and the best thing is the NTP
> > accuracy is not effected by CPU load  SO you can run other service
> > without degrading the NTP server.
> 
> Well n.b. TVB's hardware PPS timestamping post.  Also WWV and CHU decoding by 
> NTP's modules can be problematic, as well as the obvious case of the server 
> being overloaded.  Finally note that based on others' experimentation, the 
> motherboard's XO temperature is nontrivially-highly correlated with CPU load, 
> so for better motherboard XO-based holdover performance, once must create an 
> ersatz oven utilizing the CPU(s), by running them at full utilization 
> (obviously with proper scheduling priority), so typically volunteer 
> distributed computing project(s) such as BOINC (SETI@home, etc.), 
> Folding@Home, etc.  Of course then power consumption becomes problematic.
> 
> -Ruslan
> ___
> 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.

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

[Hal Murray]

> But notice that only 1/2  of the wires in a standard Ethernet cable are in
> use.

Unless you are using Gigabit Ethernet.


-- 
These are my opinions.  I hate spam.



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

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

[Chris Albertson]

Your processing machine is going to be running NTP with a reference
clock being your local status 1 NTP server

I think the processing machine would see a lighter load if it's NTP
was using GPS as the reference rather thennother NTP server.   In
other words the processing box, the one with the 4Hz work load could
be an isolated strum 1 NTP server with no other connected computers.
 Servicing the GPS interface is nearly trivial, much simply then going
over the network to another server.An ntpd that is running as
strum one that has no other ntpd connected to it has VERY little to do

BTW I first learned about NTP formerly this same reason.   I was
writing firmware for an astronomical CCD camera and we wanted to know
EXACTLY when exposures started and stopped.

On Wed, Feb 15, 2017 at 7:09 PM, MLewis  wrote:
> 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...
>
> My application cycles between a low background load to a full CPU load on
> hex cores four times a second on the quarter-second. Each quarter-second
> load, for each of 22 datasets, first takes a data snapshot, then does some
> processing, which for any or all of the datasets may trigger more
> processing, and when all dataset processing treads are complete, this is
> followed by some house-keeping tasks. Therefore the duration of those full
> loads varies, and one of the four quarter-second loads has more to do and is
> significantly longer than the other three. To get the quarter-second loads
> done as fast as possible, the bios is set to run the CPU in turbo
> continuously, otherwise power saving 'features' start dialing back core
> speed and shutting down cores, resulting in the longer quarter-second task
> not getting done within 250 ms in time for the next quarter-second's start.
>
> The rate of accumulating lag on system time varies from 2 ms a minute to 16
> ms a minute, depending on the load. The result is that the quarter-second
> data snapshots don't start on the actual quarter-second, off more and more
> as lag accumulates, until they're off their target time by more than a
> second, then seconds, etc..
>
> With NTP polling six pool sources while my application is cycling between
> load levels four times a second, the observed quarter-second start drifts
> within roughly 300 ms, sometimes 600 ms.
>
> That wasn't exactly a surprise. The base application I'm working from used
> Apache's NTPUDPClient to maintain an offset from system time from a single
> NTP source.  After expanding the design to use multiple NTP sources, I found
> that the reported offsets from pools were stable when my CPU load was
> stable, but when it was cycling in/out of the heavy loads, the reported
> offsets became more variable between sources and the number and offset of
> reported offsets that were outliers became ridiculous. As much fun as it was
> to design custom cascading outlier filters, this led me to abandon the
> underlying base application's offset to system time and use NTP to maintain
> system time.
>
> 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.
>
> 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.



-- 

Chris Albertson
Redondo Beach, California
___
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.

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

[Chris Albertson]

On Wed, Feb 15, 2017 at 11:48 PM, Chris Albertson
 wrote:
> On Wed, Feb 15, 2017 at 10:30 PM, Ruslan Nabioullin
>  wrote:
>> On 02/15/2017 01:17 PM, Chris Albertson wrote:
>>>
>>> Why set up a dedicated NTP server if you only have two computers
>>> that will use it?Your server will be accurate to a few
>>> microseconds but your two computers will only by good to a few
>>> milliseconds because ethernet is not nearly as good as PPS.
>>
>>
>> Well Ethernet can be *extremely* accurate if PTP is used (a whitepaper
>> specifies <= 100 ns accuracy if the LAN is optimized for it).

But PTP requires special hardware.   You may not have this.

A cheap why to distribute time is use PPS on a back channel.   You
build a little amplifier and rig it so all computers receive PPS from
the same GPS source.  NTP runs on all these computers and you add the
"Atom" ref clock.   The trouble is you need to run more wires,
Ethernet and PPS.But notice that only 1/2  of the wires in a
standard Ethernet cable are in use.

-- 

Chris Albertson
Redondo Beach, California
___
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.

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

[Chris Albertson]

The desktop PCs can each be configured with as many reference clocks
as you like.   That is independent of how many stratum 1 NTP servers a
company needs to operate.Maybe you are running some stratum 2
servers on your routers and using more from the Internet.All these
choices are independent of each other.

If you are serving Windows PCs then, I think those are all running
SNTP and then use just one NTP server

For most companies there really is no need to even have a GPS
receiver.  Being within 10  milliseconds is just fine so pool servers
will do.

> I would argue that you need at least three servers (and more like five). When 
> given only two
> servers NTP simply dithers back and forth between them. It does not have
> a way to figure out which of two clocks is wrong. It will detect a missing 
> clock, but
> not one that is simply off time by a bit.
>
-- 

Chris Albertson
Redondo Beach, California
___
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.

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

[MLewis]

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...
My application cycles between a low background load to a full CPU load 
on hex cores four times a second on the quarter-second. Each 
quarter-second load, for each of 22 datasets, first takes a data 
snapshot, then does some processing, which for any or all of the 
datasets may trigger more processing, and when all dataset processing 
treads are complete, this is followed by some house-keeping tasks. 
Therefore the duration of those full loads varies, and one of the four 
quarter-second loads has more to do and is significantly longer than the 
other three. To get the quarter-second loads done as fast as possible, 
the bios is set to run the CPU in turbo continuously, otherwise power 
saving 'features' start dialing back core speed and shutting down cores, 
resulting in the longer quarter-second task not getting done within 250 
ms in time for the next quarter-second's start.


The rate of accumulating lag on system time varies from 2 ms a minute to 
16 ms a minute, depending on the load. The result is that the 
quarter-second data snapshots don't start on the actual quarter-second, 
off more and more as lag accumulates, until they're off their target 
time by more than a second, then seconds, etc..


With NTP polling six pool sources while my application is cycling 
between load levels four times a second, the observed quarter-second 
start drifts within roughly 300 ms, sometimes 600 ms.


That wasn't exactly a surprise. The base application I'm working from 
used Apache's NTPUDPClient to maintain an offset from system time from a 
single NTP source.  After expanding the design to use multiple NTP 
sources, I found that the reported offsets from pools were stable when 
my CPU load was stable, but when it was cycling in/out of the heavy 
loads, the reported offsets became more variable between sources and the 
number and offset of reported offsets that were outliers became 
ridiculous. As much fun as it was to design custom cascading outlier 
filters, this led me to abandon the underlying base application's offset 
to system time and use NTP to maintain system time.


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.


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.

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

[Ruslan Nabioullin]

On 02/15/2017 01:17 PM, Chris Albertson wrote:

Why set up a dedicated NTP server if you only have two computers
that will use it?Your server will be accurate to a few
microseconds but your two computers will only by good to a few
milliseconds because ethernet is not nearly as good as PPS.


Well Ethernet can be *extremely* accurate if PTP is used (a whitepaper 
specifies <= 100 ns accuracy if the LAN is optimized for it).


Well, the assumption here is that one would render this service 
available to the public, registering the server(s) with the NTP website 
and/or the NTP Pool Project; n.b. this is still possible for connections 
lacking a static IP address, by means of an IPv6 tunnel, available at no 
cost from at least one vendor.  Otherwise yes, by some perspectives it 
can be considered quite pointless and wasteful to operate dedicated 
servers, standards, receivers, etc. with no means of time transfer to 
customers.


> NTP is almost zero load on the CPU and the best thing is the NTP
> accuracy is not effected by CPU load  SO you can run other service
> without degrading the NTP server.

Well n.b. TVB's hardware PPS timestamping post.  Also WWV and CHU 
decoding by NTP's modules can be problematic, as well as the obvious 
case of the server being overloaded.  Finally note that based on others' 
experimentation, the motherboard's XO temperature is nontrivially-highly 
correlated with CPU load, so for better motherboard XO-based holdover 
performance, once must create an ersatz oven utilizing the CPU(s), by 
running them at full utilization (obviously with proper scheduling 
priority), so typically volunteer distributed computing project(s) such 
as BOINC (SETI@home, etc.), Folding@Home, etc.  Of course then power 
consumption becomes problematic.


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

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

[Chris Albertson]

On Tue, Feb 14, 2017 at 9:38 PM, MLewis  wrote:

> That dual set model is new to me. Interesting to see its fall-back on
> failures. And the offline model.
>
> It's the poor-man's version of that model that I was aiming for (and one,
> not two sets of receiver-with-server):
> - A small box as "GPS receiver" with NTP, receiving the PPS from a GPS
> timing module.
> - That box as a source to an NTP Server that also looks at six internet pool
> sources (pools are the 'backup' if GPS/receiver-box fails).
> - My systems (two boxes) look to the NTP Server for their time reference.

Why set up a dedicated NTP server if you only have two computers that
will use it?Your server will be accurate to a few microseconds but
your two computers will only by good to a few milliseconds because
ethernet is not nearly as good as PPS.

You could save some money and just run NTP on the two computers.   A
dedicated server does not get you much because you can't get GPS level
accuracy out of it to your other devices. But this is a hobby and
setting it up is educational  And maybe you find other uses for the
server like maybe it can keep backups or store media files (videos) or
host a small web site   NTP is almost zero load on the CPU and the
best thing is the NTP accuracy is not effected by CPU load  SO you can
run other service without degrading the NTP server.  (All the time
critical stuff happens inside a tiny interrupt handler, not in user
space)

-- 

Chris Albertson
Redondo Beach, California
___
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.

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

[Bob Camp]

Hi


> On Feb 14, 2017, at 9:23 PM, Chris Albertson  
> wrote:
> 
> On Tue, Feb 14, 2017 at 7:31 AM, MLewis  wrote:
> 
>> 
>> 
>> - a dedicated machine/box for unencumbered acceptance of PPS, and
>> - for systems with a business need, a dedicated NTP server/box disciplined
>> by the PPS source (with dedicated communication), while maintaining
>> internet NTP sources as backup for when the PPS source fails?
>> Is there a better way?
>> Other considerations?
> 
> 
> Don't ever think about "backup servers".  NTP will always select the "best"
> reference clocks.   The best ones are defined as the subset of references
> that track each other.
> 
> Best practice today is to have two independent NTP servers and two GPS
> receivers.  

I would argue that you need at least three servers (and more like five). When 
given only two 
servers NTP simply dithers back and forth between them. It does not have 
a way to figure out which of two clocks is wrong. It will detect a missing 
clock, but 
not one that is simply off time by a bit.

Bob


> It is best if these are independent as you can make them,
> different buildings if you can.   I would even use different brands of
> hardware to protect against a bug.   Then throughout your company all your
> PCs are configured to look at both NTP servers
> 
> Each server is configured to use the GPS reference clock, the other "twin"
> NTP server as well as about five Internet "pool" servers.
> 
> If your location does not have an Internet connection. ( YES this can
> happen.  I've worked on computers that process classified information and
> these computers never have Internet access.)  You can configure them so
> they run in "orphan mode" that is they all use each other as reference
> clocks.  Then when GPS is lost thenoormal NTP clock selection algorithm
> will select the subset of PCs that all agree on what the time is.   The
> outliers tent to get ignored.When GPS comes back up the system makes a
> gradual and graceful recovery.
> 
> 
> 
> 
> 
> Chris Albertson
> Redondo Beach, California
> ___
> 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.

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

[Mike Cook]

>> 
>> Best practice today is to have two independent NTP servers and two GPS
>> receivers.   It is best if these are independent as you can make them,
>> different buildings if you can.   I would even use different brands of
>> hardware to protect against a bug.

This is an often missed essential, though it also applies to software. 

>>   Then throughout your company all your
>> PCs are configured to look at both NTP servers
>> 
>> Each server is configured to use the GPS reference clock, the other "twin"
>> NTP server as well as about five Internet "pool" servers.
>> 
>> If your location does not have an Internet connection. ( YES this can
>> happen.  I've worked on computers that process classified information and
>> these computers never have Internet access.)  You can configure them so
>> they run in "orphan mode" that is they all use each other as reference
>> clocks.  Then when GPS is lost thenoormal NTP clock selection algorithm
>> will select the subset of PCs that all agree on what the time is.   The
>> outliers tent to get ignored.When GPS comes back up the system makes a
>> gradual and graceful recovery.
>> 
>> 
>> Chris Albertson
>> Redondo Beach, California
> That dual set model is new to me. Interesting to see its fall-back on 
> failures. And the offline model.
> 
> Thanks to all
> 
> Michael
> 

Since when has two clocks been of any use to anyone. It is false economy to 
think that you can get a way with just two upstream references at any stratum 
level just because they themselves have many sources. 
 
For each NTP node except the top stratum (1) you need at least 4 servers to 
enable the removal of any one for maintenance or allowing for failure and still 
allow NTPs selection algorithms to work correctly. 


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

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

[MLewis]

On 14/02/2017 9:23 PM, Chris Albertson wrote:

On Tue, Feb 14, 2017 at 7:31 AM, MLewis  wrote:



- a dedicated machine/box for unencumbered acceptance of PPS, and
- for systems with a business need, a dedicated NTP server/box disciplined
by the PPS source (with dedicated communication), while maintaining
internet NTP sources as backup for when the PPS source fails?
Is there a better way?
Other considerations?


Don't ever think about "backup servers".  NTP will always select the "best"
reference clocks.   The best ones are defined as the subset of references
that track each other.

Best practice today is to have two independent NTP servers and two GPS
receivers.   It is best if these are independent as you can make them,
different buildings if you can.   I would even use different brands of
hardware to protect against a bug.   Then throughout your company all your
PCs are configured to look at both NTP servers

Each server is configured to use the GPS reference clock, the other "twin"
NTP server as well as about five Internet "pool" servers.

If your location does not have an Internet connection. ( YES this can
happen.  I've worked on computers that process classified information and
these computers never have Internet access.)  You can configure them so
they run in "orphan mode" that is they all use each other as reference
clocks.  Then when GPS is lost thenoormal NTP clock selection algorithm
will select the subset of PCs that all agree on what the time is.   The
outliers tent to get ignored.When GPS comes back up the system makes a
gradual and graceful recovery.


Chris Albertson
Redondo Beach, California
That dual set model is new to me. Interesting to see its fall-back on 
failures. And the offline model.


It's the poor-man's version of that model that I was aiming for (and 
one, not two sets of receiver-with-server):
- A small box as "GPS receiver" with NTP, receiving the PPS from a GPS 
timing module.
- That box as a source to an NTP Server that also looks at six internet 
pool sources (pools are the 'backup' if GPS/receiver-box fails).

- My systems (two boxes) look to the NTP Server for their time reference.

With all everyone has responded with, as a novice to this I have a lot 
of reading to do...

then some choices to make.

Thanks to all

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.

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

[Chris Albertson]

On Tue, Feb 14, 2017 at 7:31 AM, MLewis  wrote:

>
>
> - a dedicated machine/box for unencumbered acceptance of PPS, and
> - for systems with a business need, a dedicated NTP server/box disciplined
> by the PPS source (with dedicated communication), while maintaining
> internet NTP sources as backup for when the PPS source fails?
> Is there a better way?
> Other considerations?


Don't ever think about "backup servers".  NTP will always select the "best"
reference clocks.   The best ones are defined as the subset of references
that track each other.

Best practice today is to have two independent NTP servers and two GPS
receivers.   It is best if these are independent as you can make them,
different buildings if you can.   I would even use different brands of
hardware to protect against a bug.   Then throughout your company all your
PCs are configured to look at both NTP servers

Each server is configured to use the GPS reference clock, the other "twin"
NTP server as well as about five Internet "pool" servers.

If your location does not have an Internet connection. ( YES this can
happen.  I've worked on computers that process classified information and
these computers never have Internet access.)  You can configure them so
they run in "orphan mode" that is they all use each other as reference
clocks.  Then when GPS is lost thenoormal NTP clock selection algorithm
will select the subset of PCs that all agree on what the time is.   The
outliers tent to get ignored.When GPS comes back up the system makes a
gradual and graceful recovery.





Chris Albertson
Redondo Beach, California
___
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.

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

[Denny Page]

> On Feb 14, 2017, at 15:14, J. Grizzard  wrote:
> 
> I really recommend the PC Engines apu2c hardware. Just a touch over $100,
> schematics available, hardware serial port, GPIO, 1588-capable PHY, CPU
> crystal accessible if you want to try a clockblock-type hack, great
> support, and just decent all around.
> 

Have you fit a GPS receiver to it?

Denny

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

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

[J. Grizzard]

I really recommend the PC Engines apu2c hardware. Just a touch over $100,
schematics available, hardware serial port, GPIO, 1588-capable PHY, CPU
crystal accessible if you want to try a clockblock-type hack, great
support, and just decent all around.

There's also test pads for the PHY that could be used to do PPS directly
to that for PTP purposes, but I haven't quite yet figured out exactly
how to set that up. But the pads are there!

(hint: Order direct from manufacturer, not via a US distributor. You'll
save money and the shipping is still really quite fast.)

-j

On Tue, Feb 14, 2017 at 05:26:16PM -0500, Scott Stobbe wrote:
> Something like this would make a great NTP server.
> https://www.digikey.com/products/en?keywords=P0286-ND
> 
> Too bad they didn't include a PTP 1588 capable PHY...
> 
> On Tue, Feb 14, 2017 at 12:33 PM, Chris Albertson  > wrote:
> 
> > Here is a something that could work.  It has a real serial port and you
> > could add more ethernet controllers, uses very little power and cost only
> > $60.
> > www.newegg.com/
> >  > N82E16813157497_re=j1900-_-13-157-497-_-Product>
> >
> > There are other boards like this that use the same J1900 CPU.   I'm
> > thinking about using this as th machine tool (milling machine) controller.
> >
> > On Tue, Feb 14, 2017 at 4:26 AM, Bob Camp  wrote:
> >
> > > Hi
> > >
> > > A direct port might be a +/- 100 ns sort of thing most of the time and a
> > > +/-10 us
> > > thing every so often under some OS???s. Most desktop operating systems are
> > > not
> > > designed to prioritize random pin interrupts. A dirt cheap MCU coded with
> > > a few
> > > (hundred) lines of assembly code may be a better option than a typical
> > > desktop.
> > > Complicating this further is the degree to which some OS???s can be
> > directly
> > > or
> > > indirectly optimized. Install *this* package and it all goes nuts.
> > Install
> > > that package
> > >  and not much happens ???.
> > >
> > > Bob
> > >
> > > > On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin  > >
> > > wrote:
> > > >
> > > > Hi, generally speaking, what are the performance differences between
> > the
> > > following: 1. direct RS-232 (i.e., what I believe is a standard PCI card
> > > offering RS-232---essentially UARTs interfaced more-or-less directly to
> > the
> > > PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also
> > > have an IRIG input or even an onboard GNSS receiver).
> > > >
> > > > Thanks in advance,
> > > > Ruslan
> > > > ___
> > > > 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.
> > >
> >
> >
> >
> > --
> >
> > Chris Albertson
> > Redondo Beach, California
> > ___
> > 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.
___
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.

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

[Bob Camp]

Hi

If you want a 1588 PHY and are on a budget:

https://www.digikey.com/products/en/development-boards-kits-programmers/evaluation-boards-embedded-mcu-dsp/786?k=freescale+freedom==freescale+freedom=24619=ffe00312%2C7e80098=0=0=0=1=0=0=0=25

Drop NTP into it and let it rip.

Bob


> On Feb 14, 2017, at 5:26 PM, Scott Stobbe  wrote:
> 
> Something like this would make a great NTP server.
> https://www.digikey.com/products/en?keywords=P0286-ND
> 
> Too bad they didn't include a PTP 1588 capable PHY...
> 
> On Tue, Feb 14, 2017 at 12:33 PM, Chris Albertson > wrote:
> 
>> Here is a something that could work.  It has a real serial port and you
>> could add more ethernet controllers, uses very little power and cost only
>> $60.
>> www.newegg.com/
>> > N82E16813157497_re=j1900-_-13-157-497-_-Product>
>> 
>> There are other boards like this that use the same J1900 CPU.   I'm
>> thinking about using this as th machine tool (milling machine) controller.
>> 
>> On Tue, Feb 14, 2017 at 4:26 AM, Bob Camp  wrote:
>> 
>>> Hi
>>> 
>>> A direct port might be a +/- 100 ns sort of thing most of the time and a
>>> +/-10 us
>>> thing every so often under some OS’s. Most desktop operating systems are
>>> not
>>> designed to prioritize random pin interrupts. A dirt cheap MCU coded with
>>> a few
>>> (hundred) lines of assembly code may be a better option than a typical
>>> desktop.
>>> Complicating this further is the degree to which some OS’s can be
>> directly
>>> or
>>> indirectly optimized. Install *this* package and it all goes nuts.
>> Install
>>> that package
>>> and not much happens ….
>>> 
>>> Bob
>>> 
 On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin >> 
>>> wrote:
 
 Hi, generally speaking, what are the performance differences between
>> the
>>> following: 1. direct RS-232 (i.e., what I believe is a standard PCI card
>>> offering RS-232---essentially UARTs interfaced more-or-less directly to
>> the
>>> PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also
>>> have an IRIG input or even an onboard GNSS receiver).
 
 Thanks in advance,
 Ruslan
 ___
 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.
>>> 
>> 
>> 
>> 
>> --
>> 
>> Chris Albertson
>> Redondo Beach, California
>> ___
>> 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.

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

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

[Scott Stobbe]

Something like this would make a great NTP server.
https://www.digikey.com/products/en?keywords=P0286-ND

Too bad they didn't include a PTP 1588 capable PHY...

On Tue, Feb 14, 2017 at 12:33 PM, Chris Albertson  wrote:

> Here is a something that could work.  It has a real serial port and you
> could add more ethernet controllers, uses very little power and cost only
> $60.
> www.newegg.com/
>  N82E16813157497_re=j1900-_-13-157-497-_-Product>
>
> There are other boards like this that use the same J1900 CPU.   I'm
> thinking about using this as th machine tool (milling machine) controller.
>
> On Tue, Feb 14, 2017 at 4:26 AM, Bob Camp  wrote:
>
> > Hi
> >
> > A direct port might be a +/- 100 ns sort of thing most of the time and a
> > +/-10 us
> > thing every so often under some OS’s. Most desktop operating systems are
> > not
> > designed to prioritize random pin interrupts. A dirt cheap MCU coded with
> > a few
> > (hundred) lines of assembly code may be a better option than a typical
> > desktop.
> > Complicating this further is the degree to which some OS’s can be
> directly
> > or
> > indirectly optimized. Install *this* package and it all goes nuts.
> Install
> > that package
> >  and not much happens ….
> >
> > Bob
> >
> > > On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin  >
> > wrote:
> > >
> > > Hi, generally speaking, what are the performance differences between
> the
> > following: 1. direct RS-232 (i.e., what I believe is a standard PCI card
> > offering RS-232---essentially UARTs interfaced more-or-less directly to
> the
> > PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also
> > have an IRIG input or even an onboard GNSS receiver).
> > >
> > > Thanks in advance,
> > > Ruslan
> > > ___
> > > 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.
> >
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> ___
> 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.

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

[Tom Van Baak]

> Hence, wouldn't Best Practice be boxes loaded with only the bare OS and 
> software for the time-related tasks?

If you find yourself in a situation like this -- where your timing seems to 
improve the less load you have -- that's a sure sign that you're doing the 
timing wrong in the first place.

Best practices are to do 1PPS timing in hardware using capture registers (which 
almost every microcontroller has). That way there's a separation between the 
critical act of *making* a timing measurement from the non-critical act of 
*delivering* the measurement result the operating system. You still use 
interrupts -- but now the purpose of the interrupt is simply to indicate that a 
fresh measurement result is ready, rather than the interrupt itself being the 
measurement. The result is that the time stamp / capture register method is 
immune to interrupt latency and system load issues.

Best practices number two are to replace the crystal on the motherboard with a 
TCXO or OCXO. Then, with the help of NTP, your computer is finally acting like 
a GPSDO.

/tvb

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

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

[Bob Camp]

Hi

> On Feb 14, 2017, at 10:31 AM, MLewis  wrote:
> 
> 
> 
> On 14/02/2017 7:26 AM, Bob Camp wrote:
>> Hi
>> 
>> A direct port might be a +/- 100 ns sort of thing most of the time and a 
>> +/-10 us
>> thing every so often under some OS’s. Most desktop operating systems are not
>> designed to prioritize random pin interrupts. A dirt cheap MCU coded with a 
>> few
>> (hundred) lines of assembly code may be a better option than a typical 
>> desktop.
>> Complicating this further is the degree to which some OS’s can be directly or
>> indirectly optimized. Install *this* package and it all goes nuts. Install 
>> that package
>>  and not much happens ….
>> 
>> Bob
>> 
> Hence, wouldn't Best Practice be boxes loaded with only the bare OS and 
> software for the time-related tasks?

That would be one approach.

> As in:
> - a dedicated machine/box for unencumbered acceptance of PPS, and
> - for systems with a business need, a dedicated NTP server/box disciplined by 
> the PPS source (with dedicated communication), while maintaining internet NTP 
> sources as backup for when the PPS source fails?
> Is there a better way?

It depends on what you are trying to do. If the objective is to replace a piece 
of test gear
logging 100% of your events at the 100ns level, the computer likely will not 
measure up. If the objective is to run
NTP at the 100 us level, there are a lot more things you can get away with. NTP 
is designed from the 
ground up to be quite tolerant of various issues. 

Bob

> Other considerations?
> 
> 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.

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

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

[Chris Albertson]

Here is a something that could work.  It has a real serial port and you
could add more ethernet controllers, uses very little power and cost only
$60.
www.newegg.com/


There are other boards like this that use the same J1900 CPU.   I'm
thinking about using this as th machine tool (milling machine) controller.

On Tue, Feb 14, 2017 at 4:26 AM, Bob Camp  wrote:

> Hi
>
> A direct port might be a +/- 100 ns sort of thing most of the time and a
> +/-10 us
> thing every so often under some OS’s. Most desktop operating systems are
> not
> designed to prioritize random pin interrupts. A dirt cheap MCU coded with
> a few
> (hundred) lines of assembly code may be a better option than a typical
> desktop.
> Complicating this further is the degree to which some OS’s can be directly
> or
> indirectly optimized. Install *this* package and it all goes nuts. Install
> that package
>  and not much happens ….
>
> Bob
>
> > On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin 
> wrote:
> >
> > Hi, generally speaking, what are the performance differences between the
> following: 1. direct RS-232 (i.e., what I believe is a standard PCI card
> offering RS-232---essentially UARTs interfaced more-or-less directly to the
> PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also
> have an IRIG input or even an onboard GNSS receiver).
> >
> > Thanks in advance,
> > Ruslan
> > ___
> > 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.
>



-- 

Chris Albertson
Redondo Beach, California
___
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.

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

[MLewis]

On 14/02/2017 7:26 AM, Bob Camp wrote:

Hi

A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 
us
thing every so often under some OS’s. Most desktop operating systems are not
designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few
(hundred) lines of assembly code may be a better option than a typical desktop.
Complicating this further is the degree to which some OS’s can be directly or
indirectly optimized. Install *this* package and it all goes nuts. Install that 
package
  and not much happens ….

Bob

Hence, wouldn't Best Practice be boxes loaded with only the bare OS and 
software for the time-related tasks?

As in:
- a dedicated machine/box for unencumbered acceptance of PPS, and
- for systems with a business need, a dedicated NTP server/box 
disciplined by the PPS source (with dedicated communication), while 
maintaining internet NTP sources as backup for when the PPS source fails?

Is there a better way?
Other considerations?

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.

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

[Denny Page]

> On Feb 13, 2017, at 23:47, Hal Murray  wrote:
> 
> There is a whole class of low power mother boards targeted at the embedded 
> market.  A few of them have multiple Ethernets - goof for building firewalls. 
> I haven't found any low cost ones.

This one might be of interest:

https://www.kickstarter.com/projects/874883570/marvell-espressobin-board?token=6a67e544
___
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.

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

[Bob Camp]

Hi

A direct port might be a +/- 100 ns sort of thing most of the time and a +/-10 
us 
thing every so often under some OS’s. Most desktop operating systems are not
designed to prioritize random pin interrupts. A dirt cheap MCU coded with a few
(hundred) lines of assembly code may be a better option than a typical desktop. 
Complicating this further is the degree to which some OS’s can be directly or
indirectly optimized. Install *this* package and it all goes nuts. Install that 
package
 and not much happens ….

Bob

> On Feb 13, 2017, at 11:07 AM, Ruslan Nabioullin  wrote:
> 
> Hi, generally speaking, what are the performance differences between the 
> following: 1. direct RS-232 (i.e., what I believe is a standard PCI card 
> offering RS-232---essentially UARTs interfaced more-or-less directly to the 
> PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also have 
> an IRIG input or even an onboard GNSS receiver).
> 
> Thanks in advance,
> Ruslan
> ___
> 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.

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

[Hal Murray]

mlewis...@rogers.com said:
> Know of any with an Ethernet port, preferably two, that aren't run from  a
> USB controller?

You didn't put a qualifier on your "any".  (or I missed it)

If you want a Raspberry Pi class board, the BeagleBone Black has a real 
Ethernet, but only one.

If you need 2 real Ethernets, the cheapest approach is probably to get an old 
PC with PCI slots and add a PCI Ethernet card.

There is a whole class of low power mother boards targeted at the embedded 
market.  A few of them have multiple Ethernets - goof for building firewalls. 
 I haven't found any low cost ones.
  http://www.mini-box.com/Atom

Soekris has various boards with multiple Ethernets and no display.
  http://soekris.com/products.html


-- 
These are my opinions.  I hate spam.



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

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

[Hal Murray]

rnabioul...@gmail.com said:
> Hi, generally speaking, what are the performance differences between the
> following: 1. direct RS-232 (i.e., what I believe is a standard PCI card
> offering RS-232---essentially UARTs interfaced more-or-less directly to  the
> PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might  also
> have an IRIG input or even an onboard GNSS receiver). 

You didn't say what you are trying to do.

Most OSes can grab a time-stamp when a modem control signal changes.  (I know 
nothing about Windows.)

Latency will depend on the IO hardware, CPU architecture,, the interrupt 
software, and what the CPU is doing: other interrupts, cache faults, and 
stuff like that.

With RS-232 on PCI, the latency in the hardware should be low, as in sub 
microsecond.

USB is polled.  That adds the noise/jitter of the polling interval and the 
opportunities for hanging bridges.
  http://www.leapsecond.com/pages/m12/sawtooth.htm
(That page shows the interaction between the PPS and the GPS receiver clock.  
You get similar graphs with the interaction between PPS and USB clock.)

Most low cost RS-232/USB units are old/slow USB 1.  That polls at 1 ms.  
There is at least 1 chip (FTDI FT232RL) that uses USB 2 which is 8 times 
faster.
  I got a breakout board (TTL levels, not RS-232) from Sparkfun.
https://www.sparkfun.com/products/12731
  Adafruit has USB-RS232 version.  I haven't tried one.
https://www.adafruit.com/product/18

I don't know of any advantages of putting the GPS receiver on the PCI card.  
(other than the obvious of one less lump that needs space on a shelf)

If you have custom logic on a PCI chip, it should be reasonable to get better 
timing.  The simple approach would be to just put a DDS style counter out there 
so reading the clock is as simple as an IO read.  But IO reads are slow.  There 
should be a way to calibrate how slow that is and then use that to calibrate 
normal time keeping.


albertson.ch...@gmail.com said:
> I said "two orders of magnitude"  it might even be three orders. 

3 seems reasonable.  That's milli-second to micro-second.



I think the Linux PPS code has an option to flap a pin on the printer port when 
it sees a PPS.  The idea is that you can measure the latency with a scope: 
trigger on PPS and see how long until the printer pin changes.  I haven't tried 
it.

-- 
These are my opinions.  I hate spam.



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

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

[MLewis]

On 14/02/2017 12:24 AM, Chris Albertson wrote:

Pretty dramatic difference between a "real" serial port and USB.  Like two
orders of magnitude or more.

If you computer lacks a serial port, just buy a new computer.  The
Raspberry Pi or the like costs about $40 the serial port has a pin that is 
tied to an interrupt.  If
you read the code associated with that interrupt it is like maybe 4 or 6
lines of C and VERY simple.
...


Great for picking up the PPS.
Know of any with an Ethernet port, preferably two, that aren't run from 
a USB controller?


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.

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

[Chris Albertson]

Pretty dramatic difference between a "real" serial port and USB.  Like two
orders of magnitude or more.

If you computer lacks a serial port, just buy a new computer.  The
Raspberry Pi or the like costs about $40.   But the money you save on
electric power will pay off that $40 in less than a year.

Why is this?  the serial port has a pin that is tied to an interrupt.  If
you read the code associated with that interrupt it is like maybe 4 or 6
lines of C and VERY simple.   USB on the other hand is packetized.
Nothing happens on till a block of data comes in and then it is quite
complex so the time from the pin going active to the internal counter being
sampled is quite variable   I said "two orders of magnitude"  it might even
be three orders.


On Mon, Feb 13, 2017 at 8:07 AM, Ruslan Nabioullin 
wrote:

> Hi, generally speaking, what are the performance differences between the
> following: 1. direct RS-232 (i.e., what I believe is a standard PCI card
> offering RS-232---essentially UARTs interfaced more-or-less directly to the
> PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI cards (which might also
> have an IRIG input or even an onboard GNSS receiver).
>
> Thanks in advance,
> Ruslan
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 

Chris Albertson
Redondo Beach, California
___
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.

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

[Gary E. Miller]

Yo Ruslan!

On Mon, 13 Feb 2017 11:07:49 -0500
Ruslan Nabioullin  wrote:

> Hi, generally speaking, what are the performance differences between
> the following: 1. direct RS-232 (i.e., what I believe is a standard
> PCI card offering RS-232---essentially UARTs interfaced more-or-less
> directly to the PCI bus); 2. RS-232 via USB; 3. PPS decoding PCI
> cards (which might also have an IRIG input or even an onboard GNSS
> receiver).

#2 will have a lot higher jitter than #1.  On a #2 you can expect
500 micro second best timing.  On a #1 you can get to 1 micro second.

On a RasPi using GPIO you can get to 500 nano second.  Data
available on request, but better on the de...@ntpsec.org list.

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
___
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.