Message-ID: <46538AB8.8030009@tmr.com>
Date: Tue, 22 May 2007 20:28:40 -0400
From: Bill Davidsen <davidsen@tmr.com>
Organization: TMR Associates Inc, Schenectady NY
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061105 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Miguel Figueiredo <elmig@debianpt.org>
CC: Ray Lee <ray-lk@madrabbit.org>,
       Linux Kernel M/L <linux-kernel@vger.kernel.org>,
       Con Kolivas <kernel@kolivas.org>
Subject: Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
References: <464F57DD.2000309@tmr.com> <4650774F.9040208@debianpt.org> <2c0942db0705200944r19a37bd8pd7c220903084e4d3@mail.gmail.com> <46507E1D.6030002@debianpt.org> <46532E8A.4030900@tmr.com> <46534C31.1060306@debianpt.org>
In-Reply-To: <46534C31.1060306@debianpt.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 6307
Lines: 141

Miguel Figueiredo wrote:
> Bill Davidsen wrote:
>> Miguel Figueiredo wrote:
>>> Ray Lee wrote:
>>>> On 5/20/07, Miguel Figueiredo <elmig@debianpt.org> wrote:
>>>>> As I tryied myself kernels 2.6.21, 2.6.21-cfs-v13, and 2.6.21-ck2 
>>>>> on the
>>>>> same machine i found *very* odd those numbers you posted, so i tested
>>>>> myself those kernels to see the numbers I get instead of talking 
>>>>> about
>>>>> the usage of kernel xpto feels like.
>>>>>
>>>>> I did run glxgears with kernels 2.6.21, 2.6.21-cfs-v13 and 2.6.21-ck2
>>>>> inside Debian's GNOME environment. The hardware is an AMD 
>>>>> Sempron64 3.0
>>>>> GHz, 1 GB RAM, Nvidia 6800XT.
>>>>> Average and standard deviation from the gathered data:
>>>>>
>>>>> * 2.6.21:               average = 11251.1; stdev = 0.172
>>>>> * 2.6.21-cfs-v13:       average = 11242.8; stdev = 0.033
>>>>> * 2.6.21-ck2:           average = 11257.8; stdev = 0.067
>>>>>
>>>>> Keep in mind those numbers don't mean anything we all know 
>>>>> glxgears is
>>>>> not a benchmark, their purpose is only to be used as comparison under
>>>>> the same conditions.
>>>>
>>>> Uhm, then why are you trying to use them to compare against Bill's
>>>> numbers? You two have completely different hardware setups, and this
>>>> is a test that is dependent upon hardware. Stated differently, this is
>>>> a worthless comparison between your results and his as you are
>>>> changing multiple variables at the same time. (At minimum: the
>>>> scheduler, cpu, and video card.)
>>>
>>> The only thing i want to see it's the difference between the 
>>> behaviour of the different schedulers on the same test setup. In my 
>>> test -ck2 was a bit better, not 200% worse as in Bill's 
>>> measurements. I don't compare absolute values on different test setups.
>>>
>> Since I didn't test ck2 I'm sure your numbers are unique, I only 
>> tested the sd-0.48 patch set. I have the ck2 patch, just haven't 
>> tried it yet... But since there are a lot of other things in it, I'm 
>> unsure how it relates to what I was testing.
>>>>
>>>>> One odd thing i noticed, with 2.6.21-cfs-v13 the gnome's time 
>>>>> applet in
>>>>> the bar skipped some minutes (e.g. 16:23 -> 16:25) several times.
>>>>>
>>>>> The data is available on:
>>>>> http://www.debianPT.org/~elmig/pool/kernel/20070520/
>>>>>
>>>>>
>>>>> How did you get your data? I am affraid your data it's wrong, 
>>>>> there's no
>>>>>   such big difference between the schedulers...
>>>>
>>>> It doesn't look like you were running his glitch1 script which starts
>>>> several in glxgears parallel. Were you, or were you just running one?
>>>
>>> No i'm not, i'm running only one instance of glxgears inside the 
>>> GNOME's environment.
>>>
>> If you test the same conditions as I did let me know your results.
>>
>
> Hi Bill,
>
> if i've understood correctly the script runs glxgears for 43 seconds 
> and in that time generates random numbers in a random number of times 
> (processes, fork and forget), is that it?
>
No, I haven't made it clear. A known number (default four) of xterms are 
started, each of which calculates random numbers and prints them, using 
much CPU time and causing a lot of scrolling. At the same time glxgears 
is running, and the smoothness (or not) is observed manually. The script 
records raw data on the number of frames per second and the number of 
random numbers calculated by each shell. Since these are FAIR 
schedulers, the variance between the scripts, and between multiple 
samples from glxgears is of interest. To avoid startup effects the 
glxgears value from the first sample is reported separately and not 
included in the statistics.

I looked at your results, and they are disturbing to say the least, it 
appears that using the ck2 scheduler glxgears stopped for all practical 
purposes. You don't have quite the latest glitch1, the new one runs 
longer and allows reruns to get several datasets, but the results still 
show very slow gears and a large difference between the work done by the 
four shells. That's not a good result, how did the system feel?
> You find the data, for 2.6.21-{cfs-v13, ck2} in 
> http://www.debianpt.org/~elmig/pool/kernel/20070522/
>
Thank you, these results are very surprising, and I would not expect the 
system to be pleasing the use under load, based on this.
> Here's the funny part...
>
> Lets call:
>
> a) to "random number of processes run while glxgears is running", 
> gl_fairloops file
>
It's really the relative work done by identical processes, hopefully 
they are all nearly the same, magnitude is interesting but related to 
responsiveness rather than fairness.
> b) to "generated frames while running a burst of processes" aka 
> "massive and uknown amount of operations in one process", gl_gears file
>
Well, top or ps will give you a good idea of processing, but it tried to 
use all of one CPU if allowed. Again, similarity of samples reflects 
fairness and magnitude reflects work done.
> kernel    2.6.21-cfs-v13    2.6.21-ck2
> a)    194464        254669       
> b)    54159        124
>
>
Everyone seems to like ck2, this makes it look as if the video display 
would be really pretty unusable. While sd-0.48 does show an occasional 
video glitch when watching video under heavy load, it's annoying rather 
than unusable.

Your subjective impressions would be helpful, and you may find that the 
package in the www.tmr.com/~public/source is slightly easier to use and 
gives more stable results. The documentation suggests the way to take 
samples (the way I did it) but if you feel more or longer samples would 
help it is tunable.

I added Con to the cc list, he may have comments or suggestions (against 
the current versions, please). Or he may feel that video combined with 
other heavy screen updating is unrealistic or not his chosen load. I'm 
told the load is similar to games which use threads and do lots of 
independent action, if that's a reference.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

-
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/