From 2436d783d1f0c31d8782b6297a1e43f377457ba6 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Fri, 23 Sep 2011 13:22:39 -0400 Subject: First step towards including new profiling results. --- www/performance/performance.xml | 145 +++++++++++++++++++++++++++------------- 1 file changed, 98 insertions(+), 47 deletions(-) (limited to 'www') diff --git a/www/performance/performance.xml b/www/performance/performance.xml index 8ec4ae88..c1aa314f 100644 --- a/www/performance/performance.xml +++ b/www/performance/performance.xml @@ -31,10 +31,10 @@ 1.3 - 20 September 2011 + 23 September 2011 esr - Note that this paper is now only historical. + Update to include whole-cycle profiling. @@ -69,9 +69,11 @@ NMEA and baud rates higher than the NMEA-standard 4800 bps as ways to increase GPS performance. While working on gpsd, I became interested in evaluating these claims, which have some implications for the design of -gpsd. This paper discusses the theory and -the results of profiling the code, and reaches some conclusions about -system tuning and latency control. +gpsd. Later, the average and peak latency +became of interest for modeling the performance of GPS as a time +service. This paper discusses the theory and the results of profiling +the code, and reaches some conclusions about system tuning and latency +control. @@ -82,13 +84,40 @@ accuracy of its fixes, is a function of the GPS system and receiver design; GPSD can do nothing to affect it. However, a GPS fix has a timestamp, and the transmission path from the GPS to a user application introduces some latency (that is, delay between the time -of fix and when it is available to the user). Latency could be significant -source of error for a GPS in motion. +of fix and when it is available to the user). + +Latency could be significant source of position error for a GPS in +motion. It may also be a significant issue if the GPS is being used as +a high-precision time source. + +This paper describes the results of two rounds of measurement +using different tools. Both yielded interesting results, and can usefully +be juxtaposed with one another. + +The first round was performed in 2005 using a version of the +code very near 2.13. This was before the JSON protocol change and before +GPSD developed the capability to do automated cycle detection. +Consequently the statistics extracted were primarily timings of +packets coming over the wire from the GPS. + +The second round was performed in 2011 using a version of the +code between 3.1 and 3.2. At this time GPSD was being evaluated as a +high-precision time source for use in measuring network latency and +checking the performance of NTP. The profiling tools built into +GPSD had been rebuilt with an emphasis on timing the entire GPS +reporting cycle, rather than individual packets. + +Both the 2005 and 2011 rounds used the same consumer-grade +sensor attached via USB to a Linux machine via a USB link, reporting +to gpsd which is polled via sockets by a +profiling application. -The case we'll consider is a normal consumer-grade USB sensor -attached to a Linux machine via an RS232 or USB link, reporting to -gpsd which is polled via sockets by -application. Consider the whole transmission path of a PVT + +Per-sentence profiling + +Modeling the reporting chain + +Consider the whole transmission path of a PVT (position/velocity/time) report from a GPS to the user or user application. It has the following stages: @@ -117,7 +146,7 @@ into a session structure available to the user application. -It is also relevant that consumer-grade GPses do not expect to +It is also relevant that consumer-grade GPSes do not expect to be polled, but are designed to issue PVT reports on a fixed cycle time, which we'll call C and which is usually 1 second. gpsd expects this. A few GPSes @@ -255,12 +284,12 @@ order of ten microseconds. - -Data and Analysis + +Data and Analysis I took measurements using a Haicom 204s USB GPS mouse. This device, using a SiRF-II GPS chipset and PL2303 USB-to-serial chipset, is -very typical of today's consumer-grade GPS hardware; the Haicom people +very typical of 2005's consumer-grade GPS hardware; the Haicom people themselves estimated to me in late 2004 that the SirF-II had about 80% and rising market share, and the specification sheets I find with Web searches back this up. Each profile run used 100 samples. @@ -281,8 +310,7 @@ a tool built for this purpose and included in the distribution. ––enable-profiling is that a form of the B command that normally just reports the RS232 parameters can be used to set them (it ships a SiRF-II control string to the GPS and then changes the line -settings). I discovered that something in the SiRF-II/PL2303 -combination chokes on line speeds of 19200 and up. +settings). Another effect is to enable a Z command to switch on profiling. When profiling is on, each time @@ -308,8 +336,8 @@ see the effect of profiling overhead. The first thing to notice here is that the fix latency can be just over a second; you can see the exact figures in the raw data. Where is the time going? Our next -graph was generated with gpsprof -t -"Haicom 204s" -T png -f raw -s 4800 +graph was generated with gpsprof -T png -t +"Haicom 204s" -f raw -s 4800
Instrumented latency report @@ -334,8 +362,7 @@ low overhead. It is also a little surprising that E1 is so large relative to E1+T1. Recall, however, that this may be measurement error. -Our third graph (gpsprof -t "Haicom 204s" -T -png -f split -s 4800 changes the presentation so we can see +Our third graph (gpsprof -t "Haicom 204s" -T png -f split -s 4800 changes the presentation so we can see how latency varies with sentence type.
Split latency report @@ -435,11 +462,40 @@ different USB GPS mouse using the same SiRF-II/PL2303 combination: very similar to the Haicom numbers. The main difference seems to be that the BU303b firmware doesn't ship GPGLL by default. + + +Per-cycle profiling + +Modeling the reporting chain + +When the old GPSD protocol was replaced by an application of JSON +and the daemon developed the capability to perform automatic detection of +the beginning and end of GPS reporting cycles, it became possible to measure +whole-cycle latency. Also, embedding timing statistics in the JSON digest +of an entire cycle rather than as a $ sentence after each GPS packet +significantly reduced the overhead of profiling in the report stream. + + + + + +Data and Analysis + + + + + + + Conclusions -All these conclusions apply to the consumer-grade GPS hardware -generally available in 2005, e.g. with a C of one second. +All these conclusions apply to the consumer-grade GPS hardware +generally available in 2005 and today in 2011, e.g. with a cycle time +of one second. As it happens, 2005 was just after the point when +consumer-grade GPS chips stabilized as a technology, and though unit +prices havdve fallen they have changed very little in technology and +performance over the intervening six years. For Application Programmers @@ -479,33 +535,28 @@ capabilities they support could be just as effectively supported through NMEA's $P-prefix extension mechanism. -For the Design of <application>gpsd</application> - -gpsd does not introduce measurable -latency into the path from GPS to application. Cycle times would -have to decrease by two orders of magnitude for this to change. +For GPSD as a Time Service -Setting a 9600bps line speed, and then polling the GPS twice a -second rather than waiting for an update, would halve the expected -latency of the system from 0.5 to 0.25sec. This would be right at the -edge of the SiRF-II's performance envelope. +We have measured a typical intrisic time latency of about 70msec due to +on-GPS processing and the USB polling interval. While this is noticeably +higher than NTP's expected accuracy of ±10msec, it should be +adequate for most applications other than physics experiments. - -2009 Update - -One consequence of the new gpsd wire protocol is that client -applications no longer poll the daemon. This means the "W' statistic -is always zero, and is no longer collected when timing sentences. - - -2011 Update - -While I believe the conclusions this paper reached are still valid, the -timing facilities it relied on have been replaced with a different and -simpler set using the automatic cycle detection logic introduced in -2.90 to do whole-cycle timing rather than per-sentence timing. - +For the Design of GPSD + +In 2005, I wrote that gpsd does not +introduce measurable latency into the path from GPS to application. I +said that cycle times would have to decrease by two orders of +magnitude for this to change. + +In 2011, with better whole-cycle oriented profiling tools and a +faster test machine, latency incurred by +gpsd can be measured. It is less than 0.1 +sec on a 2.66 Intel Core Duo under normal load. How much less depends +on how the model computations underestimate RS232 transmission time +for the GPS data. + -- cgit v1.2.1