Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!highspl!fithp!mhw
From: mhw@fithp (Marc Weinstein)
Newsgroups: comp.sys.3b1,unix-pc.uucp
Subject: Re: more on the HFC saga
Message-ID: <1991May18.170853.2649@fithp>
Date: 18 May 91 17:08:53 GMT
References: <101141@becker.UUCP>
Distribution: na
Organization: Weinstein Consulting
Lines: 50

From article <101141@becker.UUCP>, by bdb@becker.UUCP (Bruce D. Becker):
> In article <1991May15.002922.20778@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes:
> 
> 	As far as I can see, HFC is just a big source of
> 	problems and should be avoided if at all possible.
> 	Even if it works correctly (which for many versions
> 	of the O/S it doesn't), it's very susceptible to
> 	"skid" at high baud rates. This means that the
> 	time between the detection of overrun and the
> 	assertion of the appropriate control line can
> 	be long enough under some load conditions that
> 	characters are still dropped.

We've found this is true at 19200, but not so at 9600.  I've had *lots*
of activity on the PC and can't seem to cause a file transfer to fail.

>       HFC isn't actually
> 	useful for UUCP transfers, and wreaks havoc with
> 	interactive users because the modem's buffering
> 	system has no concept of interrupt characters
> 	(like "^C") needing special handling.

Well, sort of...The place where HFC on the UNIXPC really works is when your
PC can send chars out faster than the remote modem can handle them.  For
instance, if either the DCE-to-DCE speed or the DCE-to-DTE speed on the far
end are less than the host DTE-to-DCE speed, then the modems will apply
HFC and the UNIXPC will properly halt data transmission.  HFC does NOT
seem to work for handling overflow on incoming PC ports.

> 	I've run the serial port (actually tty002, but
> 	that oughtn't to be a real difference) at 19200
> 	with a direct connection to a faster system
> 	(with respect to serial speed), using a protocol
> 	which sends a 1K block and gets an ACK in
> 	response. The fastest I can send stuff is about
> 	1300 bytes/sec, which I take to be the maximum
> 	rate at which characters can be delivered out
> 	the serial port (probably interrupt service
> 	overhead).

Yeah - we'd like to try this, but we only support the 'g' protocol in
UUCP.  Is this a UUCP connection you're talking about, or a UMODEM-type
transfer?

Marc

-- 
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw		Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhw