3 replies to this topic

[Mordynak]

Evening all.

I noticed today that I'm getting a lot of lag and really severe rubber banding.
Normally I only tend to get it bad in EU and OC. US being fine. (Odd in itself as im in the EU)

I opened up the task manager to see if anything was using the network. Only to find that MWO is using 72kbps....

That is ridiculously high. Even for a game with as much going on as MWO.


Anyone else mind posting how much data is being sent when in a match?

Cheers all.

[Tibbnak]

Transfer rate isn't really something to be worried about because that's probably burst traffic, especially since it is rare to have a proper easy to use tool that doesn't average over a time period and gives the exact usage rate for the driver on a high resolution.. What you should probably be more worried about for a multiplayer game is throughput and sustained traffic.

Personally, considering MWO comes bundled with a standalone version of ts3 that runs in the background, it isn't really that bad.

Over the last week of playing on and off, I have 47 megabytes total worth of upload attributed to the mwoclient.exe and 682.4 mb of download. Half of that is attributed to loading HTTP requests; probably the ingame browser and the various shop bits and interface that load every time you leave a game and go back into the lobby. (It's possible their built in browser doesn't keep a cache and loads from scratch every time you load in)

Just did a test on the download incoming. Oddly enough, loading into the login screen from steam is about 2.5 MB of HTTP requests, logging in is another 2.3 MB of HTTP and about 400KB of TCP/ip data, Queing up for quick play and getting to the voting screen is a very miniscule amount of tcp/ip data

Loading into a map starts minesquel but then works up to about 200 KB of data, In the lobby waiting, MWO's using about 3KB/s down and 1KB/s up. Ramps up to about 10KB/s when you start running around in a match.

It probably would go up if anyone bothered to use voice chat on my team, but sadly nobody did the round I played. Knowing how the protocol TS uses works, it probably wouldn't increase it much more than 20KB/s unless it was a really busy voice chat.
Loading back into the menu from a game takes another 2.4 megabytes of data over HTTP and a small amount of TCP/ip traffic. In total this exercise used 11.7 MB of data download.

If you are registering constant throughput of 70KB/s+ from MWO then it's possible the combined teamspeak dll glitched out or is sending an unusual amount of data. Try disabling voice chat and playing a match and seeing if that helps any?

Edit: another possibility is packet loss or line loss. If your connection or anything inbetween you and the server have enough of a delay or halt in traffic, you can trigger a retry packet. Over time or with a high enough lossy connection these can add up and magnify any usage. Common causes of this could be electrical problems or other radio sources causing interference on wireless bands, physical barriers, having a subpar residential router with shoddy routing firmware that takes to packet fragmentation like a frog to water, or if you are using a completely wired connection, possibly congestion or subpar routing on your ISP or their peering network's end.

Edited by Tibbnak, 14 October 2016 - 09:48 AM.

[D V Devnull]

Folks, Lag and RubberBanding have NOTHING to do with Packet Size. The only thing that causes those issues is how fast the Packets are actually being transferred as whole items, a time (known as "Ping") in which the shorter and lesser is better, which comes down to issues with delays caused by Routers and ISPs on the internet. Please avoid confusing Bandwidth (Max. Data Size) with Speed (Ping/"Time for Packet Transfer") when you're talking about Lag/RubberBanding!!!

~Mr. D. V. "Dealing with Ping Time since well before MWO existed..." Devnull

[Tibbnak]

D V Devnull, on 14 October 2016 - 11:09 AM, said:

...[HERP DERP]...

Thank you for contributing nothing besides a factually incorrect complaint and also revealing that you didn't even bother reading any of the posts in this thread beyond a quick skim.

If you'd bothered, you might have noticed the OP referring to RATE OF PACKETS RECEIVED IN BURST possibly being an issue, and the reply referring to RATE OF PACKETS RECEIVED IN BURST possibly being not a proper metric, and also a quick test to see a single usage case, and a possible short diagnosis.

If you also bothered to even have any sense of an idea of what you were talking about, you might have realized that:
1) Your conflation of the shorthand technical term "Ping" with the unfragmented max TCP window is incredibly disturbingly ignorant.
2) Your extremely basic and qualitative understanding of latency and routing is disgusting
3) You fail to mention that Lag/Rubber banding comes in many forms, and not all of them network based. Some of them could be internal to the server. Others a miscommunication between the client and server, say if the map's navigation mesh (or cryengine equivalent) was compiled incorrectly and the server experiences a hiccup when it predicts your state straight into a wall and then quickly tells the client that "the client's movement is incorrect" and "here is a new position", to which the client (having not errored and technically still in the 'past' in terms of rewind state) is set to exclusively trust the server and resets your position back to what the server (falsely) thought was the proper location. Thus causing a rubber band with no network issues involved.)

Frankly I find it irresponsible that you appear to even think you have a viable opinion on anything related to internet communications and I would suggest you henceforth cease giving any opinion on it until you become far more educated. If you state your terrible and misinformed opinion enough on the internet then people might mistake it for factual information.