[zeromq-dev] 100ms latencies in 1.0

Martin Sustrik sustrik at fastmq.com
Tue Oct 20 12:45:50 CEST 2009

Hi Robin,

> I've noticed that our system seems to see 100ms latency occasionally. It 
> happens in bursts and affects 4 in 1000 messages. Its usually exactly 
> 100ms when this happens (not 110 or 120 or 400).

Yuck :(

> I also noticed this variable in the config.hpp
> //  Maximal wait time when engine sets timer (milliseconds).
>         max_timer_period = 100
> And in select_thread.cpp:
>         //  Compute the timout interval. Select is free to overwrite the
>         //  value so have to compute it each time anew.
>         timeval timeout = {max_timer_period / 1000,
>             (max_timer_period % 1000) * 1000};

The timeout should be used only for reconnection timers (i.e. when 
connection is broken, 0MQ tries to reconnect after 100ms rather than 
immediately). In normal state, no 100ms delay should occur.

Can you change the value of max_timer_period to say 200ms and have a 
look whether the delay you are seeing have increased correspondingly?

> We are using linux/c
> Is this expected behavior? Under what conditions? What are the 
> implications of reducing max_timer_period? Are there better ways to 
> avoid what looks like a polling delay (e.g. make it use a select call)? 
> Could it be that I'm not setting up my iothreads/dispatcher threads 
> correctly and that causes this? Does the 2.0 version work the same way?

Nope. It's a bug not a design problem. As already said above 
max_timer_period shouldn't ever be triggered in normal state of affairs.


More information about the zeromq-dev mailing list