[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [rtl] Networking With RT-Linux
>>>>> "Aleksandar" == Aleksandar Bakic <bakicale@brazil.tcimet.net> writes:
Aleksandar> David Schleef <ds@stm.lbl.gov> 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 majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/