The new Linux 2.6 kernel offers many improvements over the 2.4 version. One area of technical advancement is in the kernel networking options. Although there are enhancements in most of the files associated with the networking options, this article focuses on major feature improvements and additions that affect entire sections rather than on specific files.
Networking Improvements in the 2.6 Kernel
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I recently migrated to the 2.6.4 kernel(well now 2.6.5 today) and was using IPV6. I was having horrible latency problems. Now, I don’t know if it was coincidence or what, but when I rebuilt the kernel for 2.6.5 and left out IPV6 the problem seemed to just go away. I’m also using a windows wrapper for my wireless card, so maybe that has something to do with(probably not) but the moment I booted into 2.6.5 without IPV6 the problem just went away.
Not everything is rosy for me in 2.6.5 land though. I’ve experienced 2 hard lockups. Seemed to have something to do with network activity because epiphany was loading up a page both times. Maybe a windows wrapper driver problem or possibly an ATI driver problem. I did switch to SMP on 2.6.5 since I have a p4 HT(I thought maybe the kernel might be able to use HT). I’ve heard that maybe these video card vendor drivers might have problems with SMP or something. who knows.
does the 2.6 kernel improve the use of networking by threads?
that is, if i attempt to have lots of threads (say 100+) each sending requests and receiving responces over TCP/UDP then the request rate isn’t improved due to thread scheduling.
does the 2.6 kernel provide any magic (such as kernel units of work which are performed away from the thread, asynchronously perhaps) do improve the networking transacton rate?
i’m not knowledgable in this area but am interested in the answer.
You might want to take a look at NPTL (The Native POSIX Thread Library) that comes in 2.6.x. I don’t know if that will help you, but take a look.
Yes, the 2.6 has a _much_ improved thread handling, and a better scheduler. Improvemnt in threaded applications are
significant. Nothing spesifically in the networking, but it has almost always been asynchronous.
2.6 also introduces epoll , which can sigificantly improve single threaded applications that relied on select/poll for handling multiple connections. If you really want speed, this is the way to go, not threads.
Lumbergh,
If you’re using ndiswrapper as the windows wrapper for your wireless network card, I’ve exactly the same issue – hard lockups. Except I’m still using the 2.4.23 kernel.
Once I removed ndiswrapper.o from loading, my problems ceased. It’s possible the extra complexity of IPv6 is giving it grief, but I would suspect ndiswrapper first before the IPv6 kernel modules.
My two cents worth…
One thing to try is to make your ATI driver use your kernel built AGPGART drivers rather than using the one’s provided in the driver. I’m running Gentoo with kernel 2.6.5 using MM sources. I was having a few problems with stability of the kernel, as soon as I switched to external AGPGART modules in the fglrxconfig I haven’t had a problem. Smooth sailing.
Gnome 2.6 + Kernel 2.6 = One hella nice desktop.
As someone said and I’d like to stress, the way to handle requests is select + thread pool, not one thread per request. It just isn’t done the latter way.
Yep, I am using NDIS wrapper for my wireless. I didn’t have that issue with 2.6.4, but who knows. I’m starting to think it’s a suspend-to-disk issue and interaction with some driver. I noticed in the help in kernel config that it said that it might cause problems with some drivers and is experimental.
Dmesg keeps on giving me this repeating over
Debug: sleeping function called from invalid context at include/asm/semaphore.h:119
in_atomic():1, irqs_disabled():0
thanks for the comments.
re: bleyz, i agree about the thread pool, but that’s for a server. what about a very rapid client which throws out many requests… as many as it can…. (a benchmarking client, stress loading tool, for example)