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
- 60GB PATA disk, connected in what is know as a pata-to-sata bridge.
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:
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.