more on the HFC saga
Bruce D. Becker
bdb at becker.UUCP
Fri May 17 22:57:42 AEST 1991
In article <1991May15.002922.20778 at netcom.COM> gandrews at 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 at becker.UUCP, bruce at 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.
More information about the Comp.sys.3b1
mailing list