more on the HFC saga

David Burris burris at highspl
Wed May 22 15:13:27 AEST 1991


>From article <102086 at becker.UUCP>, by bdb at becker.UUCP (Bruce D. Becker):
>
> 	I'm puzzled about your belief that HFC is
> 	a requirement for 19200 bps connections.
> 	This is certainly not the case as far as
> 	I can see. I've been using 19200 bps
> 	successfully for a long time without
> 	ever using HFC, as have many others.
> 

Don't I keep seeing that you are running UUCP 'g' protocol? 

I'm puzzled why your puzzled! It's simple, myself and my neighbors
want reliable transfers of any size file at high baud rates. We have
been experimenting with sending large files using an interface speed
of 19200 and V.42bis and UUCP 'e' protocol and can prove repeatedly
that it WILL NOT WORK. The receiving system CANNOT KEEP UP.

I have made considerable improvements and can transfer 100K
compressed news batches with no problem. The failure seems to occur
around 150K.

I am currently studying the kernel/driver code (not source) to find
out what's happening. So far, at 19200 data speeds, I've found a few
possible places where the SOFTWARE will drop entire clists on input
overflow.

Also, as was mentioned in a previous article, all that is necessary
is to find the system activities that can cause lost characters and
strategically toggle flow control before and after those activities.

Right now, I'm concentrating on the tty drivers and line discipline
to make sure that they don't silently drop clists any more. Instead
I would like to exert HFC and wait for clists to free.

As a start, make certain that you allocate enough clists for your
system and set the ttyhog tunable parameter to a high value. If the
input characters allocated to clists exceeds ttyhog, the entire
input buffer is silently flushed. On the 7300, the maximum for
ttyhog is 1024. This is less than one seconds worth of buffering
using V.42bis at 19200. Although this may not be where the
characters are getting lost, its a candidate.

-- 
================================================================
David Burris					Aurora,Il.
burris at highspl		           ..!linac!highspl!burris
================================================================



More information about the Comp.sys.3b1 mailing list