Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!rutgers!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.dcom.modems
Subject: Re: V.32bis and V.17 approved by CCITT
Message-ID: <20432@cbmvax.commodore.com>
Date: 7 Apr 91 01:14:25 GMT
References: <7151.27F9618A@zswamp.fidonet.org>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Organization: Commodore, West Chester, PA
Lines: 32

In article <7151.27F9618A@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes:
> In a letter to All, Heiko Blume (src@scuzzy.in-berlin.de ) wrote:
> 
>  >root@zswamp.fidonet.org (Geoffrey Welsh) writes:
> >   Given that design criteria, it's damned silly that the HST can't carry 
> >UUCP-g at all well.  You're right that 350 CPS is ridiculous for a 9600 bps 
> >modem.
> 
>  >well, it wasn't designed for uucp, so you can't really blame it.
> 
>    It wasn't designed specifically for UUCP-g, but it definitely was designed 
> for protocols (both windowed and not) which sent ACK packets which were small 
> in comparison to the data packets, and UUCP-g does fall into that broad 
> category, doesn't it?
> 
>    (Or am I displaying ignorance about the size of UUCP-g ACK/NAK packets?)

Broad category, yes, numbers no.  UUCP requires a ~1:10 back channel ratio,
the HST provides a 1:32 ratio.  The HST scheme is wonderful for manual input
and some windowed/streaming protocols, inadequate for others.  USR might have
been able squeeze in a 450 or 600 baud back channel while retaining standard
high speed modulation, but they didn't and even so it would have fallen short.

The fault is largely in the standard Unix "g" protocol implementation, the
protocol provides for negotiated packet sizes which would work acceptably with
the HST, however the implementation is (9 cases of 10) broken and there is no
way to actually specify that you want to use larger packet sizes.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)