From: Stanislav Meduna <stano@meduna.org>
To: "Thomas Gleixner" <tglx@linutronix.de>,
"Nebojša Ćosić" <nebojsa@asnn.org>
Cc: eg Engleder Gerhard <eg@keba.com>,
linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: UDP jitter
Date: Fri, 08 Nov 2013 10:39:57 +0100 [thread overview]
Message-ID: <527CB16D.3040909@meduna.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1311080134050.23353@ionos.tec.linutronix.de>
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
--
Stano
next prev parent reply other threads:[~2013-11-08 10:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-29 20:22 UDP jitter Nebojša Ćosić
2013-04-30 15:22 ` Carsten Emde
2013-04-30 17:26 ` Nebojša Ćosić
2013-11-06 8:53 ` AW: " eg Engleder Gerhard
2013-11-06 11:57 ` Nebojša Ćosić
2013-11-06 19:07 ` Thomas Gleixner
2013-11-07 8:00 ` AW: " eg Engleder Gerhard
2013-11-07 9:33 ` Nebojša Ćosić
2013-11-08 2:07 ` Thomas Gleixner
2013-11-08 9:39 ` Stanislav Meduna [this message]
2013-11-08 10:32 ` Nebojša Ćosić
2013-11-08 11:48 ` Thomas Gleixner
2013-11-08 12:22 ` Armin Steinhoff
2013-11-08 18:57 ` E-Blokos
2013-11-08 10:50 ` Tom Cook
2013-11-08 10:51 ` AW: " eg Engleder Gerhard
2013-11-08 11:30 ` Thomas Gleixner
2013-11-08 12:07 ` AW: " eg Engleder Gerhard
2013-11-08 13:35 ` Thomas Gleixner
2013-11-09 10:26 ` Nebojša Ćosić
2013-11-09 16:33 ` Joe Korty
2013-11-08 12:14 ` Stanislav Meduna
2013-11-08 13:32 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527CB16D.3040909@meduna.org \
--to=stano@meduna.org \
--cc=eg@keba.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=nebojsa@asnn.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.