Date: Fri, 6 Jun 1997 11:48:02 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: lada@ws6303.gud.siemens.at (Hr.Ladavac) Cc: lada@ws6303-f.gud.siemens.co.at, jkh@time.cdrom.com, henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Extremely poor interactive response under heave SCSI load Message-ID: <199706060948.LAA01417@labinfo.iet.unipi.it> In-Reply-To: <199706060940.LAA07518@ws6423.gud.siemens.at> from "Hr.Ladavac" at Jun 6, 97 11:39:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 . > > I wish it were only delayed writes...the reads are delayed as well. sorry I was thinking in 'network mode' where you don't have explicit reads... replace "write" with "request" in my description. > What might be possible is to change the strategy routine for od driver to give > reads priority over writes since read is *much* faster than write on a PD. In > fact, one could clone the od driver into the pd driver with changed strategy. > > The other possibility is to make FFS give priority to metadata reads in > comparison to normal reads and writes. However, I don't know whether that is > really the problem (no FreeBSD box, as previosly stated ): or if that can be > done at all. Sounds non-trivial, though. both solution sound like hacks, similar to prioritizing interactive traffic vs. bulk one on a ppp link. And you still have the problem of classifying requests, which is probably almost as hard as determining "flows" (i.e. streams of requests generated by the same process). I have no idea of what information are available at the fs level, so I will leave some more knowledgeable person the answer. 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/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706060948.LAA01417>