Jump to content

  • Log In with Google      Sign In   
  • Create Account


MMORPG and the ol' UDP vs TCP


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • This topic is locked This topic is locked
69 replies to this topic

#61 PlayerX   Members   -  Reputation: 279

Like
0Likes
Like

Posted 05 June 2005 - 07:04 PM

Quote:
Original post by anonuser

Being "good enough" is what caused all the server problems with WoW. GW is not really an MMO, it spawns an instance of the world for each player / group so I imagine a lot more is left up the client in the case of GW, though I can't really be sure.

WoW is notorious for server problems.

Again as an tribute to AC, AC servers were rarely down and besides over populated places (sub in pre-marketplace days) you'd not notice any lag.


WoW has an order of magnitude more players than most of us, indie or not, can hope to get. I think it's premature to blame that on TCP.


Sponsor:

#62 hplus0603   Moderators   -  Reputation: 5165

Like
0Likes
Like

Posted 06 June 2005 - 07:17 AM

Quote:
WoW has an order of magnitude more players


Be careful to separate number of players per shard ("server") from number of players for the game, total. Even a successful indie usually only runs a single shard, and can probably get the same number of players on that shard as you'd get on a single shard for a commercial game.

As an example, A Tale In The Desert is a fairly successful, indie MMOG.

#63 PlayerX   Members   -  Reputation: 279

Like
0Likes
Like

Posted 06 June 2005 - 12:14 PM

Maybe it's their backbone network being overloaded. The trouble is we just don't have the information as to why their servers are struggling. They aren't saying. My point was, it's presumptive to blame all their problems on their use of TCP. Until they tell us, we just don't know.


#64 rmsimpson   Members   -  Reputation: 228

Like
0Likes
Like

Posted 07 June 2005 - 06:55 AM

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



#65 Megahertz   Members   -  Reputation: 285

Like
0Likes
Like

Posted 07 June 2005 - 01:10 PM

Here's what I got on 3 test runs ( I actually ran about 15 with similar results). From a glance it looks like the iocp version performs very poorly.

BLOCKING

Reciever

D:\Old D drive\udptest\udptest\udptest_blocking\release>udptest_blocking.exe 7000
Listening on port 7000
Received 100000 packets in 3758ms

D:\Old D drive\udptest\udptest\udptest_blocking\release>udptest_blocking.exe 7000
Listening on port 7000
Received 99703 packets in 3766ms

D:\Old D drive\udptest\udptest\udptest_blocking\release>udptest_blocking.exe 7000
Listening on port 7000
Received 99860 packets in 3769ms

D:\Old D drive\udptest\udptest\udptest_blocking\release>




Sender

D:\Old D drive\udptest\udptest\udptest_blocking\release>udptest_blocking.exe -c
100000 -b 1024 -s 127.0.0.1 7000
Sending 100000 packets size 1024 bytes to 127.0.0.1 port 7000
Sent 100000 packets (102400000 bytes) in 3758ms

D:\Old D drive\udptest\udptest\udptest_blocking\release>udptest_blocking.exe -c
100000 -b 1024 -s 127.0.0.1 7000
Sending 100000 packets size 1024 bytes to 127.0.0.1 port 7000
Sent 100000 packets (102400000 bytes) in 3766ms

D:\Old D drive\udptest\udptest\udptest_blocking\release>udptest_blocking.exe -c
100000 -b 1024 -s 127.0.0.1 7000
Sending 100000 packets size 1024 bytes to 127.0.0.1 port 7000
Sent 100000 packets (102400000 bytes) in 3769ms

D:\Old D drive\udptest\udptest\udptest_blocking\release>





IOCP

Reciever

D:\Old D drive\udptest\udptest\udptest_iocp\release>udptest_iocp.exe 8000
Listening on port 8000
Received 71247 packets in 3692ms

^C NOTE: HAD TO CTRL-C HERE CAUSE THE PROGRAM WAS HUNG.


D:\Old D drive\udptest\udptest\udptest_iocp\release>udptest_iocp.exe 8000
Listening on port 8000
Received 70699 packets in 3691ms

D:\Old D drive\udptest\udptest\udptest_iocp\release>udptest_iocp.exe 8000
Listening on port 8000
Received 88184 packets in 3733ms

D:\Old D drive\udptest\udptest\udptest_iocp\release>



Sender


D:\Old D drive\udptest\udptest\udptest_iocp\release>udptest_iocp -c 100000 -s 1200 -s 127.0.0.1 8000
Sending 100000 packets size 1024 bytes to 127.0.0.1 port 8000
Sent 100000 packets (102400000 bytes) in 3691ms

D:\Old D drive\udptest\udptest\udptest_iocp\release>udptest_iocp -c 100000 -s 1024 -s 127.0.0.1 8000
Sending 100000 packets size 1024 bytes to 127.0.0.1 port 8000
Sent 100000 packets (102400000 bytes) in 3689ms

D:\Old D drive\udptest\udptest\udptest_iocp\release>udptest_iocp -c 100000 -s 1024 -s 127.0.0.1 8000
Sending 100000 packets size 1024 bytes to 127.0.0.1 port 8000
Sent 100000 packets (102400000 bytes) in 3731ms

D:\Old D drive\udptest\udptest\udptest_iocp\release>


#66 rmsimpson   Members   -  Reputation: 228

Like
0Likes
Like

Posted 07 June 2005 - 02:09 PM

One of the reasons I ditched the old IOCP framework and rewrote it in subsequent code is because it was a little too bulky and had a couple issues I was never able to satisfactorily resolve - hence the freeze you saw.

Also, it doesn't detect hyperthreading - so if you run the IOCP version on a hyperthreaded machine, it'll make too many threads and slow things down. I should probably modify the IOCP version to add a -t switch to control the number of threads that get created.

What are the stats on the machine you ran the programs on?

Robert


#67 Megahertz   Members   -  Reputation: 285

Like
0Likes
Like

Posted 07 June 2005 - 02:16 PM

Intel P4 3.4GHz HT processor
Asus P4C800-e motherboard.
Netgear FA310TX ethernet card

We'll if you say there's an issue running on HT's cpus then I think that probablly explains the poor performance.


-=[ Megahertz ]=-

#68 John Schultz   Members   -  Reputation: 807

Like
0Likes
Like

Posted 07 June 2005 - 04:27 PM

ASUS P4C800-E 3.2Ghz HT, Intel CSA (Gigabit, non-PCI bus)

(Used same params as MegaHertz)

Blocking:

2583ms, 2611ms, 2577ms (no loss)

IOCP

2728ms, 2658ms, 2730ms (no loss)

ASUS P2B-DS, Dual PIII 700

Blocking:

2343ms, only 8527 packets received (similar on other runs).

IOCP

4782ms, 85770 packets received (similar on other runs).

Across the wire, between machines, the IOCP receiver (MP box) received ~60K vs. ~40K packets for blocking.

Thus, it does appear that on a multiprocessor system, with this benchmark, IOCP can be a win for UDP (I would perform more varied benchmarks before committing to IOCP for a commercial project).

Thanks for posting the benchmark!

#69 Afr0m@n   Members   -  Reputation: 100

Like
0Likes
Like

Posted 18 June 2005 - 10:28 PM

Why hasn't this thread been stickied? :(

#70 hplus0603   Moderators   -  Reputation: 5165

Like
0Likes
Like

Posted 20 June 2005 - 01:47 PM

I generally don't sticky threads. However, I'll put a link to it in the FAQ. To avoid infinite necroing, I'll close it -- if you need to ask about any concept in here, I think that question deserves a new thread :-)




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS