RB>> Yes I allways got 117% efficiency back then.

RB>> You don't see that these days.
RB>> I have seen 116% at 26400, but I would say that was due to a
RB>> speed shift up. One day I would like to see 117% efficiency
RB>> at 33600.

Use MNP4 rather than LAPM, and you will.  Or Hydra rather than ZedZap, if
big numbers are more important than stability :)

 DD> . . .[chomp]. . .

 DD> The following are (some of) my mail connects this week to marwick.

 DD> # 09 Dec 13:30:39 BINK Connect 33600/Arq/V34/Lapm/V42Bis
 DD> + 09 Dec 13:32:59 BINK CPS: 3910 (520058 bytes)  Efficiency: 116%
 DD> + 09 Dec 13:33:37 BINK CPS: 3872 (147173 bytes)  Efficiency: 115%

 RB> Exactly, Notice at 33600 you never get more than 116% (cps in the 3900's)
 RB> but you do at 31200

 DD> # 11 Dec 01:35:51 BINK Connect 31200/Arq/V34/Lapm/V42Bis
 DD> + 11 Dec 01:38:20 BINK CPS: 3886 (559640 bytes)  Efficiency: 124%
 DD> + 11 Dec 01:38:43 BINK CPS: 3907 (85962 bytes)  Efficiency: 125%

No, these figures when it upshifts are calculated with respect to the speed
in the Connect line (as David realised), rather than to the final speed. 
They're not real (well, the CPS is, near enough, but not the 'efficiency').

 DD> Obviously, most of these shifted up a speed.

 RB> What I'm getting at is, that this lack of 117% at 33600 is either due to
 RB> the lack of needed bandwidth above 3000 as Arthur was explaining OR
 RB> a failing of the compression protocol used.

No, it's due to 116% being about IT with ZedZap using LAPM protocol, at any
connect rate at all.

If Binkley ran the ymodem-g thing, you'd see about 120% (as in those
'4000CPS' figures), as it carries less block checking data with it.  You
won't see it in Binkley/ZedZap though, so it's comparing apples with
oranges.

Cheers, Ian

--- MaltEd 1.0.b5