GRAW net code, lag and reliability

[Stormin]

My opinion is GRAW runs much smoother since the last patch... I was able to increase the video to 1152x864, with no adverse effects... And I have a 2.4 gig machine with 1.5 gigs RAM... I had to run it at 1024x768 before.... So, you see it's getting better...

Edited August 8, 2006 by Stormin

[NOX]

I thought GRIN and UBI were going to use something other than UDP I thought I had read SCTP, but they chose UDP and TCP.

We have no idea of what is flowing where at this point, but given game developers propensity to take the easy way out in regards to Net code-I think that they are using more UDP than TCP.

Before I am called a critic-let me explain a little of what UDP is. 1st it is an "unreliable" protocol the "stack"

OK lets look at the OSI layer-when it comes to networks this is the order of operation-no and's, if's, or buts about it.

Application (7) the user-level protocol

Presentation (6) optional data formatting layer

Session (5) maintains any logical conversation

Transport (4) determines which the program on the host will receive the packet; may also handle congestion control, reliability, etc.; e.g. TCP or UDP

Network (3) host addressing, determines destination computer of the packet; e.g. IP

Data Link (2) hardware addressing; e.g. the Ethernet frame

Physical (1) the network interface, cabling, etc

We are on number 4 and some 3, but more 4.

OK UDP is not a "reliable" in quotes not because it is an opinion that I have, but is a descriptor from the technical community.

UDP-makes no attempt or effort to handle data discrepancies. if a packet sent from your computer to the server or visa versa, and is lost it is just forgotten-a big OH WELL! If corruption occures in the packet-a big OH WELL and it is dropped-but that was the big game winning head shot packet-I can see you saying OH WELL!

Another really cool thing happens when someones connection is faster than yours, they may be closer to the server have bigger internet pipe, or fewer config problems (not running the wrong firewall that is filtering on the winsock ports)-his packet gets put in front of yours-and when you get shot by that guy that ran past you or is around the corner-I know you are saying OH WELL!

These "packets" I really should be calling the Datagrams the "D" in UDP, can also be lost, thrown out ignored, orphaned and abandoned-utterly abused castigated and Humiliated-when the servers buffer is full. You ask how does this happens-well in the windows world, we use Winsock.

Here is some more really technical stuff-it hurt my head at one time as well-so here you go!

Winsock application (GRAW)

Winsock API (GRAW ASKING WINDOWS)

Specific implementation of Winsock (WINDOWS)

Protocol stack API (WINDOWS Asking internet Protocol)

Protocol stack (TCP/IP, UDP, SPX/IPX eieio asking NIC)

Hardware driver API (someplace in your machine)

Hardware driver (over at the neighbors having a beer trying

to forget all this stuff)

Networking hardware (Ethernet NIC, WiFi card, modem, etc.)

Communication medium (DSL/CABLE/T1 to the big white cloud "al gore")

OK back to Winsock-hey is starts with win so it gotta be good, and it's got the socks, just like it's brother sockets over in the UNIX house-why is it causing trouble? Well when you take 2000 server or 2003 server and drive it up to 95+% utilization, the communication buffer fills because the CPU has no free cycles to spare to clear it. Buffer fills up, you see pings registering really high and you say "hey you the guy with the modem get lost", but his connection may be a T-1 in reallity"

You may be in a server and playing with 10 peeps and 2 more show up and then lag, cheater, hacker-how come you can run and shoot me?-OH WELL!.

I started with the statement "I had read that SCTP was to be used", it is a newer protocol. TCP/ip is 50 years old? UDP is pretty old as well. SCTP or even RTP would have given the stability found in TCP and the "open ways" of UDP. OH WELL!

All caused by a huge conspiracy called the OSI model-

