Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!milton!ogicse!decwrl!uunet!fub!geminix.in-berlin.de!gemini
From: gemini@geminix.in-berlin.de (Uwe Doering)
Newsgroups: comp.unix.sysv386
Subject: Re: Buffers vs. tty throughput
Message-ID: <B5MNMPN@geminix.in-berlin.de>
Date: 28 Jan 91 11:33:52 GMT
References: <9101272226.AA01243@iecc.cambridge.ma.us>
Organization: Private UNIX Site
Lines: 36

johnl@iecc.cambridge.ma.us (John R. Levine) writes:

>I have an internal Telebit with a 16550 UART, and uucp connections generally
>run between 800 and 1100 cps, depending on who's on the other end.  I noticed
>that my system is fairly disk bound, and that since I'm not running NFS I
>don't fill up all my RAM.  It seemed sensible to increase my disk buffers, so
>I built a new kernel with 4000 rather than 2000 buffers.  It works OK, except
>for one thing -- uucp throughput stinks.  It was down around 400 cps.  I
>rebooted the old kernel and throughput is back up.  As far as I can tell, the
>only difference between the old and new kernels is NBUF.
>
>What is going on?  The most likely thing I can think of is that somewhere in
>the buffer management code there is an N^2 algorithm that runs with
>interrupts masked, and with 4000 buffers it takes so long that even with a
>16550 I lose interrupts.  I note that in the mtune file, 2000 is the maximum
>number of buffers you're normally supposed to configure, but losing
>performance when you add more buffers is pretty pitiful.  As I recall, a
>16550 has a 16 character silo, so to lose characters you'd have to stay
>masked for upwards of 15ms at a time.

I noticed this, too, on ISC 2.0.2. On my system even 2000 buffers are too
much. Yes, there seems to be some incredible nasty code in the kernel
that disables interrupts for long enough that even an NS16550A chip
loses characters, at least at 38400 bps. I mention this problem in the
README file of FAS 2.08 (to be released in the next few days), so
at least those who read this file will know the consequences of increasing
the NBUF parameter.

I wonder whether AT&T has changed this code in SysVr4 to be less reckless.
We'll see.

      Uwe
-- 
Uwe Doering  |  INET : gemini@geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini