I am looking to implement a system (under Windows XP/2K) that has to send or receive messages at 2.5KHz (2500 messages/second). Is this possible and does anyone know any reference code / documents that could help me in setting this up? To make matters worse each packet is ideally looking to be around 4Kwords (16KBytes) if possible. Thanks [Edited by - Lord Darkblade on October 11, 2006 8:24:03 AM]

If sending on Ethernet, this means you will fragment your packets at the link layer. However, if you have a good network, that won't matter.

16 KB times 2500 packets means about 40 MB per second, which with framing and other overhead means > 400 Mbit/s. You'll need Gigabit Ethernet cards with good drivers, and high-quality switching hardware between the source and the destination, but if you have that, this should be no big deal. (Well, if you use TCP, you also have to assume jumbo frames, else you might run into window size problems)

The main question is whether the constant flow of packets is the main requirement, or actual reliable transmission of data. If all the data has to be sent, but it's OK to jitter a bit (especially if a packet gets lost), then use TCP. If it's more important to keep sending, and a dropped packet here or there doesn't matter, then use UDP.

Other things you need to worry about include what to do with the received data (it might saturate a hard disk bus, for example), and how to avoid other Windows processes to get in the way (run on a dual-core CPU, and give yourself real-time process status).

Do you have any hints on how to get a windows client receiving data at a rate nearing that? Its constant flow (UDP) rather than lossless thats needed (though the network is very small, 5 nodes, only 2 of which can send).

Unfortunately its running on a bog standard XP machine... :(

Have you considered compressing the packets a little? I have no idea what sort of data you're sending, but perhaps it can be compressed a bit?

Is the windows machine receiving it able to handle that kind of incoming data? What does it do with it? Does it store it to a hard drive? If it does, you won't be able to keep up with the incoming packets.

Also, TCP may actually be the better bet here. While the ACKing may slow things down a tad, TCP has good flow control tools that will be useful in a setup with multiple machines transmitting an obscene amount of data. The UDP-flooding machines may block each other. Optimally, you'd want to write a flow-control system into your UDP protocol.

Finally, is the data being sent to the client machines identical? If you control the network, why not use multicasting? If you're sending to 5 machines, that'll knock the total bandwidth need down 80%.

Having more than one sender (or more than one stream) on a single gigabit network will not necessarily work, because you will saturate the network. If you have high-quality switching hardware (non-blocking, wire-rate, etc) then it might still work, as long as the sending is point-to-point. If any one machine needs to send or receive more than one stream, you're unlikely to get it to work right.

Receiving is no different from sending, really; much of the same design considerations should hold. The biggest question is what kind of processing you can do with this data, as it is a fairly fast rate -- you may get bound on things like disk throughput, or ability to upload data to the graphics card, for example.

I would try with a tight loop on a blocking UDP socket first, and if that doesn't work, try with a dual-core machine running three completion threads using the I/O completion port mechanism.

The system will be multicasting to the nodes (not that dumb :D), the data is basically all video data and cannot be compressed (a requirement :( ). The data is not stored to disk and should basically be flushed to the video card asap (though thats a different situation).

Okay, you've got 5 basic PCs, they've got XP, and 2 of them might be sending. You didn't specify whether they might be sending simultaneously, but I'll assume they can be. So, 2 senders*2500 packets/sec*16KB/packet = a max of 640 Mb/sec on the line (not counting headers + (possibly) acks. So you're still good with gigabit ethernet, technically. Honestly, your bottleneck won't be on the network itself. It'll be somewhere in the generating/packing/encoding/decoding/unpacking/sending to the video card and all the other stuff you'll have to do. Networking-wise, with very good networking hardware, over a very short distance, with no other traffic on the line, this is very doable, unless I got my math wrong.

As long as there is only one broadcaster on the network at one time, then a multicast would work. Two separate nodes trying to send at the same time would probably saturate the network in a bad way.

Note that, for video, there exist lossless real-time compression mechanisms that get about 2:1 compression on average (such as HuffYUV). If you want to optimize throughput, there's no reason not to use one of those.

Well...maybe. If the 5 are connected with a switch that can actually handle that kind of throughput, and there's no need for acknowledgement, and both senders are sending at regular intervals and not in spurts, I don't think having two senders is going to significantly harm things, although you might want to check on a network simulator. A third sender would knock you into the gigabit line, though.

If you were really crazy about it, you could install a second gigabit network for the other sender. You'd need your machines to have two gigabit ethernet cards, though. I'm not sure how much throughput your system bus could handle.

And I have to again agree with hplus that unless you're doing this as a school assignment and the assignment included "No compression, even if it's lossless" in the requirements, for the love of all that's holy lossless compress the heck out of it. It's the absolute best thing you could posssibly be doing.

I took a couple standard gaming PC's and installed some gigabit ethernet cards in them and was only able to push out 110Mbps over the network. I chalked it up to bus speed limitations on the machines, either that or it was the netgear gigabit switch. I never did get around to trying with a crossover cable.

If you want to stress test a gigabit network, you're going to need server class hardware/servers. (i.e. the ones with PCI-E slots)

If anybody has had any other experiences, please speak up. =)


-=[ Megahertz ]=-