🚀 go-pugleaf

In article <1k1vlpINNi7u@ftp.UU.NET> jerry@olivea.ATC.Olivetti.Com (Jerry Aguirre) writes:
>In article <1k18fcINN274@ftp.UU.NET> tom_limoncelli@Warren.MENTORG.COM (Tom Limoncelli) writes:
>>I expected it to be better to off-load the dirty work to the modem,
>>since my Sun3 is so slow.  However, I found that the 2x bytes going
>>through the serial port slowed things down worse than running
>>"compress" on the Sun3.

>I have measured the CPU used and running compress actually saves cycles
>because later uuxqt and uucico have half the data to process.  The time
>saved copying, checksumming and servicing interups is slightly more than
>that used by the compress program.

>That was for sending.  On receive the savings should be even greater
>as receiving typically results in more interupts and uncompress uses
>less cycles than compress.

Furthermore, my tests have shown that some of the compression modes
used by modems seem to kill uucp protocol g throughput.  On large,
plain ASCII files, with my ZyXEL V32bis/V42bis modem, I get around
550 cps with MNP5 on, and 1000cps with MNP5 off.  Remember that since
this has no host-based compress either way, it means that the same
file takes almost twice as long to transfer with MNP5 on - and since
it's probably optimal for compression, precompressed data could only
be even worse thru MNP5.  This appears to be due to packetization
used by MNP5 interfering with g protocol's packetization.  My tests
have also shown that V42bis doesn't seem to make much difference from
no compression at all (ie: still around 1000cps), tho this may be more
an artifact of my DTE speed.

I seem to get optimal throughput with MNP4 and MNP5 disabled.
V42bis doesn't seem to make any difference.

One of my feeds is a Sun3, and I routinely get 1100 CPS on large compressed
files - he is using a ZyXEL too.
-- 
Chris Lewis; clewis@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff 3.0 info: psroff-request@ferret.ocunix.on.ca
Ferret list: ferret-request@ferret.ocunix.on.ca