[zeromq-dev] ZMQ_RATE

[Steven McCoy]

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

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