Hi Pieter, I tried the same performance tests with POSIX message queues and there was no delay in receiving the messages. The same test with ZeroMQ showed delays of upto 470msec. Doesn't this mean that we can rule out the possibility of another process taking up CPU time randomly (as you had suggested earlier)?
Are there any sleep/wait (for semaphores) in the zeromq code that could send my process to suspeneded/sleep state. I am not able to figure out why this delay is seen when using ZeroMq and not with message queues.**** ** ** Thanks,**** Divya**** ** On Thu, Mar 28, 2013 at 3:54 PM, Pieter Hintjens <[email protected]> wrote: > On Wed, Mar 27, 2013 at 4:51 PM, Divya Mohan <[email protected]> > wrote: > > > Current and default scheduling policy is SCHED_OTHER. I had given highest > > priority to my receive process thinking delay due to scheduling will be > > taken care off but even then the messages are delayed. > > > > Also I am not using any sleep in my receive process. Only send process > has > > a sleep of 1 msec. > > In general changing thread priorities is a bad idea. > > Perhaps you have another process taking CPU time at random occasions, > causing the sender I/O thread to be swapped out. > > If you want guarantees that there are no spikes you'll have to use a > real time kernel. It will increase average latency but remove the > spikes. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
