Quote:Original post by John Schultz
Your test/benchmark sounds cool: if you could post your benchmark(s) showing that (overlapped I/O+) IOCP+threaded(+MP, etc.) does something extra-ordinary for UDP in Win32, including a means to compare with single-threaded standard UDP sockets, network developers would be interested in running the benchmark (I can test on various Intel/AMD/MP hardware).
As promised here's the link to the source/exe's
http://www.phxsoftware.com/files/udptest.zip
I ran the tests a few times both local-loopback on 127.0.0.1 and between two machines (one an old Duron 950 and the other a dual 2.2ghz Xeon). Someone with better machines and more time than me can fiddle around and come up with better tests of course. Personally, I couldn't really find a scenario where one worked better than the other except in the dual-xeon, where IOCP performance should theoretically be superior to the single threaded approach. However, since I was sending from the old AMD machine, the xeon was able to happily keep up even on the 100BT network with minimal effort (total CPU usage in the 0-2 range) on both blocking and IOCP tests. I would've liked to run multiple senders on multiple machines to a single receiver to see how that fared, but I didn't have enough machines handy.
Still, the little 950 Duron was able to receive ~115mbits/sec on my 100BT network without any packet loss on both tests. Generally speaking the larger the packet, the better the throughput (up to the fragmentation threshhold of course). The 115mbit/sec number was based on 1200byte packets sent 100,000 times.
The readme.txt is as follows:
-----------------------------
UDP sender/receiver test
This project is a quickie project I wrote to make some rough comparisons
between IOCP and straight blocking winsock calls.
It was compiled with Visual Studio 2003.
UDPTEST_IOCP
This version uses an I/O Completion Port framework I wrote a long time ago
and am no longer using in my current IOCP socket projects. However, it was
the socket code and framework I published on CodeGuru and didn't have any
legal restrictions on it, so I decided to use it for this test.
UDPTEST_BLOCKING
I tossed an extremely rudimentary UDP class into this project, and implemented
only the bare necessities to build up and tear things down. It uses a single
thread which blocks on recvfrom() until the socket is closed and the
thread terminates.
USAGE
RECEIVING:
The command-line for receiving packets is:
UDPTEST_XXX <port # to listen on>
In receiver mode, the main thread sleeps for a fixed 15 second timeout. The
sender must be finished sending before the 15 seconds are up. Once they're
up, the program spits out how many packets it got and how long it took to get
them. The actual packet performance timer begins when the first packet is
received and ends when the last packet is received (or the 15 second timeout
occurs, whichever comes first).
Example (listens for incoming packets on port 2525)
UDPTEST_IOCP.EXE 2525
SENDING:
The command-line for sending packets is:
UDPTEST_XXX -c <count of packets> -b <byte size of packets> -s <ip addr dotted form> <port # to send to>
In send mode, the program immediate starts sending -c number of packets of
size -b bytes to the ip address and port specified in the command line. When
finished it will report the number of packets sent, the bytes sent, and how
long it took to send the packets.
Example (sends 50,000 packets 1,200 bytes long to loopback address on port 2525)
UDPTEST_IOCP.EXE -c 50000 -b 1200 -s 127.0.0.1 2525
Robert Simpson
mailto:robert@blackcastlesoft.com
