Re: Determining if it is "safe" to send UDP packets
From: gregory_may (None)
Date: 02/11/05
- Next message: L. Spiro: "Breakpoints and ecx."
- Previous message: gregory_may: "Re: Determining if it is "safe" to send UDP packets"
- In reply to: gregory_may: "Re: Determining if it is "safe" to send UDP packets"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 11 Feb 2005 10:34:15 -0800
In my case, I had to build some test programs that sent & received packets.
I actually had to do a fair amount of work fine tuning the receiving client
application ... I finally went with the .Net thread pool. Using the thread
pool in .Net probably increased my Frames/Second at least 25%. I also had
several thread concurrency & memory management issues on the broadcasting
program to nail down. Some of which only showed up sporadically & under
load.
My suggestion for both the client & broadcasting program is to rip open the
comm layer (at the lowest level) & put timing checkpoints so you can see at
what time messages go out & in of your program. This was the only way I
could tell what was going on.
"gregory_may" <None> wrote in message
news:%23G2ok0UDFHA.2620@tk2msftngp13.phx.gbl...
>I am currently developing an application that uses UDP for broadcasting
>images. I have parameters that let me "Tune" how long I must wait before
>the next packet hits the wire. In my application, a 50 ms delay between
>sends has proved to be the best compromize between speed & reliability.
>
> In my testing, going below this threashold actually can blow up the
> network driver on the receiving machine!
>
> So, you might try just to add a basic delay to make sure the next paket
> doesnt go out too soon.
>
> Good Luck!
>
> g.
>
>
> "Spiro Trikaliotis" <news-200501@trikaliotis.net> wrote in message
> news:slrncvpg5a.8uh.news-200501@news.trikaliotis.net...
>> Hello Roger,
>>
>> thank you for your answer.
>>
>> Roger Levy <rhl@i3e.org> wrote:
>>
>>> I could be glib and say the answer is TCP but I assume you have good
>>> reasons for using UDP.
>>
>> Yes, we have. We want to transfer images obtained from a camera as fast
>> as possible over a wireless link. The protocol used is tolerant of
>> packet losses, thus, it is not a big problem if the one or the other
>> packet does not get received.
>>
>> Every image is packed. Unfortunately, the packed images appear almost
>> all at the same time. That's the reason why we have to send them out in
>> bursts.
>>
>> As we are sending on a (direct) wireless link (but assuming we are the
>> only one sending anything), we do not need to take into account any
>> potential problem like congestion, routers that add processing delay, or
>> the like.
>>
>> For testing purposes, we tried to connect two machines via fast
>> ethernet, utilizing a cross-connect cable. Thus, we are sure that it is
>> the sender's OS that is throwing the UDP packets away.
>>
>>> I think a possible answer to determining when it is "safe" to send is
>>> to automate the process that you have described as a "training"
>>> process that takes place before sending important data. Training is
>>> essentially what modems do to determine the highest reliable data
>>> rate. Training would require you to define a message protocol that
>>> enables the destination machine to detect when training is is being
>>> executed and how to respond to it. The complexity of such a scheme
>>> would probably lead me back to TCP.
>>
>> As real-time is a major issue, TCP or a similar approach is obviously
>> out of scope. Furthermore, as I told before, we do not need each and
>> every packets. Anyway, getting only the first 10%, and nothing
>> aftermore, is *not* enough for us.
>>
>> It is very interesting to see the scheme of the packet losses if you
>> just send out a burst: The first x% of packets are all send. Then, the
>> next 100%-x% are not send, they are almost all completely lost. After
>> this, again x% are send, and so on. It really looks like a full buffer
>> on the sender's site.
>>
>>
>> Another problem with TCP is its assumption that a lost packet is due to
>> a congestion (which is not true in our case, as we do not have
>> congestions), but lost packets are rather frequent on the wireless link.
>>
>>
>>> Another approach is to make your UDP path more reliable but you
>>> haven't given enough network topology for anyone to tell you where to
>>> start.
>>
>> Well, we have A, and we have B, connected directly via the wireless
>> link. It cannot be more simple, can it? ;-) BTW: We need a datarate of
>> not more then 150 KB/s on the wireless link - a data rate which it can
>> surely handle. Furthermore, our protocol is not allowed to perform any
>> handshaking. The receiver is fast enough (this is know before-hand).
>>
>>
>>> Recently I shifted to Linux for this problem because I felt there was
>>> more tunability available.
>>
>> BTW: We have exactly the same problem with Linux. ;-) Only our own
>> drivers in RT-Linux give us full control, and there, it works.
>>
>>
>>> My belief is that you are tackling a problem that is ripe for
>>> optimization but you need to understand that the potential for errors
>>> or lost data will always exist with UDP.
>>
>> Yes, we are fully aware that the potential for errors or lost data is
>> always there with UDP. In fact, that's exactly what we want. ;-)
>>
>> Anyway, we do not want the kernel to "unnecessarily" throw away some
>> packets on its own. At least, we want to be informed of this process, so
>> we can react.
>>
>> Thank you for your input,
>> Spiro.
>>
>> --
>> Spiro R. Trikaliotis
>> http://www.trikaliotis.net/
>
>
- Next message: L. Spiro: "Breakpoints and ecx."
- Previous message: gregory_may: "Re: Determining if it is "safe" to send UDP packets"
- In reply to: gregory_may: "Re: Determining if it is "safe" to send UDP packets"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
