Message-Id: <200307231417.h6NEHoqj010244@turing-police.cc.vt.edu>
To: jimis@gmx.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: Feature proposal (scheduling related) 
In-Reply-To: Your message of "Wed, 23 Jul 2003 13:57:41 +0300."
             <3F1E6A25.5030308@gmx.net> 
From: Valdis.Kletnieks@vt.edu
References: <3F1E6A25.5030308@gmx.net>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-194208322P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 23 Jul 2003 10:17:50 -0400
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5244
Lines: 96

--==_Exmh_-194208322P
Content-Type: text/plain; charset=us-ascii

On Wed, 23 Jul 2003 13:57:41 +0300, jimis@gmx.net  said:
> 1)I 'm connected to the internet via dial-up, therefore I only have 40 kbits of 
> bandwidth available. What I want to do is listen to icecast radio via xmms (at
> 22 kbits), download the kernel sources with wget, and browse the web at the same
> time. Currently I think that this is *impossible* (correct me if I'm wrong) as
> the radio will be full of pauses and the browsing experience painfully slow.

Basically, you're stuck.  The biggest part of the problem is that although you
can certainly control the outbound packets, you have no real control over when
inbound packets arrive at the other end of your dial-up.  One person suggested
using QoS to help things along - but that needs to be implemented at the OTHER
end of the dial-up - which means unless your provider does QoS on the terminal
server, you're basically stuck.  Packets will probably just get queued up in
order of arrival.

And even if the packets do get prioritized so your xmms traffic "goes first",
that's still not going to be perfect, due to a phenomenon canned 'jitter',
which is a measure of how "bursty" the traffic is, and how much *variability*
there is.

Let's say you have xmms going, and a very slow wget.  The last 5 packets of
xmms traffic arrived when the modem was idle, and immediately start coming
across, so the jitter is near zero.  Now a 6th xmms packet arrives - but the
modem is 3 bytes into transmitting a 1500 byte wget packet.  Wham! that packet
gets to wait 300ms for its turn, and you just got 300ms of 'jitter'.  If the
xmms didn't have 300ms of sound already buffered, you're screwed and about to
have a drop-out.  QoS doesn't help here - the best it can do is guarantee that
you only have to wait for the currently transmitting packet and not for any
already-queued packets. (As an aside - TCP windowing will probably guarantee
that any given connection will only have 1 or 2 packets queued up - but if
you're going to run 5 concurrent data-transfer connections, that's still 5-10
packets. If you don't have QoS, any given packet *could* end up with several
seconds of latency here, and the exact order of arrival could make your jitter
anywhere from 0 to several seconds...

You *might* be able to improve the jitter characteristics by dropping the MTU
on the dialup connection from the 1500 byte range down to 576, but this has its
own problems. First, you're going to be sending 3x as many packets, so the
overhead of packet headers is going to triple, cutting into your effective
bandwidth.  Second, there are often issues with windowing, fragmented packets,
and PMTU Discovery when you do this.

> 2) Normally mozilla starts in 5 seconds after intense disk I/O to load all 
> needed libraries. If I run in the background a long disk intense process
> (like find / -name 'whatever' -xdev) loading mozilla could need 20 boring 
> seconds, or doing other simple tasks might be irritating slow. What I would like 
> to be able to do is (once again let's suppose nice has the --disk option to set 
> disk I/O priority):
> $ nice --disk 1 find / -name 'whatever' -xdev
> $ mozilla
> and load mozilla ,which has the default disk priority 0, fast. The scheduler 
> should give to mozilla most disk troughput when it needs it.

Again, here there be serious and nasty dragons.  The problem is that you have
to balance several competing issues:

1) Trying to maintain good overall disk throughput - if you keep pushing
Mozilla's disk requests *right now*, regardless of what the disk is doing, the
disk ends up spending a LOT of time just moving the heads back and forth.  Even
at 5ms a shot, seeks are *expensive*, so you often want to re-order the
requests to minimize the distance travelled.  Think of it as the difference
between planning your trip to the grocery store, the gas station, the post
office, and the bank to make it shortest, as opposed to going back home after
each one because there's something at home that needs doing Right Now...

2) There's a phenomenon called "starvation".  See that 'find' command in your
example?  If mozilla is disk-hungry enough, bad I/O scheduling can mean that
'find' command will sit there *forever*, tying up resources the whole time.
This can cause issues.  For instance - if you've flagged 'mozilla' as the
process that gets first shot at the disk, what do you do if you start paging to
the swap area, and some OTHER process has to read a page in?  What if that
"other process" is the X server or your window manager?  Think REALLY hard here
- just saying "I'll renice them too" is NOT the right answer.. .;)


--==_Exmh_-194208322P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQE/HpkOcC3lWbTT17ARAs13AKCzT58wqdOHAkDvpmxXgTNqV06KdQCfbHcI
u3NbSxFHbMcd2exJKphNPic=
=1fyJ
-----END PGP SIGNATURE-----

--==_Exmh_-194208322P--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/