Re: UDP jitter

["Nebojša Ćosić" <nebojsa@asnn.org>]

> On 08.11.2013 03:07, Thomas Gleixner wrote:
> 
> > Simply because it has nothing to do with priority inversion. It's just
> > the nature of a single unmanaged queue. The behaviour is completely
> > correct.
> 
> I cannot comment on the code as I did not analyze it myself
> (at least yet), but I think Nebojsa is worried by the situation
> where the high-prio thread is not able to _queue_ its packets because
> of the low-prio thread is sitting in some lock being preempted
> by something unrelated.
> 
> > Just for the record. I'm really frightened by the phrase "UDP
> > realtime" which was mentioned in this thread more than once. Looking
> > at the desperation level of these posts I fear, that there are going
> > to be real world products out already or available in the near future
> > which are based on the profound lack of understanding of the
> > technology they are based on.
> 
> Yes there are real-world product using real-time ethernet - not
> necessarily UDP but for example anything EtherCAT based absolutely
> needs to be able to send certain packets cyclically no more than
> 100 ms (or 10 ms or 2 ms) apart otherwise all hell breaks loose
> with real-world connected hardware. The room for jitter is the
> limit minus cycle the packets are being sent, which can be pretty
> tight.
> 
> On the same wire there is a non-rt traffic, usually sent by another
> lower-prio thread. The queuing of the packets itself is not a problem -
> this is basically a request-response protocol and there will never
> be more than several packets before the higher-level one - but
> a priority inversion where the first thread is stuck in the network
> code because something preempted the low-prio one that is just queuing
> a packet would be a big problem.
> 
> There is nothing else on the network interface, but there usually
> is another ethernet interface for non-realtime traffic. If some
> of the locks involved is driver-wise instead of interface-wise
> we already lost (I understand that this case would be the problem
> of the driver and not the infrastructure).
> 
> If I am understanding the Nebojsa's worries wrong or if the
> scenario cannot happen, please disregard.
> 
> Regards

Thanks Stanislav for excellent description.
In my case, bandwidth usage was bellow 5%, and measured delays on udp
messages were in some cases longer than 40ms. Only two nodes where
connected on test bench, and only one network interface per node was
available.
I have to repeat that the code in question worked in my case, which is
very specific, and that reason for discussing it is to try to come to a
proper solution to this problem.
And yes, I do believe that, even if behaviour is documented, it is still
a problem and can be dealt with in a better way.

-- 
Nebojša
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html