Miguel Figueiredo wrote:
Bill Davidsen wrote:
Miguel Figueiredo wrote:
Ray Lee wrote:
On 5/20/07, Miguel Figueiredo <[email protected]> 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 <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
