Latency and responsivness on Linux in general

Andertxu · 2010-11-21 02:26:59

ChoK wrote:

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).

I did a "ls -R " on /usr and it shows the entire directory amazingy fast . And my /usr partition > 30G

fsckd · 2010-11-21 03:25:12

Pfft. This is ArchLinux. We need real hard data to back our claims.

$ find /usr -print | wc -l
153826
$ time find /usr -print
> snip listing <
1.37user 0.16system 0:13.99elapsed 11%CPU (0avgtext+0avgdata 12368maxresident)k
0inputs+0outputs (0major+890minor)pagefaults 0swaps
$ time ls -R /usr
> snip listing <
1.48user 0.25system 0:12.08elapsed 14%CPU (0avgtext+0avgdata 11184maxresident)k
0inputs+0outputs (0major+766minor)pagefaults 0swaps

Let's get rid of terminal latencies.

$ time find /usr -print >/dev/null
0.20user 0.39system 0:00.64elapsed 92%CPU (0avgtext+0avgdata 11392maxresident)k
0inputs+0outputs (0major+1295minor)pagefaults 0swaps
$ time ls -R /usr >/dev/null
0.58user 0.33system 0:00.98elapsed 93%CPU (0avgtext+0avgdata 11072maxresident)k
0inputs+0outputs (0major+759minor)pagefaults 0swaps

Fast indeed.

I would not blame the kernel entirely. A more extreme comparison: run GNU/Linux on an old 68k Mac. You would find Xorg unusable. (And if you want to compare with other OSes, feel how snappy System 7 is even with a blingin Kaleidoscope theme.)

maxexcloo · 2010-11-21 06:57:15

I always notice severe lag/slowdowns when copying files to NTFS partitions. That has always bugged me.

thestinger · 2010-11-21 18:05:45

maxexcloo wrote:

I always notice severe lag/slowdowns when copying files to NTFS partitions. That has always bugged me.

The NTFS driver isn't a real filesystem driver, it's a FUSE (userspace) one. So I think you can expect that. The linux kernel will probably never support NTFS as a first tier filesystem.

Last edited by thestinger (2010-11-21 18:06:20)

wahi · 2010-11-21 21:00:40

i have a dell xps 1530 and i use either awesome with no compositing(when working) or xfce with compositing enabled when i am wasting time, i was earlier using noveau but now i have switched to the nvidia driver.

thing is that while my system is quite minimal( i think) and i installed all the relevant things that i could find(following the instructions on the wiki completely) like laptop-mode-tools, cpufreq etc still when i use powertop it still shows 500+ wakeups from idle every 5 seconds. it is not that i have noticed any particular sluggishness at all, in fact i use the ondemand governor and even then things seem to move at least as quickly as they did on win 7(if not faster). most of the stuff that i do use is built from abs or aur but i have not used overtly aggressive optimizations. i am using the stock arch x86_64 kernel though.

i think i would probably tweak my c flags a bit more and then compile a minimal kernel that just has support for my hardware and enable all power management hacks and see.

edit: i was wondering though, once wayland comes out, i would probably replace xorg with wayland and i hope nouveau 3d has seen some more development and replace gcc with clang and see if i get any performance boost.
another thing i was thinking was that, one should probably try to optimise the libraries instead of the programs. and aim such that most of the programs that one uses are written in the same languages and somehow minimise the total number of libraries that are only used dependencies by the programs, i don't know what this would achieve, but i would like to see how does the performance get affected if i did all this stuff

Last edited by wahi (2010-11-21 21:07:02)

stqn · 2010-11-22 17:29:12

rwd wrote:

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.

I was curious about this so I IxQuicked and found this blog post dated from june, which states:

(...) the next version of evdev (2.5) has a changed default for the middle mouse button emulation code. It is now off by default.

(The current version of xf86-input-evdev is 2.5.0-1.)

And since I'm replying to this thread, I'll say that my new computer feels pretty responsive so far (Core i3, integrated Intel HD graphics, SSD. Default Arch kernel, XFCE with or without compositing enabled, cpufreq enabled and set to ondemand, ext4 with noatime.) Firefox and Liferea still take a few seconds to load, but apart from that it's not sluggish at all.

kcbanner · 2010-12-01 15:06:19

Check your GTK engine. Several of them are quite slow. I discovered this some time ago when trying to find out why many of my applications were not as responsive as I'd like. Get the 'gtkperf' package and try a few themes to see the difference.

anonymous_user · 2010-12-02 01:38:49

Can you name specific engines that tend to be faster or slower? Has anyone tried testing murrine vs equinox vs clearlooks vs rezlooks etc?

clutch · 2010-12-02 02:32:30

find /usr/ -print | wc -l  
109722
time find /usr -print
...
find /usr -print  0.07s user 0.27s system 13% cpu 2.550 total
time ls -R /usr/
...
ls --color=auto -R /usr  0.21s user 0.21s system 44% cpu 0.964 total

