> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
