[zeromq-dev] Integrating additional PGM rate limit controls into ØMQ

Steven McCoy steven.mccoy at miru.hk
Sat Nov 27 14:52:04 CET 2010


On 27 November 2010 16:05, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Hi Steven,
>
> For getting the best usability I propose following:
>
>
>     * TXW_MAX_RTE, the maximum transport rate.
>>
>
> (this is max rate for both ODATA and RDATA combined, right?)
>

This is the total multicast packet limit, so ODATA, RDATA, SPMs, but not
NAKs, NCFs, or SPMRs.


>
>     * ODATA_MAX_RTE, limit for original data packets.
>>
>>    * RDATA_MAX_RTE, limit for repair data packets.
>>
>
> ZMQ_RATE => TXW_MAX_RATE
>
> A new option, say ZMQ_REPAIR_RATIO, that would be the percentage of
> ZMQ_RATE to guaranteed to be available for the repairs.
>
>
>  And for whatever reason you can also set the following flags:
>>
>>    * ODATA_CONTROLLED, whether original data packets are rate limited.
>>    * RDATA_CONTROLLED, whether repair data packets are rate limited.
>>
>
> As far as I understand, the ODATA limit can be turned off because the
> overall limit is bound by TXW_MAX_RTE and thus ODATA cannot surpass that
> value anyway.


It is so you can say specify a rate for ODATA packets but
have unlimited RDATA.


> Let me give an example:
>
> ZMQ_RATE = 100Mb/s
> ZMQ_REPAIR_RATIO = 5%
>
> would mean:
>
> The whole traffic consisting of both ODATA and RDATA will never exceed
> 100Mb/s. If there are no repairs ODATA would flow at rate of 100Mb/s.
>
> If there is need for repairs, the bandwidth for them is cut from the
> overall quota, say 97Mb/s for ODATA and 3Mb/s for RDATA.
>
> When the rate of RDATA packets reaches 5% of overall bandwidth (5Mb/s) some
> of them have to be dropped, meaning that some receivers will loose messages
> ("unrecoverable data loss").
>
>
For this example look at setting TXW_MAX_RTE to 100mb/s and RDATA_MAX_RTE to
5mb/s.

We've discussed RDATA over ODATA packet priority before, it's not the way to
go if you want performance.

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


More information about the zeromq-dev mailing list