|
Hi,
OK, it might be because of the configuration they used : 4 senders on
one side, 4 receivers on the other side, and the router in the middle.
Maybe it was simpler than the traffic generated by the traffic generator
for the FF project.
I don't know which one is simpler but a HW packet generator has
virtually nothing else to do but generate packets. So in the end
calculation you don't have to take into account the invariants of the
senders kernel and whatever there is.
I don't know for the chip in itself, but the driver seems to be very
complete on Linux, compare to some 3Com cards for instance.
I never had problems with 3com NICs, their fast enough for their price
and I think the 3c59x driver under Linux is rather complete too.
What seems to make the real difference is polling packets from the
device (in fact from DMA) rather than beeing interrupted on each arrival
of a packet on the device. In the bibliography of the article I pointed
you, there's a reference to a paper by Mogul an Ramakrishnan about
eliminating receive livelock in an interrupt-driven kernel. That should
be it.
Indeed. I hope to understand their setup, the result and the drawbacks
of their implementation soon so I can forward it to the appropriate
people in Linux kernel development.
My apologies to anybody considering this a little bit too off-topic for
the list ; I'm stopping with this subject. :)
It is not really off-topic, it belongs to the two LVS sections:
o performance analysis/improvment
o NIC driver problems
Trust me, there had been lots of discussions on those subjects with far
more off-topic content on this list. OTHO everyone's mileage varies on
what he considers on/off-topic so I'll follow your call and stop this
thread on my side too.
Thanks again for the valuable input and best regards,
Roberto Nibali, ratz
| 