# policy event engine **URL:** \ **Category:** Zeek\ **Created:** [January 21, 2011, 2:56pm UTC](https://community.zeek.org/t/policy-event-engine/1802 "2011-01-21T14:56:19Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Yuriy](https://avatars.discourse-cdn.com/v4/letter/y/ea666f/32.png) [@Yuriy](https://community.zeek.org/u/Yuriy)\ **Post date:** [January 21, 2011, 2:56pm UTC](https://community.zeek.org/t/policy-event-engine/1802/1 "2011-01-21T14:56:19Z")
Hello, I can`t understand scripts asynchronous call behavior. When I pointing 20 second in table`s data type attributes “&create\_expire=20sec”, I find unpredictable behavior: the table`s item removed not in 20 seconds, it can be removed after 25,30 etc seconds. As I found it is depending on how many packets in the network: if there is no packets after timer value, my timer will never expire. And when the first packet appear, the timer immediately expire (but, for example, has been more than a few hours). Why is this so? Thank you for explanation. ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [January 21, 2011, 3:07pm UTC](https://community.zeek.org/t/policy-event-engine/1802/2 "2011-01-21T15:07:30Z")
> I can`t understand scripts asynchronous call behavior. When I pointing 20 second in table`s data type attributes “&create\_expire=20sec”, I find unpredictable behavior Unpredictable but expected. 🙂 Timers in Bro aren't "hard". They will be dispatched when Bro gets around to them, not at the exact moment the timer was scheduled to fire. The only thing you can be assured of is that it won't be dispatched prior to the time which is set. > : the table`s item removed not in 20 seconds, it can be removed after 25,30 etc seconds. As I found it is depending on how many packets in the network: if there is no packets after timer value, my timer will never expire. By default, the notion of time in Bro is driven forward by the packet timestamps which means that timer expirations will go accordingly. No packets == no time advancement == no timer expiration. If remote communication is enabled, the internal time will be clock driven. I don't know offhand if that requires an actual connection or if just holding open a socket will work. > And when the first packet appear, the timer immediately expire (but, for example, has been more than a few hours). I don't understand what you are saying here. Which timer expires immediately?   .Seth ---
**Author:** ![Yuriy](https://avatars.discourse-cdn.com/v4/letter/y/ea666f/32.png) [@Yuriy](https://community.zeek.org/u/Yuriy)\ **Post date:** [January 21, 2011, 3:36pm UTC](https://community.zeek.org/t/policy-event-engine/1802/3 "2011-01-21T15:36:40Z")
Thank you for the quick reply, Can you understand me (at least briefly) what is the reason of "...the notion of time in Bro is driven forward by the packet timestamps...", why not internal clock? As I understood the only way to change such behavior (packet timestamps clock driven) is "If remote communication is enabled, the internal time will be clock driven...". Can one little detail, please? ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [January 21, 2011, 3:43pm UTC](https://community.zeek.org/t/policy-event-engine/1802/4 "2011-01-21T15:43:03Z")
> Thank you for the quick reply, > Can you understand me (at least briefly) what is the reason of "...the > notion of time in Bro is driven forward by the packet timestamps...", why > not internal clock? I expect that it was an optimization, but you'll have to wait for a response from Robin or Vern to clarify that point. > As I understood the only way to change such behavior (packet timestamps > clock driven) is "If remote communication is enabled, the internal time will > be clock driven...". Can one little detail, please? If you load the listen-clear.bro script, that may make Bro drive off of the clock and not packet timestamps. This is where my comment about me not knowing whether an actual connection has to take place or not applies.   .Seth ---
**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\ **Post date:** [January 21, 2011, 4:17pm UTC](https://community.zeek.org/t/policy-event-engine/1802/5 "2011-01-21T16:17:09Z")
> \> Can you understand me (at least briefly) what is the reason of "...the > \> notion of time in Bro is driven forward by the packet timestamps...", why > \> not internal clock? > > I expect that it was an optimization, but you'll have to wait for a response from Robin or Vern to clarify that point. Yes, because in a typical deployment environment, many packets stream in every second, and they arrive via pcap with timestamps attached. Plus, we haven't perceived an important benefit from having precise timers; for typical uses (keeping tables from growing too large), imprecise timers are generally fine.     Vern ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 21, 2011, 5:54pm UTC](https://community.zeek.org/t/policy-event-engine/1802/6 "2011-01-21T17:54:36Z")
There's actually one more aspect to this: while Bro's timers are not precise, in typical situations they are also not \*that\* imprecise as you are observing here with tables. The reason here is that table expiration is actually done in batches: there's not a an individual timer per element (in which case expiration would be more timely), but one per \*table\*. Every time that one first, a certain number of table elements is checked to see whether they have already expired---which is why you're seeing expirations occuring in discrete intervals. You can fine-tune the specifics of this process with the parameters table\_expire\_interval, table\_incremental\_step, and table\_expire\_delay; see policy/bro.init. Robin ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 21, 2011, 5:57pm UTC](https://community.zeek.org/t/policy-event-engine/1802/7 "2011-01-21T17:57:35Z")
s/first/fires. Robin ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:39pm UTC](https://community.zeek.org/t/policy-event-engine/1802/8 "2022-05-06T15:39:26Z")