There is a "Microsoft tweaks" strand I started I did not realize that this post string was here or forgot that it was. I am trying to get grin to help us understand this a little more especially how they implemented winsock and timing issues with MTU (this alone can crap packets big time) and other things that I am percieving. We can make some changes at the server level to help with IO and Buffer Performance, but we need more input. By the way dedicated files will not help unless they can get the code to stop these high Utilization percentages-winsock will still have to wait until the cpu can get to it.

Ah well! things are better than a month ago, and looking up.

MS Vista is coming and our OSI layers 3&4 are going to really get an upgrade, code named "Chimeney" I hope UBI is paying attention (and our friends at Gamespy-wink wink nod nod).

NOX

Looking aimlessly for the keys to my little yellow bus!

[Colin]

Ah well! things are better than a month ago, and looking up.

MS Vista is coming and our OSI layers 3&4 are going to really get an upgrade, code named "Chimeney" I hope UBI is paying attention (and our friends at Gamespy-wink wink nod nod).

I have read some on this it will improve things for the better and long overdue too.

[BOTA:X]

NOX -

UDP is very appropriate for an online game. Packets in GRAW are time sensitive.

Take for instance, a packet that says you're standing in a particular position. It it is lost, there is no point in resending it, because you could have moved by now. It will just send the new coordinates.

Now, this can cause some sync errors. Take for instance the "auto sniper rifle". If someone doesn't get the packet that says a sniper changed from his rifle to his M9, then they will still see him holding the rifle. When the starts to shoot that pistol rapid fire, the un-synced clients will hear a sniper rifle in semi auto.

There are ways to build checks in, but GRIN must have not thought about this one. For instance, all you have to do is add a little informatoin about WHAT the client is firing when he shoots his gun.

[Papa6]

I hardly think that gamespy who's setup these free play servers will invest in better equipment. Since GRAW's release I did make a note on pings. they are always high, always have been.

only when they give you guys dedicated server abilities, then maybe things will change in that regard. I'm just amazed at how GRIN is the FIRST game EVER in my collection of software to NOT offer dedicated server abilities.

IMHO, GRAW is like windows, they threw it out there and are trying to play catch up by patching. 4 months and still no word exactly on the dedicated issue.

[Cangaroo.TNT]

Since GRAW's release I did make a note on pings. they are always high, always have been.

I find this statement odd. Not wrong, but odd. When I play GRAW, I get really low pings. My GRAW pings are the lowest I have experienced as far back as I can remember. Lower than BF2, and even lower than Black Hawk Down. And, they are consistently low. I play in AFZ most frequently. It might be their server, but I've made the same observation in every server I'm in.

Edited August 12, 2006 by Cangaroo[TNT]

[RAbbi_74]

I get higher pings to the EU servers, but typically 40's to 60's to the Dallas servers, and fairly low to AFZ, SCE, BDA, and so on. I try to avoid playing a server I ping at 100+, and still I have quite a few options...

[ToW-Angel]

I'm lucky to find a server under 100 for me... But, I think that's due to a network connectivity issue outside my home. I have a node that only gives 1 ping time on a tracert, and yet the cable company says there's nothing wrong.

Most of my pings run between 100-120 when I'm playing.

I will add that the playability for me has gotten better since the last patch though, even though my pings are over a hundred.

Edited August 12, 2006 by ToW-Angel

[NOX]

PINGS Schmings. but you are right it matters as mutch about where you sit as what you got

Angel check your splitters-if you have more than two a trip to radio shack to replace them, I have 15x2 cable and requested buz class splitters when they installed it-just higher quality components less noise.

PINGSCHMING

Try sending 8k packets to a loaded server during game in progress. 8k is the set default for a UDP packet-"datagram".

Well I guess I would rather play a time sensitive game with error control-I may only be able to play with 16, but I would rather match a game that people can trust semi-visually. I do not like being shot around corners, it means that my visual on bad guy is way off-how can you play a game like this consistently-unless you want to play a noob nade spawn fest.

