Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!tmsoft!becker!bdb
From: bdb@becker.UUCP (Bruce D. Becker)
Newsgroups: comp.sys.3b1,unix-pc.uucp
Subject: Re: more on the HFC saga
Message-ID: <101141@becker.UUCP>
Date: 17 May 91 12:57:42 GMT
References: <1991May13.010730.4743@fithp> <2793@public.BTR.COM> <1991May15.002922.20778@netcom.COM>
Distribution: na
Organization: G. T. S., Toronto, Ontario, Canada
Lines: 57

In article <1991May15.002922.20778@netcom.COM> gandrews@netcom.COM (Greg Andrews) writes:
|
|Yeah, but I've already pointed out to him that saying "my HFC works with
|UUCP transfers over a TrailBlazer PEP connection" doesn't prove anything.
|[...]
|The modems provide end-to-end flow control through the *uucp protocol*
|rather than hardware handshaking.  It matters not whether hardware flow
|control is perfect or broken - the modems don't use it when they're
|spoofing uucp.
|[...]
|My back-of-the-envelope calculations came up with 1,000 cps, but it's still
|the same conclusion - 24 megabytes in 7 hours is much closer to 9600 bps
|than 19200...


	I run a TB+ at 19200 without flow control or
	locked interface speed, and with modem
	compression turned off.  The maximum throughput
	I seem to get over a clean line is nearer to
	1200 bytes/sec, but this is hardly ever acheived
	due to line noise and system loading.

	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. 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.


	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). No flow control is in effect during
	these transfers, yet the error rate is fairly
	low (consistent with an overlong cable in an
	electrically noisy environment)...


-- 
  ,u,	 Bruce Becker	Toronto, Ontario
a /i/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `\o\-e	 UUCP: ...!utai!mnetor!becker!bdb
 _< /_	 "It's the death of the net as we know it (and I feel fine)" - R.A.M.