Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!tmsoft!becker!bdb
From: bdb@becker.UUCP (Bruce D. Becker)
Newsgroups: unix-pc.uucp,comp.sys.3b1
Subject: Re: more on the HFC saga
Message-ID: <103431@becker.UUCP>
Date: 21 May 91 12:13:48 GMT
References: <101141@becker.UUCP> <1991May18.170853.2649@fithp>
Organization: G. T. S., Toronto, Ontario, Canada
Lines: 59

In article <1991May18.170853.2649@fithp> mhw@fithp (Marc Weinstein) writes:
|From article <101141@becker.UUCP>, by bdb@becker.UUCP (Bruce D. Becker):
|[...]
|>       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'm having a hard time understanding why
	speed changes are necessary. For most
	things compression is irrelevant, or they
	are done in the host as in news batches
	or uucp files. Doing compression in the
	modem seems wasteful of resources due
	to the fact that uncompressed data gets
	punped thru the serial interface with
	an interrupt service routine invocation
	for each character!
	
	Naturally on a little beastie like the 3B1
	this is pretty ferocious CPU consumption
	at high baud rates. Better to have direct
	end-to-end transfers at the same speed,
	with no buffering in the modems. 


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

	Both, actually (UUCP 'g'). This is talking to
	an Amiga running Handshake terminal emulator
	(very fast), and Dillon UUCP 1.06.


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