The new Linux kernel includes support for and improvements in many areas of networking: from tunneling and better file security to encryption and privacy protection. This article covers how these improvements affect users even as they make Linux more secure and more enterprise-ready.
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
All these improvements are, of course, welcome. But I wonder how much time it would take for these features to be incorporated into other products (eg:SCTP, IPV6) so that users can actually reap the benefits of all this. The way I see it, it would be no good if the infrastructure is not in place for supporting, say IPV6 among others.
if i am correct, the ipsec subsystem in 2.6 has been mograted to that from the KAME project (as used in the BSDs for example). this is good as makes for better interoperability. The freeswan implementation was a horrible patch.
if i also recall correctly, the standard user-land keying daemon was racoon – which used semantics that were’ that flexible the last time i looked. we much preferred the isakmpd from OpenBSD (which we managed to get working on freebsd a couple of years ago).
i wonder if anyone is sucecssfully using this isakmpd over the new 2.6 ipsec?
I dont mind new features, but lets not forget the price: while claiming speed improvements in some esoteric areas, the kernel is nonetheless getting more and more bloated and slower. You dont have to take my word for it: write the smallest C program there is
int main(int argc, char* argv[])
{
return 1;
}
and write a wrapper around it that will
a) save current system time
b) create the process given above some 1000 times or so
c) save current system time.
That will give you the average time to create/destroy a process in your system. My findings:
Win98 is about 10 times slower than a NetBSD 1.6.1 kernel
only 6 times slower than a 2.2.20 Linux kernel
only about 2.5 times slower than the new 2.6.2 kernel.
> I dont mind new features, but lets not forget the price: while claiming speed improvements in some esoteric areas, the kernel is nonetheless getting more and more bloated and slower.
Your benchmark is artificial and not relevant for normal usage. A better benchmarks is for example the SPEC benchmark http://www.spec.org/ or TPC http://www.tpc.org
And Linux 2.6 scales up better than Linux 2.4. And you can see this on: http://bulk.fefe.de/scalability/
That’s a very misleading benchmark.
1) Adding features to the networking subsystem should have no effect on the performance of the rest of the kernel.
2) Process/thread creation (the same thing on Linux) is faster under 2.6 than under 2.4, as evidenced by the scheduler benchmarks published earlier.
3) You’re not even testing the same thing on each platform! Under Windows 9x, you’re testing the equivilent of exec(), while under *NIX, you’re testing the equivilent of fork() + exec(). Between the UNIXes, you’ve got different libcs, etc. And what kind of wrapper are we talking about, anyway? If you look at the lmbench numbers (a suite of benchmarks designed to test performance of various system calls) you’ll see that Linux is quite a bit faster than NetBSD.
Of course, this benchmark is far from perfect. But actually, as a programmer I dont care that I am kinda comparing apples to oranges here ( exec vs. fork+exec ). I couldn’t care less what method *an* OS uses to create/destroy threads/processes. What matters to me, is that when I launch a process/thread, it does get created fast. And this benchmark clearly shows that in this area, the kernel is more than twice slower than what it used to be.
Yes, 2.6 is using the KAME IPSec. you can get the tools for using ipsec + 2.6 at http://ipsec-tools.sourceforge.net. I’m happily using 2.6 + racoon/ipsec + shorewall + hostap on my access point.
2.6 creation is slower because it uses a reverse map virtual memory. This was disscused a lot in the kernel mailing lists. But for example thread creation is more than 100 times faster.
> What matters to me, is that when I launch a process/thread, > it does get created fast. And this benchmark clearly shows > that in this area, the kernel is more than twice slower
> than what it used to be.
As a real programmer you shouldn’t be bothered if Linux 2.6 starts processes 0.0001 seconds slower than Linux 2.4, or Win98 for that matter. There’s most likely a good reason for that _really_ little extra delay. I really don’t see were programmers benefit from fast process creation times, on the other hand, threads I can follow, and Linux 2.6 (IIRC) has excellent performance in this area, way better than Linux 2.4 or Win98.