Subject: re: more on NFS over TCP and priorities

From: Peter Staubach <[email-masked]>
Date: Tue, 10 Dec 2002 10:55:51 -0700 (MST)

> 
> > Though a scheme that prioritizes packets according to their
> > size seems eminently fair.  That's essentially what you have
> > with multiple connections: even though the bandwidth is shared
> > and finite, shorter packets can slip by the longer ones, simply
> > because long packets take longer to transmit.
> 
> Agreed. But there is a difference between "can slip by" and "always goes
> first". If you have two TCP streams and don't give an absolute
> priority to one over the other, I think it should be ok. (The classic
> priority queue strategy says the higher priority job/packet/... always goes
> first, and I thought that's what was being considered originally.)
> 

I am not so sure what "eminently fair" means, unless the thread that
you are interested in is the one that is using small messages.  If you
are the thread waiting for a pagein to complete so that execution can
continue, then it won't seem so fair.

I don't think that prioritizing strictly based on size of message is
going to result in better system performance.  The system in general
may actually lag because it is the larger messages which tend to make
the larger differences to applications.

If the problem is that "ls -l" requires more information than can be
retrieved in a single operation ala the NFS Version 3 style READDIRPLUS,
then let's either add a new operation which does return the correct
set of information or compound the operations differently.

I suspect that it will be easy to find a situation, even common ones,
which will suffer, given any sort of general prioritization algorithm.

		ps

---

From: Eric Werme USG <[email-masked]>
Date: Tue, 10 Dec 2002 17:34:11 -0500

> priority queue strategy says the higher priority job/packet/... always
   > goes first, and I thought that's what was being considered originally.)
   > 

I've never had to deal with such issues, but a common technique back in my
PDP-10 days was a "fairness algorithm."  Sometimes something, e.g. a disk I/O
request or runnable process, would loose out because the scheduler was giving
priority to everyone else.  The fairness code would simply take the oldest
request every Nth time so no one would get locked out.  Easy to implement,
worked great, probably discounted out of hand by the computer scientists.

Ultimately, like taxes, I think there is no completely fair mechanism.
However, anything that can leave something completely blocked can certainly
be called unfair.

	-Ric-without-the-k
-- 
Eric (Ric) Werme         |  [email-masked], [email-masked]
Hewlett-Packard Co.      |  http://ewerme.home.attbi.com/