Jump to content

Blue Saber BAR

BAR
  • Posts

    52
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Blue Saber BAR

  1. After Marsden reset the server, the server was still rubber-banding and spiking with the 1st hop. Note the max ping of the 108.61.79.86 hop. Those happen exactly when the rubber-banding in the server happens.

     

    Here is a 10 minute trace.

     

    2016_11_03_PingPlotter_1stMarineRaiders_lag_post_server_reset.PNG

  2. Marsden asked for a fat packet ping to the hop in question. Here is my ping result with a 1400 MTU size:

     

    C:\>ping -t -f -l 1400 108.61.79.86

    Pinging 108.61.79.86 with 1400 bytes of data:
    Reply from 108.61.79.86: bytes=1400 time=125ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=119ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=359ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=128ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=118ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=175ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=514ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=128ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=125ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=357ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=119ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=119ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=166ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=517ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=124ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=126ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=357ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=119ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=125ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=167ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=511ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=118ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=120ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=327ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=119ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=121ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=180ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=502ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=119ms TTL=48
    Reply from 108.61.79.86: bytes=1400 time=118ms TTL=48

    Ping statistics for 108.61.79.86:
        Packets: Sent = 30, Received = 30, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 118ms, Maximum = 517ms, Average = 210ms
    C:\>

  3. I got on tonight at 8pm PST and the server was really laggy and rubber banding, and everyone was complaining about the rubber banding. I wounded a few teammates unintentionally due to the rubberbanding. Server became a ghost town after 15mins.

     

    A single traceroute didn't give the full picture so I took a PingPlotter trace over 3 mins and isolated it down to the hop that was dropping packets and ping was spiking. A major contributor is the first hop before the server's IP (vl105-as1.pnj1.choopa.net 108.61.79.86).

     

    Hope this info helps and this gets resolved quickly.

     

    Tracing route to 208.167.243.207.choopa.net [208.167.243.207]
    over a maximum of 30 hops:

      1    <1 ms    <1 ms    <1 ms  192.168.1.1
      2     3 ms     5 ms     9 ms  static-50-53-152-1.bvtn.or.frontiernet.net [50.53.152.1]
      3     3 ms     4 ms     4 ms  50-39-211-13.bvtn.or.frontiernet.net [50.39.211.13]
      4    40 ms    44 ms    46 ms  ae2---0.cor02.bvtn.or.frontiernet.net [74.40.1.181]
      5    47 ms    44 ms    41 ms  ae3---0.cor01.plal.ca.frontiernet.net [74.40.1.225]
      6    20 ms    19 ms    19 ms  ae0---0.cbr01.plal.ca.frontiernet.net [74.40.3.150]
      7    20 ms    21 ms    19 ms  xe-0.paix.plalca01.us.bb.gin.ntt.net [198.32.176.14]
      8   121 ms   119 ms   121 ms  ae-15.r01.snjsca04.us.bb.gin.ntt.net [129.250.5.33]
      9    45 ms    44 ms    45 ms  ae-1.r22.snjsca04.us.bb.gin.ntt.net [129.250.3.26]
     10    64 ms    66 ms    67 ms  ae-8.r21.chcgil09.us.bb.gin.ntt.net [129.250.5.16]
     11    68 ms   157 ms    75 ms  ae-4.r20.chcgil09.us.bb.gin.ntt.net [129.250.2.162]
     12    86 ms    87 ms    87 ms  ae-0.r25.nycmny01.us.bb.gin.ntt.net [129.250.2.167]
     13   114 ms   112 ms   114 ms  ae-2.r07.nycmny01.us.bb.gin.ntt.net [129.250.3.98]
     14   115 ms   114 ms   112 ms  ae-0.choopa.nycmny01.us.bb.gin.ntt.net [128.241.2.202]
     15   113 ms   114 ms   114 ms  vl39-br1.pnj1.choopa.net [66.55.144.149]
     16   113 ms   115 ms   114 ms  vl105-as1.pnj1.choopa.net [108.61.79.86]
     17   110 ms   112 ms   114 ms  208.167.243.207.choopa.net [208.167.243.207]

    Trace complete.

     

    2016_11_03_PingPlotter_1stMarineRaiders_lag.PNG

  4. Name: Magnum_OBGYN_PI

    Steam I.D: STEAM_0:1:120029926

    Reasons for the Ban: Lots of TKing and remarks as "Noob teammates" while doing it. Resulted in massive retalliation TKing from others due to no Admin on at the time. Left as soon as White and Duncan joined the server.

    Recommended duration of ban: Perm

    Demo Provided?: No, but screenshot and TSgt. C. White and Cpl. A. Scinta are my witnesses.

    post-5857-1442124609_thumb.jpg

  5. Not to high jack the thread, but my scenario was so similar I thought I would chime in.

    Historically, I have had a very stable ping of 89ms in the server with my fiber connection coming from the West Coast. About 6mo. ago, my ping to the server started kicking up in the evening. Now I can watch my ping like almost clockwork spike around 3pm PST and remain at 189-205ms. I suspect my route changed to a crappy, overloaded network. During the weekday morning and afternoons the connection is back to the normal 89ms ping.

    There are similarities to the route that Gearheart posted (129.250.x.x subnet) where the ping can be seen to spike. Also seeing a 50% packet loss. :blink:

    Any help here would be awesome Woz!

    JzI9hK1.jpg

  6. I am not a MSO tech, but I have a feeling I know the issue.

    This sounds like the university is using a captive portal network system to "corral" a user into a designated subnet (set of IP addresses) and then once authenticated (ie. logged in) the subnet will change (ie. your ip address will change) to the the university's trusted network. This causes confusion within the Windows firewall as it appears as an entirely different network and puts it into the "public network" category.

    Under the public network category, the Firewall permissions are much more restricted. Can you try temporarily disabling the Windows firewall and see if that remedies your issue? If it does, then you will need to re-enable the firewall and change your connection from "Public" to "Work" when on the university's trusted network.

    See how to disable/enable Windows Firewall:

    Turn Windows Firewall on or off

    See Microsoft's Tech on changing network locations from public to work:

    Choosing a network location

    Hope this helps. Cheers! :D

×
×
  • Create New...