And if you look back at the OSI you will note that both UDP and TCP are on the same level and both use WINSOCK-thus both suffer the burdened server syndrome. Also if Winsock is having problems, you better be using UDP, because it would really suck dead dogs if you did try to use "real" net coding solutions other than an ugly unreliable catch all like UDP.

I really do not like tracing packets coming in on a protocol that was intended to be used by such things as DNS-lol. Do not take it all as negative. The net code is pretty darn good when the server is under 10.

I like it as accurate as possible-give me next gen netcode, really big maps, great ballistics, and keep the physics (for now). I like matching and not public play, makes me even pickier than the next guy-that is my problem not GRIN's, but I am [GR] and like the ladders.

Given the need to compete I need the guys I play with to be thier best-but sometimes they got higher pings or rigs that are having trouble with winsock-this is not only a server issue but a workstation issue as well and all points to really high CPU utilization. Sockets are what they are.

NOX

All I am saying is give "Sc.P'c" a chance-it is time sensitive with error control

[}PW{ Postal]

Yeah...what ^ said...lol Way over my head but it sounds good.

[BOTA:X]

Also NOX, the CPU utilization on a dedicated server seems to be caused by graphics. The entire game has to be loaded into memory, and the server must have a supported graphics card.

I look forward to the server files that run in a non d3d window =)

[RAbbi_74]

Did I read correctly last week that the SADS will NOT require the server to have a compatable on-board GPU?

[ROCO*AFZ*]

Did I read correctly last week that the SADS will NOT require the server to have a compatable on-board GPU?

It doesn't now...

Haven't tried integrated but i know a TI4600 Ultra can server, an FX 5200 and also our current 6200. The 1st 2 can't play it but the 3rd can. All can host. Note sure about integrated as i don't have one to try.

Edited August 12, 2006 by ROCOAFZ

[RAbbi_74]

THANKS, ROCO! That's good news for anyone!

[BOTA:X]

Really? How did you get the game to open, i thought thats when it detects the vid card?

Oh well, learn something every day...

[NOX]

Also NOX, the CPU utilization on a dedicated server seems to be caused by graphics. The entire game has to be loaded into memory, and the server must have a supported graphics card.

I look forward to the server files that run in a non d3d window =)

How did you test this?

And again UPD TCP are both on the same level of the OSI-and both are serviced by Winsock, as well as every..every...every ip based program i.e. Cleint server. Winsock is and always will be in the MS world the connector to the OS and Application layer, from the stack.

I keep pointing you back to the OSI, but you keep on dodging it.

[BOTA:X]

Sorry don't have a server running to test at the moment, use to when the game ws released.

But from what I gathered the application layer is probably the slowest link in a GRAW "dedicated server". My case is this: Across my LAN I was showing about a 14-16ms 'ping' to my server. Now if I dropped to desktop and did a real ping from the command line, it was of coarse <1ms.

My point is that even in an empty server, the application layer is waiting far too long to do anything. My only explaination for this is that the bloatware we call the GRAW dedicated server is wasting CPU cycles elsewhere. Worse yet...when the server is full and CPU usage starts to raise, that 16ms premium is going to go up.

I originally replied because you were bashing UDP as the choice of protocol, which is currently the best I can think of that is supported over the internet.

As a side bar, heres a funny anomaly for you guys:

When I look at the game list on gamespy and sort by ping, I see everything in quasi-groups of pings. Example:

2 servers @ 47ms

4 servers @ 62ms

3 servers @ 78ms

6 servers @ 94ms

And those same 4 numbers, 47-62-78-94 keep coming up every time! I wish I could see a pattern or have some kind of explanation.

[NOX]

Sorry don't have a server running to test at the moment, use to when the game ws released.

But from what I gathered the application layer is probably the slowest link in a GRAW "dedicated server". My case is this: Across my LAN I was showing about a 14-16ms 'ping' to my server. Now if I dropped to desktop and did a real ping from the command line, it was of coarse <1ms.