Honestly I rarely notice any lagginess that isn't obiously related to my mid-grade mechanical HDD (ie, copying large files between partitions). Then again, I have a small mountain of available CPU power, a pretty decent GPU for general desktop stuff (i5-750 running at 4.01ghz, nvidia GTS250), and I run DWM and almost entirely cli apps. I have noticed some slow-down in Gnome with a bone-stock setup on my htpc and my fiance's machines, but they are pretty old and underpowered. Firefox is slow to start on all three, but Firefox would probably be slow to start on just about anything.

Last edited by clutch (2010-12-02 02:39:49)

Simplet · 2010-12-02 15:25:24

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. 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

karabaja4 wrote:

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.

Exactly the same here. This is the first time I see someone feeling the same about GUI responsivness in Linux.
You explained very well what I feel.

The best example, is the file explorer. Instant opening under windows and little lag under linux (on various file system/file explorer/wm/...).

But this might be explained for various reasons like those below :

dnefedr wrote:

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.

G7BLOCK · 2010-12-09 02:05:08

I have also noticed this issue for a long time. It is difficult to describe what it is beyond ``a general lack of responsiveness''. Since it is difficult to say anything meaningful about this problem, my attempts to explain it in the past have all been met with doubt and suspicion. This lead me to assume that either my machine/setup was faulty, or I was experiencing some kind of placebo effect due to many years of using Windows. But having read this thread I believe this problem is real, so I will try to be as concrete as possible in describing it.

This lack of responsiveness is apparent in many aspects of the GUI including manipulating windows and pulling down menus. When I say this, I am making a direct comparison to the responsiveness of the GUI in Windows XP. (I cannot speak for later versions of Windows.)

In Windows XP, I can rapidly drag the bottom-right corner of a window in random directions and the window frame is redrawn very rapidly. There is tearing/ghosting, but at least what is occuring on screen feels like it is in direct response to the movement of the mouse. Note that the contents of the window may not be redrawn as rapidly, but the the frame of the window is. Doing the same thing in Linux, with say Openbox, the window appears to be redrawn quickly, but there ``feels'' like an ever-so-slight delay between my mouse movements and what appears on screen.

Another test is to select the File menu of a program, and rapidly span the cursor across other menu items. In Windows, each menu is rapidly displayed and hidden in what feels like "real time". Doing the same in a GTK application in Linux results in only every second menu item being drawn, giving the impression that the cursor skipped over the other items.

Finally, the file manager in Windows XP feels faster than any GUI file manager I have used in Linux.

Overall, the difference between the responsiveness of WIndows XP and say Gnome feels like the difference in responsiveness before and upgrading RAM (maybe not so much now, but 5 - 10 years ago). It doesn't affect usability, and it's not immediately noticible, but the feeling is that it is "faster". Again, maybe it's just placebo.

I hope this helps.

Last edited by G7BLOCK (2010-12-09 02:11:29)

rwd · 2010-12-09 10:05:06

G7BLOCK wrote:

I have also noticed this issue for a long time. It is difficult to describe what it is beyond ``a general lack of responsiveness''. Since it is difficult to say anything meaningful about this problem, my attempts to explain it in the past have all been met with doubt and suspicion. This lead me to assume that either my machine/setup was faulty, or I was experiencing some kind of placebo effect due to many years of using Windows. But having read this thread I believe this problem is real, so I will try to be as concrete as possible in describing it(....)

The trouble with defining latency is probably that there are so many factors involved. The delay in dropdown menus is mainly due to a default delay setting in GTK. You can disable it like I said in my previous post. Lag when resizing windows can be due to the compositing engine. I find xcompmgr rather slow compared to the built in compositing in xfwm4 (xfce window manager) for example. It could also be a general lack of awareness among developers how much responsive UI matters, and only test on their own high-end computers.

tavianator · 2010-12-09 18:42:04

To everyone talking about Windows XP: it's 9 years old! You should see how blazing fast Windows 95 is on my box . The only way that comparing Arch to XP would be fair is if you were using a 2001 snapshot of Arch, which sadly doesn't exist 'cause Arch isn't that old.

I can neither confirm nor deny that Linux has more latency than modern Windows operating systems, because I haven't had Windows installed for years. But comparisons to XP just aren't fair.

Cdh · 2010-12-09 19:11:27

G7BLOCK wrote:

This lack of responsiveness is apparent in many aspects of the GUI including manipulating windows and pulling down menus. When I say this, I am making a direct comparison to the responsiveness of the GUI in Windows XP. (I cannot speak for later versions of Windows.)

G7BLOCK wrote:

window appears to be redrawn quickly, but there ``feels'' like an ever-so-slight delay between my mouse movements and what appears on screen.

