Red Hat Bugzilla – Bug 173006
High lag variability with UDP and forcedeth driver
Last modified: 2007-11-30 17:11:16 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: The best way to see this is to run bzflag. I'm not a networking guru so I don't know how to write simple C code to demonstrate this. Basically, bzflag uses UDP. When I check my lagstats, the variability number is ridiculously high. The latency (lag) is low, but the variability is 200x higher than the lag. This makes the game completely unplayable. Hopefully this makes sense. In general network traffic works (I can surf the web, etc.). But this problem appears even when I run bzflag on a server on localhost, so no internet involved at all. The problem is just worse when I connect to a server on the internet. Version-Release number of selected component (if applicable): kernel-smp-2.6.14-1.1637_FC4 How reproducible: Always Steps to Reproduce: 1. Compile and run the latest bzflag (I have bzflag-2.0.4.20050930). 2. Start a server on localhost. 3. Connect the client to the server. 4. Hit 'n', then type 'lagstats'. The first number is the lag, and the 2nd is the variability. On my system I see lag of 1 or 2 ms, and variability of 250-450 ms. Expected Results: The lag should be about 1 ms, with variability around the same amount. On a server on the internet, I expect lag of ~100 ms and variability ~10 ms. Additional info: AMD 64 X2 3800+ Gigabyte K8N Pro-SLI nVidia 6600GT 128mb 250 Gb SATA hard drive on-board Gigabit ethernet, forcedeth driver # dmesg | grep eth forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.41. eth0: forcedeth.c: subsystem: 01458:e000 bound to 0000:00:0a.0 eth0: no IPv6 routers present
I forgot to add that when I connect to a server on the internet, I actually see lag of ~100 ms, variability ~4500 ms.
One additional comment for something I discovered last night. When I run the bzflag that comes with FC4, I don't see this problem. However, when I compile it from source, the problem is still there with 2.6.14-1.1644. So perhaps the problem really lies with some other FC4 package. I don't know how to find out which one though.
Hmmm...perhaps you should stick w/ the bzflag that comes w/ FC4? :-) I'm inclined to close this as NOTABUG. Can you explain why you need to rebuild bzflag?
I initially built it a little while ago when FC4 had an older bzflag. And it seems that compiling my own on my system should be better than downloading an RPM anyway. But there still must be a problem. What's different about the system that compiled the official FC4 RPM of bzflag that makes its version work, and the vanilla one I downloaded from bzflag.org not work? That's the big question. So while there is a workaround, it's still unsettling that there is a difference.
Unless you are a developer or have some other need for a "latest and greatest" version, I would suggest using pre-packaged RPMs. There is usually a reason someone chose to package a specific version (i.e. it is known to work, has configuration options specific to the distro, etc). The most likely difference in behaviour is that there is some crucial difference in the source used to build the RPM and the source you downloaded from the net. Not all source is created equal... :-) Anyway, this would seem most likely to be a problem w/ the upstream bzflag project. I would advise you to provide your feedback to them. I'm going to close this as NOTABUG. Thanks for the report!