Xref: utzoo comp.dcom.modems:4029 comp.mail.uucp:3307
Path: utzoo!attcan!lsuc!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.dcom.modems,comp.mail.uucp
Subject: Re: UUCP over X25 [Was Re: Telebits and uucp g-protocol]
Keywords: Telebit Trailblazers, g-protocol, uucp
Message-ID: <1989Jun22.154318.25599@eci386.uucp>
Date: 22 Jun 89 15:43:18 GMT
References: <335@nixtor.UUCP> <10391@smoke.BRL.MIL> <1989Jun12.185746.7217@eci386.uucp> <193@cat.Fulcrum.BT.CO.UK>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 68

In article <193@cat.Fulcrum.BT.CO.UK> igb@fulcrum.bt.co.uk (Ian G Batten) writes:
>In article <1989Jun12.185746.7217@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes:

>>G-protocol does work over X.25 with PADS.
>>At 9600 baud, you can send 3 64 byte packets in 200-ish ms.  Then you add 
>>the 50 ms. timeout
>>to send the ack packet back, plus X.25 gateway delays, plus network
>>turnarounds, plus satellite links etc.  Yuck.  When we tested 9600 X.25/PAD
>>links with G, we got 600 baud effective thruput.  And that was simply bouncing
>>it off our local X.25 connection 5 miles away.  Cross country was more like 
>>60 baud.

>This may be a difference between US and UK, but I find that UUCP over
>X25 is basically OK.  I have a machine with a TB+, a pair of v22bis
>modems and a 2400 bps X25 line.  I see 245 cps with the 'e' protocol
>from HoneyDanber (interestingly, 'x' doesn't seem to work for me!) and
>perhaps about 140 for 'g' protocol.  This is for a newsfeed over about
>100 miles.

I don't think that our numbers necessarily disagree.  "Cross-country"
in this case meant 3000+ miles and (well, maybe that should have been 
"cross-continent") at least one international gateway (Bell
Canada "DATAPAC" => US "Tymnet").  And at least one 4800 baud hop.
And lots of other traffic sharing the lines...  60 baud "g" protocol,
but with "f" protocol, our effective thruput ranged from about 3000
(full binary data) to 4300 (which, after all, was near the max rated speed
of one of the trunks).

With "g", you can send your three packet window not too badly, but
remember, you have to wait for the "transmit timeout" (minimum 50ms
on our pad) before the last bit of it actually gets sent.  
[Well, depends on X.25 packet size etc. etc. etc.]

As well, you also have to wait for the transmit timeout before the acks get
sent back.  So, think of basic X.25 "g" speed as: "time to send
three packets at rated link speed" *plus* two "transmit timeouts".
As your speeds get higher and higher, the transmit timeouts tend to
dominate, and your speed will reach a plateau.  If you can increase
your window size, that helps a lot.  Not having acks required
until the end of the file is transmitted (as in "f" and "e") is
*much* better.

The above discussion is over-simplified and doesn't include gateways of 
course...

>[E protocol is pretty similar to 'f', but doesn't reduce the datawidth.
>I've never tried shipping binary data over X25 with it.  As it gets us
>full bandwidth of the line for our news feed, we aren't going to disturb
>it.]

You mean you aren't using compressed batching?!  e is very dangerous
unless you've carefully set up your PAD - a single binary character in
the data could do all sorts of nasty things (at best, cause it to
be impossible to send a file because the PAD strips the character so
checksums will never match, to such things as resetting the pad,
changing parameters etc.).  If you've not spent the time making absolutely
certain that the PADs are set up correctly, you're best off using "f"
protocol.

[I had given Rick Adams a X.25 PAD dialer module that didn't quite make
it into BSD 4.3, which has PAD initialization built in.  See the 
comp.sources.unix archives if you want it...  I don't have access to
it no more.]
-- 
Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis
Phone: (416)-595-5425