[zeromq-dev] ZMQ_RATE

[Steven McCoy]

On 3 October 2011 14:50, Steven McCoy <steven.mccoy at miru.hk> wrote:

> On 3 October 2011 12:41, Steven McCoy <steven.mccoy at miru.hk> wrote:
>
>> On 3 October 2011 12:02, Emmanuel TAUREL <taurel at esrf.fr> wrote:
>>
>>>  On 03/10/2011 17:53, Steven McCoy wrote:
>>>
>>> On 3 October 2011 11:18, Emmanuel TAUREL <taurel at esrf.fr> wrote:
>>>
>>>>   On 03/10/2011 17:02, Steven McCoy wrote:
>>>>
>>>> On 3 October 2011 10:19, Emmanuel TAUREL <taurel at esrf.fr> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I am experimenting PUB/SUB sockets with PGM protocol.
>>>>> I am actually using with the ZMQ_RATE socket option.
>>>>> My understanding of this parameter was that it is the maximum rate for
>>>>> sending/receiving data and thus limits the network bandwidth used by
>>>>> PGM.
>>>>> In my test, the publisher sends messages as fast as it can.
>>>>> I have tried different value for the ZMQ_RATE parameter: 100 which
>>>>> means
>>>>> 100 kbits/sec (the default) and 80000 which means 80Mbit/sec.
>>>>> I capture network packets using wireshark. When I look at its IO graph
>>>>> after the capture, there is no difference between the two runs.
>>>>> During the PGM transmission, I always have a network usage close to 100
>>>>> Mbit/sec which is my network bandwidth between the pub and sub hosts.
>>>>>
>>>>> Where is my error?
>>>>> Do I have to understand that ZMQ_RATE limits the data rate in the
>>>>> process but not on the network (meaning buffering required in case of
>>>>> slow ZMQ_RATE)?
>>>>>
>>>>>
>>>>  Correct but the differences are going to be only latent.
>>>>
>>>>  The default for ZMQ_RATE is now 40*1000, 40mbit/s, because you cannot
>>>> really do any testing with 100kbit/s as it is way too slow.  This does
>>>> suggest you are on an older version and you may wish to retry with at least
>>>> 2.1.9.
>>>>
>>>>  You can compare with the local_thr and remote_thr performance test
>>>> programs which work correctly.
>>>>
>>>>  There may be a problem with timer accuracy on your platform, you may
>>>> try setting the environment variable PGM_TIMER to GETTIMEOFDAY, TSC, or
>>>> CLOCK_GETTIME for different methods:
>>>>
>>>>
>>>> http://code.google.com/p/openpgm/wiki/OpenPgmCReferenceRunWithTheseCapabilities
>>>>
>>>>
>>>>  Thank's for your answer.
>>>> I am using zmq 3.
>>>>
>>>>
>>>  So this might be a regression on setting the rate limit on the PGM
>>> socket.  I would suggest comparing operation with version 2.  I'm only
>>> looking at v2 for bug fixes and v4 for enhancements so additional awareness
>>> is required for the v3 branch.
>>>
>>>
>>> I am sorry but I am lost. In our application, we would like to use either
>>> TCP transport either PGM transport.
>>> With ZMQ 3, we have the nice event subscription feature and this is why
>>> we are using it.
>>> Do you mean that PGM is not supported with ZMQ 3?
>>>
>>>
>> Well it means I haven't reviewed it, I think Martin is still listed as the
>> official maintainer.
>>
>> A quick look at 3.0.1 it would appear that v3 does not set any rate
>> limiting at all.
>>
>> 2.1: Sets PGM_ODATA_MAX_RTE PGM socket option.
>>
>> https://github.com/zeromq/zeromq2-1/blob/master/src/pgm_socket.cpp#L251
>>
>> The lines are dropped in 3.0:
>>
>> https://github.com/zeromq/zeromq3-0/blob/master/src/pgm_socket.cpp#L238
>>
>>
> Looks like it was collateral damage from a December commit working on the
> recovery interval parameter:
>
>
> https://github.com/zeromq/zeromq3-0/commit/fcfad5682ed7a7f5108853d2a7039aedfd9a9ac2#diff-5
>
>
It was fixed in 2.1 but not propagated to the other branches:

http://lists.zeromq.org/pipermail/zeromq-dev/2011-March/009723.html

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111003/590eeaf3/attachment.htm>