For the script you sent me, the 1-second skips aren't that surprising.
Bro's "schedule" sets a minimum time in the future for when the event
will occur. The actual time will be a tad later, depending on how long
it takes the event engine to process the buffer of packets that leads
to the clock advancing past the scheduled time. So for example if
at network time 1.95 you schedule an event for one second in the future,
that won't be looked at until a set of packets arrives for which one
of them has a network time of >= 2.95. Those packets will first be
processed before doing the scheduled event.
In addition, network-time will lag current-time by an amount proportional
to the packet capture buffer. If the buffer is a few hundred msec's worth,
then you will not infrequently get a mismatch regarding times of one-second
Report time is 1447869607.383869, report hour is
Report time is 1447869617.52706, report hour is 10:0:17 <----- big jump
is definitely not good. I'm not seeing how your script could lead to
that behavior other than the event engine going away (= spending time
processing packets) for around 10 seconds.
Report time is 1447869618.188414, report hour is
Report time is 1447869619.04252, report hour is 10:0:19 <- stall ?
Report time is 1447869619.733979, report hour is 10:0:19 <--- stall ?
I can at least construct a theory. Suppose the event was supposed to
happen at 10:0:18.8. A packet comes in with that network time, so the
event fires, but only 200 msec later, so current-time shows 10:0:19.
The script schedules based on network-time rather than current-time, so
it'll set the next event for 10:0:19.8. When that packet arrives, there's
less to process, so the script runs before the current-time advances to
In any case, I agree that Craig's proposed fix is a good way to deal
with this. In addtion, I think this points up the utility of Bro
providing cron-style event scheduling in addition to relative-time