An implementation goal of compression code was to arrive at something simple enough to run at ISDN speeds (64Kbps) on a typical 1989 workstation. 64Kbps is a byte every 122us so 120us was (arbitrarily) picked as the target compression/decompression time./45/
Machine | Average per-packet processing time (us) | |
---|---|---|
Compress | Decompress | |
Sparcstation-1 Sun 4/260 Sun 3/60 Sun 3/50 HP9000/370 HP9000/360 DEC 3100 Vax 780 Vax 750 CCI Tahoe | 24 46 90 130 42 68 27 430 800 110 | 18 20 90 150 33 70 25 300 500 140 |
As part of the compression code development, a trace-driven exerciser was developed. This was initially used to compare different compression protocol choices then later to test the code on different computer architectures and do regression tests after performance `improvements'. A small modification of this test program resulted in a useful measurement tool./46/ Table 3 shows the result of timing the compression code on all the machines available to the author (times were measured using a mixed telnet/ftp traffic trace). With the exception of the Vax architectures, which suffer from (a) having bytes in the wrong order and (b) a lousy compiler (Unix pcc), all machines essentially met the 120us goal.
45. | The time choice wasn't completely arbitrary: Decompression is often done during the inter-frame `flag' character time so, on systems where the decompression is done at the same priority level as the serial line input interrupt, times much longer than a character time would result in receiver overruns. And, with the current average of five byte frames (on the wire, including both compressed header and framing), a compression/decompression that takes one byte time can use at most 20% of the available time. This seems like a comfortable budget. |
46. | Both the test program and timer program are included in the ftp-able package described in appendix A as files tester.c and timer.c. |