v13 - random words

While performing some tests with a congested 10Mbps link, a strange thing happened: The link was congested only on one direction and both endpoint queues were RED queues. Based on the parameters and the queue size, the delay between those two links should be something near 170ms. However, the delay was much larger: >300ms (!).

The “problem” was the ring-buffer of the underlying driver (e1000). This one used a buffer of 128 packets which when added to the average 150 packets in the queue, resulted in >300ms delay.

You can see this buffer by running:

#ethtool -g eth0

And you can modify this buffer by running:

#ethtool -G eth0 tx 80

This is the transmit buffer which (when filled) adds to the delay of the local queue.

Of course, in normal use, this buffer is a good thing as it will allow to get higher transfer rates easier (from the POV of the operating system). But when making experiments, this little thing gets in the way.

Another thing is that there seems to be a minimum value for this number. For example, on this card:

Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller

the minimum value is 80 (using e1000 driver from kernel 2.6.32)

So beware and don’t loose a week looking for this thing like I did.

NOTE: This is not related to the transmit queue length that is used on the interface, as shown by:

# ifconfig eth0
# ip link show eth0


For a long time ago, a computer connected to the Internet had an RV770 ATI card and used to use the proprietary fglrx driver. Yes… That was my pc…

Then the latest fglrx (10.2) wasn’t compatible with the latest kernel (2.6.33) and that kernel supported Kernel Mode Setting (KMS) using the radeon driver. Debian also started to have appropriate libdrm and Xorg (+ driver).

So I switched to radeon/KMS driver… At first everything was not working and I blamed the radeon driver. However, as it was proved, even after uninstalling the fglrx driver it kept causing me problems. A couple of files were left behind and there was at least one file left diverted to the fglrx’s one. To fix this problem one needs to examine diversions (dpkg-divert –list), use debsusm (e.g. debsums -s libgl1-mesa-glx) and reinstall the packages with checksum problems.

Finally, after switching to radeon/KMS the following things changed:

• The used memory after startup reduced from about 2.5-3GB to less than 500MB (!!!!). I’m not talking about card’s mapped memory. I’m talking about system’s memory.
• Everything runs a lot faster. It looks like system latency is greatly reduced. There are two kind of improvements: (a) KDE’s desktop effects are smoother and (b) it looks like the latency is reduced. Somehow the effects seem to run faster because there is less delay.
• I stopped getting crashes of plasma when logging-in.
• KDE’s effects stopped being disabled every now and then.
• Tearing disappeared (!).
• Compositing effects seem to use less CPU.
• Some sound-card issues disappeared. Every now and then the sound was muted after system startup, but not any more.

So yeah… I really suggest that you switch to radeon/KMS if you’re using the fglrx driver. It sucks.

BTW, I also tested that to a laptop with an older ATI card and it had most of the above improvements as well. A colleague of mine also switched to opensource driver and show the exact same, dramatic reduce of memory usage.

This video illustrates why Linux is superb:

MP4, 80MB: http://www.v13.gr/files/videos/kde4-1/kde4-1-3.mp4
MP4, 40MB: http://www.v13.gr/files/videos/kde4-1/kde4-1-2.mp4
AVI, 40MB: http://www.v13.gr/files/videos/kde4-1/kde4-1-2.avi

In the video you see: KDE 4.3, mplayer, tvtime, konqueror, KVM, nexuiz, wine.
The video was made with kdenlive

Sometimes there is the need to allow normal users to run wireshark and capture packets from the network. Running wireshark with sudo is a security hole since anyone can overwrite any file.

A secure one-liner that solves this problem is:

# (sudo dumpcap -w -) | wireshark -k -i -

Assuming that sudo is configured to allow the user to run “dumpcap -w -” as root.

This should be 100% secure (except from the traffic monitoring issue) and will work well in (for example) labs.