[zeromq-dev] No rate limitation using JZMQ

Benjamin Errouane Benjamin2002 at gmx.de
Fri Dec 18 18:44:56 CET 2015


>
> A new parameter was added in PGM that can set the individual limits for
> Original Data (ODATA) and Repair Data (RDATA) packets thus reserving
> bandwidth for repairs and ancillary data.


Are these parameters somehow accessible in JZMQ? I would have thought the
setRate-function would use these limits in some way. But if I'm
understanding your statements correctly the throttling is achieved in the
zmq-Framework rather than in the OpenPGM-framework, right?


The general recommendation however for ZeroMQ users has been to implement a
> level of application rate limiting before feeding into ZeroMQ, however it
> can be coarse limiting as the underlying framework implements fine grained
> throttling.


I thought about limiting the rate at application level but this is not
really the preferred solution, because the network should be adaptable to
changes in the network topology. What kind of throttling does Zmq
implement? Right now I'm not experiencing any throttling, but this may be
due to the application currently pushing messages at maximum rate.


It is a continuing problem with reliable multicast in general and one may
> wish to try the NORM protocol as an alternative.


Actually I'm also using the NORM-Framework and its Java-Bindings. It's
congestion control seems to be a pretty neat feature.

For zmq I'm using the zmq3 stable release. Is the norm-API available in
this version? If not, can I use jzmq with the zmq4 stable release?

Cheers

2015-12-18 17:55 GMT+01:00 Steven McCoy <steven.mccoy at miru.hk>:

> On 18 December 2015 at 08:30, Benjamin Errouane <Benjamin2002 at gmx.de>
> wrote:
>
>> I'm experiencing high loss when using JZMQ with the pgm transport (up to
>> 100%), when the application is trying to send as fast as possible. In fact
>> it tries to send way faster than the Gigabit-LAN is allowing. I think this
>> might be the reason why no paket is arriving.
>>
>> Any suggestion how to fix that?
>>
>> As explained before, limit the rate via setRate(int) has no effect.
>>
>>
> This would require some investigation, the Rate socket option is defined
> to limit the overall usage of the network channel bandwidth.  Due to ZeroMQ
> design this usually means pushing data as fast as possible however this
> does not work well with protocols without congestion control.  A new
> parameter was added in PGM that can set the individual limits for Original
> Data (ODATA) and Repair Data (RDATA) packets thus reserving bandwidth for
> repairs and ancillary data.  The general recommendation however for ZeroMQ
> users has been to implement a level of application rate limiting before
> feeding into ZeroMQ, however it can be coarse limiting as the underlying
> framework implements fine grained throttling.
>
> It is a continuing problem with reliable multicast in general and one may
> wish to try the NORM protocol as an alternative.
>
> --
> Steve-o
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20151218/5f6d705d/attachment.htm>


More information about the zeromq-dev mailing list