🚀 go-pugleaf

In biz.comp.telebit, Alexander Steins <alex@octagon.de> writes:
|> Hi,
|> 
|> this is shurely a FAQ, but I don t have the appropriate one... Sorry,
|> 
|> Ok, 
|> I use Telebit WorldBlazer Modems to connect uucp Sites. I installed Taylor
|> UUCP 1.04 instead of the NeXT default uucp. Taylor works very well here
|> and now I m searching for the optimal g Protocol Parameters in conjunction 
|> with Telebits WorldBlazer Modems to get the highest throughput rates.

#### Best Taylor UUCP WB-WB config

If you have a Telebit WorldBlazer modems on both ends,

	protocol-parameter g packet-size 64
	protocol-parameter g window 3
	protocol-parameter g short-packets false

Then enable TurboPEP and UUCP 'g' protocol spoofing on the modem:

	Calling end:	S50=255 S111=30
	Answering end:	S50=0   S111=255

This configuration will work regadless of what UUCP the other end
is using.  Whether you use compression on the line is optional
(depends on the data you're sending).


#### Best Taylor V.32bis configuration

|> It would although be interesting to know what the best parameters for V32bis
|> modems would be.

If you are using V.32bis/V.42/V.42bis and both ends have support
for variable-sized 'g' protocol packets (Taylor, UUPC/Extended, BSDI).
try the following Taylor configuration:

	protocol-parameter g packet-size 1024
	protocol-parameter g window 7
	protocol-parameter g short-packets true

And the modem:

	Calling end:	S50=7	S111=0
	Answering end:	S50=0   S111=255  (it's always the same; neat, eh?)


Note: If both ends can use Taylor's 'i' protocol, you might want to
      look into using that.  I'm just giving 'g' parameters.


#### What to expect, in general, for throughput

|> Could anybody post his/her expiriences, please?

People who use PEP modems get the best throughput when they use
Telebit's 'g' UUCP protocol spoofing and the old UUCP protocol
parameters g(3,64).

People who use flat V.32 (no MNP, no V.42/V.42bis) will see about
870 cps throughput per file.  People who use any kind of modem
error correction (with or without compression) will see *less*
than 870 cps when using g(3,64) protocol parameters.  (Multiply
all cps numbers by 1.5 for flat V.32bis).

People whose have UUCP packages that support variable-sized packets,
and use g(7,512) (or greater packet size) and V.32/V.42 will see
around 900 cps (I think).  If they add compression and are transfer-
ing compressable data (like text), their throughput will exceed 960
cps.  Typically, I can see a properly configured site will get
1000-1100 cps (your milage may vary) when sending/receiving an even
mix of mail and news.  (Multiply all cps numbers by 1.5 for V.32bis).

Note: Sure, I bet that some of you out there get more than 2000cps
      on your V.32bis UUCP feeds, but I'm talking about averages for
      people who transfer real text and real data over their line.
      Take numeric boasting to comp.dcom.modems.

People who use the 'G' protocol will see similar throughput
advantages when using larger packet sizes, but their throughput
will suffer dramatically when sending small files because 'G'
does not allow variable-sized packets (in at least any implemen-
tation I've seen).  Perhaps compression can reduce the overcome the wasted
bytes sent in the packet filler.  Anyone out there using 'G' with
large packets and V.42/V.42bis?



I was going to go into deeper detail, but after 4 hours of protocol
analysis and writing, I decided to use it for a class project and
later as a UUNET FAQ or an O'Reilly "Managing UUCP" Appendix.

--
Eric Ziegast
UUNET Postmaster
ziegast@uunet.uu.net