Danial Thom wrote:
--- Victor Semionov <[EMAIL PROTECTED]> wrote:
Why is that? I thought polling should
decrease CPU usage by avoiding too
many context switches when a hw irq is
generated frequently, but it
shouldn't make the transfer slower if
there are no other jobs running.
You have to poll often enough to keep the
pipe full, otherwise your max
throughput can be limited. Also, rl hardware
isn't the greatest and
probably requires a lot more CPU than a
device with working buffer/DMA
design.
HZ is 1000, which I guess should be more than
enough with
kern.polling.burst_max=150.
Indeed, it was hardware's fault - my other NIC
is a fxp and I got much better
results with it - less CPU, while throughput
stayed the same as without
polling.
Great. So you've added 900 totally unnecessary
context switches, plus all of the rubbish that
gets done every clock tick, even when there is no
traffic. Brilliant.
Modern hardware doesn't interrupt every packet;
in fact with intel em controllers its easily
tunable, so you get the advantages of polling
without the disadvantages of having a system
designed by an idiot. Polling will cause you to
lose tons of packets under bursts of heavy load.
Although it is downright comical that you're
concerned about cpu cycles but you were using the
slowest, least efficient ethernet controller ever
conceived.
The fxp driver has a built-in hold off of 6000
ints/sec (which is 1/6000th of a second for you
mathletes). There is no reason to use polling
with intel hardware; in fact its a big negative.
Danial
Heh. We just discussed polling vs interrupts in an embedded systems
class this past quarter. Interrupts are better for more intermittent use
and polling is better for more frequent use, as polling is actually a
deadloop of course-for checking a flag most of the time-with potentially
a lot of wasted clock cycles before a context switch is made and the
task that was being polled for is run. Also, considering that actual
computer hardware isn't going to be running 100% of the time (except for
the CPU running idle tasks and stuff), interrupts are by far the better
way to go in general. But yeah... too many interrupts are bad as well...
Anyhow, that was sidetracking a bit :).
-Garrett
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
