The directional out-of-order maybe caused by some network tapping
devices and/or some mirroring polices of the switches. In wireshark, it
will often appear as pairs of packets of different directions labeled as
"TCP ACKed unseen segment" and "TCP Spurious Retransmission".
It will make many Binpac analyzers unable to work normally because
in most cases the current state of one direction depends on the packets
of the opposite direction.
In theory if we know the number of the bytes we have missed from
the other direction, we could make a good guess if we should use
another state to decode current packet.
So my question is: is this other-side gap information available in
Binpac?
Thanks in advance and best regards,
Song
Greetings:
I've been tinkering with the --coverage flag to capture runtime statistics
which can then be used to compile zeek with branch prediction hints. My
preliminary tests indicate a substantial performance increase, enough to
justify engaging the zeek community.
I noticed that the configure script includes --enable-coverage, which
doesn't quite do what I want, as it compiles with debug support. and I'm
most interested in optimization for production use.
In brief, I've been testing:
./configure --enable-coverage
for the initial compile, then run against pcaps and live traffic, and use
that profiling data to recompile:
CFLAGS=’-fprofile-use -fprofile-correction -flto’ CXXFLAGS=’-fprofile-use
-fprofile-correction -flto’ ./configure
with a substantial performance boost against a regular compile (can
additionally do --build-type=Release for compiling with -O3 flag).
Has anyone else tinkered with this? - I would be happy to elaborate, and
discuss with others.
Jim
