Path: utzoo!attcan!uunet!husc6!mailrus!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <14533@mimsy.UUCP>
Date: 14 Nov 88 09:04:20 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 42

`OOPS'

Corrections (as pointed out by Don Speck):

In article <14515@mimsy.UUCP> I claimed:
>Not necessarily.  UUCP's `g' protocol runs into trouble not because of
>reversals---the 6-byte ack packets fit in the reverse channel---but

Point 1: The TB+ does not have a `reverse channel'; it has an
`interactive mode'.  (See recent technical details posting from
Telebit.)  I believe (based on personal observation) that one
modem can be sending big packets while the other is sending little
interactive packets, which means that the g protocol acks fit in
the small packets; the small packets *act* like a reverse channel
but are not in fact the same.  So: `1,$s/reverse channel/periodic
small packet/g' :-).

>rather because its packet size (64 bytes * 3 = 192 bytes) is just large
>enough to convince the TB+ to send a large data packet (1024 bytes) to

Ack!  I do not know where I came up with 1024 bytes.  Large packets are
256 bytes.  (Also, I forgot the 6-byte headers this time.  A 3 packet
window gives 70*3 = 210 bytes out of the 256 that would fit in a large
packet.)

>the other modem, but not large enough to fill the large packet.
>Streaming protocols and large-packet protocols whose acks fit in the
>reverse channel would run at full speed.

I should emend this: not `would' but `could': the TB+ should delay
somewhat before sending a 256-byte packet if you have fed it only 210
bytes, in the hope that it could fill the remaining 46 bytes.  It would
be a bad thing for performance if, every time the host connected to the
modem hiccuped with a slow interrupt, the TB+ had to send a partial
packet.  This delay appears (personal observation again) to exist and
to be on the order of ten milliseconds.  This could be fixed by having
the tty driver speak a protocol with the modem, so that the modem
knows when to send immediately and when to wait.  (This is, of course,
the moral equivalent of spoofing.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris