Michael DeMan wrote:
Hi,
Just my 2-cents, but we've found polling to be extremely valuable on
low-end hardware as described here.
We use it only on fxp drivers, but it moved throughput on 133Mhz
hardware from something around 8Mbps to 20Mbps on regular layer-3 packet
forwarding and also bum
Hi,
Just my 2-cents, but we've found polling to be extremely valuable on
low-end hardware as described here.
We use it only on fxp drivers, but it moved throughput on 133Mhz
hardware from something around 8Mbps to 20Mbps on regular layer-3
packet forwarding and also bumped VPN performance
Sam Leffler wrote:
> I see no statistics; are you sure you are not being pounded by phy
> errors.
I've put together a small patch to the ath driver which exposes some
interupt statistic sysctls, and a small shell script to read these and
list them once per second. Both are attached.
Here are the
Nate Nielsen wrote:
Sam Leffler wrote:
Nate Nielsen wrote:
Adding polling to this driver does increase performance on embedded
systems. With my current patch (on a 233Mhz system), the throughput (in
this case a simple TCP stream) goes up by ~6Mbits, from 18Mbits to
24Mbits.
I routinely get
Sam Leffler wrote:
> Nate Nielsen wrote:
>> Adding polling to this driver does increase performance on embedded
>> systems. With my current patch (on a 233Mhz system), the throughput (in
>> this case a simple TCP stream) goes up by ~6Mbits, from 18Mbits to
>> 24Mbits.
>
> I routinely get >20 Mb/s
Nate Nielsen wrote:
Sam Leffler wrote:
You might try explaining why you think polling helps your performance.
Unless you've significantly restructured the interrupt handling in the
driver most work is deferred to a non-interrupt context.
Yes, I saw that. However the interrupts themselves w
Sam Leffler wrote:
> You might try explaining why you think polling helps your performance.
> Unless you've significantly restructured the interrupt handling in the
> driver most work is deferred to a non-interrupt context.
Yes, I saw that. However the interrupts themselves when they are fired
a
Nate Nielsen wrote:
I've been working on polling for the FreeBSD ath wireless driver.
On slow CPU's polling helps prevent (by supressing certain interrupts)
livelock and increases throughput. This is true of Atheros cards on
Soekris and other embedded hardware.
Just thought I'd post something h
I've been working on polling for the FreeBSD ath wireless driver.
On slow CPU's polling helps prevent (by supressing certain interrupts)
livelock and increases throughput. This is true of Atheros cards on
Soekris and other embedded hardware.
Just thought I'd post something here in case anyone is
