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.