Bug 173006 - High lag variability with UDP and forcedeth driver
High lag variability with UDP and forcedeth driver
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-12 00:12 EST by Dan Hensley
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-02 13:07:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dan Hensley 2005-11-12 00:12:56 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
Comment 1 Dan Hensley 2005-11-12 00:14:03 EST
I forgot to add that when I connect to a server on the internet, I actually see
lag of ~100 ms, variability ~4500 ms.
Comment 2 Dan Hensley 2005-11-30 10:07:50 EST
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.
Comment 3 John W. Linville 2005-11-30 14:01:13 EST
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? 
Comment 4 Dan Hensley 2005-11-30 15:03:36 EST
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.
Comment 5 John W. Linville 2005-12-02 13:07:54 EST
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! 

Note You need to log in before you can comment on or make changes to this bug.