How would you like to help fix the Internet?
One of the efforts I’ve been contributing to during the last year is the Bufferbloat project, a group of experienced Internet engineers who believe that excessive buffering and poor queue-management strategies may be the real villains behind a lot of network problems commonly attributed to undercapacity.
Before we can solve the problem, we need to measure and map it by collecting a lot of packet-propagation-time statistics. Awkwardly, we suspect that one of the services being screwed up by bufferbloat-induced latency spikes is the Network Time Protocol. So…Dave Täht (aka Dave from my basement) is trying to build a device he calls the Cosmic Background Bufferbloat Detector. The CBBD would be a flock of routers scattered all over the world, watching NTP packet timings using a common timebase independent of NTP, and sending data back to a collection server for analysis and visualization.
That’s where I, as the lead of the GPSD project, come in. GPSes are an obvious candidate for a high-precision NTP-independent time service. But there’s a problem with that…
With rare and extremely expensive exeptions, GPSes only report time to a hundredth of a second, at most, in their data stream. And we’ve found by experiment that SiRFs, the chip used in 80% of consumer-grade GPSes, has about a long-period wobble of up to 170 milliseconds in its time-reporting latency. This is no good; NTP time is supposed to be accurate to 10 milliseconds, so for diagnostic purposes we therefore want a timebase about an order of magnitude better than that or at about 1ms accuracy.
There is a way to get this from GPS. GPS chips have an output called 1PPS, a pulse that’s emitted at the start of each GPS-clock second with accuracy to 50 nanoseconds. So, in theory, simple: you use the 1PPS to trigger an interrupt on your host machine, latch that as top of the second, and use it to condition your clock. Even with the expected amount of interrupt-processing overhead you can expect this to keep your local clock accurate to the common timebase to about 10 microseconds – two orders of magnitude finer than our 1-millisecond accuracy goal.
GPSes, or at any rate the sort of inexpensive GPSes you’re limited to when you’re contemplating deploying a hundred or more attached to CBBD routers, are simple beasts. They’re built around a module like the SiRFStar II or III that’s basically a single chip with RF and signal-processing stage for the GPS. That module ships TTL-level serial data, with two lines for TX/RX, a ground, RTS, and a fifth wire carrying the PPS strobe (usually mapped as the DCD or Data Carrier Detect line).
Typically these wires are carried to a serial-to-USB converter such as a PL2303 which provides the data path off the device. Yes, some GPSes go to RS232, but that’s increasingly uncommon and we couldn’t use those anyway because the inexpensive routers we can afford to deploy by the hundred only have USB ports. Yes, serial-to-USB adaptors do ship an event corresponding to a change in DCD line state; turns out USB latency costs you about 50 microseconds of slop, which is well within our maximum error budget.
This is where it gets messy.
You see, in order to cut costs (or something) most GPS manufacturers drop the 1PPS strobe line on the way out. They could connect it to the DCD input on the serial-to-USB converter, but they don’t.
Now let me introduce you to two devices. Exhibit A is the Globalsat BR355. I have one on my desk. This is an extremely typical consumer-grade GPS mouse based on the SiRFStar III. It doesn’t ship 1PPS, though older versions sold under the same name apparently did – removed to cut costs.
Exhibit B is the ZTI Z050, advertised as a USB navigation and timing dongle. It fits a GPS chip and serial-to-USB converter in a thumb-drive case. It uses a different, non-SiRF chip called a Trimble, but that’s a detail; it ships to the converter over TTL just like the SiRFStar. But the ZI050 does carry the 1PPS trace to the serial-to-USB converter, and you can see PPS events on the USB bus. ZTI advertises 1ms accuracy,
Essentially, the logical differences between these devices come down to the presence or absence of one trace on the circuit board.
The BR-355 costs $36. The Z050 says “call for quote” and I was told $950. Yes, that’s right; that one PPS trace costs $914.
Now, part of this is the North American distributors marking the device up insanely. A European friend caled ZTI direct and was quoted €175 or about $225. That’s not the highway robbery the distributor was attempting (they’re called “Omnicor” – try not to give them your business) but it’s still bloody ridiculous.
So I’m trying to think up a solution, and it occurred to me that building your own USB GPS from parts and a custom circuit board isn’t that complicated. One of my GPSD devs has actually done it. We can’t use a homebrew GPS for this deployment, that wouldn’t scale to a hundred units, but …
…isn’t there an opportunity here? It ought to be possible to manufacture a timing dongle like the ZI050 really cheaply; remember, the PCB-level difference is between it and that $36 BR-355 is basically one trace. One design engineer with connections to a Taiwanese job shop ought to be able to get a thousand of these cranked out at barely $10 a pop.
That’s what I’m looking for. These clowns should have competition. So, calling all open-source hardware engineers – can we do this thing? Spec a parts list, design a PCB to fit in a thumb drive, publish it as an open design, and then actually get the little sucker manufactured?
There might even be money in this. The Bufferbloat project wants at least a hundred of these for the CDDB, and the thumb-drive form factor could make it really popular with laptop users.
Anybody feeling entrepreneurial?