Re: [gpsd-dev] PPS over USB

[Hal Murray]

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.