Path: utzoo!attcan!uunet!tektronix!reed!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Newsgroups: comp.dcom.modems
Subject: Re: V.32 will dominate the marketplace (Was: Re: Which is best?)
Message-ID: <725@omen.UUCP>
Date: 15 Nov 88 22:05:53 GMT
References: <2261@looking.UUCP> <1248@nusdhub.UUCP> <14515@mimsy.UUCP> <14533@mimsy.UUCP>
Reply-To: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Distribution: na
Organization: Omen Technology Inc, Portland Oregon
Lines: 69

In article <14533@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
:`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.

Unimportant in the case of ZMODEM and TrailBlazer modems.
Whether or not a "short block" goes out at first, the sending
modem's buffer will continue to accept characters at full
speed.  As this buffer is 4k or more, the modems will be
operating at full tilt for the remainder of the file.

With UUCP-g, Sliding Windows Kermit, WXMODEM, and SEAlink, the
frequent ACK packets are the problem, forcing frequent line
turnarounds unless spoofing is used.

:(This is, of course, the moral equivalent of spoofing.)

Adding a modest delay to data transmission is not the moral
equivalent of spoofing.  Spoofing creates its own data and
eats some data, all in the name of efficiency.

Telebit's XMODEM and Kermit spoofing bollixes protocols the
spoofing does not understand.  Sliding Windows Kermit and
possibly Long Packet Kermit don't mix with Kermit spoofing.
XMODEM and XMODEM-1k transfers that use the full protocol have
problems.  YMODEM gets into trouble before the first file gets
through.


Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
  Omen Technology Inc    "The High Reliability Software"
17505-V NW Sauvie IS RD   Portland OR 97231   503-621-3406
TeleGodzilla BBS: 621-3746   CIS: 70007,2304    Genie: CAF