I have tried xfwm devel with and without compositing, compiz, xcompmgr and cairo-compmgr with openbox. I see what you mean, but I don't consider this to be a real issue, because the delay is so short that you don't even get it when you are not looking for it. Just looks a bit different from what windows does.

G7BLOCK wrote:

Doing the same in a GTK application in Linux results in only every second menu item being drawn, giving the impression that the cursor skipped over the other items.

To achieve this I had to move it VERY fast. Can you make a video?

Finally, the file manager in Windows XP feels faster than any GUI file manager I have used in Linux.[/quote}
Cannot reproduce

Cdh wrote:

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).

Heller_Barde · 2010-12-09 19:40:51

tavianator wrote:

To everyone talking about Windows XP: it's 9 years old! You should see how blazing fast Windows 95 is on my box . The only way that comparing Arch to XP would be fair is if you were using a 2001 snapshot of Arch, which sadly doesn't exist 'cause Arch isn't that old.
I can neither confirm nor deny that Linux has more latency than modern Windows operating systems, because I haven't had Windows installed for years. But comparisons to XP just aren't fair.

that sounds a bit ridiculous... Operating systems should not get slower with newer versions. That would obviously going the wrong way... If anything it should get faster. So comparisons with Windows XP are quite relevant (especially because the last service pack is _not_ 9 years old)

cheers
Barde

Last edited by Heller_Barde (2010-12-09 19:41:33)

pogeymanz · 2010-12-09 19:43:08

tavianator wrote:

To everyone talking about Windows XP: it's 9 years old! You should see how blazing fast Windows 95 is on my box . The only way that comparing Arch to XP would be fair is if you were using a 2001 snapshot of Arch, which sadly doesn't exist 'cause Arch isn't that old.
I can neither confirm nor deny that Linux has more latency than modern Windows operating systems, because I haven't had Windows installed for years. But comparisons to XP just aren't fair.

I have to disagree with this mentality. I find comparing to XP completely fair. It is not unreasonable to want a comparable feature-set that uses a comparable amount of resources to XP. Right now in Linux-land, if I want to have an OS use as few resources as WinXP, I have to strip it so far down that I can barely get anything done with it. That isn't cool.

Granted, we can't compare Ubuntu 10.10 to WinXP because Ubuntu 10.10 has a much larger feature-set than WinXP.

And WinXP is NOT 9 years old. I hate that claim. Service Pack 3 came out only a few years ago (2007 or 2008) and it can still probably run circles around most Distros that came out then.

EDIT: Barde beat me to the SP3 point.

Last edited by pogeymanz (2010-12-09 19:43:35)

ngoonee · 2010-12-10 00:22:37

Besides, Windows 7 OOTB is really quite speedy, on a good machine. And service packs are just updates, not 'latest developemnt', so yes the initial release date is the one which should be used for comparison.

tavianator · 2010-12-10 00:53:47

Heller_Barde wrote:

that sounds a bit ridiculous... Operating systems should not get slower with newer versions. That would obviously going the wrong way... If anything it should get faster. So comparisons with Windows XP are quite relevant (especially because the last service pack is _not_ 9 years old)

IMHO, desktop operating systems should get more powerful as time goes on. You're right that they should not get slower, in the sense that a modern computer running a modern OS should be faster than an ancient OS on an ancient computer. But I do want my OS to take advantage of my computer's resources to bring me useful features, even if that would make it slow on older computers (file indexing, for example).

OTOH, I do believe that if you should be able to sacrifice features for performance if you want, and that Arch should still run nicely on older computers. But most setups are not feature-equivalent to Windows XP; they're either minimalist or full-out GNOME/KDE. Enlightenment or XFCE may be close.

See below for a defence of my "9 years old" claim.

pogeymanz wrote:

I have to disagree with this mentality. I find comparing to XP completely fair. It is not unreasonable to want a comparable feature-set that uses a comparable amount of resources to XP. Right now in Linux-land, if I want to have an OS use as few resources as WinXP, I have to strip it so far down that I can barely get anything done with it. That isn't cool.
Granted, we can't compare Ubuntu 10.10 to WinXP because Ubuntu 10.10 has a much larger feature-set than WinXP.

Exactly. Even a new Arch install with just GNOME and a web browser has more features than Windows XP. All I'm saying is that we should be extra careful to compare apples to apples. If it turns out that Arch or Linux in general is losing in a totally fair comparison, then that's something that should be worked on.

And WinXP is NOT 9 years old. I hate that claim. Service Pack 3 came out only a few years ago (2007 or 2008) and it can still probably run circles around most Distros that came out then.

