Monday, December 04, 2006

Surely not a way to do performance testing, but still...

Back then, when I started using Linux based operating system (namely, RedHat, Mandrake to finally settle on Debian and then finally arriving at Ubuntu) I used to show off to my Windows using friends one o "features" at the time that was the major attraction GNU/Linux had for me. Rock solid, smooth multitasking that always kept the system responsive and usable.

A special case of that was that I showed them, how on heavy disk IO of the system, I can still have a responsive UI and use the desktop while their Windows desktop on the other hand , using the same exact hardware, running the same "benchmark" operation, started to lag on the desktop UI, have very jerky mouse movement performance and nearly choke to death.

Are those times over?

Recently, I revived this "experiment" using my ThinkPad T43p laptop with the following specs:
  • PCI-E bus
  • 1GB Ram
  • 1.87GHz
  • 60GB PATA disk, connected in what is know as a pata-to-sata bridge.
I am runnign latest feisty, but I could also reproduce this using edgy, and dapper on the same laptop configuration. I am using the open source ATI Xorg driver.

Now, what I have done (I urge you to try the same and let me know how that went for you) is make sure no running application are open after boot, open one gnome-terminal window, and there in a quick sequence I do:

find /
CTRL+SHIFT+T (open a new tab on the gnome-terminal)

And repeat this until you have 4 tabs with find running inside them. Now when I attempt this to open some more tabs (1-2) , the UI starts to lag, disk access becomes increasingly slow and the UI eventually becomes so unresponsive that even the mouse cursor refuses to obey the the mouse movements. Even when not displaying the tabs output (e.g. ALT+TAB to another window entering text) the performance loss doesn't go away, and even prevents me from easily entering text to this blog post. The most annoying part of this, is that ALT-TAB to switch another app becomes nearly impossible when the system is under this load (e.g. you can actually see UI redrawing etc as it happens) Something tells me this should not be the case...

Does anybody have an idea why this is caused? How can we possibly address this? In the beginning I thought using the -nolatency kernels could help, but this seems to have no effect on this. Any insight, comment or feedback on that are welcome.


Salvatore said...

I'm runnind 5 find / in gnome terminal and the system is still fast and usable. I'm in feisty.
Performance are better with aiglx an compiz on.

Jean said...

Last time I have such a behavior on a Linux box was because of some bad blocks on the disk.

Kieran said...

works fine with konsole under kubuntu edgy with several apps open. not sure how much help is but it seems it's confined to gnome.

`GooZ´ said...

I just tried this in Edgy, on a 1.7Ghz mobile pentium with 512MB ram and a shitty video card. My system doesn't slow down in any way.
Tested from within yakuake running in XFCE.

sivang said...

What if these are 4-5 different gnome-terminal windows? is then there is a performance hold ?

`GooZ´ said...

Nope, except for the HUGE cpu load, I almost don't notice it.

sivang said...

what happens if you try 3-4 "du -h --max-depth=1" on / , and attempt to still do something disk IO wise on another terminal ?

`GooZ´ said...

The only difference now is that the hotkey for next song in rhythmbox has a little slower response, but not that much. Even other programs start almost as fast as they normally would.

sivang said...

So, according to you system specs, are you using XFCE and not GNOME for that matter? what sort of hd and hd controller does your machine use?

Anonymous said...

12 "find /" on feisty, disk IO got slow but otherwise the OS is performing well.

* feisty
* dir_index is on
* encrypted swap (this can sometimes impact the performance)
* I'm on a -lowlatency kernel

Sometimes heavy IO coincides with heavy swapping ("only" 512Mb here, and I like beagle & co.) and that *does* slow the system down as described.

John said...


2.16GHz Pentium M
100GB Travelstar hdd

Became unworkable at about 6 terminals running find. Was able to Ctrl-C in the 6th, system became more responsive and back to normal as the terminals were shut down.

Sounds like IBM's pata-to-sata bridge may be the issue?

sivang said...

Hmm, I wonder if we could get more folks with machines based on the PATA-to-SATA bridge and possibly complain to them so they will replace this gizmo, or replace our machines (I have 3 years warrenty).

The fact that only you managed to experience the same symptoms really suggests that's something inherent to the hardware configuration. If there are any other folks with IBM/Lenon PATA-to-SATA bridge based chipsets, please leave your comment here.

anime4christ said...

No problems here with ~8-10 terminals. Using a Sony Vaio VGA-RA710G with Edgy installed.