🚀 go-pugleaf

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