Service packs never changed the minimum or recommended hardware requirements for Windows XP. (Actually, the required hard drive space increased, but that's it.) Therefore, even XP with the latest upgrades and service pack is targeted at computers that came out with Windows XP, in 2001. To save you a google, the recommended specs are a 300MHz or faster CPU and 128MB or more of RAM.

Note that I am definitely not saying you guys are wrong about the existence of excessive latency. In fact, a look at the hottest LKML messages will show you that Linus is very concerned with improving desktop latency and responsiveness.

Last edited by tavianator (2010-12-10 00:59:20)

G7BLOCK · 2010-12-10 01:05:13

pogeymanz wrote:

It is not unreasonable to want a comparable feature-set that uses a comparable amount of resources to XP. Right now in Linux-land, if I want to have an OS use as few resources as WinXP, I have to strip it so far down that I can barely get anything done with it. That isn't cool.

This is exactly why I ventured away from Windows in the first place. This is also why I went with Arch as my first distro; the idea of building up from a bare-bones base is what attracted me. In my ignorance I assumed that running Firefox by itself in a dedicated X session would focus my computer's resources on the browser, and therefore make it run really fast. I thought that I could achieve Windows 95 speeds by simply keeping my OS's footprint comparably small. (Actually, I thought Arch would feel even faster, given the i686 optimized binaries.) I know how absurd these ideas sound, but they seemed perfectly reasonable to me at the time and were only compounded by the constant affirmation that Linux was "blazing fast".

ammon · 2010-12-10 03:19:23

But linux distros ARE more responsive then windows7, vista.
My friend recently installed Mint Debian edition to try it out (he uses W7 usually). And he is total linux noob.
And he said that is feels faster, much faster (even with compiz). Ok, I did install him kernel26-lqx, but i think thats not what it made feel fast.
You forget that W7 will load bunch of stuff into ram, preload program etc. Thus making things feel faster.
You can do same thing with preload daemon, check wiki.

What is faster on windows is searching files and programs on disk.
Maybe im not informed to state that as I use minimal setup based on Openbox, maybe GNOME supports such thing.

About file managers. I think thunar beats windows explorer. Not to speak of pcmanfm, which beats thunar double time.

karabaja4 · 2010-12-10 03:52:57

Please, Linux vs Windows discussion is not constructive. What I concluded reading this thread that responsiveness probably has two major culprits:

1) Xorg. It's roots are meant for desktop usage, so I bet it could be alot faster, not to mention lack of proper support for compositing and full utilization of GPU. I guess we will have to wait for Wayland to come out.
2) Kernel. Since alot of kernel code is not directed towards average desktop usage, some things are just not polished enough. This includes buggy GPU drivers (which are not part of kernel, but nevermind) as well as things like task and I/O schedulers.

@ammon and similar posts: read the first post of this thread, some will claim there is no responsiveness problem because they either don't notice it or they didn't use anything else for sufficient amount of time. Either way, it doesn't matter. If you don't notice the latency problem described through this whole thread, you probably can't help add anything constructive here (because, once again, responsiveness is very subjective term), so please don't flame with posts like that one just now.

Last edited by karabaja4 (2010-12-10 03:54:58)

Arch Linux

#26 2010-11-21 02:26:59

Re: Latency and responsivness on Linux in general

#27 2010-11-21 03:25:12

Re: Latency and responsivness on Linux in general

#28 2010-11-21 06:57:15

Re: Latency and responsivness on Linux in general

#29 2010-11-21 18:05:45

Re: Latency and responsivness on Linux in general

#30 2010-11-21 21:00:40

Re: Latency and responsivness on Linux in general

#31 2010-11-22 17:29:12

Re: Latency and responsivness on Linux in general

#32 2010-12-01 15:06:19

Re: Latency and responsivness on Linux in general

#33 2010-12-02 01:38:49

Re: Latency and responsivness on Linux in general

#34 2010-12-02 02:32:30

Re: Latency and responsivness on Linux in general

#35 2010-12-02 15:25:24

Re: Latency and responsivness on Linux in general

#36 2010-12-09 02:05:08

Re: Latency and responsivness on Linux in general

#37 2010-12-09 10:05:06

Re: Latency and responsivness on Linux in general

#38 2010-12-09 18:42:04

Re: Latency and responsivness on Linux in general

#39 2010-12-09 19:11:27

Re: Latency and responsivness on Linux in general

#40 2010-12-09 19:40:51

Re: Latency and responsivness on Linux in general

#41 2010-12-09 19:43:08

Re: Latency and responsivness on Linux in general

#42 2010-12-10 00:22:37

Re: Latency and responsivness on Linux in general

#43 2010-12-10 00:53:47

Re: Latency and responsivness on Linux in general

#44 2010-12-10 01:05:13

Re: Latency and responsivness on Linux in general

#45 2010-12-10 03:19:23

Re: Latency and responsivness on Linux in general

#46 2010-12-10 03:52:57

Re: Latency and responsivness on Linux in general

Board footer