I have tested Andrew Morton's low latency patch versus Ingo's sched
O(1) patch a bit:
"O1" is 2.4.18-pre2 + sched-O1-2.4.17-G1
"LL" is 2.4.18-pre3 + 2.4.17-low-latency + riel's 2.4.3ac4-largenice
(Red Hat 7.2 Linux, UP Athlon CPU 850MHz)
Comparison:
Tuxracer:
- reports same framerate on both when no other load is on the
machine and the game is smooth in both cases.
Tuxracer + kernel compilation (both nice 0):
LL: the game skips a lot, ugly :(
O1: the game skips much less than LL, playable
Tuxracer + kernel compilation with nice +19:
LL: no skipping, almost same as without kernel compilation
O1: skips a little less then with kernel compilation (nice 0)
but skips much more than LL in this case.
Xmms/Jess visual plugin:
- same framerate when no load
(LL: maybe a little bit larger (+10%) framerate than O1)
Xmms/Jess + kernel compilation:
LL: almost doesn't work, very bad :(
O1: lower framerate (1/3), skips a little, but works
Xmms/Jess + kernel (nice +19):
LL: almost exactly same as LL without kernel compilation!
O1: framerate somewhere between.. skips ocassionaly
Conclusion:
This is not a real test nor real benchmark, only a little stupid luser
test, but it can show that LL is much better in interactivity and
smoothness but you HAVE to setup priorities (nice levels) of tasks by
hand (explicitely). When you don't setup priorities explicitely than
sched O1 makes the job for you but don't achieve same
interactivity/smoothness performance as LL.
So I suggest a combination of some conservative LL + O(1) scheduler
will make linux desktop kicking ass! :)
--
Martin Ma?ok http://underground.cz/
[email protected] http://Xtrmntr.org/ORBman/
On Fri, Jan 11, 2002 at 01:12:52PM +0100, Martin Ma?ok wrote:
> I have tested Andrew Morton's low latency patch versus Ingo's sched
> O(1) patch a bit:
>
> "O1" is 2.4.18-pre2 + sched-O1-2.4.17-G1
>
> "LL" is 2.4.18-pre3 + 2.4.17-low-latency + riel's 2.4.3ac4-largenice
"PS" is 2.4.18-pre3 + sched H6 + preempt
With PS I got somewhere in between O1 and LL, which means that desktop
performance under load with "nice -n +19 make bzimage" (audiovisual
xmms plugins, tuxracer, Q3A, mozilla) were best smooth with LL, and a
little worse with PS.
With "nice -n 0 make bzimage" desktop interactivity was best with PS,
a little worse with O1 and worst with LL.
If I get enough free time, I will test O1+preempt versus O1+mini-ll.
Something tells me that best results will be with O1+LL, because in LL
versus preempt, LL wins for me (interactivity, smoothness).
--
Martin Ma?ok http://underground.cz/
[email protected] http://Xtrmntr.org/ORBman/
On Mon, Jan 14, 2002 at 01:01:34AM +0100, Martin Ma?ok wrote:
> If I get enough free time, I will test O1+preempt versus O1+mini-ll.
O1+mini-ll feels better and smoother when playing tuxracer during
kernel compilation (both nice +19 and +0 cases). (but I haven't tested
O1+preempt+lockbreak)
However, comparing full_ll versus O(1)+mini_ll when there's no
load, I get 10% higher framerate of XMMS/Jess audio/visual plugin.
When there is some real load, O(1)+mini_ll performs ~30% higher
framerate then just full_ll.
(So the winner for my desktop is still vanilla+full_ll+largenice while
explicitely running non-interactive highload tasks with nice +19 (ie,
compilations, cronjobs, mailserver...) the only "audio skipping" task
is mkisofs)
--
Martin Ma?ok http://underground.cz/
[email protected] http://Xtrmntr.org/ORBman/
On Mon, Jan 14, 2002 at 09:06:44AM +0100, Martin Ma?ok wrote:
> However, comparing full_ll versus O(1)+mini_ll when there's no
> load, I get 10% higher framerate of XMMS/Jess audio/visual plugin.
(forgot to finish the sentence...) higher framerate with full_ll.
but:
> When there is some real load, O(1)+mini_ll performs ~30% higher
> framerate then just full_ll.
--
Martin Ma?ok http://underground.cz/
[email protected] http://Xtrmntr.org/ORBman/
Shortly: the winner is 2.4.18pre2aa2 for me (but it's close).
> > If I get enough free time, I will test O1+preempt versus O1+mini-ll.
>
> O1+mini-ll feels better and smoother when playing tuxracer during
> kernel compilation (both nice +19 and +0 cases). (but I haven't tested
> O1+preempt+lockbreak)
>
> However, comparing full_ll versus O(1)+mini_ll when there's no
> load, I get 10% higher framerate of XMMS/Jess audio/visual plugin.
> When there is some real load, O(1)+mini_ll performs ~30% higher
> framerate then just full_ll.
>
> (So the winner for my desktop is still vanilla+full_ll+largenice while
> explicitely running non-interactive highload tasks with nice +19 (ie,
> compilations, cronjobs, mailserver...) the only "audio skipping" task
> is mkisofs)
(and if anybody is interested at all)
I have tested many different variants during last week:
/boot/bzImage-2.4.17 /boot/bzImage-2.4.18-pre3-ac1_sh7_ml
/boot/bzImage-2.4.17-rc2 /boot/bzImage-2.4.18-pre3-ac2-sh7-ml
/boot/bzImage-2.4.17sH5 /boot/bzImage-2.4.18-pre3-ac2-sj0-ml
/boot/bzImage-2.4.18pre1 /boot/bzImage-2.4.18-pre3h4p
/boot/bzImage-2.4.18pre2 /boot/bzImage-2.4.18-pre3ll
/boot/bzImage-2.4.18pre2aa2 /boot/bzImage-2.4.18pre3sH4
/boot/bzImage-2.4.18pre2aa2r /boot/bzImage-2.4.18-pre3sH5
/boot/bzImage-2.4.18pre2l /boot/bzImage-2.4.18-pre4-si3-ml-p-l
/boot/bzImage-2.4.18pre2s /boot/bzImage-2.4.9
And as far as I can tell, 2.4.18pre2aa2 is the winner for my desktop.
My usual (and testing workload) consists of KDE2.2.2, Mozilla,
xmms/mp3, mplayer/divx, tuxracer etc.. while 1-2 compilations on
background with nice +19. I experienced most interactive desktop with
-aa kernel.
(My HW is Atlon 850, 256MB RAM, KT133A VIA, Matrox G450).
--
Martin Ma?ok http://underground.cz/
[email protected] http://Xtrmntr.org/ORBman/