On Wed, Nov 24, 1999 at 03:01:19AM -0700, Kulwinder Atwal wrote:
>
> > I' d love to see measurements showing this. Our tests give us numbers that are
> > better than the ones we have seen for QNX. Please make sure to measure
> > _worst case_ instead of "typical" .
> >
>
> Yes, they are 'typical' values. I was referring to the following URL:
>
> http://www.qnx.com/literature/whitepapers/archoverview.html#AppendixB
"Typical" is worthless. Vanilla Linux has "typical" interrupt latencies of a
couple of microseconds. Even NT has good "typical" interrupt latencies.
The interesting question for hard realtime is "worst case" and for soft realtime
"typical" needs some additional information (under what workload, with what
distribution ... ). Note that is is possible to improve "typical" at the
expense of "worst case".
> The reason I mentioned UDP was because it is a wrapper protocol for
> RTP, RTCP, and RTSP.
But UDP is, like IP, a "best effort" protocol with no timing.
>I only mentioned these and IPv6 because it allows
> existing multi-purpose networks to be used for RT messaging. It is not
> the ideal solution, but a better solution than TCP. I know that IPv6
> uses 'flow control' to prioritize messages. I have been reading the RFC
> on IPv6 and I think a solution is possible. The non-rt components can
> be interrupted or passed on to normal linux. By placing IPv6 in RT ,
> then RT can have direct control over every byte sent and received. If a
> RT task is in progress the NIC can be ignored until RTL is free. When
> there is no RT task pending RTL can simply pass the buffers between
> linux and the NIC. When a RT task needs to send/ receive RTL can create
> RT buffers.
>
> Are there issues that I have overlooked with IPv6?
I don't know. My impresion of IPv6 is that it is complex enough to make rt
a problem. But this is a superficial impression and it would be nice to see
someone do a better analysis.
Note that current NICs have poor worst case RT behavior: for example,
Linux fills the output TX queue with N non-rt messages and then RT must
stall waiting for N*TX_time. 1394 and USB allow for bandwidtth and time
slice reservations making realtime more real. We could do the same with
a NIC by software reservation of every K'th packet, but ...
The other drawback of IPv6 is that nobody uses it.
In any event, RTLinux networking drivers are strongly encouraged and
I look forward to seeing people write them and contribute them.
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
