Quick question:
What data rates are normal for ET to upload and download. After getting a lot of lag spikes recently across all servers - after 18 months of perfect connections - I have installed netlimiter to monitor uploads and downloads.
I have noticed that ET downloads range from about 5-10kB/s depending on the action on screen. The uploads seem to range from about 2-10kB/s. I noticed that roughly speaking they were about 2kB/s whilst in limbo which seems normal - since there is no reason to transmit as much to the server. Whilst playing the rates were around 5kB/s.
During one of these lag spikes when my ping raises to between 500 and 999ms for about a second or so I checked netlimiter... ET was uploading at about 10kB/s. Since I am on ADSL this is getting close to the point where my uploads saturate and hence my connection collapses causing the spikes.
From what I can figure out ET is responsible for the lag spikes so what i want to know is exactly what goes on in the server to make this happen...and if indeed it is a normal occurrence. Anyone who can tell me the range of uploads/downloads their ET goes through would be appreciated.
Incidently rate 25000, snaps 20, cl_maxpackets 76.
ET downloads and uploads
Moderators: Forum moderators, developers
min(rate,sv_maxrate) controls download
min(cl_maxpackets, <your frame rate>) and cl_packetdup controls most of your upload.
cl_packetdup does not actually come anywhere close to doubling your upload requirement.
On 2.56 and below, LAN detection is broken, so that if you are in the same class A/B/C IP block as the server, ET will assume you are on a LAN, and upload once per frame no matter what. This can quickly flood your connection.
10 kb/s upload seems excessive. My observation was that a 'packet' was about 75 bytes, including ethernet frame. At cl_maxpackets 100 (the max you can get, unless you suffer from the above mentioned broken LAN detection) this should mean an upload of about 60kbit/sec (~= 7.5kbyte). Even with ATM overhead (which can be a lot, see http://www.sonic.net/support/docs/ip-atm.overhead.pdf ), that shouldn't quite saturate a 128k upload DSL connection. Not everything goes in the 'packets' counted by cl_maxpackets, so on a 128 connection, you might still go over limit. Most home internet connection behave very poorly if you saturate the connection.
Is it possible that servers where you see this have pb screenshots enabled ? these are well known for causing lag, and take quite a bit of upload.
edit:
IP class ranges.
Class 1st Octet Range.
A 1-126
B 128-191.X
C 192-223.X.X
For ET (and most other quake3 games) to think you are on a LAN, the first octet and the following Xs must be the same.
min(cl_maxpackets, <your frame rate>) and cl_packetdup controls most of your upload.
cl_packetdup does not actually come anywhere close to doubling your upload requirement.
On 2.56 and below, LAN detection is broken, so that if you are in the same class A/B/C IP block as the server, ET will assume you are on a LAN, and upload once per frame no matter what. This can quickly flood your connection.
10 kb/s upload seems excessive. My observation was that a 'packet' was about 75 bytes, including ethernet frame. At cl_maxpackets 100 (the max you can get, unless you suffer from the above mentioned broken LAN detection) this should mean an upload of about 60kbit/sec (~= 7.5kbyte). Even with ATM overhead (which can be a lot, see http://www.sonic.net/support/docs/ip-atm.overhead.pdf ), that shouldn't quite saturate a 128k upload DSL connection. Not everything goes in the 'packets' counted by cl_maxpackets, so on a 128 connection, you might still go over limit. Most home internet connection behave very poorly if you saturate the connection.
Is it possible that servers where you see this have pb screenshots enabled ? these are well known for causing lag, and take quite a bit of upload.
edit:
IP class ranges.
Class 1st Octet Range.
A 1-126
B 128-191.X
C 192-223.X.X
For ET (and most other quake3 games) to think you are on a LAN, the first octet and the following Xs must be the same.
send lawyers, guns and money
pb screens are supposed to only upload at 1kb/sec. Actually grabbing and saving the frame can cause a spike, presumably due to HDD activity and additional CPU use. Quite a few servers with rather incorrigible admins have huge lists of useless MD5Tool checks also, again HDD access and cpu spikes. I find the MD5Tool checks to give a much worse lag impact than a pb screen grab (YMMV), but the bandwidth usage should be negligible.
Cheers guys.
I found that lowering my maxpackets from 76 to 60 has removed the problem. I guess this is because when ET suddenly doubles its uploads (why???) its no longer enough saturate my uploads.
My lagometer results when these spikes occur show the bottom line with large yellow bars (no red indicating packets lost).
So my question becomes who is to blame? Is it my ISP for suddenly dropping the standard of my connection or is it ET for suddenly (but occasionally) increase upload requirements?
I found that lowering my maxpackets from 76 to 60 has removed the problem. I guess this is because when ET suddenly doubles its uploads (why???) its no longer enough saturate my uploads.
My lagometer results when these spikes occur show the bottom line with large yellow bars (no red indicating packets lost).
So my question becomes who is to blame? Is it my ISP for suddenly dropping the standard of my connection or is it ET for suddenly (but occasionally) increase upload requirements?