Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!mcsun!hp4nl!gouldnl!ted
From: ted@gouldnl.nl (Ted Lindgreen)
Newsgroups: comp.dcom.modems
Subject: Re: MNP 5 vs. uucp 'g' (vs. Telebits)
Summary: use 'g' with telbits
Keywords: uucp telebit
Message-ID: <2876@gouldnl.nl>
Date: 8 Sep 89 11:23:07 GMT
References: <124236@sun.Eng.Sun.COM> <1989Sep7.235838.11756@tmsoft.uucp>
Reply-To: ted@gouldnl.UUCP (Ted Lindgreen)
Organization: Encore Unix Centre Europe
Lines: 40

>some of {f,t,e} protocols .....
...
>throughput).  I don't know if anyone has tried running a telebit using
>these protocols instead of 'g'.  It would be interesting to hear the
>results.
>

Yes, I have done some testing of the f and t protocols. It turns out
that the throughput in terms of baudrate (how you use the line) is
not very different. There is a difference in total throughput in
terms of <number of bytes of the transfer>/<total connect time>.
The 'f' protocol is a real lozer on compressed files, because the
f-protocol only uses the characters between space and tilde in order
to cope with those nasty PADs. All other data is turned into a double
character. It means that a compressed transfer increases with some
75%. Switching on compression in the modem compensates somewhat, but
the net result is still 25% to 40% less total throughput compared to
the 'g' and 't' proto which use the full 8 bits of each byte.
The t-protocol gave a minor improvement (5%) compared with 'g'.

The f-protocol performs a sum check on the whole transfer, but I don't
think that the t-protocol does that. 

For both f and t proto flow control is essential.
For the f-protocol one can use X-on/X-off on most machines, on a few
machines one can use hardware flow control as well.
For the t-protocol one must use hardware flow control.

With the g-protocol my advice is to switch off compression in the modem
for compressed news batches, the difference is some 10% to 15%.

My conclusion was:
With the g-proto spoofing of the trailblazer one gets a nearly
optimal througput with the easiest setup procedure for the g-protocol.
The f-protocol is bad for non-ascii data.
The t-protocol does not garanty the correctness of the transfer.
-- 
| Ted Lindgreen                        ...!mcvax!hp4nl!gouldnl!ted |
| Encore Unix Centre Europe                       ted@gouldnl.uucp |
| Maarssenbroek, The Netherlands        (USA) ...!gould!tlindgreen |