Messages in this thread | | | Date | Fri, 7 May 1999 03:34:56 -0700 | From | (Jim Gettys) | Subject | Re: Overscheduling DOES happen with high web server load. |
| |
> From: davem@redhat.com > Date: Fri, 7 May 1999 04:53:49 -0700 > To: jg@pa.dec.com > Cc: andrea@e-mind.com, ezolt@perf.zko.dec.com, linux-kernel@vger.rutgers.edu, > jg@pa.dec.com, greg.tarsa@digital.com > Subject: Re: Overscheduling DOES happen with high web server load. > ----- > Date: Thu, 6 May 1999 17:52:10 -0700 > From: jg@pa.dec.com (Jim Gettys) > > So theory is therefore that the HZ rate was taken from what Digital > UNIX was using and applied without further thought. > > One further theory, from the networking perspective, is that a higher > resolution HZ allows you to use more accurate timestamping in TCP and > thus get more accurate round trip estimates. I don't know if the > Digital people had specifically thought about this at the time.
I don't specifically remember discussions of TCP RTT estimates, but getting better performance data everywhere, including network code, and reducing latency in scheduler dependent wakeups of processes (better "interactive feel"), as I remember the discussions. Some of the need for this is less now that we have better performance tools and performance counters. I was at least periperally involved early on in both MIPS and Alpha ports, where the topic came up.
100hz == 10 ms == about 1/3 - 1/6 of human perception or your latency budget for actions to be percieved as truly "instantaneous"; you never can get latency back.
Given Jay's recent mail on the topic, I think things jibe with my memory: the console is set that high in large part since we run that fast on other operating systems; this got set as part of the initial experiments when porting to new architectures; the cost of running at a high basic rate is low enough that this was a rational design decision. - Jim
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |