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
