Latency and responsivness on Linux in general

karabaja4 · 2010-11-18 20:09:27

Ever since I used Linux, even before I switched to Arch, there was some sluggishnes on Linux GUI in the air I could never put my finger on. I first began to notice this sometime after I started using GNOME on Ubuntu 7.04. It was nothing I could say - look, this thing is slow. Everything opened in acceptable latencies, but overall experience was... well, sluggish. But as I said, nothing I can put my finger on. Once I mentioned something like this on some unrelated Linux forum a while ago, and was shot down by alot of users claiming otherwise. At the time I just switched from Windows systems and was used to extreme responsivness.

Now I'm using Arch and the feeling is still there, even though I use Openbox and most minimal system configuration as possible. Recently I began to experiment with various kernel patches meant to improve system responsivness on *desktop* computers, like Con Kolivas's BFS scheduler and BFQ I/O scheduler. The result was positive, but still not satisfactory enough.

I know some people will say that they don't experience any slugishness described here. And that's understandable, because not everyone is speed-freak like me when it comes to desktop usage, and not everyone is using *desktop* applications or environments.

Recently, there was an article on Phoronix and Slashdot about ~200 lines kernel patch that, I quote, "does wonders" - see local thread here. The patch made a big hype, because it lead people to believe they could improve their system speed, but in reality all the patch did was prevent your system from choking the CPU to death if you do crazy things like spawn 64 jobs with -j64 inside a single tty when compiling. You can see alot of people on Ubunu forums begging for someone to compile a PPA so they could try it. I take this as evidence that Linux *desktop* users crave responsivness on their systems.

So I wonder what's the deal here? Is it GTK related - because most of this I experience while using GTK applications? Is it kernel related? Filesystem? Something else? I don't think this has to do with hardware configuration because my system (A64 3200+) should be more than enough for basic desktop usage. Perhaps Linux kernel is more oriented for server usage and as such unsuitable for *desktop* usage and experience, because most kernel developers are hackers themselves and care little about average Joe. Example of this is the same article mentioned above, in which they posted reply from Linus Torvalds praising the patch because it made possible for him to compile kernel with -j6 or whatever while doing something else in peace. Average Joe cares little about this.

Please, don't turn this discussion in Windows vs Linux responsivness - there was a similar thread here which is now in Topics Going Nowhere, and let's try to keep discussion constructive.

Thanks.

Last edited by karabaja4 (2010-11-18 22:09:24)

ChoK · 2010-11-19 01:10:02

I don't usually like to participate in such discussion, because trolls are quick to come and I prefer to ask myself what to do instead of trying to find *the* culprit, but well ...

I agree that there is a responsiveness problem and KDE apps are affected as well as GTK one. Actually it's more like plasma/kwin are affected but I think it's more of a video drivers issue than anything.

I have 2 main problems currently : One is I/O load choking the desktop to death. The other one is the RAM hogging applications : firefox and chromium being the main culprits, java, amarok, nepomuk following.

Oh yeah ext4 is really slow at listing files with ls, directories with 10000+ files are unmanageable , ntfs can do that instantly (or windows doesn't throw the inode cache, gotta try tuning vfs_cache_pressure).

Last edited by ChoK (2010-11-19 01:13:15)

pseudonomous · 2010-11-19 02:48:03

The problem may be, to some degree Xorg. Try looking at:

the xorg developer pages

Of course, now that XCB is pretty much done, some of the problem is the toolkits still using Xlib instead.

falconindy · 2010-11-19 04:08:43

pseudonomous wrote:

now that XCB is pretty much done

An odd claim to make.

https://bugzilla.redhat.com/show_bug.cgi?id=465759#c23
http://xcb.freedesktop.org/TODO/

seiichiro0185 · 2010-11-19 07:34:48

I found this this morning and the author claims it has the same effect as the above mentioned kernel-patch. Since I'm at work and have to use a windows computer atm I can't try it, but maybe someone wants to give it a shot and see if it helps with desktop responsiveness.

Awebb · 2010-11-19 08:10:37

It would be interested to see a screencast showing what exactly a "lack of responsiveness" is.

Where exactly do you see those lags? Is it the time it takes to Alt+Tab/click on the icon in the panel and switch to the window, or the time it takes to start an application (from the runner, terminal or shortcut)?

Giselher · 2010-11-19 08:11:27

seiichiro0185 wrote:

I found this this morning and the author claims it has the same effect as the above mentioned kernel-patch. Since I'm at work and have to use a windows computer atm I can't try it, but maybe someone wants to give it a shot and see if it helps with desktop responsiveness.

I can't create the cpu directory in /sys/fs/cgroup -_-. No idea why.

flamelab · 2010-11-19 08:30:51

The major problem of responsiveness is located not in the CPU, but on the GPU (to be exact: the drivers) and the HDD.

To be more specific:

1)GPU: The major problem is that on the modern Linux GUIs, despite the fact that the most demanding WM (Kwin) is using old OpenGL specifications, most of the drivers fail to use the GPUs full potential. For a minimize/maximize, that is a huge effort for .... Catalyst. The use of Blur is a major effort for the Intel drivers. The best of them, the binary Nvidia driver, has problems on resizing the windows - what?

