On Aug 20, 2009, at 2:22 PM, Sake Blok wrote:
(however, a recent post *did* reveal that display filtering was way
quicker on MacOS/X and Linux as it was on Windows)
Which posting was that?
I can imagine the drivers being optimized for normal usage of the
network, not capturing.
For desktop usage, that *might* mean no polling, as polling increases
latency and boosts throughput, although if you're downloading
something big, or streaming something, that might be the right tradeoff.
For server usage, that might mean polling.
The document at
http://developer.apple.com/documentation/DeviceDrivers/Conceptual/NetworkDriver/4_Writing%20the%20Driver/NetworkController.html#/
/apple_ref/doc/uid/TP40000913-CH204-TP9
says:
Receiving packets is typically done through an interrupt handler, or
possibly a timer for a device that requires polling. In either case,
reception is always handled within the protected context of the
driver’s work loop
so, presumably, it's up to the driver to decide whether to poll or use
interrupts. Unfortunately, I don't think the Ethernet driver is one
of the open-source Darwin bits, so there's no public indication of how
it handles input.
(I don't capture enough traffic to speak from experience - I mostly
either read capture files supplied to me or do small captures of
traffic to and from my own machine.)
Assuming you are working on a MacBook (Pro?), did you get a chance to
work with a SSD as well as a HDD? If so, did you experience different
performance?
At home, an MBP; it has a (rather crowded) HDD:
$ df /
Filesystem 512-blocks Used Available Capacity Mounted on
/dev/disk0s2 311909984 302013824 9384160 97% /
At work, an iMac (also with an HDD).
I've never captured to an SDD. (Well, actually, I did, once, but it
was with tcpdump on a certain ARM-based Apple handheld device; I never
ended up dragging the capture back to my machine to see why I couldn't
connect to the restaurant's free Wi-Fi network.)
