[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] PPS over USB
From: |
Hal Murray |
Subject: |
Re: [gpsd-dev] PPS over USB |
Date: |
Mon, 07 May 2012 13:15:35 -0700 |
address@hidden said:
> I guess I still don't understand the bufferbloat / thumbgps requirements,
> but either you need a very stable clock local, or you need a bunch of
> clocks which are sync'ed to each other (across the world). Problem seems
> to be that unless you all have the same reference (eg gps) then you could
> all be microsecond "accurate", just all at an offset to each other?
The big picture is that the bufferbloat project wants to measure queuing
delays.
How does time get involved?
After the typical exchange of a pair of NTP packets, you have 4 time stamps:
the time the request left the client
the time the request arrived at the server
the time the response left the server
the time the response arrived at the client
Those time stamps are local time and will be off by any errors in the system
clock.
ntpd assumes the network delays are symmetric and computes the clock offset.
If you assume that both clocks are accurate, you can compute the network
delays. If you collect data for a while, you can assume that the lowest
network delays are what you get when the packets don't encounter any queuing
delays. Longer delays are due to queuing someplace.
The numbers work out reasonable. The bufferbloat guys are interested in
delays of 10s or 100s of ms. 1 ms clocks are good enough to see that.
------------
The next step is that the people who are likely to help collect data for the
bufferbloat project don't have soldering irons, and the target router does
have USB.
Eric's PPS mod (add one wire) to a typical GPS "mouse" solves all their
problems because he's found a vendor that will do the soldering iron level
work.
----------
> 1) My jitter is slightly higher than expected. Q: is this related to the
> way GPSD estimates the arrival time of the first $, ie can I make a change
> to the gpsd algorithm which would give me 0.5ms precision on my NMEA time
> (from venus 6 over usb)
You can collect enough data to analyze that. Turn off ntpd and gpsd and such
so your local clock won't get jerked around. Or point ntpd to a nearby (LAN)
system with a good clock.
Write a hack program to grab data from your GPS unit and log the data and
timestamps to a file. Then play around with graphing the data. (Poke me
offline if you want some starter code.)
-----------
There is another important worm in this area. The magic phrase is "hanging
bridge".
Consider what happens if the clock driving your USB logic gets synchronized to
GPS time. It might always poll the device at exactly the right or wrong time.
When that happens, you can't average out the noise. Since your local USB
clock is probably tweaked by temperature, slow temperature changes are almost
guaranteed to tickle this problem.
Short version here (good pictures):
Motorola GPS M12+ Sawtooth
http://www.leapsecond.com/pages/m12/sawtooth.htm
Long story here:
Tom Clark and Rick Hambly: Timing for VLBI
http://gpstime.com/files/tow-time2009.pdf
-------------
>> In the context of bufferbloat, accuracy is not a big deal. We could go
>> through a calibration dance if that helps.
> Can you explain what you mean in more detail? I get the difference between
> accuracy, stability, jitter, but not what you mean here?
Suppose your clock is right-on and mine if off by 13 ms and we are trying to
measure network delays.
We exchange packets for a while when our network connections are idle. Now we
know the clocks look like they are off by 13 ms. Actually, the network routing
may be asymmetric which would inject a difference if both clocks were correct
and/or modify the difference if the clocks are off.
It doesn't matter as long as it is stable. The bufferbloat guys are trying to
measure queuing delays. They don't think of it as "clocks are off by 13 ms".
They say "47 ms from me to you" and "60 ms from you to me". If you now take
measurements when real traffic is also flowing, any extra delay times are
queuing delays.
--
These are my opinions, not necessarily my employer's. I hate spam.
- Re: [gpsd-dev] PPS over USB, (continued)
- Re: [gpsd-dev] PPS over USB, Eric S. Raymond, 2012/05/07
- Re: [gpsd-dev] PPS over USB, Eric S. Raymond, 2012/05/06
- Re: [gpsd-dev] PPS over USB, Eric S. Raymond, 2012/05/06
- Re: [gpsd-dev] PPS over USB, Terje Mathisen, 2012/05/06
- Re: [gpsd-dev] PPS over USB, Gary E. Miller, 2012/05/06
- Re: [gpsd-dev] PPS over USB, Dave Taht, 2012/05/06
- Re: [gpsd-dev] PPS over USB, Ed W, 2012/05/07
- Re: [gpsd-dev] PPS over USB, Terje Mathisen, 2012/05/07
- Re: [gpsd-dev] PPS over USB, Ed W, 2012/05/07
- Re: [gpsd-dev] PPS over USB, Gary E. Miller, 2012/05/07
- Re: [gpsd-dev] PPS over USB,
Hal Murray <=
- Re: [gpsd-dev] PPS over USB, Eric S. Raymond, 2012/05/07
- Re: [gpsd-dev] PPS over USB, Dave Taht, 2012/05/07
- Re: [gpsd-dev] PPS over USB, Eric S. Raymond, 2012/05/07
- Re: [gpsd-dev] PPS over USB, Hal Murray, 2012/05/08
- Re: [gpsd-dev] PPS over USB, Eric S. Raymond, 2012/05/08
- Re: [gpsd-dev] PPS over USB, Ed W, 2012/05/08
- Re: [gpsd-dev] PPS over USB, Dave Taht, 2012/05/08
- Re: [gpsd-dev] PPS over USB, Eric S. Raymond, 2012/05/08
- Re: [gpsd-dev] PPS over USB, Ed W, 2012/05/08
- Re: [gpsd-dev] PPS over USB, tz, 2012/05/08