* about the tuning of eepro100
@ 2002-08-10 9:38 zhengchuanbo
2002-08-10 9:51 ` Paweł Krawczyk
0 siblings, 1 reply; 6+ messages in thread
From: zhengchuanbo @ 2002-08-10 9:38 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
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
zhengcb@netpower.com.cn
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: about the tuning of eepro100
2002-08-10 9:38 about the tuning of eepro100 zhengchuanbo
@ 2002-08-10 9:51 ` Paweł Krawczyk
2002-08-10 10:09 ` Adrian Bunk
2002-08-10 17:55 ` Jamie Lokier
0 siblings, 2 replies; 6+ messages in thread
From: Paweł Krawczyk @ 2002-08-10 9:51 UTC (permalink / raw)
To: zhengchuanbo; +Cc: linux-kernel @ vger. kernel. org
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: about the tuning of eepro100
2002-08-10 9:51 ` Paweł Krawczyk
@ 2002-08-10 10:09 ` Adrian Bunk
2002-08-10 17:55 ` Jamie Lokier
1 sibling, 0 replies; 6+ messages in thread
From: Adrian Bunk @ 2002-08-10 10:09 UTC (permalink / raw)
To: Paweł Krawczyk; +Cc: zhengchuanbo, linux-kernel @ vger. kernel. org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: about the tuning of eepro100
2002-08-10 9:51 ` Paweł Krawczyk
2002-08-10 10:09 ` Adrian Bunk
@ 2002-08-10 17:55 ` Jamie Lokier
2002-08-10 18:02 ` Paweł Krawczyk
1 sibling, 1 reply; 6+ messages in thread
From: Jamie Lokier @ 2002-08-10 17:55 UTC (permalink / raw)
To: Pawe? Krawczyk; +Cc: zhengchuanbo, linux-kernel @ vger. kernel. org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: about the tuning of eepro100
2002-08-10 17:55 ` Jamie Lokier
@ 2002-08-10 18:02 ` Paweł Krawczyk
2002-08-10 18:18 ` Jeff Garzik
0 siblings, 1 reply; 6+ messages in thread
From: Paweł Krawczyk @ 2002-08-10 18:02 UTC (permalink / raw)
To: Jamie Lokier; +Cc: zhengchuanbo, linux-kernel @ vger. kernel. org
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: about the tuning of eepro100
2002-08-10 18:02 ` Paweł Krawczyk
@ 2002-08-10 18:18 ` Jeff Garzik
0 siblings, 0 replies; 6+ messages in thread
From: Jeff Garzik @ 2002-08-10 18:18 UTC (permalink / raw)
To: Paweł Krawczyk
Cc: Jamie Lokier, zhengchuanbo, linux-kernel @ vger. kernel. org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-08-10 18:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-10 9:38 about the tuning of eepro100 zhengchuanbo
2002-08-10 9:51 ` Paweł Krawczyk
2002-08-10 10:09 ` Adrian Bunk
2002-08-10 17:55 ` Jamie Lokier
2002-08-10 18:02 ` Paweł Krawczyk
2002-08-10 18:18 ` Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox