🚀 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

In article <24furc$rcl@news.UU.NET> ziegast@godzilla.UU.NET (Eric W. Ziegast) writes:
...

>#### 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

I use a Telebit Worldblazer and get about 1250 cps over the whole
connection with just v32bis no error correction no compression 7*64
packets, for newsfeed, large files to site A.  If there is a lot of
mail, it is significantly less.  I use uupc11z for OS/2.  Site A does
not have Worldblazers, I do not know what brand they are.  At my feed
time, the site seems to be not very busy and I see a steady flow of
packets  to here. (for 7*64.  3*64 is not as good and I don't use it).
Their DTE rate seems to be sufficiently high to reach 3000 cps on a LAPM
connection with f protocoll for large text files (mail).  However, since
hardware flow control seems to be a problem there, it does not work
reliably for large files, therefore no use.  I have 38,4000 DTE speed
here.

>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).

To another site B - they have Telebit Worldblazers -, using v32bis and
compression (telebit lempel-ziv, and s190=2 <mainly receiving data>)
with 7*512 variable packets, I get pretty much 1625 cps regulary for
large files on a file basis (batched compressed news).  Overall varies
since the files sizes are not consistently large, and is somewhere
between 1300 and 1550 cps.  The measurement on the other side looks
better and shows pretty much always above 1500 cps.  I guess it is
because I have to go thru a terminal server to log on, and over there is
starts counting after the protocoll starts.  This is all compressed
batched news, and can be considered a tiny feed (about 1-2 MB per day
typically).  The host seems to be servicing the packets in time for
7*512, but not quick enough for 3*64.

I tried a similar setting with TPEP, but reached only 1350 cps on a file
basis.  3*64 spoofing didn't yield to a better result, although
sometimes up to 1550 cps on a file basis.  It depends a lot how
attentive the hosts are in supplying the packets, and 7*512 leaves a lot
more room for packet blackouts without performance penalty.

>
>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.

My typical feed is more news than mail.  I think he asked for
experiences, so depending on his typical feed profile, it might be
useful for him.  But I heard that the numbers you gave are typical if
you are connected to systems that are quite busy and not very attentive
in servicing the connections due to the large number of connections and
perharps overload.

>
>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?

Not used it yet due to lack of support on the other sides.  f seems to
be of more interest to me for mail (C grade) connections, since it can
zip thru at 3000 cps per file with v32bis LAPM connections.  I would
expect a lot less overall, but still close to 2000 cps for mail.

>
>
>
>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

--
-------------------------------------------------------------------------------
Mustafa Soysal                                      msoysal@mistik.speedway.net
-------------------------------------------------------------------------------