BG> Sure, but what Rod has stated is not a theory,
BG> it's a physically proven and undeniable fact.

PE> Just like undeniable facts about disk cache's
PE> ceasing to have any effect after 2 meg?

RS> Thats completely different, a number plucked out
RS> of the air, without any testing to confirm it.

PE> You mean like the claim that zip wouldn't save 1 second off
PE> your transfer times of the incoming PKT file, which suddenly
PE> turned into a "I can get bigger savings elsewhere anyway"?

If you cant grasp that the saving on archiving the outgoing PKT
is tiny and insignificant compared with the total session time
in the 4 minute class, and that if you really do care about saving
seconds on the session time there are FAR more effective ways of
doing that, like dropping the echoes that I hardly ever read...

RS> In the case of 38400, you have a detailed calculation which shows
RS> that 3200 cps has lots of headroom to 3840 cps and the clearly
RS> visible flow control when uploading is a real test. The gaps in
RS> the TXD light *ARE* the surplus capacity. So you arent even just
RS> calculating with the possibility of an error in the calculation you
RS> are ALSO seeing the headroom in a real live test, every time you use it.

PE> Nothing like a real live test of putting 57600 in and seeing what happens.

IYO, in mine the clear evidence of the gaps in the TXD which are when
the modem has told the mailer to stop sending for a bit is plenty good
enough evidence that the calculation didnt get mangled, that there is
indeed plenty of headroom. AND I already told you that I had tested
the higher rates when doing the V42bis compression tests TOO.

Its also something that has been hashed over for years in the tech
echoes, with lots of people having to try it themselves before they will
believe it, and ALL concluding that 38400 is all you need in that scenario.

PE> Paul Markham and I tried some tests 1-2 years ago, and although
PE> it looked like it hadn't reached the limit of 38400 (e.g. we were
PE> getting CPS rates of 3000 or something, and so there was "obviously"
PE> still another 800 cps to go before we reached the limit), we tried
PE> it at 57600 and it increased the throughput anyway, maybe up to 3400.

RS> Sounds like you stuffed up the test in some way. I did actually
RS> try it myself, but in a different situation, transferring much
RS> more compressible database files with long ascii text fields
RS> which usually werent anything like used. The speed made no
RS> difference between 38400 and anything higher.

PE> The files we were using had only "X" in them.

Well, thats hardly surprising then is it ?  And completely
irrelevant to whether it would help with the speed of my PKTs.

The problem is that a test file like that uses the 'here come 200 Xs'
type of compression. The PKTs dont have much of that in them, they
actually mostly use the dictionary type compression stuff.

PE> I can't remember the exact figures (I can't see them
PE> recorded anywhere), and I can't remember the CPS rates,
PE> but I do know that we were both surprised with the results.

RS> Bet if you try to repeat it now you cant. Or its
RS> some fucked code in your Spirit or something.

PE> Ok, I'll get Paul to try it again sometime.

Well, use real files, PKTs, because it is possible for artificial
files with just one byte repeated etc to exceed the 38400 capability
in some circumstances.

--- PQWK202