Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!rjn
From: rjn@hpfcdc.HP.COM (Bob Niland)
Newsgroups: comp.dcom.modems
Subject: Re: Re: Telebits and uucp g-protocol
Message-ID: <4980005@hpfcdc.HP.COM>
Date: 3 Aug 89 04:47:56 GMT
References: <328@larouch.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 72

re: >> I'm using a pair of USR HST modems between work and home.  Both
    >> computers address the modems at 19200 bps, and I get phenomenal
    >> throughput using UUCP 'f', even on pre-compressed binary files.

> jparnas@larouch.UUCP (Jacob Parnas) asks...
> What throughput do you get on compressed and uncompressed data files?

From an old posting,  updated this evening...

These tests were performed between a 320 (a 16.6 MHz 68020) running HP-UX
5.5 and a 350 (25 MHz 68020) running 6.0.  The serial interface was port 0
of a 98642A MUX on both ends.  The HSTs were configured as per [my usual
recommendations], and 'f' protocol was used.  The telephone call was local,
but probably involved two exchanges (from a 223- prefix to a 226- prefix).
The command used was 'uucp', and the times are from the
/usr/spool/uucp/LOGFILE, and include some UUCP session overhead.

Test data objects:

   ASCII  - "/etc/newconfig/Update.info/from.2.x" (a 113Kb text file)
   binary - "/hp-ux", 5.5 (the kernel file, about 800Kb)
   packed - ASCII.Z, as crunched by compress(1)

The results:

   ASCII  - 1618.3 bytes/sec 
   binary - 1101.5 bytes/sec
   packed -  919.2 bytes/sec (raw), 2476.1 bytes/sec (net)

This last result is interesting.  The "raw" figure is...
  ASCII.Z_size/time
... and the "net" figure is the original...
  ASCII_size/time 

The SD (Send Data) LED on the HST was cycling much more slowly for the .Z
test than for the other two, and I expected that the double compression
might actually expand the data, resulting in worse throughput than the
simple ASCII case.  Obviously this did not happen.

My first thoughts are that either the HST is using a different algorithm
than the compress(1) Lempel-Ziv and is gaining some additional compression,
or, that the modem detected expansion, turned off compression, yet saved
time because it did not have to expend internal CPU cycles performing it.
In any case, it appears that you can reduce your phone bill by
pre-compressing data before sending it.

 ..later that decade...

I re-ran the test tonight between a 332 (16.6 MHz 68030) and the same 350
using the same modems and MUXes.  Both systems running HP-UX 6.5.  The
remote system was hiding behind a PBX this time.

Test data objects:

   ASCII  - "/etc/newconfig/Update.info/from.2.x" (the same file)
   binary - "/hp-ux", 6.5
   packed - ASCII.Z, as crunched by compress(1)

The results:

   ASCII  - 1530.8 bytes/sec 
   binary - 1106.9 bytes/sec
   packed -  832.0 bytes/sec (raw), 1888.0 bytes/sec (net)

These HSTs are a year old.  U.S.Robotics is claiming slightly higher
performance for the current HST.  I haven't tried the newer ones, or
the V.32 versions.

Regards,                                              Hewlett-Packard
Bob Niland                                            3404 East Harmony Road
ARPA: rjn%hpfcrjn@hplabs.HP.COM                       Fort Collins
UUCP: [hplabs|hpu*!hpfcse]!hpfcla!rjn                 CO          80525-9599