Bill Campbell wrote:
On Tue, Aug 02, 2005, Victor Semionov wrote:
[ ... ]
I was uploading some large file to my neighbor's windows box. With polling disabled, the transfer rate was 8 MB/s and CPU usage was 90%. I turned on polling with sysctl and CPU usage decreased to 50%, which I expected, but also the transfer rate dropped to 4.5 MB/s, about half. The numbers are approximate. The interface is a RealTek (rl driver). No background jobs were running. kern.polling.* all defaults.

What is kern.hz set to?  Does increasing it improve throughput?

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.

I certainly don't claim to be an expert on this subject so take this with a
grain of salt.

Interrupts were originally created to eliminate the need for polling
allowing processes to sleep until an interrupt occurs rather than having
the process in a loop testing to see if any input is ready or the device is
available for further work.

Blocking was created to eliminate the need for polling/sitting in a loop testing a condition. Interrupts were created to take the CPU away from normal processing in order to attend a high-priority, time-critical condition or signal which can't wait.

A good serial chip/UART, or a NIC receiving packets, shouldn't fire an interrupt just because a character/packet came in, they should fire an interrupt when their SILO/buffer is getting full or has some data which hasn't been serviced in a while. ("Interrupt coalescing")

--
-Chuck

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to