My point is that even in an empty server, the application layer is waiting far too long to do anything. My only explaination for this is that the bloatware we call the GRAW dedicated server is wasting CPU cycles elsewhere. Worse yet...when the server is full and CPU usage starts to raise, that 16ms premium is going to go up.

I originally replied because you were bashing UDP as the choice of protocol, which is currently the best I can think of that is supported over the internet.

As a side bar, heres a funny anomaly for you guys:

When I look at the game list on gamespy and sort by ping, I see everything in quasi-groups of pings. Example:

2 servers @ 47ms

4 servers @ 62ms

3 servers @ 78ms

6 servers @ 94ms

And those same 4 numbers, 47-62-78-94 keep coming up every time! I wish I could see a pattern or have some kind of explanation.

Those pings are weird!!

Oh I agree that UDP has a place on the internet, all of the Voice over internet phone systems you will find in corporations use UDP for voice as well as three other TCP controler ports.

I went back and loaded GRAW went to the internet games menu and then verified CPU% and it ws pegged at 99%, the only time is fluctuated is when taskman updated-it is set yo real time.

Your ping variation from inside graw vs the desktop-when you ran your ping request tou were probably using CMD and it is also a real time interface to the server in XP so by default has priority over the desktop and so and so forth until you get to GRAW.

That 12 or 13ms variation is WINSOCK or better GRIN's API call to WINSOCK. Since the CPU is pegged there is no overhead for the call to take place. So you see elevated pings from within the game browser. Now get into a server with a lot of peeps and blam, and as I posted before both XP and NT server (yes it is all NT-lol) only have by default 200ms to reply. So if any of the TCP controls GRIN is utilizing to track client state run over this figure you WILL and I mean WILL smack ###### packets and the buffers, both on XP and Server will fill up because there is no CPU and they cannot catch up.

I like curve ball pitchers, but round that take a hard right around a building-only tell my that my visual lock on bad guy is way way way off and this is really not so good.

I have dealt with this before in the MS server world, all MS servers that get to 95% can start to strain, Some of the servers will smack ###### packets all day at 80%. Fortunately for me most all apps I deal with use TCP and thus will try to put packets back together and do a ACK when necessary to keep things going.

sockaddr_in or is that MSG_PEEK greetings to GRIN

NOX

[NOX]

Technologies progresses hand in hand. Faster connections make possible more amounts of data being synced over networks. That is why you could play a game on a 28 kbps modem back in the days. It has nothing to do with programmers forgetting about the noble art of net coding.

There is a setting for connection speed in GRAW, and when someone sets up a server it should be used properly for optimal gaming performance. The game will then adjust the amount of data being sent between server and clients. Take note that a server hosting 32 players must in fact have 32x the bandwith chosen in the game interface.

WOW I did not see this, and hope that you made a mistake.

32X what?

What is What for the lask of a, GRIN advised WHAT!, if what is =128x32 then it is <than what we got. And is not 512 as stated in the game briefs on release.

NOW if WHAT is =to <50ms then we have a memory demand per socket request of 16k (memory I could be wrong)

How many open sockets are you requesting visa vie client/server on top of UDP?

Can we decrease from 8k and 200ms on TCP-which I think you are you using for chat and game stats?

sockaddr_in or is that MSG_PEEK greetings to GRIN

NOX

[NOX]

Matter of fact why not create net code for MATCHING-take this to UBI.

Create distributed code for intra-clan, all clients of a clan are using distributed code- the host server would be itself a client of the distribution. Members of the clan or group distribute task and then communicate to the opposiing clan via the clan gateway or " clan server"

Only the servers one from each clan would pass data "inter" all cheats could be captured here. And if one clan is out of spec at the client level only that clan suffers ie bad configs and high pings or cheats-or yiu will loose until you fix it.

Your TCP would be be between the two servers and NO wide area UPD, many clients to one relationship. We know that object are not tracked via TCP, I can move cans and you see them as they were at map start (thanks ROCO) so you are using UDP and your physics are srewed.

NOX