[zeromq-dev] Delayed message reception problem.
Pieter Hintjens
ph at imatix.com
Mon Apr 15 09:22:38 CEST 2013
Hi Asif,
I'm hoping Divya will provide us with reusable tests that show the problem.
-Pieter
On Mon, Apr 15, 2013 at 7:50 AM, asif saeed <asif.lse2 at gmail.com> wrote:
> Excellent, Divya. Very good analysis.
>
> @Pieter,
>
> I am also going to use ZeroMQ in an Ubuntu environment and Divya's analysis
> is really worrying me. Does ZeroMQ have benchmarks on non real-time systems?
> What kind of performance tests are there to test the performance?
>
> Sincerely,
>
> -Asif
>
>
> On Fri, Apr 12, 2013 at 10:29 PM, Divya Mohan <divya.mohan310 at gmail.com>
> wrote:
>>
>> 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 <ph at imatix.com> wrote:
>>>
>>> On Wed, Mar 27, 2013 at 4:51 PM, Divya Mohan <divya.mohan310 at gmail.com>
>>> 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
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
More information about the zeromq-dev
mailing list