Re: how to control UDP sending Speed?

On Sat, 17 Mar 2007 10:54:51 +0800, Victor <vvhh2002@xxxxxxxxxxxxx> wrote:

Thanks, Pete
I just want program a UDP stream sending application for a IPQAM device that
is needed by Digial TV VOD Broadcast system.The speed of my server and a
IPQAM device is 10000Mbps.
The IPQAM device only can accept a constant bit rate udp TS(mpeg2 transport
stream) data stream for broadcasting TV.

What is the network configuration here? Does the IPQAM device receive the UDP datagrams directly? What is its relationship to the sender? Are they on the same computer? On the same LAN? Or communicating over the Internet and/or some other telecommunications link? Does the sender get any feedback whatsoever regarding the state or status of the IPQAM device, and/or any other components in the network involved in transmitting the data?

What does it mean when you write "only can accept a constant bit rate UDP TS data stream"? I ask, because there is no such thing as a genuinely "constant bit rate UDP stream". UDP isn't stream-oriented in the first place, and as a protocol that's part of TCP/IP there's definitely no ensuring that the UDP datagrams arrive in an exact frequency (for that matter, UDP doesn't guarantee delivery, doesn't guarantee unique delivery, and doesn't guarantee in-order delivery). It seems likely to be that if the IPQAM device is actually receiving the UDP datagrams directly, it *must* have some sort of buffering. So you shouldn't really need for the transmitted datagrams to be sent at a perfect delivery sequence. They just need to arrive fast enough to keep the IPQAM device's buffer(s) filled (or nearly so), without going too fast (causing UDP datagrams to be dropped).

If the IPQAM isn't receiving the UDP datagrams directly, then obviously there's some other component that is and is passing them along. That other component should be able to do the buffering and even out the flow of data to the IPQAM device proper.

Keep in mind that I have no idea what an "IPQAM device" is. :) All I know is what you've written here, which is that it's some sort of video receiver that uses UDP.

As far as your implementation goes, I would offer a few thoughts: one is that you probably don't need the high-resolution timer, since network i/o is a) not that granular anyway, and b) operates in the realm of milliseconds, not microseconds. The second is that rather than looping, it would probably make more sense to just sleep for a given number of milliseconds. This will avoid too much CPU overhead and weird thread starvation bugs (which ironically can cause your network i/o to become more irregular, even as you are trying to even things out and reduce it). Yes, it's true that the Windows thread scheduler does not guarantee that you'll be woken up exactly after the time you specify in Sleep(), but as long as you are calculating a new wait interval each time (and it appears that you are), then you'll be pretty close and will maintain a proper average with a minimal of overhead.

It seems to me that if you send an amount of data with each interval that is somewhere between 10% and 50% of the IPQAM device's network i/o buffers, while at the same time ensuring that you are waiting for some reasonable amount of time (ie tens of milliseconds), things ought to work reasonably well. Of course, these two parameters may not be mutually compatible, depending on how large the IPQAM device's buffers are. You may have to fiddle with the specifics to get something that works just right.

As far as the question of writing your own network driver goes, I don't really know. You'll have to learn all about the low-level definitions of UDP and IP (on which UDP is built), as well as the intracacies of driver development under Windows (see the Windows DDK). I think that the network driver is a user-mode driver, which should simplify things, but I'm not sure about that, and even if it is, you still have the issue of interacting with the network hardware driver at a lower level. Bottom line is that it's gonna be complicated if you go that route. The other thing is that even if you develop your own driver, you may not have control over the network components between your driver and the IPQAM device. Just because you send data out at a perfectly regulated interval, that will not ensure that the data arrives at the device at a perfectly regulated interval. The best-case scenario will be where that device is actually on the same computer, and even there the way that i/o happens on Windows will prevent you from achieving a perfectly regulated delivery.

And of course, I will reiterate: unless you are sending data one byte at a time, the blocks of data you send are still going to be transmitted at the nominal rate of the network connection. If you are sending 1K blocks once per second, then that will achieve a 1K/sec data rate, but each 1K block is going to be sent at whatever rate the network is (100Mbps, for example).

Since I don't know what an "IPQAM device" is, I cannot comment with much authority on its design. But, assuming it is designed to be even minimally aware of TCP/IP networks, there should be no reason at all that your data has be sent at *exactly* some rate. TCP/IP networks just don't work that way, and so the designers of the device surely have anticipated this and provided for some buffering to allow for somewhat uneven delivery. You should be able to target an average, and as long as you do that correctly, things should work fine.

If I were you, I would look more closely at the implementation of the average solution first, to see if it can be improved, rather than diving into a much more complicated proposal such as writing your own network driver.

Pete
.

Relevant Pages

  • Re: UDP packets are dropped by the PIX
    ... >>personal use of city property. ... 165.155.0.0/16 is the public schools. ... >available recommended standard, IPSec, relies upon UDP. ... have access to some network stuff, even though I'm a network guy. ...
    (comp.security.firewalls)
  • Re: polling an intranet for a device type
    ... The form has a UDP component, with a reomte host of 255.255.255.255 ... You've probably guessed from posts that I'm new to Socket programming, ... I'm looking to collate a list of specific devices on a network by sending ... an individual socket connection? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Kerberos UDP vs TCP
    ... Various network devices and improperly configured network cards are what I most often see screwing up the UDP packet delivery. ... TCP does add a good amount of overhead and I would recommend doing a network impact study before considering switching whole hog to TCP. ...
    (microsoft.public.security)
  • Re: send(2) does not block, send(2) man page wrong?
    ... >> can't drain the data fast enough. ... >> blocking and releasing would be a little bit harder to do for UDP. ... Which is the same result as you would get if the bottleneck is just one ... network hop away instead of at the local NIC. ...
    (freebsd-hackers)