LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: using LVS with 2 servers

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: using LVS with 2 servers
From: Jacques Thomas <jacktom@xxxxxxx>
Date: Fri, 18 Jan 2002 13:59:51 +0100
Good afternoon Roberto,

> Awesome!!! I started reading the stuff. I didn't know about that. Thank
> you for the link. They take a completely different approach but they
> seem to have tried it over diffserv too. What is really interesting, is
> that they manage to exchange messages via BSD pf sockets while Hadi uses
> the netlink transportation mechanism.

I'm glad to see you like it !
 
> > This is where I took my figures from. I think, before reading the
> > interesting links you've just mentionned, that the main difference lies
> > in the packet size used for the benchmarks. At the Click project, they
> > focused on routing capacity (using 64-byte packets) and not bandwidth.
> > It might also be that their test configuration was simpler.
> 
> Well the FF project I mentioned used 64-byte packets too with a HW
> packet generator. Otherwise you would never in get these high rates.

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.
 
> > Still with these small packets, they managed to route up to 435Kpps on
> > there test configuration with a 700Mhz PIII CPU. Like the 'fast
> > forwarding bird', they had to modify the hardware driver : they changed
> > it from an interrupt-driven mode to a polling mode. The network card
> > used was a DEC 21140 NIC.
> 
> Exactly the card they were using for their test. This must a very good
> chip. I'm going to delve further into it.

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.

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.


My apologies to anybody considering this a little bit too off-topic for
the list ; I'm stopping with this subject. :)


Best Regards,

        Jacques THOMAS.


<Prev in Thread] Current Thread [Next in Thread>