Re: where does PCAP timestamp before or after the MAC scheduler?

[Bruce M Simpson <bms () spc org>]

On Thu, Mar 30, 2006 at 12:17:47PM +0200, Debrei Gabor wrote:
> We want to compare 802.11 MAC schedulers performance, to decide 
> how much the Media Access takes.
>
> We want to know where/when does PCAP put the timestamp (from not 
> so accurate kernel time) on to the packets. I already know,  it does 
> when the kernel "sees" the packet. The question is: Is it after or before 
> the MAC scheduler? I mean, does it in TR or RX buffers or at higher 
> protocol layers take place?
> (If it takes place in the buffers the use of HW monitoring devices the 
> only way of measuring? )

Depends on the operating system, the driver, and the hardware!

In the case of FreeBSD, the timestamping won't happen until BPF sees the
packet, that is, the driver has called bpf_mtap(), and there is at least
one bpf consumer.

In the case of net80211, bpf_mtap2() is called to send radiotap headers
separately.

So you will have to inspect the driver you're using. Usually bpf_mtap()
happens during receive queue processing, before packets are dispatched
further up in the protocol stack, so whether this is interrupt or polling
mode driven will depend on the mode the card's running in.

You could in theory watch memory accesses on FreeBSD over a FireWire bus
in near real time, though I think this establishes a PCI window on the
*host* system which is only updated when the host initiates a read cycle
to the target and thus only propagates the read cycle via FireWire's I/O
bus cycles when one is initiated -- I'm not sure if writes propagate from
target system to host's PCI target, it's been 2 years since I worked with it.
:-(

In some cases the use of the timestamp can be changed to sacrifice accuracy
in favour of performance, via a sysctl (did we apply that patch... please
check the code!) generally in practice this is only an issue with
gigabit link speeds.

BMS
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.