That a huge issue. I still remember, on the days of KDE3, when using Compiz+KDE3, the fglrx could cause a 3 seconds lag on the Kicker window.

2)HDD: The x86_64 users are familiar with the weird lag when moving huge files on Linux. Well, that's also apparent on Windows as well, but not in such dramatic manner. I mean, the system may even freeze, even though most of the GUI elements are located within the RAM, I mean, wtf, what's going SO wrong here ? All the 2.6.3x series of kernels suffer from that issue.
> I also don't forget that weird problem with the memory cards/USB etc

Cdh · 2010-11-19 09:04:11

I say it heavily depends on your system. I had very different systems over time and sometimes I really felt the same "sluggyness" but now I do not at all (see below).

Awebb wrote:

It would be interested to see a screencast showing what exactly a "lack of responsiveness" is.

On the other hand I made a little video for the other thread:
http://dl.dropbox.com/u/13721560/thunar.mkv
Even qt programs open near to instantly on xfce... (when everything is in cache of course. hard disk is still extremely slow).

Fruity · 2010-11-19 09:51:03

The thing which pops out to me, is that these guys (the phoronix kernel hack and seiichiro0185's link) Are stressing their computers a great deal. For mere mortals who aren't forcing the computer to deal with 60+ high CPU processes at the same time: quote; linus "while doing a "make -j64" on the kernel at the same time", how relevant is this, really?

Surely for the average linux user, if there is a problem it's going to lie with bloated software (compare the speed of xfce vs kde), various hardware - for example a 5,400rpm IDE drive vs a 10,000rpm sata3 vs an SSD, what about the file system, this has a massive impact on read and write performance.

ijanos · 2010-11-19 09:58:26

karabaja4 wrote:

Ever since I used Linux, even before I switched to Arch, there was some sluggishnes on Linux GUI in the air I could never put my finger on.

Oh the untouchable sluggishness. Try xcompmgr with all the effects turned off (they are buggy anyways). My thoughts on this is that compositing will increase that feel of responsiveness of the GUI.
Proper compositing is what linux desktops lack compared to osx or windows, and sadly the the situation will not improve till wayland comes along (which will take years)

ngoonee · 2010-11-19 10:09:11

Fruity wrote:

The thing which pops out to me, is that these guys (the phoronix kernel hack and seiichiro0185's link) Are stressing their computers a great deal. For mere mortals who aren't forcing the computer to deal with 60+ high CPU processes at the same time: quote; linus "while doing a "make -j64" on the kernel at the same time", how relevant is this, really?

Hmm, after playing around with Linux for a while I'm pretty sure the following will be eating your CPU:-
1. Some sort of compile (rarely) from the AUR
2. Some conky processes, which will almost certainly be running scripts, lua or not.
3. Quite a few daemons for various tasks (dovecot, laptop-mode-tools, sshd, dbus etc. etc.)
4. The heavy CPU load of a system using compositing (seriously, Xorg is at the top of CPU usage if the system is idle)

I've never really wanted to compare responsiveness of my Arch with the Windows I previously used. I know I'm just doing so much more with it.

Awebb · 2010-11-19 15:26:33

ngoonee wrote:

3. Quite a few daemons for various tasks (... laptop-mode-tools ...)

How ironic. laptop-mode-tools are supposed to help us save battery. It's done by eating away battery. That's like a smoke against cancer :-D

ngoonee · 2010-11-19 16:16:30

Awebb wrote:

ngoonee wrote:
3. Quite a few daemons for various tasks (... laptop-mode-tools ...)
How ironic. laptop-mode-tools are supposed to help us save battery. It's done by eating away battery. That's like a smoke against cancer :-D

It does save battery. It is also an additional process . For most laptops the difference between using it and not using it is quite stark, if you don't use it then you'll be using acpid and some combination of power-saving scripts (hard disk spin-down, unload bluetooth/wifi etc.) yourself anyway.

el mariachi · 2010-11-20 12:58:21

http://www.webupd8.org/2010/11/alternat … patch.html
anyone tried this?

Truth be told, my Pentium III 933Mhz computer starts apps as fast as my core2duo laptop. Go figure...

Ramses de Norre · 2010-11-20 13:08:03

el mariachi wrote:

http://www.webupd8.org/2010/11/alternat … patch.html
anyone tried this?
Truth be told, my Pentium III 933Mhz computer starts apps as fast as my core2duo laptop. Go figure...

I'm running 2.6.36 with the patch that method is trying to duplicate, but I'm not really noticing anything new. But then, I didn't really have performance issues.

eldragon · 2010-11-20 13:28:25

im not sure what people here suggest is what the OP is about.

i did get the feeling when i switched to linux from XP a while ago that the gui was slowish.. as if you could notice the screen being drawn. im almost sure its X to blame (this was before compiz came around). when compiz arrived, things improved a bit, but its still there.

i used nvidia / ati / intel and all have the same effect.

i tried xfce / gnome / openbox / kde and all have the same effect

its not something that a screen cast will capture.

i got used to it with time but really hope wayland will fix this.

that said, this is only a perceived slugginess and its not dependant on cpu usage.

dnefedr · 2010-11-20 16:04:35

I have noticed this problem for years, anytime I have tried to discuss it with the community I would always get shunned or insulted. Everyone keeps claiming that Linux is faster than Windows, and how their machine performs so much better under Linux. My experience is that this is rarely true under the GUI, even with a very minimal desktop/window manager. This is especially noticeable for people who tweak Windows, who disable unneeded services, remove menu delay in the registry and keep a very clean system. The problem is that responsiveness is all relative to personal experience, yes as a OS I think Linux can perform faster than Windows. Especially in raw processing tasks, like extracting a file. But the rendering of GUI elements like windows, menus, icons and scrolling still feel less responsive to me under Linux. I'm not sure if a accurate test can be developed to measure these differences.

I think it ultimately has to do with the implementation of the kernel, xorg, poor drivers for video cards and GUI of choice. Gnome and KDE being the worst culprits of causing unresponsiveness.

Also consider the fact that Windows has an embedded kernel and GUI, with explorer also functioning as the desktop/window manager, task bar and file manager. This allows windows to run faster, since the GUI elements are not split up (often integrated into a single process) and feel more responsive. However have you noticed if your file manager crashes it takes down the whole GUI and requires a restart or relaunching of explorer.exe? Keep in mind I am talking specifically about XP.

Last edited by dnefedr (2010-11-20 16:06:10)

Awebb · 2010-11-20 17:52:15

ngoonee wrote:

It does save battery. It is also an additional process . For most laptops the difference between using it and not using it is quite stark, if you don't use it then you'll be using acpid and some combination of power-saving scripts (hard disk spin-down, unload bluetooth/wifi etc.) yourself anyway.

Indeed. I use it on my netbook, it does a good job. Maybe I'll get rid of it soon and learn to do manually what it does, but in the end, I'll return to it, it's nice and quite complete.

rwd · 2010-11-20 20:27:37

Try the Con Kolivas patch ( AUR kernel26-ck) . It is a CPU scheduler tweak to minimize latency, which translates to responsiveness to a desktop user, at the cost of overall throughput. Also I always minimize the popup-menu delays in ~/.gtkrc-2.0 :

gtk-menu-popup-delay = 20
gtk-menu-popdown-delay = 20

Then there are ways to get rid of input delay, for example by disabling the default 3-button emulation in xorg that lags the mouse.

Last edited by rwd (2010-11-20 20:37:05)

3]) · 2010-11-20 23:11:07

