m0rd0r's bl0g

What is a Jumbo Frame and why should you enable it when they will go fragmented over the Internet? First of all, in small local 1G networks it has quite a good impact on performance. Especially on multimedia over IP. And Second – it’s quite good on file transfer too. It takes less overhead and more real payload when Jumbo frames are enabled even on your own local home network (I have 7.5 PCs in my home. One behind the TV. One holds the internet connection and protects the others. One holds all my files with a Samba sharing. Other keeps live backup of my blog. One heavy game PC. One Linux sand-box for experiments. One UMPC. And one Android smartphone.) So it will not affect performance if both my TV PC plays a movie directly from the Samba and I am uploading a backup of my Blog, while a uTorrent session on the game PC is downloading the files over the Samba. All 3 in parallel.

Good enough?

First of all. You must have Jumbo frames enabled in Kernel. Second. You must check if your NIC is high MTU capable (MTU = Max Transfer Unit) with ifconfig. If it’s unable, you will see error message. I have a 4 NIC PC for experiments with old classic RTL8139 chip. They don’t do the job at all:

bash-4.1# lspci | grep [Ee]ther
01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
bash-4.1# ifconfig eth3 mtu 512
bash-4.1# ifconfig eth3 mtu 4000
SIOCSIFMTU: Invalid argument
bash-4.1# ifconfig eth3 mtu 9000
SIOCSIFMTU: Invalid argument
bash-4.1#

Not going to help me at all. So I switch to the more potent machine on my work desk.

root@router:~# lspci | grep [Ee]ther
0c:00.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter (rev 11)
0c:01.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter (rev 11)
root@router:~#

For this test I am using one Telco Systems network unit in the Laboratory where I work to generate traffic of 5 Mbits/s over a linux  bridged connection. Obviously, the bridged connection over the Lab PC is not allowing Jumbo frames. PDU sizes of 2000 and 9000 bytes, do not pass.

----------------------------------------------------------------
|  Size  | Successful rate | Net Successful rate |  Frame-loss |
+--------+-----------------+---------------------+-------------+
|    64  |      5000Kbps   |        3809Kbps     |     0.000 % |
|   128  |      5000Kbps   |        4324Kbps     |     0.000 % |
|   256  |      5000Kbps   |        4637Kbps     |     0.000 % |
|   512  |      5000Kbps   |        4812Kbps     |     0.000 % |
|  1024  |      5000Kbps   |        4904Kbps     |     0.000 % |
|  1280  |      5000Kbps   |        4923Kbps     |     0.000 % |
|  1518  |      5000Kbps   |        4934Kbps     |     0.000 % |
|  2000  |         0Kbps   |           0Kbps     |   100.000 % |
|  9000  |         0Kbps   |           0Kbps     |   100.000 % |
+--------+-----------------+---------------------+-------------+

----------------------------------------------------------------
|  Size  |    Min Delay    |    Avg Delay    |    Max Delay    |
+--------+-----------------+-----------------+-----------------+
|    64  |       77.312 us |       79.037 us |      166.400 us |
|   128  |      102.912 us |      104.884 us |      255.488 us |
|   256  |      154.624 us |      156.385 us |      197.632 us |
|   512  |      249.856 us |      251.178 us |      501.248 us |
|  1024  |      432.128 us |      433.554 us |      444.416 us |
|  1280  |      523.264 us |      524.655 us |      649.728 us |
|  1518  |      607.744 us |      609.398 us |      635.904 us |
|  2000  |        0.000 us |        0.000 us |        0.000 us |
|  9000  |        0.000 us |        0.000 us |        0.000 us |
+--------+-----------------+-----------------+-----------------+

And this is what happened when I issued the commands

ifconfig eth0 mtu 9000
ifconfig eth1 mtu 9000
...
...
----------------------------------------------------------------
|  Size  | Successful rate | Net Successful rate |  Frame-loss |
+--------+-----------------+---------------------+-------------+
|    64  |      5000Kbps   |        3809Kbps     |     0.000 % |
|   128  |      5000Kbps   |        4324Kbps     |     0.000 % |
|   256  |      5000Kbps   |        4637Kbps     |     0.000 % |
|   512  |      5000Kbps   |        4812Kbps     |     0.000 % |
|  1024  |      5000Kbps   |        4904Kbps     |     0.000 % |
|  1280  |      5000Kbps   |        4923Kbps     |     0.000 % |
|  1518  |      5000Kbps   |        4934Kbps     |     0.147 % |
|  2000  |      5000Kbps   |        4950Kbps     |     0.000 % |
|  9000  |      5000Kbps   |        4988Kbps     |     0.000 % |
+--------+-----------------+---------------------+-------------+

