[ntp:questions] is USB inherently evil, or only if something else is on the bus?
elliott.ch at verizon.net
Thu Aug 9 20:29:30 UTC 2012
There is no such thing as a USB interrupt. Under USB version 2.0 and below,
a device can transmit data only when polled by the host. Under USB 3.0, a
device can tell a host it has data to send. USB has four modes of data
transfer: Control, bulk, interrupt, and isochronous. Control is used to
tell the host of the device's existence and its capabilities, and to
configure the device by the host. Bulk is used by mass storage and scanner
devices to transfer large amounts of data; it has error checking, but no
guaranteed transfer rate. Interrupt mode has error checking and a
guaranteed latency, from 1 to 255 ms. In other words, the host will poll
the device for data every 1, 2, ... (in powers of 2 for OHCI controller
hosts) ms. The device can send a previously agreed upon nop if it has no
data to transfer, but it counts as a transfer. "Isochronous transfers are
streaming, real-time transfers that are useful when data must arrive at a
constant rate or within a specific time limit and occasional errors are
tolerable." There is no error checking, and hence no retransfer of data
received with errors. Examples of uses include USB microphones and
I wrote a C++ program that sets up an RS-232 serial port exactly like NTP
does. The port is driven by a USGlobalSat BU-353W GPS USB device, converted
to a COM device by a Prolific USB-to-Serial driver, and read at 57,000 baud.
The program waits for an NMEA RMC string at the port, records the time
received using the GetSystemTime Windows API call, and outputs the time
received, the offset between system time and GPS time, and the NMEA RMC GPS
string to a file; it then waits for another RMC string. Then I used a Java
program to plot the system time vs. the offset. You can see a typical
result at https://skydrive.live.com/redir?resid=92A71A1C4B64FD41!270.
An explanation of this plot is in order. The X-axis is time in hours past
midnight in UTC. The Y-axis is the offset (difference GPS Time minus system
time) in milliseconds. The squiggly lines in the graph are the offsets.
The straight line somewhat bisecting the offsets is the regression line Y =
m X + b. The parallel lines on either side of the regression line are +- 3
times the standard error of the prediction (Y-predicted). If the offsets
were normally distributed, then the probability of an offset falling outside
the standard error of the prediction is less than 0.01. In statistical
quality control terms, a process is considered to have fundamentally changed
when it falls outside these limits; there is an error.
The process shown in the graph repeats indefinitely using my BU-353W. In
other words, the offsets always begin at about 300 ms, rise slowly to about
360 ms, vary erratically between 260 and 360 ms for about two hours, settle
at 260 ms, and then rise slowly to 360 ms to repeat forever.
It is not clear to me if the problem is the USB interface or the GPS device.
On the one hand, if the Prolific USB-to-Serial driver is using USB interrupt
mode and requesting data every 255 ms, and the USB controller schedules data
transfers just slightly out of sync with system time, then the graph is
fully explained, except possibly for the erratic behavior between 260 and
360 ms offsets. On the other hand, using the SiRFdemo.exe program, one can
access the GPS output in a SiRF proprietary binary format, interpreted and
labeled. In that output there is a quantity labeled "Clock Bias" (right now
104571115 ns) which also varies up and down similar in pattern to the
offsets. If the GPS output were captured in binary and the clock bias
applied to the "EstGPSTime" also output, would the time be more accurate?
Don't know, in part because USGlobalSat won't disclose the binary format.
It might be possible to write a USB driver to capture the binary output of
the BU-353W and output it to a file in hex and then figure it out.
Microsoft has a page here
spx entitled "How to Access a USB Device by Using WinUSB Functions" that
appears to explain how this could be done, but I have not tried it yet.
If the problem with the wandering offsets is the USB interface, then I do
not see why the short-term solution is not to poll the USB GPS device every
1 ms. Then at least one would have 1 ms resolution of the time the GPS
string was read, and any offset would be due to the delay in the GPS sending
the data. (But I just cannot persuade myself that I am the first to think
of this.) Then long term solution might be to switch to USB 3.0 and let the
GPS notify the host when there is data to send.
This whole message is based on reading 155 pages (of 504) of Axelson, J.
(2009). USB Complete: The Developer's Guide (Fourth ed.). Madison, WI:
Lakeview Research LLC. Let the reader beware.
> -----Original Message-----
> From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On
> Behalf Of Rick Jones
> Sent: Wednesday, August 08, 2012 5:35 PM
> To: questions at lists.ntp.org
> Subject: [ntp:questions] is USB inherently evil, or only if something
> else is on the bus?
> I've scrounged a couple old Pentium M laptops (Hewlett-Packard nc6000s
> for the trivia-minded) with serial ports while entertaining the
> possibility of undertaking a project to do what so many others have
> done - connect-up a GPS receiver with PPS support. That has me
> wondering about some of the previous discussion about USB and how it is
> perhaps not "evil" but considered quite sub-par for serving-up the PPS
> Is that unsuitability inherent in USB, so it matters not whether there
> is anything else on the USB, or is it more a case of being "bad"
> generally only when other things are on the same USB? I'm still
> looking to go serial, but was wondering.
> Also, speaking of things considered "bad" and drifting - fudging the
> LOCAL(0) is definitely frowned upon right? If I happen to have say
> four servers in a location which might loose its connectivity to the
> outside world I probably don't want those servers to fall-back on
> LOCAL(0) right? Would configuring each to have the other three as
> "peer" entities be the way to go?
> Pointers to the fine manual for any of the above would be welcome.
> rick jones
> I don't interest myself in "why." I think more often in terms of
> "when," sometimes "where;" always "how much." - Joubert these opinions
> are mine, all mine; HP might not want them anyway... :) feel free to
> post, OR email to rick.jones2 in hp.com but NOT BOTH...
> questions mailing list
> questions at lists.ntp.org
More information about the questions