I think that keeping the networking portion as a part of the non-realtime
task (kernel) running at low priority is not a good idea. Now days, many (most)
of the real-time systems depending upon the network connectivity. Making
networking stack as low priority task will result in a non-reliable
communication.
Also, may systems are designed to provide the connectivity, say routers. Ffor
such
system, this approach is highly un-reliable. May be I am wrong, but in that
case pls
correct me.
Regards,
Yusuf
Paul Koning wrote:
> >>>>> "Aleksandar" == Aleksandar Bakic <[EMAIL PROTECTED]> writes:
>
> Aleksandar> David Schleef <[EMAIL PROTECTED]> writes:
> >> Even though it leads you down the dark path of "reinventing TCP",
> >> I would suggest switching to a UDP connection. One of the things
> >> UDP offers over TCP is that you can effectivly hog the network --
> >> TCP tries to be nice. TCP has a feature called "slow start",
> >> which makes it ramp up the bandwidth it tries to use. This can
> >> cause problems if you expect to be able to use a lot of bandwidth
> >> quickly.
>
> Aleksandar> I thought about this, but a friend, who has more
> Aleksandar> experience with the network configurations at my
> Aleksandar> university, said that he had had too many dropped packets
> Aleksandar> when using UDP (around 90%). And I don't need quick
> Aleksandar> one-time connections, but just the opposite (periodic
> Aleksandar> sending of data, 225kBps on average).
>
> Your friend's comment misses the point.
>
> If you do not need reliable delivery (i.e., your application will
> still work if n% of the packets never get to their destination) then
> UDP is unquestionably the right answer -- provided your network
> delivers a loss rate comfortably below n%.
>
> If you have a network loss rate of k% and you need an application loss
> rate less than that, you need some sort of error recovery mechanism.
>
> The traditional one is TCP: ACK, timeout, and retransmit ("ARQ"). You
> can use TCP, if the built-in algorithms meet your needs. Or you can
> roll your own "TCP equivalent" out of UDP. As David mentions, you can
> use your preferred algorithms that way, for example not use slow start
> or not use congestion avoidance (back down if loss rates go up).
>
> If you have a network with a 90% loss rate, is is severely broken. No
> normal protocol will work acceptably on such a network. You need to
> repair it first. As a rule of thumb, going back about 30 years, a
> packet loss rate of 1% will cut your application throughput by 50%,
> possibly more. Note that UDP isn't the issue here; TCP won't get any
> useful work done on such a network either. Normal ARQ algorithms just
> aren't designed to work under such abuse.
>
> There's an alternative to ARQ that's sometimes useful: FEC (Forward
> Error Correction). That doesn't use retransmission, but relies
> instead on redundant transmission to ensure things still get through
> in the presence of errors. A very simple example is sending every
> packet twice.
>
> You can easily construct FEC on top of UDP.
>
> The reason you might use FEC is that it lets you deal with a lossy
> network without introducing extra delays when packets are dropped.
> The price you pay is that you always send extra data even when packets
> are not being dropped. The classic application is satellite data
> transmission, where you can't afford waiting for the round trip time.
> (ARQ to Mars would be absurd...)
>
> paul
> --- [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/
--- [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/
