Fedora 13 networking performs extremely well

Robert Arkiletian robark at gmail.com
Wed Aug 18 21:11:43 UTC 2010

On Wed, Aug 4, 2010 at 8:33 AM, Uwe Zimmermann <uwe at gambitcomm.com> wrote:
> Hello,
> our product "MIMIC Simulator" has been running on Fedora for a long time
> (eg. see
> http://www.gambitcomm.com/site/support/support_platforms.shtml
> ).  But, we have seen a steady decline in performance over successive
> versions of Fedora (eg. see
> http://gambitcomm.blogspot.com/2010/06/mimic-1030-performance-test-report-high.html
> Our application is somewhat unique in that it can create many (10s of
> thousands) IP aliases, opens sockets to multiple ports on each.
> Only with Fedora 13 (kernel version have we
> seen a surprising performance improvement, where running 20,000 simulated
> agents is the same as running 10, in terms of networking performance. At
> first we could not believe it, but subsequent tests have confirmed that
> we indeed are seeing the improved performance. The specific improvement
> seems to be that the kernel seems to be efficiently demultiplexing among
> all open sockets to deliver received messages from the network card.
> Can some expert point me at a specific fix (spec, kernel module, source
> code revision) that could account for this? It would be in the networking
> code, possibly the socket demultiplexer. I have looked for this for a
> while and just cannot find it. This change would be after Fedora 12.
> Any hint would be appreciated.
> Thank you in advance.
> Uwe Zimmermann
> Gambit Communications

F13 uses 2.6.33 but I know 2.6.35 has an improvement that could also
benefit you. Maybe Fedora devs included it in F13 but I doubt it.

>From http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-35-1047707.html?artikelseite=1;page=2

"Google developer Tom Herbert submitted two major improvements to the
network subsystem of Linux 2.6.35: Receive Packet Steering (RPS) and
Receive Flow Steering (RFS). RPS distributes the processing steps for
handling received network packets across the available processor cores
so that these can work in parallel from the protocol layer onwards.
RFS, together with other functions, is said to offer a software
emulation of the multi-queue functionality found in network cards

RFS, the second technology, is based on the first and tries to assign
the processing of layer 3 and 4 of the network protocol directly to
the processor core which runs the userspace application that will
eventually accept and process the network data. The kernel hacker
gives a rough overview of how this is done in his commit comment in
the source code management system. This comment also contains various
test results which show that the throughput is increased a little
further with RFS; the benchmark results also show considerably shorter
latencies. Further details about these technologies can be found in an
article about RPS and RFS on LWN.net."

More technical info at LWN.net

Robert Arkiletian
Eric Hamber Secondary, Vancouver, Canada

More information about the users mailing list