[zeromq-dev] QoS support

[Martin Sustrik]

Erich Heine wrote:

> Not at the moment, I'm still in the "define the problem" stage :)  It is 
> not easy tho.  I'm sort of toying with tying into various tc queues 
> automatically, but this is very linux-centric (actually worse, it is 
> pretty version specific for linux, at least 3 different methods required 
> depending on kernel version)

Well, no way to deal with that unless we'll mess with tc (or other such 
tools) from 0MQ itself. However, alternating global settings from a 
single application is not a good practice.

> 
>     One more question: Can you think of a scenario where there's large
>     number of priority levels? Say 256? Or 10000? The point is that it's
>     rather acceptable to have 3 connections per feed, however, it's not
>     acceptable to have 10000 of them.
> 
> Yes and no. It depends on whether each signal can be ranked.  For 
> instance Consumer X wants  signals (NAME{prio (higher number better 
> prio)}) A{3}, B{3}, C{2}, D{1}, and Consumer Y wants signals A{3}, B{2}, 
> D{1} E{1}.  We could prioritize and send out these as: A{3} B{3} C{2} 
> D{1} E{1} or as A{6}, B{5}, C{2} D{2} E{1} (or the latter condensed into 
> 4 actual queues..).
> In the later scenario, many queue levels could emerge.
> 
> Of course one thing to remember with queueing theory is that at a 
> certain point increasing the number of queues worsens the situation. 
> Basically it is an optimization problem.

Right.

Martin