I've been running performance tests against pcap_next_ex() and
pcap_dump(). I've placed micro-second timers around both functions and
sent millions of packets to my test programs.
Both functions performed admirably over a short period of time (up to 8
Gbits/sec) but, as time progressed, both
On Aug 22, 2015, at 12:48 PM, barcaroller wrote:
> I've been running performance tests against pcap_next_ex() and pcap_dump().
> I've placed micro-second timers around both functions
So those are presumably real-time timers rather than CPU timers.
> and sent millions of packets to my test pr
On 2015-08-22 23:21:55 +, Guy Harris said:
I've been running performance tests against pcap_next_ex() and
pcap_dump(). I've placed micro-second timers around both functions
So those are presumably real-time timers rather than CPU timers.
Using the Boost timer functions. I could be wron
On Aug 22, 2015, at 6:03 PM, barcaroller wrote:
> Using the Boost timer functions. I could be wrong but I think they are based
> on gettimeofday().
So probably real-time.
That means that, *if* there are other processes on the machine, some of the
time *could* be due to other processes havin
On 2015-08-23 01:42:30 +, Guy Harris said:
So probably real-time.
That means that, *if* there are other processes on the machine, some of
the time *could* be due to other processes having all the cores, but,
with 8 cores, that's unlikely unless your test programs are lighting up
all 8 co
On Aug 22, 2015, at 8:06 PM, barcaroller wrote:
> It has puzzled me too. Keep in mind that I am making millions of these pcap
> calls; only one of them could be taking 2 seconds.
Then the average might be more interesting than the maximum.
> I actually read the packets from a pcap file (not
On 2015-08-23 03:13:50 +, Guy Harris said:
It has puzzled me too. Keep in mind that I am making millions of these
pcap calls; only one of them could be taking 2 seconds.
Then the average might be more interesting than the maximum.
Yes, but the average was only about 20 times higher, whi
