Announcement

**wicked_lord** · 08-22-2014, 10:35 PM

Also when i lived in Lake City, FL i had issues to my past server's but it was NOT due to the server's it was due to the ROUTING issues going from MY house to THE server. Those were on a DIFFERENT HOST then this one. My issue was in Atlanta 2 (TWO) hops before the server itself and had NOTHING TO DO with the server. So check your shit before you blame my servers. KthxGG

**R00k** · 08-22-2014, 10:47 PM

ping is determined by user to server distance.

there are variables involved.

fiber vs copper...

before i get to far in science class,
77
my hair on my mole is telling me that spike is gonna reply in 2 posts.

if we can finish seismic or riftquake or any mod that works with DP7/FTE-DP7 protocol then we can play euro vs usa vs brASIL

AND 10x our playr base and 10x our learning curve

ive met atleast 10 greats players from usa, euro, brazil, canada, etc
in the last 4 years.

we are the first free 2 play game online.

"an advantage is not one, unless taken".

**wicked_lord** · 08-22-2014, 10:51 PM

Originally posted by R00k View Post

ping is determined by user to server distance.

there are variables involved.

fiber vs copper...

before i get to far in science class,
77
my hair on my mole is telling me that spike is gonna reply in 2 posts.

if we can finish seismic or riftquake or any mod that works with DP7/FTE-DP7 protocol then we can play euro vs usa vs brASIL

AND 10x our playr base and 10x our learning curve

ive met atleast 10 greats players from usa, euro, brazil, canada, etc
in the last 4 years.

we are the first free 2 play game online.

"an advantage is not one, unless taken".

What the issue is r00k is that usually Rev ping's 15-25 to CAX. However sometimes like a little bit ago his ping was 60-70.

Lurkered (concept) has the same issue. Sometimes he pings 35-40 sometimes he pings 50-55 and neither one of them have ever at least that i know of ran a trace route to find out where the problem lies. Atlanta is a main HUB and has a lot of traffic in and out and I am almost positive they have an issue somewhere between their router/modem and the server and instead of blaming the server for the ping spike I want them to run a trace route to find out where the issue is at. It is NOT the server guaranteed.

**R00k** · 08-22-2014, 10:57 PM

routing might, in the end only by 1% of the problem.

if he is using analog 56.k
isdn
cable
--att
-vs---timewarner
----vs fiber
---------vsgoogle 1gb fiber
-
-
-vs

this is 2014, same shit as 1996.... go with fiber. or we should migrate to a new quake compatible protocol.

**PrimalLove** · 08-23-2014, 12:46 AM

If you want to do constant traceroute you can use this. Or if you are a bit more advanced just go grab Wireshark

Or NCAT!

My analysis shows this is the weak link so to speak:

Code:

as3595.xe-2-0-5-103.ar1.atl1.us.nlayer.net [69.31.135.54]

Average 74ms ping. Worse 184ms.

The routing is efficient (for the most part) up to this point. About 7 hops for me. Up to here my averages are around 20 or below. But it levels off to a respectable 54 average soon after.

Also here is a batch file you can use to run ping, traceroute and then output it to a file for analysis.

Code:

@echo off
cls
echo.

echo Run PING to  %1  with small and large packets
echo Run TRACERT to  %1
echo Writing output to c:\pingtrace.txt for viewing
echo Will be opened after Finished
echo Optionally: Delete Text File

if "%1"=="" echo No remote host was specified... terminating.
if "%1"=="" goto end
echo.

echo Working . .
ping -f -n 10 -l 1464 %1 > c:\pingtrace.txt
echo Working . . .

echo ======================================================== >> c:\pingrpt.txt

ping -f -n 10 -l 12 %1 >> c:\pingtrace.txt
echo Working . . . .

echo ======================================================== >> c:\pingrpt.txt

tracert %1 >> c:\pingtrace.txt
echo Working . . . . .

edit c:\pingtrace.txt

echo.
del c:\.txt /p

:end

