linux-kernel - Re: Sched - graphic smoothness under load

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 19 May 2007 20:44:28 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Ray Lee <ray@...rabbit.org>
CC:	Linux Kernel M/L <linux-kernel@...r.kernel.org>
Subject: Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48

Ray Lee wrote:
> On 5/19/07, Bill Davidsen <davidsen@....com> wrote:
>> I generated a table of results from the latest glitch1 script, using an
>> HTML postprocessor I not *quite* ready to foist on the word. In any case
>> it has some numbers for frames per second, fairness of the processor
>> time allocated to the compute bound processes which generate a lot of
>> other screen activity for X, and my subjective comments on how smooth it
>> looked and felt.
>>
>> The chart is at http://www.tmr.com/~davidsen/sched_smooth_01.html for
>> your viewing pleasure.
> 
> Is the S.D. columns (immediately after the average) standard
> deviation? If so, you may want to rename those 'stdev', as it's a
> little confusing to have S.D. stand for that and Staircase Deadline.
> Further, which standard deviation is it? (The standard deviation of
> the values (stdev), or the standard deviation of the mean (sdom)?)
> 
What's intended is the stddev from the average, and perl bit me on that 
one. If you spell a variable wrong the same way more than once it 
doesn't flag it as a possible spelling error.

Note on the math, even when coded as intended, the divide of the squares 
of the errors is by N-1 not N. I found it both ways in online doc, but I 
learned it decades ago as "N-1" so I used that.
> Finally, if it is the standard deviation (of either), then I don't
> really believe those numbers for the glxgears case. The deviation is
> huge for all but one of those results.
> 
I had the same feeling, but because of the code error above, what failed 
was zeroing the sum of the errors, so (a) values after the first kept 
getting larger, and when I debugged it against the calculation by hand, 
the first one matched so I thought I had it right.

> Regardless, it's good that you're doing measurements, and keep it up :-).

Okay, here's a bonus, http://www.tmr.com/~davidsen/sched_smooth_02.html 
not only has the right values, the labels are changed, and I included 
more data points from the fc6 recent kernel and the 2.6.21.1 kernel with 
the mainline scheduler.

The nice thing about this test and the IPC test I posted recently is 
that they are reasonable stable on the same hardware, so even if someone 
argues about what they show, they show the same thing each time and can 
therefore be used to compare changes.

As I told a manger at the old Prodigy after coding up some log analysis 
with pretty graphs, "getting the data was the easy part, the hard part 
is figuring out what it means." If this data is useful in suggesting 
changes, then it has value. Otherwise it was a fun way to spend some time.

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/