From owner-freebsd-hackers Fri Jun 6 02:07:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA09053 for hackers-outgoing; Fri, 6 Jun 1997 02:07:57 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA09045 for ; Fri, 6 Jun 1997 02:07:48 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA01298; Fri, 6 Jun 1997 10:34:13 +0200 From: Luigi Rizzo Message-Id: <199706060834.KAA01298@labinfo.iet.unipi.it> Subject: Re: Extremely poor interactive response under heave SCSI load To: lada@ws6303.gud.siemens.at (Hr.Ladavac) Date: Fri, 6 Jun 1997 10:34:13 +0200 (MET DST) Cc: jkh@time.cdrom.com, henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199706060811.KAA00771@ws6423.gud.siemens.at> from "Hr.Ladavac" at Jun 6, 97 10:11:40 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > > cache) ram while under heavy SCSI load (or not so heavy really, e.g: > > > > > > This has been a known bug for ages. If you really want to test it out, try ... > The problem is extremely easy to reproduce if you have one of these > PD drives and use them for backups. > > You will need a FFS on the PD media so that you can mount it. Then write to > the PD. Since this operation is extremely slow, a nice amount of backlogged > blocks will be made in cache--in fact, 16MB of RAM is more than enough-- > especially if you do a dump to the PD. I have dnot read the previous messages in this thread so I might be wrong, but it sounds like a fair bw allocation among flows, much the same as you have when you are on a slow ppp link which does not implement priorities, and you run an ftp transfer in parallel with a telnet session. Solutions exist for this problems, i.e. separate the flows (easy for tcp/udp connections since the headers clearly identify packets) at the bottleneck, and serve the various queues in a round-robin fashion. The network drivers do not work like this because it is unlikely that long queues develops at a 10Mbit/s interface (but they do on a ppp liink, so perhaps this ought to be done in the tun device -- I might work on this in the next months). A similar approach could be used for scheduling disk writes assuming one has a way to determine which writes are related. This might not be trivial . Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________