Perhaps linux's lack of responsiveness GUI wise has to do with a combination of ''drivers lacking-inefficient coding-and unoptimized kernels' ?

Maybe code isn't optimized for speed, but for usability?

Perhaps its an driver issue?

There are many factors that could create this whole 'latency and responsiveness' issue.

Last edited by 3]) (2010-11-20 23:16:48)

karabaja4 · 2010-11-20 23:23:23

Sorry for lack of response.

ijanos wrote:

Oh the untouchable sluggishness. Try xcompmgr with all the effects turned off (they are buggy anyways). My thoughts on this is that compositing will increase that feel of responsiveness of the GUI.
Proper compositing is what linux desktops lack compared to osx or windows, and sadly the the situation will not improve till wayland comes along (which will take years)

I don't use xcompmgr for exacly that reason, it's buggy as hell, and not maintained anymore. I figured I don't need compositing anyway.

eldragon wrote:

im not sure what people here suggest is what the OP is about.
i did get the feeling when i switched to linux from XP a while ago that the gui was slowish.. as if you could notice the screen being drawn. im almost sure its X to blame (this was before compiz came around). when compiz arrived, things improved a bit, but its still there.
i used nvidia / ati / intel and all have the same effect.
i tried xfce / gnome / openbox / kde and all have the same effect
its not something that a screen cast will capture.
i got used to it with time but really hope wayland will fix this.
that said, this is only a perceived slugginess and its not dependant on cpu usage.

