Quake 3 on a 56K modem sucks!

[Barbarella]

hi,

i use a 56k too at 44000 bps and i currently have 5 to 10 server at 141 and a lot of 169.

What are your MTU and RWIN settings ? If you don't know then try MTUSPEED PRO 4.1
http://www.mjs.u-net.com/mtuspeed.htm

use 'optimum settings'

it will boost your connection.

Now you have to creat a connection that use 'software compression'. The 'how to' can be found at savageuk.com

After that reduce your maxfps to 30 to 40, i use 35 : cg_maxFPS 35
Because there is a direct relation between snaps and maxfps. I use a snaps of 28.

[xortam]

Thanks Barbarella for the new info. I'm in the middle of removing and reinstalling my modem and making sure its still up to date. Things were a bit of a mess because I had switched between serial and USB connections (and back) on this modem. I had a PNP and USB modem installed on the same COM1 port (two drivers, one modem). Its now cleaned up and I'm currently testing with the USB connection and only have the one modem installed on COM3. Doesn't look like it made any difference as I still get poor performance. Like you, I had seen the same number of low ping servers once before (at time of 19 January 2000 05:31 post) so I know its possible (unless it was just a temporary lull in the network). I was starting to look at NetMedic that came with the 3Com modem. Anybody have luck with this? I've downloaded MTUSpeed and will check it out after I've done some more testing.
As far as compression ... I don't think I can run w/o error control and compression checked ... I get auth errors in this case. I thought I was running this way before but it now looks like I wasn't. Apparently, the modem settings in the modem control panel are different than the modem settings in DUN. I believe the DUN settings (modem configuration under connection properties) override the control panel settings. Can anybody confirm this? I've got to retest this now that I reinstalled the modem. I'll keep everyone posted if I haven't slit my wrist by then.

[xortam]

