error control and compression: modem gaming friend or foe?
tho...@netdoor.com
A co-worker of mine suggested that disabling error control and
compression may improve some modem gaming overall. The concept is
plausible although I'm a little doubtfull. A highly-interactive,
low-bandwith application could be improved by removing compression if
the compression was responsible for a noticable amount of latency.
It's also plausible that transmition errors of some degree could be
entirely acceptable for modem gaming. Does anyone have any
experimental data that would suggest whether disabling error control
and/or data compression would improve or degrade modem gaming
performance?
--
TK Harris, IT Manager (601) 969-1434
NetDoor -> http://www.netdoor.com FAX: (601) 969-3838
Anthony Hill
On 18 Apr 1997 20:21:45 -0500, tho...@netdoor.com wrote:
>A co-worker of mine suggested that disabling error control and
>compression may improve some modem gaming overall. The concept is
>plausible although I'm a little doubtfull. A highly-interactive,
>low-bandwith application could be improved by removing compression if
>the compression was responsible for a noticable amount of latency.
Compression isn't much of a factor with respect to latency,
but error control is.
>It's also plausible that transmition errors of some degree could be
>entirely acceptable for modem gaming. Does anyone have any
>experimental data that would suggest whether disabling error control
>and/or data compression would improve or degrade modem gaming
>performance?
It all depends on how the game is designed. With many games,
only a VERY small amount of data needs to be transmitted, but it's
HIGHLY dependand on latency (Doom is a definate example of this sort
of game, and I suspect Quake as the same way). In this case,
disabling error control (which also disables data compression) and
connecting at a slower speed (eg 9600bps) will give you much better
performance. Connecting at normal v.34 speeds (eg 28.8) with error
control disabled is, generally speaking, a really bad idea, since it
tends to lead to a lot of errors (which will affect both throughput
and effective latency). However, forcing connections to lower speeds
will usually result in a very low error rate, and can be useful in
latency intensive applications.
Anthony Hill | Despite popular belief, this
ah...@travel-net.com | is NOT a .sig file.
John Navas
[POSTED TO comp.dcom.modems]
tho...@netdoor.com wrote:
>A co-worker of mine suggested that disabling error control and
>compression may improve some modem gaming overall. The concept is
>plausible although I'm a little doubtfull. A highly-interactive,
>low-bandwith application could be improved by removing compression if
>the compression was responsible for a noticable amount of latency.
>It's also plausible that transmition errors of some degree could be
>entirely acceptable for modem gaming. Does anyone have any
>experimental data that would suggest whether disabling error control
>and/or data compression would improve or degrade modem gaming
>performance?
TCP/IP ping times to a local POP:
9600 No ARQ: round-trip (ms) min/avg/max = 255/257/259
14400 No ARQ: round-trip (ms) min/avg/max = 197/198/201
14400 ARQ: round-trip (ms) min/avg/max = 138/142/149
28800 No ARQ: round-trip (ms) min/avg/max = 133/142/185
28800 ARQ: round-trip (ms) min/avg/max = 113/114/116
In other words, this is yet another urban myth.
--
Best regards,
John mailto:JNa...@NavasGrp.Dublin.CA.US http://www.aimnet.com/~jnavas/
28800 Modem FAQ: http://www.aimnet.com/~jnavas/modem/faq.html
Anthony Hill
On Sun, 20 Apr 1997 19:15:07 GMT, JNa...@NavasGrp.Dublin.CA.US (John
Navas) wrote:
>tho...@netdoor.com wrote:
>
>>A co-worker of mine suggested that disabling error control and
>>compression may improve some modem gaming overall. The concept is
>>plausible although I'm a little doubtfull. A highly-interactive,
>>low-bandwith application could be improved by removing compression if
>>the compression was responsible for a noticable amount of latency.
>>It's also plausible that transmition errors of some degree could be
>>entirely acceptable for modem gaming. Does anyone have any
>>experimental data that would suggest whether disabling error control
>>and/or data compression would improve or degrade modem gaming
>>performance?
>
>TCP/IP ping times to a local POP:
>
> 9600 No ARQ: round-trip (ms) min/avg/max = 255/257/259
>14400 No ARQ: round-trip (ms) min/avg/max = 197/198/201
>14400 ARQ: round-trip (ms) min/avg/max = 138/142/149
>28800 No ARQ: round-trip (ms) min/avg/max = 133/142/185
>28800 ARQ: round-trip (ms) min/avg/max = 113/114/116
>
>In other words, this is yet another urban myth.
Now try it again when using something which DOESN'T send data
in 576 byte packets anyway. Error control is not going to have any
signficant effect on TCP/IP connections, but it can when sending one
character at a time or in very small packets, and most modem games
send data in very small packets. When data is being packetized into
chunks larger then the error control packets, then the latency issue
isn't signficant.
John Navas
[POSTED TO comp.dcom.modems]
ah...@travel-net.com (Anthony Hill) wrote:
>On Sun, 20 Apr 1997 19:15:07 GMT, JNa...@NavasGrp.Dublin.CA.US (John
>Navas) wrote:
>>tho...@netdoor.com wrote:
>>
>>>A co-worker of mine suggested that disabling error control and
>>>compression may improve some modem gaming overall. The concept is
>>>plausible although I'm a little doubtfull. A highly-interactive,
>>>low-bandwith application could be improved by removing compression if
>>>the compression was responsible for a noticable amount of latency.
>>>It's also plausible that transmition errors of some degree could be
>>>entirely acceptable for modem gaming. Does anyone have any
>>>experimental data that would suggest whether disabling error control
>>>and/or data compression would improve or degrade modem gaming
>>>performance?
>>
>>TCP/IP ping times to a local POP:
>>
>> 9600 No ARQ: round-trip (ms) min/avg/max = 255/257/259
>>14400 No ARQ: round-trip (ms) min/avg/max = 197/198/201
>>14400 ARQ: round-trip (ms) min/avg/max = 138/142/149
>>28800 No ARQ: round-trip (ms) min/avg/max = 133/142/185
>>28800 ARQ: round-trip (ms) min/avg/max = 113/114/116
>>
>>In other words, this is yet another urban myth.
>
> Now try it again when using something which DOESN'T send data
>in 576 byte packets anyway. ...
Those ping packets were 50 bytes. I get similar results at 32 bytes.
If you have different hard data, please post it.
John Navas
[POSTED TO comp.dcom.modems]
ni...@inter.nick (nick) wrote:
>
>On Sun, 20 Apr 1997 19:15:07 GMT, JNa...@NavasGrp.Dublin.CA.US (John
>Navas) wrote:
>
>> 9600 No ARQ: round-trip (ms) min/avg/max = 255/257/259
>>14400 No ARQ: round-trip (ms) min/avg/max = 197/198/201
>>14400 ARQ: round-trip (ms) min/avg/max = 138/142/149
>>28800 No ARQ: round-trip (ms) min/avg/max = 133/142/185
>>28800 ARQ: round-trip (ms) min/avg/max = 113/114/116
>
>I tried pings with results just like these. Since I didn't have
>software or hardware comression enabled, I guessed that the packets
>used for ping might be compressable. Did you have software and/or
>hardware compression enabled when you were testing? Maybe you could
>try a test with software compression on a non-arq link, one with no
>software compression over an arq+compression link, and a test with
>software compression over an arq+compression link. I could accept
>this arq+games thing as a myth..
Good points. TCP/IP Software Compression and IP Header Compression were
enabled in my earlier tests. So I re-ran my tests with a somewhat
different setup:
TCP/IP PING TIMES TO A LOCAL POP (dial-in Point Of Presence)
MODEM ERROR MODEM DATA PING TIMES PING TIMES PING TIMES
SPEED CONTROL COMPRESSION min (ms) mode (ms) max (ms)
----- ------- ----------- ---------- ---------- ----------
9600 OFF N/A 218 226 234
14400 OFF N/A 174 177 188
14400 ON NO 183 187 195
14400 ON YES 141 142 163
28800 OFF N/A 128 131 145
28800 ON NO 136 143 147
28800 ON YES 112 116 119
^^^
Tests were run with an external USRobotics Sportster 56000 attached to a
16550 serial port locked at 115200 using Windows 95 Dial-Up Networking
and the Microsoft "ping" utility (32 bytes of data). TCP/IP Software
Compression and IP Header Compression were disabled.
Zia
nick <ni...@inter.nick> wrote in article
<3362ec71...@snews.zippo.com>...
>
> On Sat, 19 Apr 1997 04:09:51 GMT, ah...@travel-net.com (Anthony Hill)
> wrote:
>
>
> > It all depends on how the game is designed. With many games,
> >only a VERY small amount of data needs to be transmitted, but it's
> >HIGHLY dependand on latency (Doom is a definate example of this sort
> >of game, and I suspect Quake as the same way).
Do you have any ideas about how Netmech fits into this scheme? I've noted
the effects of both lag and packet loss on a variety of networking systems,
and Would be very interested in your opinions.