more on the HFC saga

[Marc Weinstein]

>From article <103431 at becker.UUCP>, by bdb at becker.UUCP (Bruce D. Becker):
> In article <1991May18.170853.2649 at fithp> mhw at fithp (Marc Weinstein) writes:
> |From article <101141 at becker.UUCP>, by bdb at becker.UUCP (Bruce D. Becker):
> |
> |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.

Most modems now support the ability to nail your port rate to something 
(9600 or 19200) and vary the modem-to-modem rate to suit the remote 
system.  This makes administration much easier - one rate in gettydefs,
one rate in your Systems file.

>       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
> 	pumped thru the serial interface with
> 	an interrupt service routine invocation
> 	for each character!

Hmmm - don't understand the logic here.  If I want to send a file to
someone, and I know my modem will compress the file anyway, then I don't
have to bother with compressing the file before the fact.  Less wory,
less bother.

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

True, if both ends use the same speed.

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