Yeah, exacly. I agree, it's not something you could capture, it's just there. It may be xorg, but somehow I doubt it...

dnefedr wrote:

I have noticed this problem for years, anytime I have tried to discuss it with the community I would always get shunned or insulted. Everyone keeps claiming that Linux is faster than Windows, and how their machine performs so much better under Linux. My experience is that this is rarely true under the GUI, even with a very minimal desktop/window manager. This is especially noticeable for people who tweak Windows, who disable unneeded services, remove menu delay in the registry and keep a very clean system. The problem is that responsiveness is all relative to personal experience, yes as a OS I think Linux can perform faster than Windows. Especially in raw processing tasks, like extracting a file. But the rendering of GUI elements like windows, menus, icons and scrolling still feel less responsive to me under Linux. I'm not sure if a accurate test can be developed to measure these differences.
I think it ultimately has to do with the implementation of the kernel, xorg, poor drivers for video cards and GUI of choice. Gnome and KDE being the worst culprits of causing unresponsiveness.
Also consider the fact that Windows has an embedded kernel and GUI, with explorer also functioning as the desktop/window manager, task bar and file manager. This allows windows to run faster, since the GUI elements are not split up (often integrated into a single process) and feel more responsive. However have you noticed if your file manager crashes it takes down the whole GUI and requires a restart or relaunching of explorer.exe? Keep in mind I am talking specifically about XP.

I agree that some users will claim they don't experience this problem, I explained why in the first post. As for the Windows part, yes, they don't have these symptomps... but let's keep the discussion off comparing Linux to Windows because as already mentioned trolls are quick to come and I really don't want this thread TGN'ed...

I also agree that this problem is probably due to combination of kernel and/or xorg and/or drivers. I'm just trying to figure out which.

rwd wrote:

Try the Con Kolivas patch ( AUR kernel26-ck) . It is a CPU scheduler tweak to minimize latency, which translates to responsiveness to a desktop user, at the cost of overall throughput. Also I always minimize the popup-menu delays in ~/.gtkrc-2.0 :
gtk-menu-popup-delay = 20
gtk-menu-popdown-delay = 20
Then there are ways to get rid of input delay, for example by disabling the default 3-button emulation in xorg that lags the mouse.

As mentioned in the first post, I already use the -ck patchest.

