Re: single packet capture time w/pcap vs. recvfrom()

[Brandon Stafford <brandon () mindtribe com>]

Ryan Mooney wrote:

> Brandon,
>
> For curiousity sake (I have a simular app and am seriously interested
> in performance).
>
> - What platform (OS/processor) are you on,

OpenBSD 3.4 on a HP Kayak XA, Pentium II, 233 MHz (ugh!)

> - How did you measure the time to call recvfrom(), or perhaps
>   even a more relevant question is how do you use recvfrom()
>   (whats the surrounding code like, do you select() first, etc..)?

I am measuring execution time using gettimeofday(). I am not 
using select(), though I did write a version that used 
select() previously-- it was about the same speed, but I 
didn't measure it too precisely.

I'll post a code snippet later tonight.

> I ask because I'm seeing substantially better numbers for recvfrom (0.021ms),
> although granted it is for a fairly short message but that doesn't explain
> the 1000X performance delta.

0.021 ms! This is what I need! A glimmer of hope!

> If your on a slower platform (embedded perhaps given your company?) the 
> numbers will be obviously be worse, recvfrom seems to scale almost directly
> proportional to clock speed.

The devices sending the packets are slow embedded devices, 
but the receiver is relatively fast. I also tried the same 
code on a Via Epia running at 600 MHz with no speed 
improvement, which is what makes me suspect that there is a 
timeout involved, rather than just a lot of instructions to 
execute.

> rdtsc is defined as an assembly snippet that reads the processor clock register on
> I386 achitectures.  Other architectures are obviously different.
> The overhead for calling {rdtsc(); index = !index; rdtsc(); } is 84-96 clock
> cycles so I just ignored it for this since its way less than the noise.
>
> extern __inline__ unsigned long long int rdtsc()
> {
>     unsigned long long int x;
>     __asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
>     return x;
> }

Interesting.

I'll post some code snippets with timing results later.
I'll also try the same stuff on a 2 GHz Linux machine 
running the 2.6.3 kernel to see if OpenBSD is a dog.

Thanks for the comments,
Brandon


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