Well I've tried every which way but loose and I still get get my pings lowered. My ISP requires that I set Error Correction but I can disable hardware compression. Apparently, the ISP doesn't support software compression (doesn't show up in detailed status window) and it appears to perform the same w/ or w/o hw compression. I did the MTU ping test and set my packet size to small (548). Didn't help. I read that Win98 "automatic" setting defaults to "small" anyway. Ran the MTUSpeed tool and it optimized for 548 as well. Applied the registry settings and it still didn't help. This is getting old and I'd probably be better off putting my efforts towards getting another DSL line installed. The frustrating thing is knowing this should be better.

[Barbarella]

hi,

MTU is not all, i use a MTU of 576(recommanded value), but you have to set the rwin to 2144.

(MTU - 40) * n = Rwin. MTU = 576 and n = 4. The 40 is the IP header (can't be change)

Try this number.

Be carreful with USB modem and O/C. If you O/C make your test first without O/C.

With software compression i get an 150 to 250 ping but with hardware an 200 - 300.

Another thing that can help you. Having a high connection speed do not mean the best connection. Well, sometimes a can connect to 49333 bps but i got a lot of time out. Slower connection are better for access time

Look your lagometer, if you got a lot of red line try a slower connection like 45333 or 44000.

To set the speed connection i use the AT command &N29 (for 44000). I have a Us-Robotics 56K professionnal message modem. Look at your manual.

[xortam]

Thanks for all the info Tumu, but I've tried all of this and I think the problem is the ISP. ATT has definitely degraded the network since they've taken it over from IBM and I have been considering switching anyway. I don't know if IBM allowed larger packets and software compression before but at least they were extremely reliable. My wife's company is getting more stringent about how their home DSL lines are being used and it looks like its time to get my own. Its nice having them manage the firewall and protecting my machine but it does limit what applications I can run. The curious thing about the modem is that I did once see low pings like Barbarella saw ("5 to 10 server at 141 and a lot of 169"), but I haven't seen that since.

Barbarella, First of all, as my original post shows, I'm not overclocking anything on my system (yet). Secondly, what I was trying to say in my last post is that both MTU and RWIN (among others) were set by MTUSpeed. I first ran the ping tests that Tumu referred to and which are documented here on the SavageUK site. I pinged the empty Q3 server that I've been testing on. That test determined that my ISP would fragment messages larger than 548 thus directing me to use an MTU of 576. I also read (again confirming what Tumu said) on Lynn Larrow's Place that Win98 defaults the IP packet size to automatic (which is what I originally had) and that equated to the "small" setting which represented an MTU of 576. No wonder that changing this setting didn't have any effect on my performance. I then ran MTUSpeed and applied the "optimal settings" which also reported an MTU of 576 and an RWIN of 2144 (4 packets): I didn't notice any difference after this change as well. Today, I'll check over my current and old registry values and see exactly what MTUSpeed changed (if anything).

Tumu, I'm a little concerned over Win98 compatibility with MTUSpeed. I guess I'll know better when I compare my old and new registry. If I understand you correctly, MTUSpeed will set up RWIN and your other registry values fine, but not MTU, which should be set manually through the dial-up properties in the networking control (just be sure MTU matches in MTUSpeed). Is that right? MTUSpeed optimized to disable PMTUAutoDiscovery and PMTUBlackHoleDetect already so no change there. I already had checked that as I believe the Lynn Larrow site mentioned those settings. As far as compression, this is what has confused me. Going in, I had thought that hw compression would yield better results. Everyone started mentioning sw compression but I didn't know why that would actually improve things. I haven't done any on-line gaming (unless you count Snipes on an old NetWare network 13-14 years ago) so I'm going with what the gamers are recommending (notice what Barbarella reports). Again, apparently my ISP doesn't support sw compression anyway and I didn't notice a difference w/ or w/o hw compression: I'll do some more comparisons changing the hw compression setting. I don't have any choice about enabling error correction as my ISP won't auth w/o that enabled. My ISP specifically supports my modem for 56K transfers (V.90) and they state that I can get up to 33.6k uploads. Maybe NetMedic will verify this info for me. I'm going to perform the line noise test (ATI6) that ATT mentions and test with my other voice line and another local POP. I'll also check out your 56K site some more. What do you think of Barbarella's recommendation about capping the connect speed? I've been connecting fairly consistently at 50,666. It sounds like I could smooth things out by reducing the speed, thus reducing the amount of error correction (hw) but this would raise my pings.

[This message has been edited by xortam (edited 24 January 2000).]

[Tumu]

Duh.

I have been reading this thread for a while and some suggestions given by people are totally incorrect when it comes to gaming..

Ok, let's deal with issues in hand one by one:

MTU: Win95 with DUN 1.3 and Win98 use default MTU of 576 octets. If you want to change it, you will have to go into Control Panel and Network settings, take Dial-Up Adapter properties and go to the last leaf, where you can find IP Packet Size setting (Also you can set Enable Point to Point IP to No, if you don't use anykind of Dial-Up Server. It lowers latency a bit). By default it is set to Automatic what means that connection speeds under 128Kb/s, MTU is set to 576 octets. If connection speed is over that, MTU is set to 1500. Well, in case of modems, the connection speed will not be over 128Kb/s, so MTU is set to 576. To force Windows using larger MTU, set it to Large which is 1500 octets. Medium is about 1000 octets and it's not good either. Only 1500 octets is good for gaming as packet fragmentation (larger packets divided into smaller ones), which happens if using smaller MTU, can cause continous packet loss when some fragments get lost. Afaik, QW, Q2 and Q3 can send near 1500 octets of game network data and if MTU is set to 576, those data packets will get fragmented. If your ISP doesn't handle MTU's larger than 576 octets, then complain to them about it. If they ignore your complains, switch the ISP because it will never be good for gaming. You can test for packet fragmentation by first setting the IP Packet Size to Large and pinging some gateway or host in your ISP's network with "ping -f -l 1472 address". Refer to the ping-command documentation about those parameters.

MTUSpeed: This program is designed for Win95. The MTU setting in this program DOES NOT work with Win95 with updated DUN 1.3 or with Win98. The other settings (RWIN and Registry page) do work fine and it's quite good program for changing those parameters quickly. Though if you want to change the RWIN, you'll have to specify the MTU too, but you can set the MTU to 1500 as in Dial-Up Adapter properties to get the proper RWIN values. Also, if you use the Dial-Up Adapter properties to force the MTU size, you should disable PMTUAutoDiscovery and PMTUBlackHoleDetect in the MTUSpeed's Registry-leaf. That way you can ensure that your modem link to ISP doesn't cause unnecessary packet fragmentation.

RWIN: This is called receive window and it's for setting the amount of data which gets received before it's acknowledged. Optimum setting is about 3-6 times of MRU depending of connection speed and ISP. ISDN users can set to even higher than 6. MRU (maximum receive unit, maximum amount of user data in a packet) is calculated from MTU by reducing MTU with 40. MRU = MTU - 40.

Compression: In normal cases, you should disable any kind of software compression and stick to hardware based compression. But, if you have a computer with enough CPU power, you can try turning off hardware compression and switching to software one. ISDN doesn't do hardware compression, so if you need compression with ISDN, you'll have to use software compression. Though compression will make some latency to data stream, so you'll have test how much it does affect the ping times in different games.

Error correction: This should be enabled because it helps keeping those packets uncorrupted.

33.6K vs 56K: Often a 56K modem can have over 40K download speed, but the upload speed may be 28.8k or in best case, 31.2K. What that means is a 33.6K modem has greater upload speed (33.6K) than 56K modem. Depending on game, the upload speed can be more important than the download speed. With most modems, you can force the modem to V34 speeds with an AT-command. http://www.56k.com/ has some modem models covered.

Maybe these will help somewhat,

.Tumu

[Tumu]

xortam, MTUSpeed, as it is designed for retail Win95 versions (read: it's old and hasn't been updated for a while), doesn't know that DUN 1.3 update and Win98 uses different registry keys for MTU setting. If you take RegEdit and head over to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\Class\Net\ and pick out the right class key for your Dial-Up Adapter you'll find that old MTU registry key which MTUSpeed modifies. The old MTU key is the root IPMTU. The new MTU settings are in Ndi\params\IPMTU\ sub folder. The (default) setting is the one which the DUN 1.3 respects. Though if you change it manually to other values than the Automatic, Small, Medium or Large, you'll have to add a key or change existing one for it to the enum\ sub folder.

The receivewindow keys and others are in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servic es\VxD\MSTCP\.

The receivewindow should always be a multiple of MRU. I don't know what the Windows TCP/IP stack will do if it's not, but I guess it will start acknowledging packets as soon as the limit is hit (in middle of a received packet thus leaving one packet not acked until next limit hit).

And for the technical details of software compression against hardware compression is that modems don't do bit by bit or byte by byte compression. They do block compression and what that means is modems can and will wait (for little while) for a block to fill up before compressing it and sending it down the wire. But if you have a fast computer, the software compression will function much faster and with less latency between blocks of compressed data than the hardware based because the hardware based compression speed is limited by com port speed. Using hardware compression, the uncompressed data has to be sent thru the com port to the modem before it can be compressed. Also software based compressions can use bigger compression buffers and hash libraries which achieve better compression ratios. And they can be optimized to handle the crucial parts of internet protocol. Hardware based compressions don't know anything special about the data which is to be compressed.

Error correction and high speed modem connections are two things that can make a speedy connection crawl. If the modem tries to keep up too high speed connection, the error correction will have to either fix the broken data or ask for retransmission of the data (yes, error correction does retransmissions too). And if were dealing with gaming application which is designed to compensate for lost packets, the retransmission of broken data can take too much time and it will be seen in the latency. And what makes this special is that the internet packets can be large and the retransmission done by the modems can happen many times during one packet (because modems don't have big buffers, so the data has to be divided into smaller blocks, so that compression and error correction can be applied).

The "ping -f -l size" command will give errors when you try to go over the currently set MTU. Actually the value which you give to ping-command will be little lower than MTU because the -l parameter specifies only the amount of user data. The entire packet has also headers included. So, 1472 octets is the largest amount of user data which can be sent (or received) unfragmented with a MTU of 1500 octets.

I hope this will clear things out,

.Tumu

[Barbarella]

hi,

thanks tumu i learn a lot. It's truth that my informations were quiet old.

I have tried some of your suggestion :

1) running in 33600 to see how quake3 run with a better upload (my 56K give me only 28800 in V90 protocol). Well the ping was good but i was unable to play even with new values for snaps, rate, .... too many timeout.

2) Mtuspeed don't handle the DUN 1.3. You're right. Only the RWIN can be change. To change the MTU i use TweakDUN 2.23. The évalution version can change the MTU but not the RWIN
http://www.sysopt.com/maxmtu.html

3) I test a MTU (*4) of 1500. Bad result with
Quake3 but excellent for downloading big file


Xortam i don't have any news ideas. I hope you will find out what's going wrong.

[xortam]

Thanks for the update Tumu. I was in the process of checking my old and new registry settings when I caught your response. The registry looks fine. I was also referencing the MSFT tech note on the protocol settings. Your previous post alerted me to the fact I ping tested with the small packet setting. That thought had crossed my mind during my testing but then those grey cells suddenly died. I went back and retested and found that my ISP will route large packets intact (the DSL line couldn't handle above medium). I've currently got MTU set at 1500 and the RWIN set to 4x (5840). Like Barbarella, this made Q3 perform worse. I've got some other areas that I need to pursue. I tried the AT commands (ATI6 and ATI11 for my modem) to retrieve the statistics and setup info. I found that I have very high Blers (Bit Link Error RateS) indicating I have noisy lines (signal level is good). I've tested my other voice line and another POP but they're all bad. I've got to recheck my internal wiring and maybe test running a line directly off of the tap on the telephone network interface box. The statistics also showed that I never got an uplink rate higher than 2400.

[xortam]

Well I just got done testing my phone lines coming directly off of the test ports on the network interface box (avoiding the house wiring). I wasn't about to cart all of my equipment out to the back yard so I built myself a 100 foot long phone cable out of some Cat 5 cable I had (shouldn't be any noise on that). I still get high Blers on both of my voice lines. Looks like I'm not going to get any decent on-line gaming until I get this fixed or replaced. At this point I'll see how much hassle it is to get the phone company to chase this down while I'm shopping for a DSL line. I bet I'll get the DSL installed before I hear back from the telco.

[SVS[RUS]SU-37]

Hey people. When you dont get in connection MICROSOFT COMPRESSION it doenst mean that your isp doesnt support it. Some times when I am connecting w/p microsoft compression sometimes with it. When I connected with microsoft comp... I got good ping from 150 to 250 depends on how many ppl on quake 2 server. (can be from 0-16 players) And in quake 2 I got my rate set to 4800, I see that many people saying you should set your rate to 3000, I done that once and it seemed same, no less ping o packet loss. About packet loss when I got microsoft compression I dont have any of packet loss its like 99% of no packet loss.

When I am connecting and I dont see in connection detales microsoft compression I just reconnecting till I have it there. Some times it takes me about 10 times to reconnect. But I got another provider which really seems dont have microsoft compression support....

------------------
SVS RUSSIAN

[xortam]

SVS[RUS]SU-37, As I stated before, apparently my ISP doesn't support sw compression. I've connected countless times w/ sw compression enabled and I've never seen this feature enabled in the connection details box. I haven't found anywhere that my ISP documents such features.
I was reading your thread this morning. absalom mentioned that Q2 does it own compression already: I assume Q3 does as well. I noticed no performance difference w/ and w/o hw compression and that would support absalom's statement. Several people, including yourself, have noticed differences w/ sw compression, so this seems contradictory. I don't know of the differences in the network code between Quake 2 and 3 so I can't comment if the rate settings are comparable.
I'm going to try knocking my link down to V.34 and see if that improves my noise level and uplink speed. I have a friend with the exact same MB, modem, and ISP (and POP) as me, so I'm having him check his Blers count (when he gets back in town Monday).

[xortam]

S.O.B., I just played on a Quake 3 server w/ 11 others and got decent pings. I disabled V.90 and x2 and got xmit/rcv rates of 31200 (much better than my 24000 uplink before) and 0 BlerS. I was starting to read some contradictory things about BlerS. ATT said you shouldn't have any more than a couple for a long session otherwise it indicated a noisy line or low signal level (diagnostics showed my signal was fine). I checked out Richard Gamberg's 56K site where they stated ...

It's my understanding that 3Com modems are designed to operate with a bler rate approaching 4000 per hour.

My ISP supports SREJ (selective reject). I'll post my diagnostics screens after I eat some lunch, etc. Modifying the modulation looks like it does the trick.

[Tumu]

SVS[RUS]SU-37, when playing in Q2, remember to check following settings (write the setting in console and to set the value with set-command, like set cl_maxfps 30):

cl_maxfps = The amount of client to server packets sent. With V.34 or V.90 connection, usually set around 30. Compression will allow little bit higher values. If you set it too high, you will overflow your connection (ping times go thru the roof).

rate = The maximum amount of server to client data sent. This imposes a limit which the server will never go over. (For the record, server only sends 10 server to client packets per second. The client will interpolate all other frames needed.) Of course the limit isn't hit so often if there isn't any action going on. V.34 users should use around 3000 to 4000. V.90 users can try 4000-5000. If you set this too high, you will overflow your connection when there are heavy action.

Btw, BW-Admin cl_maxfps and rate caps can sometimes screw up cl_maxfps and rate values.

cl_nodelta = Enables/Disables Q2 delta encoding of packets. Default is 0 (delta encoding enabled) and it should be zero. If in any case you have to set it to 1 to achieve playability, complain to your ISP and switch them if they don't do anything.

netgraph = This command tells the current status of the game packets. Green lines are normal packets and their height tells the ping. Red lines are lost packets. Yellow lines are rate limit hitting. Blue lines are invalid delta encoded packets. You should never see blue lines coming out in continous stream. If you see lots of blue lines, try setting cl_nodelta to 1. But remember, it's only a workaround (and not very good one).

The software compression issue you have is definetely an ISP problem. Ask them about the issue. Any compression applied to connection will only make good connection little better, it will not make any miracles. Also using software and hardware compression at same time doesn't give performance increase, at may even lower it.

.Tumu

[absalom]

From personal experience, I beleive the largest problem with erratic gaming performance over the internet is due to the ISP and the way it configures/runs it's hardware. Your isp being fairly small but having several backbones can help alot, I mean ALOT. My isp, for example, has about 200 max users and utilizes 3 "unique" T1 backbones.... in addition to using Cisco routers and 3com TC v.90 racks. The admin has always "pushed" for the latest beta firmware from 3com, unless it totally destroys gaming performance. The input he gets back decides if that code stays. Sometimes he'll just test a few modems with the new firmware code and stick to the stable released on the rest. The point I'm getting here is that my isp admin cares and fine tunes things so that they 1. work for gamers 2. are stable and working for the other masses. I can remember the early days before v.90, when things were X2 or k56flex, things were flakey and horrible. After v.90, things got better... and a year later were smooth as could be. But, again, even something small as a firmware revision can make or break the way things work.

I wouldn't trust what windows tells you. The best feedback you can get about your connection is from your isp. My isp provides a diagnostics page describing about every feature you'd want to know about your connection. Just because you connect at such and such baud, doesn't mean your running that. A small glitch of line noise can cause retraining of the modem and all hell will break loose... you might be running 24600 actually. If you have a flakey 56k connect, then the best thing you can do is pull out your modem command settings and try forcing it to connect at 33.6 and disabling v.90. If your isp is using sh*tty firmware or is *gasp* still on X2 code, then your modem is going to be choking.

If you look at it from the technical standpoint, your baud connection value shouldn't have any relation to ping, as long as you don't exceed the bandwidth limitations. In other words, the only reason 56k should better 33.6 is with the movement of larger packets. The timing (ping) is theoretically the same at both baud, technically. But, again I stress, if the timing gets screwed with due to flakey v.90 code or line noise then your modem will go nuts and latency is affected. A 33.6 connect is and should always be more stable than a 56k one, given the same modem and situation. There is alot less bandwidth to deal with and alot more headroom to handle line noise. v.90 is a one way digital to analog conversion. With v.90, you upload at 33.6 (analog) and your isp sends the data back digitaly, where it is converted back into an analog signal for you modem. This digital to analog conversion is what gives you this extra bandwidth. The ideal thing to picture here is that with v.90 you don't want to send more than 33.6 and not receive more than 56k (or whatever your limit is). This, again, is all theoretical. Things in real life are never ideal, thus we are always walking a fine line when trying to push theoretical limitations of bandwidth (i.e. v.90).

As far as q3 goes, Carmack himself said it was playable on a decent 28.8 connection as long as you picked the lowest latency servers, your isp didn't suck, and you joined small populated server (like 8 or less people). When you start joining CTF servers with 20+ people, your pushing even the bandwidth limitations of even v.90. Things are going to lag no matter how "awesome" your system, isp, or modem connection is. I have some ol' school TF demos of 24+ player clan matches, and even with a kick ass system/framerate and a stable rate of 5000 in quakeworld... my ping just can't consistantly stay in the 200's. When the server is empty or has 8 people on it, it's hanging right there at 160 or less. I can only image what TF for quake3 would be like.... there's just going to be alot more data sent compared to the simplicity of a younger engine.

/me takes a typing break...

P.S. - Upgrading the v.90 firmware on your modem can help. Well, sometimes... I've heard in some cases where it can break things, but they are rare. I can see where if your isp is running old firmware and your modem is running ancient firmware that they would like each other (i.e X2). If you ask me, you can't lose if you run the latest firmware...



[This message has been edited by absalom (edited 30 January 2000).]