sudo apt-add-repository ppa:poelzi/ulatencyd-stable
sudo apt-get update
sudo apt-get install ulatencyd
It works immediately and in my experience so far: veeery nice.
Enjoy.
Home » Posts filed under performance
Diposkan oleh Unknown on Tuesday, February 1, 2011
Diposkan oleh Unknown on Sunday, December 19, 2010
Diposkan oleh Unknown on Wednesday, August 4, 2010
Diposkan oleh Unknown on Saturday, December 26, 2009
sudo add-apt-repository ppa:gma500/ppa && sudo apt-get update
"kernel BUG: unable to handle kernel NULL pointer dereference at (null)" (2.6.31)
Section "Device"Identifier "GMA500"Option "AccelMethod" "EXA"# someone suggested UXA? but that's for the i965 driversOption "DRI" "on"Option "MigrationHeuristic" "greedy"Option "IgnoreACPI" "yes"Driver "psb"EndSectionSection "DRI"Mode 0666EndSection
wget http://www.splitted-desktop.com/~gbeauchesne/libva/pkgs/i386/libva1_0.31.0-1+sds8_i386.deb
http://www.splitted-desktop.com/~gbeauchesne/libva/pkgs/i386/libva-dev_0.31.0-1+sds8_i386.deb&& sudo dpkg -i libva1_0.31.0*i386.deb
sudo ln -s /usr/X11R6/lib/modules/dri/psb_drv_video.so /usr/lib/va/drivers/
sudo apt-get install mplayer libmad0
ln -s libx264.so.67 libx264.so.65
sudo apt-get build-dep mplayersudo apt-get install libdrm-devwget http://www.splitted-desktop.com/~gbeauchesne/libva/pkgs/i386/libva-dev_0.31.0-1+sds8_i386.deb && sudo dpkg -i libva-dev_0.31.0-1+sds8_i386.debmaybe: sudo apt-get -f install
mplayer -fs -vo vaapi -va vaapi ~/HDtest.avi
sudo make install.
Diposkan oleh Unknown on Tuesday, November 3, 2009
Diposkan oleh Unknown on Wednesday, May 27, 2009
sudo sysctl -w \
net.core.wmem_max=1075200 \
net.core.rmem_max=1075200 \
net.ipv4.tcp_rmem="4096 87380 8388608" \
net.ipv4.tcp_wmem="4096 87380 8388608" \
net.core.rmem_default=1075200 \
net.core.wmem_default=1075200
Diposkan oleh Unknown on Sunday, May 24, 2009
Diposkan oleh Unknown on Tuesday, March 24, 2009
Diposkan oleh Unknown on Friday, December 19, 2008
Diposkan oleh Unknown on Sunday, November 16, 2008
Diposkan oleh Unknown on Monday, October 27, 2008
After upgrading to Ubuntu 8.10 (release candidate), I've recently noticed stuttering in video playback. That might very well also be related to my using the intel 2.5.0 xorg driver. But Phoronix now made a correct examination and found out Ubuntu is getting slower and slower since 7.04.
Complexity or just bad programming? Is it related to the kernels gettings worse and if so, is that related to the Ubuntu patches or the vanilla kernel? I'm curious for hopefully following explanations.
Diposkan oleh Unknown on Friday, October 10, 2008
I've compared the performance of both drivers with a simple iperf test over a few meters:
Broadcom Proprietary Driver:
TCP
------------------------------------------------------------
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 46362
[ 4] 0.0-10.2 sec 24.6 MBytes 20.2 Mbits/sec
[ 5] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 46363
[ 5] 0.0-10.2 sec 24.6 MBytes 20.2 Mbits/sec
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 46365
[ 4] 0.0-10.2 sec 24.0 MBytes 19.8 Mbits/secUDP
------------------------------------------------------------
Receiving 1470 byte datagrams
UDP buffer size: 375 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 35141[ 3] 0.0-10.0 sec 24.2 MBytes 20.2 Mbits/sec 1.364 ms 0/17239 (0%)[ 3] 0.0-10.0 sec 1 datagrams received out-of-order[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 38437[ 4] 0.0-10.0 sec 27.2 MBytes 22.8 Mbits/sec 1.837 ms 0/19418 (0%)[ 4] 0.0-10.0 sec 1 datagrams received out-of-order[ 3] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 45356[ 3] 0.0-10.0 sec 28.8 MBytes 24.1 Mbits/sec 1.319 ms 0/20555 (0%)[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
B43 Open Source DriverTCP
------------------------------------------------------------
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 42345
[ 4] 0.0-10.1 sec 19.6 MBytes 16.4 Mbits/sec
[ 5] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 42346
[ 5] 0.0-10.2 sec 23.1 MBytes 19.0 Mbits/sec
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 42347
[ 4] 0.0-10.2 sec 21.7 MBytes 17.8 Mbits/secUDP
------------------------------------------------------------
Receiving 1470 byte datagrams
UDP buffer size: 375 KByte (default)
------------------------------------------------------------[ 3] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 57459
[ 3] 0.0-10.1 sec 14.0 MBytes 11.7 Mbits/sec 0.438 ms 152/10171 (1.5%)
[ 3] 0.0-10.1 sec 1 datagrams received out-of-order
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 55062
[ 4] 0.0-10.0 sec 15.7 MBytes 13.1 Mbits/sec 1.372 ms 205/11373 (1.8%)
[ 4] 0.0-10.0 sec 1 datagrams received out-of-order
[ 3] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 49861
[ 3] 0.0-10.1 sec 23.4 MBytes 19.5 Mbits/sec 3.724 ms 292/17017 (1.7%)
[ 3] 0.0-10.1 sec 1 datagrams received out-of-order
[ 4] local 192.168.178.24 port 5001 connected with 192.168.178.34 port 42069
[ 4] 0.0-10.0 sec 21.5 MBytes 18.0 Mbits/sec 1.370 ms 239/15544 (1.5%)
[ 4] 0.0-10.0 sec 1 datagrams received out-of-order
As you can see, the proprietary driver is slightly faster in TCP mode. And somehow they're both really slow in UDP mode. That's something I'd like to find out more about.
Update: That was my fault. For some reason iperf restricts UDP tests to 1 Mbit/s. Now the results are more appropriate. The result is that the proprietary driver has a more stable connection speed.
But I think that's really not worth installing a proprietary driver. Broadcom really would better integrate the changes into the open source driver. Their driver is still relying on the deprecated wireless system anyway.
Update2: Further tests showed that, at least after a while of usage, the proprietary driver creates high network latencies. Ping times to the router went up from 2 ms to an average of 160ms (peaks of 500ms !).
Diposkan oleh Unknown on Wednesday, September 10, 2008
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.core.wmem_max = 262143
net.core.rmem_max = 262143
net.core.rmem_default = 262143
net.core.wmem_default = 262143
# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time = 1800
# Turn off the tcp_window_scaling
net.ipv4.tcp_window_scaling = 0
# Turn off the tcp_sack
net.ipv4.tcp_sack = 0
# Turn off the tcp_timestamps
net.ipv4.tcp_timestamps = 0
# Enable bad error message Protection
net.ipv4.icmp_ignore_bogus_error_responses = 1
# Log Spoofed Packets, Source Routed Packets, Redirect Packets
net.ipv4.conf.all.log_martians = 1
# Increases the size of the socket queue (effectively, q0).
net.ipv4.tcp_max_syn_backlog = 1024
# Increase the tcp-time-wait buckets pool size
net.ipv4.tcp_max_tw_buckets = 1440000
Diposkan oleh Unknown on Thursday, June 19, 2008
Diposkan oleh Unknown on Wednesday, June 18, 2008
I've installed Opera 9.5. It's really nice and I'm actually writing this entry with it right now. But then because of unfortunate resume problems after a BIOS upgrade with my Acer notebook, I've installed and tried the new version in Windows as well.
And frankly, I was amazed. The websites loaded so quickly it seemed they were just there immediately. Awesome work, Opera. But then I started wondering:
Why is Opera so much faster under Windows?
Diposkan oleh Unknown on Wednesday, June 11, 2008
If you find out that Xorg grows bigger and bigger with time, chances are high that this is not actually Xorg, but a program that uses its pixmap cache.
xrestop will tell you just that. It lists the applications by how much pixmap cache they use. Mine starts with "" using about 226 MB(!), looking up the process id shows that "" stands for plasma! (Nice try at hiding, budddy!)
Crazy...
Diposkan oleh Unknown on Sunday, June 8, 2008
If you want to know what exactly a program is doing, e.g. to find out why it's using 50% cpu right now, you can use the strace command:
strace -r -fF -T -p `pidof someprogram`
As always, you can find out more about the usage with man strace. It often does not respond to Ctrl-C in my experience, which is why I often kill it. killall -QUIT strace
And it also often forgets to restart the program it traced, so try a killall -CONT someprogram.
Diposkan oleh Unknown on Thursday, June 5, 2008
Researchers at the German Max Planck Institute for Software Systems put together a website that
Diposkan oleh Unknown on Saturday, February 9, 2008
Einfach ein Verzeichnis $HOME/ram erzeugen und in die /etc/fstab einfügen:
und schon habt ihr eure ganz persönliche Ramdisk, die ihr selbst (un)mounten könnt.
2010 All Rights Reserved News Jaya.