Richard Town wrote the following to Craig Ford, and I quote (in part):
-=> Note: Copied from HAYES by WIMM/2 1.31
       RT>> that will support 8: 1 compression on the fly. 
   CF-> One can easily exceed that using D/GSZ's RLE mode for suitably
   CF-> redudndant data.
 RT> Then why can't any of these 230k4 or parallel port modems post any
 RT> log extracts using POTS?
Here is a DSZ log segment:
Z 262144 115200 bps 251072 cps   0 errors  0  128 d:/dl/512ktest.run 26573
G/DSZ is invoked as follows:
gsz port 1 speed 115200 ha on est 0 35000 pa12000 pd0 p z d t -Z -M -8g
[Note that MobyTurbo is specifically disabled, and RLE mode is invoked]
The file 256KTEST.RUN is constructed via the following BASIC routine:
2 TEST$=CHR$(0)  ' file full of NULLs, change 0 to whatever test chars you 
want (you can use more than one char test strings)
3 FILENAME$="256ktest.0"   ' whatever name you want
4 KFILESIZE=256   ' file size in K bytes
5 A$="":FOR X=1 TO 128/LEN(TEST$):A$=A$+TEST$:NEXT X
10 OPEN FILENAME$ AS #1 LEN=128:FIELD 1,128 AS O$
20 FOR Y=1 TO KFILESIZE
25 PRINT Y
30 FOR Z=1 TO 8   ' 8 reps of 128 bytes blocks = 1024 bytes = 1 K
31 ' used 128 byte blocks 'cause that's the BASIC default max, to use larger
32 ' you gotta specify BASICA /s:maxblocksize
35 ' this line used to be PRINT Y,Z   but that caused too much output
36 LSET O$=A$
40 PUT #1
50 NEXT Z
60 NEXT Y
90 END
 
As you can see, that is over 250 -thousand- characters per second!
   CF>> Absolutely! One should achieve a transfer rate roughly 
   CF>> equivalent to
   CF>> DTE/10 when transferring the file.
 RT> Over POTS?
Yes. The line isn't the problem, the limitation is the ability to move data 
to the DCE. In the circumstance of the transfer above, the host's 
comprartively limitless computational resources are utilized to reduce the 
amount of real data that the DCE must transport. With V.42bis, the more 
resources that are avaialble (ie. RAM and modem CPU cycles), the more 
effective the compression algorithm will be (given a data stream with 
sufficient redundancy). V.42bis'
algorithm is not limited to 4:1 or 8:1 or any other arbitrary factor, it is 
actually capable of considerably more. The numbers that one sees bantered 
about are actually the measure of effectiveness transferring the TR30.3 test 
suite using a common V.42bis implementation strategy.
Here is what Dr. Clark had to say about it some time ago:
==== [begin] ====
From: aclark@hayes.com
Newsgroups: comp.dcom.modems
Subject: Hayes views on Optima 288 compression
Organization: Hayes Microcomputer Products, Norcross, GA
Message-ID: 
Date: 18 Mar 94 14:01:12 EDT
There have been a number of posting related to Hayes Optima 288 compression 
performance.  This note provides some insight into what we have done, and 
what improvements can be expected in performance.  [Mind you, we were being 
criticized for lack of throughput .. look what happens when we do something 
about it!!!!]
(i) Implementation efficiency
One of the main causes of throughput loss is insufficient processor 
bandwidth. If the microprocessor in the modem has insufficient power to 
maintain high throughput then it has to apply flow control to slow the data 
rate.  We have been careful in writing and optimizing our V.42bis 
implementation in order to maximise throughput.
(ii) Dictionary size
The industry has tended to implement V.42bis with a 2048 entry dictionary, as 
this represents a reasonable compromise between memory cost and performance. 
For any given data there is a "best" size of dictionary, in some cases this 
is 512 entries however it is more usually in the range 2048+ entries.  We 
found that the proportion of files for which a larger dictionary size was 
beneficial was substantial, and elected to implement an 8192 entry dictionary 
in our Optima 288 product. 
The improvement in compression performance obtained from a large dictionary 
will vary.  In some cases performance may be slightly worse (typically some 
executable files) however in the majority of cases compression is improved by 
5% to 70%.  We have seen good results on spreadsheets and database files, as 
well as some graphics data.
(iii) Maximum string length
The maximum string length has less of an impact on performance, provided it 
is set to some sensible value (say 32 upwards). There is little virtue in 
setting this to a small value, except some minor reduction in end-to-end 
delay (a few milliseconds).
(iv) Ratio of DTE to Line Speed
As others have pointed out, the "4 : 1" label for V.42bis is artificial.  The 
range of compression ratios will vary from 0.997 : 1 through to 100 : 1 or 
more. For the default Optima 288 configuration the maximum compression 
possible is around 40 : 1.  There are enough types of data for which 
compression in excess of 4 : 1 is possible that it is worth running the
DTE interface speed at 8 times the line speed.  
Even if the average throughput is less than 4 times line speed the 
instantaneous compression ratio varies enough that peaks can be up to 8 times 
line speed, and limiting the DTE speed will still reduce average throughput.  
There are a number of 28.8 modem performance reviews that will appear in the 
press during the next few months.  We look forward to seeing how Optima 288 
compares to competing products, as I'm sure you do.
Alan Clark
Hayes Microcomputer Products
==== [end] ====
Regards....
Craig
aka: cford@ix.netcom.com
--- timEd/2 1.10+
---------------