Just save it as whatever.bat and save to c drive. Type in your cmd prompt whatever.bat cax.quakeitup.com or whatever you want to ping.

It will output automatically to the root c: Also this does large and small packet scans. This is highly recommended to get your best estimate on latency. This does both scans automatically and then you can average them together to get your "true" latency. Hope this is helpful. Cheers.

**Solecord** · 08-23-2014, 08:39 AM

Originally posted by PrimalLove View Post

My analysis shows this is the weak link so to speak:

Code:

as3595.xe-2-0-5-103.ar1.atl1.us.nlayer.net [69.31.135.54]

Average 74ms ping. Worse 184ms.

Same for me. I was averaging about 70ms at the same location with a high of 185ms. Everything else was in the 40's.

**wicked_lord** · 08-23-2014, 09:40 AM

Originally posted by PrimalLove View Post

My analysis shows this is the weak link so to speak:

Code:

as3595.xe-2-0-5-103.ar1.atl1.us.nlayer.net [69.31.135.54]

HOLY SHIT!! You nailed it right on the head. NLAYER is the problem i use to have back when i lived in Lake City, FL. Every time i had ping issues to my old Atlanta, GA server's i would always see my ping spiking up to 150ms to this NLAYER.net. I E-mailed them in the past (2 years ago or so) and asked them to fix their connection issues and they E-mailed me back and said they would look into it. Nlayer seems to be one of the passing HOPS to Atlanta, GA. My normal ping on my old Atlanta server's was 15-25ms except on days where Nlayer.net had problems my ping would run high 70's. Nlayer.net is now known as Cloud Networking Solutions Provider - GTT .

**wicked_lord** · 08-23-2014, 09:50 AM

Originally posted by R00k View Post

routing might, in the end only by 1% of the problem.

if he is using analog 56.k
isdn
cable
--att
-vs---timewarner
----vs fiber
---------vsgoogle 1gb fiber
-
-
-vs

this is 2014, same shit as 1996.... go with fiber. or we should migrate to a new quake compatible protocol.

I believe both of them are Cable. Either way they both normally ping under 45 there. Rev at best pings 15ms from what i have seen in the past. Lurkered pings 45 and under most of the time.

Not everyone is offered fiber as it is address specific.
I was looking to purchase a house over near Tampa, FL last year and Verizon told me they had FIOS/FIBER in the Tampa area then i discovered that one of the house i was looking at could not get FIOS/FIBER due to it's address and being on the opposite side of the street. So let's break this down how dumb FIOS/FIBER can be.

We live on "MAIN STREET"
My address is 1010 main street
your address is 1011 main street (right across the street from my house)
I get FIOS/FIBER
You can't because the line is not ran down your side of the street.

Ok ok, sounds legit right.. what about apartment complexes??? Work's the same way..

We live in a Apartment Complex. We both live in Building "B"

3 floors of apartments. I live in first floor you live on 3rd floor.. I live in front of the building you live in back of the building.

My apartment is 103
Your's is 304
I get FIOS/FIBER
You can't get it.

Why? Same building we should be able to get it.
Because they didnt run the lines into your apartment not because you live on the 3rd floor but because the line runs on the south side of the building where i live and not the north side..

This is how it was explained to me by Verizon's FIOS/FIBER line men who i happened to see at a gas station while searching for a house that i liked and had FIOS/FIBER availability.

**wicked_lord** · 08-23-2014, 09:52 AM

Originally posted by R00k View Post

routing might, in the end only by 1% of the problem.

if he is using analog 56.k
isdn
cable
--att
-vs---timewarner
----vs fiber
---------vsgoogle 1gb fiber
-
-
-vs

this is 2014, same shit as 1996.... go with fiber. or we should migrate to a new quake compatible protocol.

Also r00k did you get my PM about the QuakeWorld routing thing for EzQuake?

**OMacKnight** · 08-23-2014, 11:53 AM

