i have been tuning the performance of eepro100 these days. we tested linux router with smartbits. our router has two PIII800 CPU,512M ram.
kernel version is 2.4.19-pre1. the driver is e100.
in the test,we found that the throughput of 64bytes frames is 61%. that's about 90kpps. then we tuned almost all the parameters the e100 driver applied, but could not get higher results.
so i think the limit is at the eepro100 card. is there any way to improve the throughput? or someone got a higher throughput then that?
the eepro100 chip is 82559.
please cc. thanks.
regards,
chuanbo zheng
[email protected]
On Sat, Aug 10, 2002 at 05:38:39PM +0800, zhengchuanbo wrote:
> so i think the limit is at the eepro100 card. is there any way to improve the throughput? or someone got a higher throughput then that?
> the eepro100 chip is 82559.
Use e100 driver from Intel [1] with the following parameters:
insmod e100.o BundleSmallFr=1 IntDelay=0x600 ucode=1
Intel's driver supports all the interrupt saving features (interrupt
delay and small packet bundling) present in EEPro/100 cards. The driver
is now GPL, so it should get back to the mainstream kernel.
[1] http://downloadfinder.intel.com/scripts-df/Detail_Desc.asp?ProductID=417&DwnldID=2896
--
Pawe? Krawczyk, Krak?w, Poland http://echelon.pl/kravietz/
crypto: http://ipsec.pl/
horses: http://kabardians.com/
On Sat, 10 Aug 2002, [iso-8859-2] Pawe? Krawczyk wrote:
> On Sat, Aug 10, 2002 at 05:38:39PM +0800, zhengchuanbo wrote:
>
> > so i think the limit is at the eepro100 card. is there any way to improve the throughput? or someone got a higher throughput then that?
> > the eepro100 chip is 82559.
>
> Use e100 driver from Intel [1] with the following parameters:
>
> insmod e100.o BundleSmallFr=1 IntDelay=0x600 ucode=1
>
> Intel's driver supports all the interrupt saving features (interrupt
> delay and small packet bundling) present in EEPro/100 cards. The driver
> is now GPL, so it should get back to the mainstream kernel.
>...
Intel's driver is already in 2.4.20-pre1.
cu
Adrian
--
You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox
Pawe? Krawczyk wrote:
> > so i think the limit is at the eepro100 card. is there any way to
> > improve the throughput? or someone got a higher throughput then
> > that? the eepro100 chip is 82559.
>
> Use e100 driver from Intel [1] with the following parameters:
>
> insmod e100.o BundleSmallFr=1 IntDelay=0x600 ucode=1
>
> Intel's driver supports all the interrupt saving features (interrupt
> delay and small packet bundling) present in EEPro/100 cards. The driver
> is now GPL, so it should get back to the mainstream kernel.
I don't think you will get better than 90% performance, but if you do
please let me know! I have written another e100 driver, in an attempt
to transmit and receive small packets at the maximum possible rate.
In tests, it would not even transmit at 100% small packets on our 82558.
(I didn't do that test on our 82559).
Ah well..
Curiously, I found that turning on the interrupt saving microcode slows
the cards down. It lessens the load on the mainboard CPU, but I am not
using interrupts, I'm polling the memory descriptors 100% of the time,
so the interrupt saving microcode shouldn't affect the mainboard CPU.
It does lower the throughput though.
-- Jamie
On Sat, Aug 10, 2002 at 06:55:58PM +0100, Jamie Lokier wrote:
> I don't think you will get better than 90% performance, but if you do
> please let me know! I have written another e100 driver, in an attempt
> to transmit and receive small packets at the maximum possible rate.
> In tests, it would not even transmit at 100% small packets on our 82558.
> (I didn't do that test on our 82559).
Maybe we were looking for separate things - I had a firewall box with
100base-TX interfaces and when flooding it at full rate with small
(40 bytes, i.e. empty IP headers) packets the system was unusable
because of the interrupt rate. After I turned the bundling on, there
was no signs of overload. Of course, I tested throughput of the
card as well but on the IP level there was no difference I could
worry about. But as I said, this was a firewall box and I was looking
for a way to stop possible DOS, not for tiny packet delivery time
slowdown, which may be important in other applications.
--
Pawe? Krawczyk, Krak?w, Poland http://echelon.pl/kravietz/
crypto: http://ipsec.pl/
horses: http://kabardians.com/
Pawe? Krawczyk wrote:
> On Sat, Aug 10, 2002 at 06:55:58PM +0100, Jamie Lokier wrote:
>
>
>>I don't think you will get better than 90% performance, but if you do
>>please let me know! I have written another e100 driver, in an attempt
>>to transmit and receive small packets at the maximum possible rate.
>>In tests, it would not even transmit at 100% small packets on our 82558.
>>(I didn't do that test on our 82559).
>
>
> Maybe we were looking for separate things - I had a firewall box with
> 100base-TX interfaces and when flooding it at full rate with small
> (40 bytes, i.e. empty IP headers) packets the system was unusable
> because of the interrupt rate. After I turned the bundling on, there
> was no signs of overload. Of course, I tested throughput of the
> card as well but on the IP level there was no difference I could
> worry about. But as I said, this was a firewall box and I was looking
> for a way to stop possible DOS, not for tiny packet delivery time
> slowdown, which may be important in other applications.
Sounds like you need the NAPI version of eepro100 or e100... NAPI is
designed to eliminate the overhead that you describe.
Jeff