[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ossig] FreeBSD's TCP/IP stack subpar?
On 07/27/05 04:59 Ditesh said the following:
> From
> http://lists.freebsd.org/pipermail/freebsd-announce/2005-July/001012.html:
>
> The TCP code now needs a general overhaul, streamlining and cleanup to
> make it easily comprehensible, maintainable and extensible again. In
> addition there are many little optimizations that can be done during
> such an operation, propelling FreeBSD back at the top of the best
> performing TCP/IP stacks again, a position it has held for the longest
> time in the 90's.
>
> So the obvious question is - who is the top of the best performing TCP/IP stacks now? Linux? OpenBSD? NetBSD? *gasp* Windows?
while this is a good attempt at baiting me, i kept the mandatory 24 hour
silence before responding, lest it evolve again into something else
altogether.
the problem with taking things individually and instead of looking at it
within a larger context over a longer period is that one starts getting to
a tendency of misrepresentation. the statement above is implied for freebsd
5.x, which did undergo a degradation of network performance due to the
removal of the GIANT kernel lock and the move towards more fine-grained
locks. as a result of this, lock overhead for packet processing increased
by a factor of 2-3, depending on the situation and firewall/nat usage.
however, this is being fixed for freebsd 6.x as the 5.x branch is a
shortlived transition between 4.x and 6.x.
4.x however still maintains the best tcp/ip and networking stack on the
planet, by many orders of magnitude over anything else out there. from the
words of robert watson,
----- BEGIN -----
As you are probably aware, one of the largest single architectural changes
between the FreeBSD 4.x and 5.x branches was the adoption of the SMPng
architecture. This architecture introduces finer-grained locking and
ithreads, and permits much more parallelism in the kernel as compared to
FreeBSD 4.x, due to the removal of the Giant lock. However, this
architectural change comes at a price: adding more locks adds overhead.
For some work loads, SMPng in 5.x is a clear win -- the increased
parallelism and preemptability of the kernel (even on UP) leads to a
substantial improvement in performance. However, with other workloads,
the cost of additional atomic operations for locks is a significant
detriment.
The network stack is probably the most sensitive part of the kernel when
it comes to observing the overhead of individual instructions -- functions
in the network stack are often run 2 or more times per packet received and
processed, especially in firewall scenarios. Events also happen on the
order of millions of times per second, and in most gigabit network
environments, the system is CPU-bound. Likewise, the move to ithreads has
added overhead in interrupt handling that can be quite sizable in terms of
measurable latency.
Part of the challenge here is that we've set ourselves a tremendously high
bar: the 4.x network stack is probably the fastest general purpose network
stack in the world, able to route packets, etc, an order of magnitude
faster than many competing systems. Our intent is to recover almost all
UP performance for the network stack, and to substantially out-perform 4.x
on SMP. We're still working on that, though :-) .
----- END -----
--
Regards, /\_/\ "All dogs go to heaven."
dinesh@alphaque.com (0 0) http://www.alphaque.com/
+==========================----oOO--(_)--OOo----==========================+
| for a in past present future; do |
| for b in clients employers associates relatives neighbours pets; do |
| echo "The opinions here in no way reflect the opinions of my $a $b." |
| done; done |
+=========================================================================+
---------------------------------------------------------
To unsubscribe: send mail to ossig-request@mncc.com.my
with "unsubscribe ossig" in the body of the message