On Tue, Mar 6, 2012 at 10:21 AM, Dennis Ferguson
<dennis.c.fergu...@gmail.com> wrote:
>
> On 5 Mar, 2012, at 18:33 , Terje Mathisen wrote:
>
>> Chris Albertson wrote:
>>> How to measure? You need to modify the interrupt handler to raise a
>>> pin on a (say) parallel port. then measure the time from PPS to that
>>> pin going high with a time interval counter. Such counters are cheap
>>> now on eBay.
>>
>> What I'm asking for is GPS unit with such an interval timer embedded on it,
>> said counter to be restarted on every PPS signal.
>>
>> The query protocol then becomes, as seen from the host:
>>
>> while (1) {
>> before = gethirestime();
>> gps_time = poll_gps();
>> after = gethirestime();
>> if (after - before < MAX_LATENCY)
>> use_timestamp(after, gps_time);
>> sleep(1);
>> }
>>
>> I.e. polling the GPS (at any time) returns the current time in NTP 32:32
>> format directly. There is no need to ever interrupt anything with a clock
>> source you can poll at any time.
>
> Note that the problem with the above is that you are asking poll_gps()
> to complete a transaction which is going to require more than 100 bits
> to be exchanged on a full-speed USB interface (I've not seen a GPS chipset
> that provides higher speed USB than that) which only delivers
> 12 bits per microsecond. (after - before) is nearly certain to
> exceed 10 microseconds, so you are going to get no where near
> sub-microsecond timing unless you have some idea of where in the
> (after - before) interval the gps_time timestamp was actually acquired.
It's even worse. The above algorithm assume that it is never
interrupted. What happens if the CPU is taken away to run a web
browser or whatever at some random point within the loop.
Likewise what of the USB interface is shared with other devices like
say a thumb drive or an external disk. The the GPS does not get full
control oof the cable and has to share bandwidth.
Also do remember that USB is "packetized". Data are held in a
buffer until it is full then it is sent at a very high bit rate.
So on short time scales the data rate is not predictable.
This is why a PPS works so well. It is the shortest possable
"message" and there is no bufering at either end. Buffering is what
kills both USB and Ethernet for precision timing. Both are
packetized. When a buffer is filled there is always some
unpredictable random time before the firmware notices it is full and
when it is send. Then on the other end the data goes into sme kind
of buffer pool and mmay not be processed right away. The delay on
that end is unpredictable too
NTP has the best algorithm for handling these problems. It measures
the delay and also, importantly, the jitter or standard deviation of
the delay. Any USB connected device is going to have considerable
standard deviation of the delay because of buffering at each end
Chris Albertson
Redondo Beach, California
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
