Grenville, this is a known problem primarily with UDP which affects some
low-end home routers a lot more then others.
RTT variance is really the tip of the iceberg with a number of common
symptoms and affects happening.
Some routers models are known to totally crash and reboot when they get
overloaded like this, although the more typical symptom (and complaint) is a
very small server list in the hundreds instead of thousands as expected.
I've asked several times in the past for some sort of pacing variable for
Steam server queries to help prevent UDP overloading of routers as well as a
stand-alone Steam rate that is not coupled to individual game rates.
Setting the rate in one will change the other and vice-versa which can
aggravate this (especially since some servers will attempt to change the
rate for the client).
So far I've just found it was easiest to just get another router if I happen
to find one that can't handle it - most router MFGs are unable or unwilling
to improve their UDP performance.
In a way, this is a testament to the aggressive efficiency of the Steam
Server query coding, it demands very high-end performance, unfortunately
from low-end hardware. You might liken this to having a 100page per minute
copier coupled to a sorter that can only handle 50 or 75 ppm.
Most home Modems (assuming stand-alone modems with an external router) will
perform very well, especially if they are configured in bridging mode for
static home IPs. Your paper did not appear to test the modem by itself
(bypassing the offending router) which would have been an important test.
Home routers with internal firewalls also will typically perform much worse
if the firewall is enabled.
KevinO
----- Original Message -----
From: "grenville armitage"
To: <hlds_apps@list.valvesoftware.com>
Sent: Monday, February 25, 2008 3:11 PM
Subject: [hlds_apps] Probe burstiness during server discovery
Hi,
Please feel free to re-direct me if this is off topic, but I was wondering
about dynamic behaviour I saw recently with the Steam client during server
discovery (when probing for available game servers).
I've written up my experiment, and results, online (5-pages):
http://caia.swin.edu.au/reports/080222B/CAIA-TR-080222B.pdf
In a nut-shell, the Steam client seems to send A2S INFO Request probe
packets
in back-to-back bursts that can induce brief congestion in home
routers/gateways,
potentially 'smearing' the measured RTTs a little higher than they should.
The experiment probed CS:S servers over a home ADSL2+ link (835Kbps up,
10Mbps down)
with a Steam client running in "modem - 56K" (averaging 35 probes/sec) and
"DSL/Cable > 2M" (averaging 319 probes/sec) modes. I also ran qstat with
default settings (averaging 54 probes/sec).
Figure 5 shows that, not surprisingly (given my home broadband
connection's
link speeds), Steam in "DSL/Cable > 2M" mode caused over-estimation of
game
server RTTs. But the Steam client in "modem - 56K" mode also seemed to
slightly over-estimate RTTs too (relative to qstat's estimates). Figure 6
suggests that might be due to the burstiness of probe packet emission from
the Steam client, even when configured for "modem - 56K" speeds.
Firstly, I'm wondering if my experimental results reflect reality (perhaps
someone with knowledge of the client's source could comment).
Secondly, if it is true, would it be worth modifying the Steam client to
rate-shape
the emission of A2S INFO Request probe packets? (More like qtstat's
smoother
spread of probe packet emissions.)
Thirdly, has anyone already done this kind of measurement? (I expect I'm
not
the first, and would be interested in pointers to other related published
work.)
cheers,
gja
_______________________________________________
hlds_apps mailing list
hlds_apps@list.valvesoftware.com
http://list.valvesoftware.com/mailman/listinfo/hlds_apps
