From: bav@hobbes.ksu.ksu.edu (Brick Verser)
Newsgroups: rec.games.netrek
Subject: Re: What is with lag from Virginia?
Date: 1 Oct 1992 05:02:56 GMT
Organization: Kansas State University
NNTP-Posting-Host: hobbes.ksu.ksu.edu

wk5w@luca.bme.Virginia.EDU (William Thang Katz) writes:
>Sometimes lag from virginia gets downright obnoxious as was the case
>today to bronco.  Results:
>
>----BRONCO.ECE.CMU.EDU PING Statistics----
>101 packets transmitted, 96 packets received, 4% packet loss
>round-trip (ms)  min/avg/max = 42/832/10163
>
>
>This is with 56 byte packets.  I could use some help tracking down
>the offending node.

Somewhat familiar sounding problems.  Boring technical network stuff
totally unrelated to netrek follows.  Stop reading if you want exciting
netrek flames...there are none contained herein.

MIDnet had major problems with excess packet loss which was eventually 
found to be caused, somehow, by the use of Proteon Ethernet cards in the 
routers at Lincoln.  When a Proteon card broke one day it was replaced 
by an old Interlan card and the packet loss disappeared.  We finally 
solved the whole problem by replacing the routers at Lincoln with 
Proteon's newer boxes.

KSU had problems internally with several hundred millisec pauses
occuring fairly regularly.  That finally turned out to be caused by
the on-campus Cisco routers doing RIP updates.  Seems there was a
bit of route flapping going on "out there" in the world which was
causing the routing tables to be updated every 30 second interval,
and when that happened the Cisco with 24 Ethernet ports simply went
to lunch for 800ms.  We "fixed" the problem by ceasing to advertise
off-campus routes on campus.

Now...on to your case...

traceroute to luca.bme.virginia.edu (128.143.4.155)
 1  129.130.7.240 (129.130.7.240)  4 ms  4 ms  3 ms
 2  proteon.ksu.edu (129.130.247.1)  35 ms  4 ms  7 ms
 3  128.242.25.1 (128.242.25.1)  35 ms  17 ms  16 ms
 4  192.35.171.10 (192.35.171.10)  38 ms  20 ms  21 ms
 5  t3-2.cnss81.t3.nsf.net (140.222.81.3)  31 ms  32 ms  32 ms
 6  t3-3.cnss80.t3.nsf.net (140.222.80.4)  34 ms  31 ms  32 ms
 7  t3-1.cnss24.t3.nsf.net (140.222.24.2)  49 ms  101 ms  68 ms
 8  t3-0.cnss40.t3.nsf.net (140.222.40.1)  43 ms  44 ms  44 ms
 9  t3-1.cnss32.t3.nsf.net (140.222.32.2)  70 ms  59 ms  58 ms
10  t3-1.cnss56.t3.nsf.net (140.222.56.2)  62 ms  64 ms  64 ms
11  t3-0.cnss58.t3.nsf.net (140.222.58.1)  66 ms  65 ms  70 ms
12  t3-0.enss136.t3.nsf.net (140.222.136.1)  65 ms  65 ms  64 ms
13  sura3-FIX-pe.sura.net (192.80.214.3)  66 ms  72 ms  68 ms
14  sura8-int-ce.sura.net (128.167.1.8)  69 ms  69 ms  70 ms
15  wtn1-sura9-c1.sura.net (128.167.212.2)  71 ms  75 ms  75 ms
16  ctv-wtn1-c1.sura.net (128.167.139.2)  78 ms  82 ms  79 ms
17  uva-ctv-c1.sura.net (128.167.66.2)  92 ms  77 ms  97 ms
18  137.54.200.12 (137.54.200.12)  130 ms  79 ms  89 ms
19  stacy-cisco-i0.acc.Virginia.EDU (128.143.220.15)  83 ms  78 ms  87 ms
20  luca.bme.Virginia.EDU (128.143.4.155)  92 ms  83 ms  79 ms

This is the path from KSU to UVA.  

I started 5 pings/sec to 128.167.1.8 and had basically good response time
with no significant packet loss and very few round-trip-times greater than
200ms.  But the NEXT node, 128.167.212.2, suffers from 800ms pauses every
30 seconds--you can set your watch by it.  Sure looks like RIP-related
update problems.  An snmp query shows both of these nodes to be Ciscos,
so it looks rather like you folks are having the very problem we had.

Best bet is to have the UVA network folks start paying attention to this
and get in touch with the SURA network folks.  Cisco told me that they
thought they could fix the RIP performance problem if we really needed
it fixed.  Since we had a workaround, we let 'em off the hook.  But if
you guys are having this problem perhaps you can get them to look into
it some more.  I think this nicely explains the 1 second pauses (though I
haven't a clue why you get 10 second pauses).  Then there's also the 
question of why there are so many route changes going on--this is probably
unrelated but if something unusual is happening that might explain why
you are only in the past days seeing the problem.

Dunno about the large packet loss.  At the moment I'm getting 1% loss so
there really isn't enough to try to find the source.

--Brick
Newsgroups: rec.games.netrek