From the UK (thought it'd be fun to take a look)

Code:

Pinging TRACERT.cable.virginmedia.net [81.200.64.50] with 1464 bytes of data:



Reply from 81.200.64.50: bytes=1464 time=28ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=437ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=27ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=23ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=272ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=23ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=24ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=65ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=28ms TTL=50

Reply from 81.200.64.50: bytes=1464 time=24ms TTL=50



Ping statistics for 81.200.64.50:

    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 23ms, Maximum = 437ms, Average = 95ms



Pinging TRACERT.cable.virginmedia.net [81.200.64.50] with 12 bytes of data:



Reply from 81.200.64.50: bytes=12 time=17ms TTL=50

Reply from 81.200.64.50: bytes=12 time=18ms TTL=50

Reply from 81.200.64.50: bytes=12 time=21ms TTL=50

Reply from 81.200.64.50: bytes=12 time=31ms TTL=50

Reply from 81.200.64.50: bytes=12 time=26ms TTL=50

Reply from 81.200.64.50: bytes=12 time=21ms TTL=50

Reply from 81.200.64.50: bytes=12 time=20ms TTL=50

Reply from 81.200.64.50: bytes=12 time=34ms TTL=50

Reply from 81.200.64.50: bytes=12 time=17ms TTL=50

Reply from 81.200.64.50: bytes=12 time=51ms TTL=50



Ping statistics for 81.200.64.50:

    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 17ms, Maximum = 51ms, Average = 25ms



Tracing route to TRACERT.cable.virginmedia.net [81.200.64.50]

over a maximum of 30 hops:



  1     1 ms     1 ms     2 ms  192.168.1.1 

  2     8 ms     7 ms     8 ms  10.172.176.1 

  3    10 ms    31 ms    14 ms  pete-core-2b-ae6-725.network.virginmedia.net [81.100.32.173] 

  4  1523 ms    18 ms    31 ms  popl-bb-1b-ae2-0.network.virginmedia.net [62.253.175.142] 

  5    17 ms    25 ms    29 ms  popl-bb-2a-ae2-0.network.virginmedia.net [62.254.42.89] 

  6    19 ms    17 ms    18 ms  popl-bb-1c-ae0-0.network.virginmedia.net [62.254.42.94] 

  7    50 ms    20 ms    22 ms  xe-1-0-0-xcr1.lsw.cw.net [166.63.211.129] 

  8    20 ms    19 ms    23 ms  ae2-xcr1.lnt.cw.net [195.2.30.54] 

  9    24 ms    25 ms    26 ms  te1-4-10G.ar7.LON3.gblx.net [64.208.27.73] 

 10    26 ms    20 ms    21 ms  NOMINUM.port-c2.552.406.ar4.LON3.gblx.net [64.210.69.250] 

 11    46 ms    23 ms    37 ms  81.200.66.253 

 12    19 ms    17 ms    18 ms  advancedsearch.virginmedia.com [81.200.64.50] 



Trace complete.

So which bits of this am I reading specifically? I half understand, but feel I don't quite fully understand. :s

**PrimalLove** · 08-23-2014, 01:05 PM

The first thing is a ping using a large packet (1464 bytes) to your destination address of 81.200.64.50. Then the second ping set uses a small packet (12 bytes) to your destination address. You can take the averages of both of those. In this case 95ms for the large packet and 25ms for the small packets and average them to get a "general" lactency you would get on that particular address/server/etc.

The last thing it does is show you the tracert from your computer to the server you are trying to connect to which is 81.200.64.50. This will also show you how many hops it takes to get to a specific server. There isn't much you can do with tracert on your end. Whatever hops you make is determined by how your ISP routes your traffic to the internet and how the server you are trying to connect to ISP routes the traffic to them. If you see time outs in tracert that is normal and shouldn't be of consideration when trying to diagnose connection latency issues. Basically your ping reports will give you the best information about latency issues.

**OMacKnight** · 08-23-2014, 04:57 PM

thanks for the explanation

Announcement

TraceRoute (tracert)

TraceRoute (tracert)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment