Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!eastapps!vergil!gsteckel
From: gsteckel@vergil.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR)
Newsgroups: comp.unix.sysv386
Subject: Re: Buffers vs. tty throughput
Message-ID: <4102@eastapps.East.Sun.COM>
Date: 29 Jan 91 19:05:37 GMT
References: <9101272226.AA01243@iecc.cambridge.ma.us> <B5MNMPN@geminix.in-berlin.de>
Sender: news@East.Sun.COM
Reply-To: gsteckel@east.sun.com (Geoff Steckel - Sun BOS Hardware CONTRACTOR)
Organization: Omnivore Technology, Newton, Mass. (617)969-3448
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 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.....
 >
 >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

I don't know if this has survived into missed'em V.3, BUT...  There were at
least two places where truly silly things happen w.r.t. the buffer cache in
V7 & friends.

1) disksort - inserting a buffer into a driver's to-be-written queue used a
quadratic (or worse) algorithm at spl6().
2) sync() - when a sync occurs, the entire cache was scanned, and one by one,
each modified block was placed in the driver's write queue, using disksort....
(can you say n^3!).
3) every read() and write() call on the serial device caused the inode for
the serial line to be updated with the current time (access/modification),
which searches the buffer pool (at spl6()) - hundreds of times a second...

I think there were more, but I forget lots.

Losing even one character can cause a truly awful degradation of UUCP transmission
rate.

I hope this helps someone.
	geoff steckel (gwes@wjh12.harvard.EDU)
			(...!husc6!wjh12!omnivore!gws)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.