@Guy, Basically, I was adding my own header (instead of radiotap) in kernel and processing it in userland with my own code. Basically I wrote my own pcap for that. Since, I did not get the performance, Now I have added extra fields in radiotap. But I still see high CPU usage. Its interesting that you point out there are more errors during mmap calls. Is this anything to do with allignment of frames ? [I am having 37 byte radiotap header, which is not very good number I suppose] Shall I see how the frame is added so that these errors don't occur.
@Dave : I am running this code on a Netgear router running OpenWrt, so I am not sure if there is profiler that can help me out. You have raised a valid point, but is there any better tool to use/write for this ? I want to know if this processor usage will effect the router performance ? Or is it fine if the processor takes 40% or more for proper functioning of router ? its clocked at 600 Mhz, so I suppose its a beefy hardware ... -Abhinav On Mon, Nov 12, 2012 at 9:01 AM, David Laight <david.lai...@aculab.com>wrote: > > hi, > > I just checked the two mechanism : > > (1) Using mmap to fetch packets from kernel to userspace > > (2) Using recvfrom() call to fetch packets > > > > I see top reports > > (1) 34% memory 20% cpu usage > > (2) 21% memory 7% cpu usage ! > > It is worth remembering that the cpu usage reported by top isn't > worth the paper it is printed on for many workloads. > IIRC it is based on the cpu state when the timer interrupt fires. > processes that are scheduled very often, and run for short periods > tend to get mis-counted. > > Since the Linux scheduler doesn't get a high-res timestamp everytime > it does a process switch, about the only way to measure idle time > is to put a very low priority process into a counting loop. > Unfortunately the scheduler might make it difficult to make the > processes priority low enough. > > David > > > > > _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
