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):
Steps to Reproduce:
1. Compile and run the latest bzflag (I have bzflag-18.104.22.16850930).
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.
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
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
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!