| |||||||||||||
Bad NIH, good NIHBad NIH, good NIHPosted Mar 11, 2013 14:40 UTC (Mon) by nye (guest, #51576)In reply to: Bad NIH, good NIH by Serge Parent article: Canonical reveals plans to launch Mir display server (The H)
$time /bin/true
real 0m0.004s user 0m0.000s sys 0m0.004s
$time xterm -e /bin/true
$ssh <remote-machine>
$time /bin/true
$time xterm -e /bin/true
In this example, <remote-machine> is at the end of an ADSL connection, with an RTT of around 45ms - ie. about the best kind of connection that's widely available for the kind of money that individuals and small organisations can afford (and if you think a couple of grand a month for an internet connection is affordable, you're not thinking 'small organisation').
(Log in to post comments)
Bad NIH, good NIH Posted Mar 11, 2013 17:29 UTC (Mon) by sfeam (subscriber, #2841) [Link]
You (or xterm) are doing something very wrong.
Here's what I get using ssh to a remote machine over a bog-standard comcast consumer cable connection, followed by display of not just a terminal window but full graphics display plus round-trip response to a mouse click. Some toolkits are better than others at negotiating fast response over a remote connection, but all are funneled through x11.
$ssh <remote-machine>
$time gnuplot -e 'set term qt; plot x; pause mouse'
$time gnuplot -e 'set term wxt; plot x; pause mouse'
$time gnuplot -e 'set term x11; plot x; pause mouse'
and here's the time for display only (no wait for mouse click):
$time gnuplot -e 'set term x11; plot x'
That's not to say that response couldn't be improved, but your 37 second latency is horrible for some reason other than x11.
Bad NIH, good NIH Posted Mar 11, 2013 23:07 UTC (Mon) by nix (subscriber, #2304) [Link]
I bet his connection is dropping packets, so there's an extra delay caused by TCP timeouts in there.
Bad NIH, good NIH Posted Mar 12, 2013 12:50 UTC (Tue) by nye (guest, #51576) [Link]
>I bet his connection is dropping packets, so there's an extra delay caused by TCP timeouts in there.
Nope, but there is something interesting to see from the ping statistics while this is going on:
118 packets transmitted, 118 received, 0% packet loss, time 117123ms
(Obviously this also covers some time before and after.)
Curious as to why my ping time goes up to several hundred ms while xterm is launching, I've discovered that this local machine feels the need to send a few megabytes of data to the remote machine before doing anything.
In fact, it looks like xterm is the culprit here. I don't have many X clients installed on the machine I'm ssh'ing into to test with, but xfontsel at least starts up a lot quicker (a couple of seconds).
If even xterm can't get X network transparency right, what hope is there for everyone else?
Bad NIH, good NIH Posted Mar 14, 2013 5:48 UTC (Thu) by Serge (guest, #84957) [Link]
> You (or xterm) are doing something very wrong.
You can check that using x11trace tool. Most of the time is taken by sending fonts and other settings. That increases startup time, but makes it work faster, because it does not have to send images, it can reference fonts on the server side.
Xterm is smarter than most people think. It has configurable fonts, colors, hotkeys and many other options. For example to see xterm menu hold Control+Left/Right/Middle mouse button. But the point is that those settings are stored on a server-side (XResource), and xterm reads them all from server during startup.
Some DEs are using that. For example on KDE xterm colors should match your theme, does not matter what host you start xterm from. That's the server-side themes in action. Nobody remembers them any more... (sigh)
Bad NIH, good NIH Posted Mar 14, 2013 5:43 UTC (Thu) by Serge (guest, #84957) [Link]
> $time xterm -e /bin/true
> real 0m0.359s > user 0m0.032s > sys 0m0.036s
Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?
Anyway, your samples confirm that running application remotely is slower than running it locally. That was obvious even without testing. :) If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:
$ time xterm
$ time weston-terminal
But even that test does not necessary mean that X is faster than Wayland. It just means, that xterm starts faster. Both times are good enough. And X11 is not a bottleneck for faster program startup time. If you actually need faster startup over network right away you can try winswitch.org/xpra.
PS: When benchmarking some soft do multiple tests and select the best result. Also don't forget to switch cpufreq governor to "performance" otherwise you're benchmarking your governor, not your soft.
Bad NIH, good NIH Posted Mar 14, 2013 11:24 UTC (Thu) by nye (guest, #51576) [Link]
>Wow. I couldn't get it that slow even on a slowest Intel Atom netbook I could find. Was that the worst test of many?
No, but many repeated runs do bring it down to 0.109s in the best case.
To be fair, I don't know if the video device and driver in use have any bearing on this, but just in case it does it's worth noting that I'm running on a laptop with Intel integrated graphics, where I have historically found the quality of both hardware and driver ranges from 'awful' to 'unspeakably awful'.
> If you wanted to say that applications should start faster under Wayland than under Xorg, you should test something like:
I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.
Bad NIH, good NIH Posted Mar 15, 2013 9:01 UTC (Fri) by Serge (guest, #84957) [Link]
> No, but many repeated runs do bring it down to 0.109s in the best case. I think this is an example where the first case is the relevant one though, because that's what you'd experience in real use.
It depends on what do you want to benchmark. If you're just curious "how fast would it be next time I try" then yes. But if your goal is to compare two programs then you must reduce impact of all other obstacles, i.e. cpu throttles, disk cache, memory/swap, other programs running, etc.
> I just wanted to disagree with your claim that slow startup is not an issue, because it very frequently is when you are running remote X clients. It happens that the example you picked was one that demonstrated the difference particularly clearly.
I was just trying to say that "core protocol imposes restrictions that cannot be avoided (e.g. slow startup due to multiple roundtrips)" is not true. Slow startup is not X11 issue when running locally. Wayland only makes things worse. Applications would ofter start slower on Wayland because they're expected to talk to hardware, which requires additional steps for hardware initialization.
As for remote startup it's not that fast because of software, not because of protocol limitations. For example it could be much faster if xterm was sending requests in batch instead of waiting for response every time before sending another request. But people are lazy... They don't like optimizing things. But they like rewriting things from scratch somewhy. It's not a problem of X11 protocol, it's a human problem.
|
|||||||||||||