Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!oliveb!jerry
From: jerry@oliveb.olivetti.com (Jerry Aguirre)
Newsgroups: comp.dcom.modems
Subject: Re: YATB
Message-ID: <17965@oliveb.olivetti.com>
Date: 12 Mar 88 03:16:53 GMT
References: <1849@mtunx.ATT.COM> <3830@umix.cc.umich.edu> <16750@pyramid.pyramid.com>
Reply-To: jerry@oliveb.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 57
Keywords: techdoc Telebit questions

In article <16750@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes:
>In article <3830@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes:
>>window size doesn't affect trailblazer throughput -- a window size of 1
>>gives the same performance as 3 or 7.
>
>I know the modem is perfectly capable of running flat out with window size 1.
>But a lot of computers are not -- and in fact, window size 3 at 9600 or 19200
>bps is too small. We have many connections where the throughput is obviously
>constrained by the system's ability to get ack packets out; I think a bigger
>window size would help immensely.

I have to agree.  If the host were talking at 19200 and able to generate
acks reasonably fast then throughput shouldn't suffer.  But I have to
run my interface at 9600 bps, to a heavily loaded slow CPU.

While it might be able to generate acks fast enough on average to keep
the line going it can't do so at any given instant.  There are other
things like disks and other serial lines to service.  Remember that the
acks are not being generated by the tty driver at interupt level.  They
are being generated by a user process.  It reduces overhead if the
process can process and ack several packets at each context switch.

The suggestion that full speed is possible with a window of 1 is
ludicrous.  The modem would be able to send only 1 packet.  It would
then have to wait for an ack before it could send another.  At a minimum
that means 8 bytes of idle time for every 64 bytes received.  The line
would be idle for 12% of the time.  Any time to process the incomming
packet and generate the ACK would add to that.

If the connection from the modem to the computer has additional delay
then performance really suffers.  By example consider dialing into a
packet switched network like tymnet or PC persuit.  Before switching to
a window size of 7, I and others experienced terrible thruput on
networks like that.  I also run UUCP over lines with a satellite delay.
Again, thruput is terrible without a window of 7.

	3 packets * 64 char/packet * 10 bits/char = 1920 bits

	1920 bits / 19200 bps = .1 second to send 3 packets.

If the system takes more than 100 ms. to return any ack then performance
suffers.  (Actually it is 66 ms. because I can't begin generating an ack
until after the first packet is received.) A satellite circuit has 700
ms. of delay.  Many packet switched networks have several hundred ms. of
round trip delay.

If the modem really negotiates the window size with the host then why
can't it use the value each host asks for?  That way systems that can't
buffer 7 packets can leave their window at 3 and systems that need a
larger window can do so.  (No, 3 is the magic number.  Count ye not to
2, nor on to 4 ...... :-)

You are too locked into what the modems are doing internally and not to
the host interface.  If I ask for a window of 7 then you should give me
a window of 7, I might have a good reason.

			Jerry Aguirre