I recently figured out one thing - the open source nouveau driver performs BETTER in 2D than nvidia's offical blob drivers (the thing most noticable is scrolling), which is kinda ironic given nvidia's unwillignes to release the drivers code... The GUI will probably remain sluggish for a long time, but maybe, just maybe, one day someone will come up with a miracle solution XD

Last edited by karabaja4 (2010-11-20 23:33:56)

thestinger · 2010-11-21 00:32:23

karabaja4 wrote:

I don't use xcompmgr for exacly that reason, it's buggy as hell, and not maintained anymore. I figured I don't need compositing anyway.

If you don't want things to be sluggish (redrawing, etc), then you DO need compositing, but Xorg doesn't really have proper compositing (we'll have to wait for Wayland). Compositing renders via the GPU, and it's a lot smoother and faster. It's the reason why XP has window tearing/lag, but Windows Vista and Windows 7 don't.

karabaja4 · 2010-11-21 00:41:56

thestinger wrote:

If you don't want things to be sluggish (redrawing, etc), then you DO need compositing, but Xorg doesn't really have proper compositing (we'll have to wait for Wayland). Compositing renders via the GPU, and it's a lot smoother and faster. It's the reason why XP has window tearing/lag, but Windows Vista and Windows 7 don't.

Heh, really? Turning on compositing manager has an effect of GUI being drawn on GPU instead of CPU? I thought it just takes care of extra effects like shadows or transparency (and that maybe those parts would have something to do with GPU)... I'll try using it for a few days and report my results. In the meantime, is there a developer who can confirm xcompmgr actually has an effect of GUI being drawn on GPU?

P.S. But still this doesn't explain why people experienced this with Compiz on any full DE (including me).

Last edited by karabaja4 (2010-11-21 00:45:31)

thestinger · 2010-11-21 00:43:09

xcompmgr doesn't work very well.. so don't count on it

compiz definitely causes the drawing to be done on the GPU though

edit: to clarify, the windows and decorations are rendered on the GPU, not the GTK stuff afaik

Also, as I said, Xorg doesn't support proper compositing. It's an improvement, but not a solution.

Last edited by thestinger (2010-11-21 00:45:50)

Arch Linux

#1 2010-11-18 20:09:27

Latency and responsivness on Linux in general

#2 2010-11-19 01:10:02

Re: Latency and responsivness on Linux in general

#3 2010-11-19 02:48:03

Re: Latency and responsivness on Linux in general

#4 2010-11-19 04:08:43

Re: Latency and responsivness on Linux in general

#5 2010-11-19 07:34:48

Re: Latency and responsivness on Linux in general

#6 2010-11-19 08:10:37

Re: Latency and responsivness on Linux in general

#7 2010-11-19 08:11:27

Re: Latency and responsivness on Linux in general

#8 2010-11-19 08:30:51

Re: Latency and responsivness on Linux in general

#9 2010-11-19 09:04:11

Re: Latency and responsivness on Linux in general

#10 2010-11-19 09:51:03

Re: Latency and responsivness on Linux in general

#11 2010-11-19 09:58:26

Re: Latency and responsivness on Linux in general

#12 2010-11-19 10:09:11

Re: Latency and responsivness on Linux in general

#13 2010-11-19 15:26:33

Re: Latency and responsivness on Linux in general

#14 2010-11-19 16:16:30

Re: Latency and responsivness on Linux in general

#15 2010-11-20 12:58:21

Re: Latency and responsivness on Linux in general

#16 2010-11-20 13:08:03

Re: Latency and responsivness on Linux in general

#17 2010-11-20 13:28:25

Re: Latency and responsivness on Linux in general

#18 2010-11-20 16:04:35

Re: Latency and responsivness on Linux in general

#19 2010-11-20 17:52:15

Re: Latency and responsivness on Linux in general

#20 2010-11-20 20:27:37

Re: Latency and responsivness on Linux in general

#21 2010-11-20 23:11:07

Re: Latency and responsivness on Linux in general

#22 2010-11-20 23:23:23

Re: Latency and responsivness on Linux in general

#23 2010-11-21 00:32:23

Re: Latency and responsivness on Linux in general

#24 2010-11-21 00:41:56

Re: Latency and responsivness on Linux in general

#25 2010-11-21 00:43:09

Re: Latency and responsivness on Linux in general

Board footer