[Bro] BroPing Connection Failure

[Fabian Hugelshofer]

Hi all,

Robin Sommer wrote:
> I see. That's actually pretty old and I don't remember what
> specifically the problem was; it might be fixed with newer versions
> of Phil's libpcap, don't know. Do you see the high CPU when using a
> standard pcap?
[...]
> P.S.: And yes, please try Seth's fix to see that already helps. 

I did some more experiments regarding this performance issue. Without
debug mode enabled, the CPU usage is not as high as I described
earlier. I am using our own policy scripts that include listen-clear.

 From a shell script, I ran Bro with different binaries for 10 minutes 
and then read the CPU time it consumed with top. There wasn't a lot of 
traffic in the network.

Bro 1.4 noloop 13.90s (parent 13.76s), child 0.14s)
Bro 1.4 default 51.06s (parent 26.56s, child 24.50s)
Bro 1.4 Patch 115.41s (parent 115.28s, child 0.13s)

The best result over all is with "--disable-select-loop". With the 
default options, the child process uses quite a lot of CPU time. Seth's 
patch fixes that for the child, but the CPU usage of the parent increases.

Bro 1.4 PCAP+default 39.21s (parent 21.05s, child 18.16s)
Bro 1.4 PCAP+Patch 82.70s (parent 81.96s, child 0.74s)

As I mentioned, I am using Phil Wood's libpcap (the current one). With 
the default version of libpcap, the performance is a bit better than 
with Phil Wood's. Still it's not great and Seth's patch again increased 
the CPU usage of the parent process.

Bro 1.5 84.66s (parent 84.41s, child 0.25s)

For the current version from trunk, it is a bit better than with 
1.4+patch. While being mainly idle, using blocking sockets is still the 
only acceptable solution for me. Bro can't use more than 10% CPU time 
for basically nothing.

Is there a way of reducing the negative effects from Seth's patch? It's 
a bit irritating that the CPU usage for the parent increases. I wouldn't 
have expected that.

Fabian