What is the behavior when you disable the select loop?
The documentation is pretty vague other than to say there is a new structure of the event loop. I looked at the code and noticed this will put pcap into blocking mode, but Im not sure what other impact this may have.
That's right, disabling the select loop will let Bro use blocking
pcap descriptors. That's the only difference and it is only
noticable when using other input than packets as well, in particular
when doing communication with other Bro nodes. If pcap blocks,
communication can stall.
Historically, Bro used to use only blocking descriptors, which we
changed when introducing the communication. Initially, the
non-blocking select loop was optional and needed to be turned on
explicitly. These days however it is the default and I don't really
know any reason to turn it off. The option to go back to blocking is
just a relict from the old times.
Any particular reason why you're interested in this?
I have been working on Bro on both an Intell and Bivio platform. On the Bivio system there is some strange occurence where if I my capture_filters are excluding traffic it will cause the application to periodically stall and completley destroy performance. Profiling did not really turn up much. I coded in some timers into the code and noticed the stalls were happening in post pcap_next() and prior to calling for the next packet. I never got to the root of the problem but by disabling the select loop my performance sky rocketed!
This build will not to communicate with other nodes so this sounds like a perfect solution.
I have been working on Bro on both an Intell and Bivio platform. On the
Bivio system there is some strange occurence where if I my capture_filters
are excluding traffic it will cause the application to periodically stall
and completley destroy performance.
What OS is the Bivio platform running? We've recently been seeing
stalls with FreeBSD 7 which sound pretty similar to what you
describe. My guess is that the FB7 problems are related to
non-blocking pcap as well because Bro seems to be the only
application which triggers them.
This build will not to communicate with other nodes so this sounds like a
(There's actually a bit more functionality which in principle could
stall, such as async DNS lookups (not a problem) or the new NetFlow
analyzer (which isn't in trunk yet)). But in any case, as long as
you have a steady stream of packets on the wire, pcap will always
have something to pass back to Bro and thus not block anyway.)
Its based of Suse on a powerpc architecture.
The stalls only seemed to happen when there are filtered packets. If I had redefined my capture_filters to accept all traffic the stalls do not happen.