[zeromq-dev] QoS support

[Steven McCoy]

2009/11/12 Erich Heine <sophacles at gmail.com>

> Point 2, is a slightly different take on the same notion. It assumes that
> some applications will not partake in the system QoS of their own accord. In
> such cases, some QoS mechanisms on the host will go a long way. Say in the
> example above there is an app that aggregates security video feeds and sends
> them along the network. For whatever reason this app runs on the same box as
> the control apps (its a beefy box at a small plant or something). The video
> system doesn't do QoS with the control system. So we need to have host based
> QoS here, with priority queueing making the video a lower priority via
> system intervention. The video may or may not be tagged on egress, that is a
> separate issue, what we are doing here is providing a guarantee to the the
> control system that it will be able to do its own thing correctly.  Further
> say each individual sensor and camera steam comes in on the LAN. We need
> ingress controls to prioritize handling of sensor data over video data.
>
>
It depends what is the limiting factor in the system and what quality you
are expecting.  If you are talking about pure network bandwidth then QoS
settings on the host are completely ignored if the switch port is maxed out
by video packets.  Such a system should be setup with bandwidth limiting on
the video feed, separate LANs for the video and sensors, or simple
prioritization at the network elements.

Next layer is the OS kernel, can it accept all the incoming packets without
drops.  Evidence has shown that best effort is generally preferable to a
prioritised queuing scheme.

Finally at the application layer you have simply processing power to handle
the incoming data streams.  This depends on number of threads, number of
cores those threads are running on, etc.  Similar to Rendezvous is to have
one incoming stream running at best effort taking data from the kernel,
separate worker threads can then cherry pick messages from the incoming
queue based on tagged priority whether tagged from source or derived from
subject or content.  You can tweak the worker pool depending on your
requirements, for instance keep some workers in reserve to only process high
priority messages.

For example, if you have four cores on a box you could reserve two for
handling sensor data, keep the third for queuing, and bind everything else
to the forth.

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