posted on Wednesday, January 14, 2009 - 11:15 am
It seems to me that these two QoS can be set to be contrary to each other i.e. you could set a small latency budget but have a low priority. In which case the priority is meaningless if it means that the latency budget will fail.
In this case priority becomes some kind of sub-priority with latency budget being the more important?
posted on Wednesday, January 14, 2009 - 11:54 am
The Latency Budget is a hint to the DDS service that the middleware may use the additional specified time budget before delivering data. This time can be used by the DDS service for efficiency e.g. to pack multiple messages. Transport priority specifies how network resources are scheduled between messages i.e. in OpenSplice messages with a higher transport priority will preempt messages having a lower transport priority. So yes; message with a low transport priority may be delayed beyond the specified latency budget in case there is too much data for the available network resources during this period. But in that case Latency Budget doesn’t become more important since latency budget is just a hint the data will still be delivered so there is no failing communication caused by failing to meet the latency budget. The deadline mechanism can be used if detection of delayed messages is required.
The transport priority is about the importance of the data whereas latency budget is about its urgency. More important information is not necessarily more urgent.
Personally I like the 'Train station' example that can be considered an analogy for the approach that is implemented in OpenSplice DDS: A railway station has multiple platforms. There is a train waiting at every platform and each train runs at a different speed. If people pay more, they are allowed to take a faster train and so they go to the platform that matches their ticket. Depending on the time they need to depart, people are allowed to get into the train first. The departure time of the train depends on the person with the most strict departure time. The money one pays can be considered the transport priority and the departure time can be considered the latency budget.
So, to get back to your question; if you need to depart now, the train will leave immediately after you get in even if there is still room left in the train to transport more people. If there is a faster train that wants to leave at the same time, that one will depart first.
posted on Wednesday, January 14, 2009 - 03:58 pm
Hi Niels, If 'Transport Priority' gets more preference over 'Latency Budget' then why to have Latency budget QOS?Is it like this that if we have lower latency budget for a message then this message will be assigned higher priority by the DDS,internally?
The analogy is still correct here: the railway service is more efficient if more people are transported in one single train. Ideally trains are full when they depart, but that is not possible when the departure time of one or more people in it has been reached before the train is full. The departure time of a person does not determine in which train he will be placed.
The latency budget is considered a hint to the middleware to allow it to improve effiency. If your application increases the latency budget, the service is able to pack more messages in one single network packet that is sent 'over the wire'.
Let me provide another perspective on these principally orthogonal QoS policies.
TRANSPORT_PRIORITY is an expression of the 'importance' of information, very much like 'scheduling-priority' is a means of expressing 'processing-importance'. In realtime systems, priority is instrumental to specify & achieve the proper determinism.
LATENCY_BUDGET on the other hand is an expression of the 'urgency' of information, i.e. the time that is allowed to get the data distributed from a publisher to a consumer. In distributed systems, such an available 'budget' is instrumental in achieving optimal throughput since it allows the underlying infrastructure to exploit this buget by packing/batching of information.
So in the train-analogy, LATENCY_BUDGET will allow the middleware to 'schedule' the data for a specific train (i.e. allows the middleware to 'gather' enough passengers to ride will a maximally full train which is of course very efficient when for instasnce compared to every single passanger riding alone in his car) whereas the TRANSPORT_PRIORITY of determines the likelyhood of getting aboard the right train (i.e. having a first-class ticket allowing you 'on-board' even when the train is full with 'economy' passengers).
In OpenSplice DDS, this concept is explicitly supported by our 'network-scheduling' concept where a number of priority-lanes can be pre-configured that 'handle' published information of a certain priority-band and where within a single-band also prioirty-preemption is applied to assure that the highest-priroity 'passengers' are 'in-front'. Each priority-band is realized by Tx/Rx threads at configurable scheduling class/priority that also apply traffic-shaping as well apply a configurable DIFFSERV priroity to the data to allow pre-emption 'along the route' also.
Finally, the LATENCY_BUDGET as expressed with published information will be utilized by each channel to pack-information into (configurable) max-burst-sizes to optimally exploit the underlying UDP/IP network where large datagrams induce less protocol-overhead per exchanged payload unit.
And before ending, its worthwhile that both policies are expressed using units that are meaningfull in the application-dommain rather than the underlying OS-terminology: LATENCY_BUDGET is expressed simply in the-maximally-allowed-number-of-milliseconds that are available to the middleware to get the information distributed whereas TRANSPORT_PRIORITY is a integer with system-wide scope where a higher-number means 'more-important'. In our OpenSplice DDS product the realtime-network-scheduler can be configured (outside application-scope so fully transparent for the applications themself) for working at a sufficiently fine-grained resolution for a configurable number of priority-lanes for best-effort as well as reliable data-exchange. And lets also not forget about yet another QoS-policy that drives effiency of point-to-multipoint-distribution which is the PARTITION QoS-policy that allows information (sets of topics) to be 'grouped' in a logical-partition (as also explained in other threads in the forum). By allowing a mapping of such logical 'DDS PARTITIONS' onto a configurable set of physical 'NETWORK PARTITIONS' that are characterized by a multicast-group and/or a set of unicast-destinations, the capabilities of the underlying network (i.e. supporting multicast for very efficient 1-to-many distribution, or in case of a very limited network-infrastructure allowing for direct point-to-point communication as the most trivial way of doing 1-to-n distribution) can be exploited 'to the max'.
Hope this helps also a little
posted on Thursday, January 15, 2009 - 09:54 am
Ah, thanks for this little debate folks.
I think that last post (Hans) brought it home for me. So, if I were to take this to the limit I could say that low priority data may never be sent (in a BEST_EFFORT scenario) because there was too much higher priority data?