From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (static-71-162-243-5.phlapa.fios.verizon.net [71.162.243.5]) by huchra.bufferbloat.net (Postfix) with ESMTP id 2978B200627 for ; Wed, 21 Sep 2011 16:02:06 -0700 (PDT) Received: by snark.thyrsus.com (Postfix, from userid 23) id 2275820C2E5; Wed, 21 Sep 2011 19:02:05 -0400 (EDT) From: Eric Raymond To: Dave Taht , Jim Gettys , bloat-devel@lists.bufferbloat.net Subject: Preliminary results of using GPS to look for clock skew Message-Id: <20110921230205.2275820C2E5@snark.thyrsus.com> Date: Wed, 21 Sep 2011 19:02:05 -0400 (EDT) X-Mailman-Approved-At: Wed, 21 Sep 2011 16:42:55 -0700 X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:02:06 -0000 As a step toward implementation of Dave's Cosmic Background Bufferbloat Detector, I took on the job of employing GPS as a reliable local time source to check whether an NTP-assisted system clock has significant skew from GPS. Towards this end, I've just spent a couple of days rebuilding and improving the latency-profiling machinery in GPSD. What this allows me to do is collate the following pieces of data: * The GPS's time of a fix in properly leapsecond-corrected UTC (Call this T) * The NTP-corrected system time at which the first burst of fix data from the device wakes up gpsd's select(2). Call this S (Start of reporting cycle) * When the daemon has received and processed the entire burst of packets constituting a reporting cycle and is about to ship JSON to the client. Call this E (End of reporting cycle). * When the client recieves the report. (R = receipt time). What's interesting is to plot the deltas S - T, E - S, and R - S as a stacked-impulse graph. I can do this at will now. More importantly, so can anyone with my software and GPSD. We have a working GPSD port to CeroWRT, so our test routers can be instrumented. The entire height R-T approximates the entire fix latency. I say "approximates" because, of course, T is on a different timebase than R, S, and E, and NTP's 10ms fuzz is an issue. But S-T gives us an idea of the atomic-clock-vs-system-clock time. There's nothing surprising about my setup - FIOS to an N600 running a recent OpenWRT build to a 2.66GHz Intel Core Duo 2 machine running Ubuntu 10.04 LTS. Over runs of 20-100 fixes, S-T (the clock-skew figure) ranges from 66 to 76 milliseconds. Total latency R-T is steady at about 0.38 seconds. R-S vanishes - it's close to 0.9 milliseconds. Total fix latency is completely dominated by E-S, the time for gpsd to receive and process the fix data from the GPS. And I'm not seeing a lot of bursty variation in these measurements. I'm going to investigate further. In particular, I'm going to try to either measure or compute how much of E-S is I/O time. My suspicion is that almost all of it is, and that gpsd's actual computation time is negligible by comparison. But preliminary indications are that NTP is in fact doing a pretty good job of keeping my system clock conditioned. I'm not seeing bufferbloat effects on time service. However, I'd welcome having my code and assumptions checked. This kind of profiling is tricky work, with large vulnerabilities to small mistakes in detail. That's the main reason I'm describing these results as 'preliminary'; some skeptical review is needed to soliudify and verify them. -- Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979