On Thu, 16 Nov 2017, Rob Janssen wrote:
Bill Unruh wrote:
I am using chrony with serial PPS on a number of different machines, and I
see the 6-7 us figure
on HP Proliant systems while on Dell PowerEdge sytems it is more like 1us.
No idea where the difference comes from.
How do you measure
On Thu, 16 Nov 2017, Denny Page wrote:
On Nov 16, 2017, at 10:32, Bill Unruh wrote:
On Thu, 16 Nov 2017, Denny Page wrote:
Interrupt latency for character devices in Linux is 6-7 us, even with no other
activity. You
It has been a while but I ran tests on a system in which I changed the
Bill Unruh wrote:
I am using chrony with serial PPS on a number of different machines, and I see
the 6-7 us figure
on HP Proliant systems while on Dell PowerEdge sytems it is more like 1us.
No idea where the difference comes from.
How do you measure that latency? It does seem that the parall
> On Nov 16, 2017, at 10:32, Bill Unruh wrote:
>
> On Thu, 16 Nov 2017, Denny Page wrote:
>
>> Interrupt latency for character devices in Linux is 6-7 us, even with no
>> other activity. You
>
> It has been a while but I ran tests on a system in which I changed the state
> of a parallel port
On Thu, 16 Nov 2017, Rob Janssen wrote:
Bill Unruh wrote:
On Thu, 16 Nov 2017, Denny Page wrote:
Interrupt latency for character devices in Linux is 6-7 us, even with no
other activity. You
It has been a while but I ran tests on a system in which I changed the
state
of a parallel port
Bill Unruh wrote:
On Thu, 16 Nov 2017, Denny Page wrote:
Interrupt latency for character devices in Linux is 6-7 us, even with no other
activity. You
It has been a while but I ran tests on a system in which I changed the state
of a parallel port pin and fed that into an interrupt grabbing
It has now been suggested to you at least by two different people-- hook your
system up to the network, and do a timing using a nearby ntp server.
That will give you of the order of 10-20us accuracy, and you can see if that
time is the same as your pps time.
I have no idea how accurate gpsd is.
On Thu, 16 Nov 2017, Denny Page wrote:
Interrupt latency for character devices in Linux is 6-7 us, even with no other
activity. You
It has been a while but I ran tests on a system in which I changed the state
of a parallel port pin and fed that into an interrupt grabbing the system time
ju
I'm not too concerned about the accuracy of the PPS. This particular GPS
receiver is pretty high quality.
https://learn.adafruit.com/adafruit-ultimate-gps/overview It delivers the
NMEA data and the PPS. A number of online resources describing similar
projects and the GPSD Time Service HOWTO page a
Interrupt latency for character devices in Linux is 6-7 us, even with no other
activity. You can get better than this using a gpio and spinning on it, but I
haven’t seen anyone do this with with serial pps.
Denny
> On Nov 16, 2017, at 09:57, Bill Unruh wrote:
>
> The PPS accuracy is largely
William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _| Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 | and Gravity __|_ www.theory.physics.ubc.ca/
On Thu, 16 N
I'm trying to determine the best way to get an idea of my clock accuracy
now that I'm getting the PPS signals. Is that "chronyc tracking"? When I do
"chronyc sources" or "chronyc sourcestats" those seem to indicate NMEA
offsets that are on the order of 40-60ms.
debian@beaglebone:~$ chronyc sources
12 matches
Mail list logo