----------------------------------------------------------------
|  Size  |    Min Delay    |    Avg Delay    |    Max Delay    |
+--------+-----------------+-----------------+-----------------+
|    64  |       14.336 us |       14.401 us |       14.848 us |
|   128  |       15.872 us |       16.723 us |       17.408 us |
|   256  |       19.456 us |       20.703 us |       22.016 us |
|   512  |       28.672 us |       28.686 us |       29.184 us |
|  1024  |       43.520 us |       44.229 us |       44.544 us |
|  1280  |       51.712 us |       52.437 us |       53.248 us |
|  1518  |       58.880 us |       59.927 us |       60.928 us |
|  2000  |       74.240 us |       74.844 us |       75.264 us |
|  9000  |      293.888 us |      294.365 us |      294.912 us |
+--------+-----------------+-----------------+-----------------+

So It actually works, but not with my cheap NICs in home. The RTL family is quite good, but the good models with faster chip are a bit expensive for my home networks. If you want the MTU set on startup, there are 2 ways. First one, you add lines like this in /etc/rc.d/rc.inet1.conf:

# Config information for eth0:
IPADDR[0]="172.16.1.1"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[1]=""
MTU[0]="9000"
# Config information for eth1:
IPADDR[1]="10.1.1.1"
NETMASK[1]="255.255.255.0"
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""
MTU[1]="9000"

Anyone giving away his “old” gigabit cards? 😉

Where is SysRQ?

First of all.

It happens.

Don’t panic.

When the Kernel sees an error that can’t be avoided with his casual means, Kernel panics.

This can be seen as an error message in console and with blinking “Caps lock” and “Scroll lock” indicators on your keyboard. Even if something happened, you are in X.org and you can’t see the console Panic message but see the blinking LED indicators – Kernel has panicked. You don’t have access to your system anymore.

Again. Don’t panic. This error is sometimes seen as often as BSOD in Windows vintage ’98.

Most of the present day editors will auto-save your work often, so you probably have a work copy of your document from 5 minutes ago. This is not a reason to panic. The only reason to be a bit wary is, the hard drive needs to be synchronized with the cache. To execute the command “sync” with panicked Kernel is actually quite possible (see below).

The system invokes Panic when there is unrecoverable error. It’s locked out, so there is no future harm, data loss or security breach. It’s not necessarily something bad. You only need to restart and have a look what actually broke.

There are few things you need to do for graceful restart.

• Get back control of your system (keyboard)
• Synchronize the cache with the disk.
• Issue a clean sigTerm and sigKill on all processes.
• Reboot, so you can have a look at logs and what the hell broke.

There are magic key strokes, that can do all of this and they are invoked by holding “Alt + SysRq” and pressing some of the buttons of the character keyboard.

• Alt + SysRq + R will try to Retake back the keyboard,
• Alt + SysRq + E will try to gracefully tErminate all processes so they flush and clean,
• Alt + SysRq + I will send signal kIll to all processes,
• Alt + SysRq + S will Sync,
• Alt + SysRq + U will Unmount and
• Alt + SysRq + B will reBoot.

If you have a look at the letters REISUB and read backwards, you will get BUSIER. So just remember BUSIER for next time the system goes BUSY with Kernel Panic 😀

There is longer way to remember it, but I never liked it. It’s “Reboot Even If System is sUper Broken”. In my opinion BUSIER is much easy to remember. Just remember to apply it backwards or you will simply just reboot with Alt + SysRq + B.

So, now we can have a look, what happened to our Kernel that led to panic. Have a look at /var/log/messages and search for the last restart logged. (less uses the slash-sign for searching. Just press “/” and write “restart”. Then with “/” and “Enter” you issue find-next, until no more are found)

bash-4.1# cd /var/log/
bash-4.1# cat messages | less
...
May 30 12:04:44 stoill -- MARK --
May 30 12:23:57 stoill kernel: [11970.623138] Bluetooth: Core ver 2.15
May 30 12:23:57 stoill kernel: [11970.623189] NET: Registered protocol family 31
May 30 12:23:57 stoill kernel: [11970.623193] Bluetooth: HCI device and connection manager initialized
May 30 12:23:57 stoill kernel: [11970.623198] Bluetooth: HCI socket layer initialized
May 30 12:31:45 stoill syslogd 1.5.0: restart.
...

Something obviously gone bad with the Bluetooth USB I inserted in the machine. Problem found, but I will not try to bore you to death with details.

Anyway. If you try to execute those Keystrokes without panicked Kernel (REISUB while holding Alr+SysRq), you will make graceful sync + reboot on your machine. If you do only the “RE” part while in X, you will close everything and make it to Login screen really fast. And if you do Alt+SysRq+S, you will sync all unsaved cache to HDD. Good to know.

If yow want to learn all possible Alt + SysRq key strokes and what they do, refer to the Kernel archives here, and happy hacking 😉