Lag and packet loss

it's a week i have lag problems,
in terms of packets loss.

if i ping any other ip,
everything works fine with 0% packet loss,
if i ping core ip 109.105.156.11,
i have an average of 10% packets loss.

what's happened?

ps:
no virus/spyware here,
and 4game foder added to antivirus exceptions.

 

same problem here, heavy lag and packets loss, right now the game is almost unplayable

 

try tracert (windows) or traceroute (linux).. maybe some router in your way is overloaded...who knows... find the lagged server and try ping them

 

tracert done,and massively pinged all ips:

seems i have a lot of packet loss with last ips near innova server,
cogentco.com ips.

 

thats a known issue, it's your isp problem, note the sarcasm

prolly is their problem but who knows, lots of people have the same problem as you

 

this is crazy,
not only cogentco.com loose a lot of packets(and it's a known issue,just google cogentco.com and you'll find many threads of people with lag problem in various mmorpg),
but that company take my packets,send them to their servers in u.s. then route them to innova server:



first cogentco.com server is in frankfurt,
second third and fourth are in washington dc(154.54.38.146 , 154.54.38.125 and 149.6.66.83)

in other words i can play on ncwest with less lag and packet loss than in an european server.

 

thank god your packets are not routed trough china. than it would take a few weeks for government to check your packets before sending them to innova server and back. but when i come to think about it innova is russian company... if you get what i mean hahaha xd

 

i think it's not correct.
154.54.38.146, 154.54.38.125, 149.6.66.83 - frankfurt, lux, lux.

innova luxconnect (luxembourg) is as51497 (http://www.lu-cix.lu/members-list.html), so your packets goes directly from frankfurt (cogentco first server) to lu-cix.

and some routing & ripe info if it's needed (from innova's looking glass service)

Spoiler

Code:

router: luxembourg, luxconnect 
command: traceroute [color="#ff0000"]154.54.38.146[/color] as-number-lookup wait 1


 1  te3-2.ccr01.lux01.atlas.cogentco.com (149.6.66.81) [as  174]  0.510 ms  0.475 ms  0.442 ms
 2  te2-1.ccr01.frf01.atlas.cogentco.com (154.54.38.126) [as  174]  4.012 ms te1-1.ccr01.frf01.atlas.cogentco.com (154.54.38.122) [as  174]  4.027 ms te2-1.ccr01.frf01.atlas.cogentco.com (154.54.38.126) [as  174]  3.978 ms

---

Code:

router: luxembourg, luxconnect 
command: traceroute [color="#ff0000"]149.6.66.83[/color] as-number-lookup wait 1


 1  149.6.66.83 (149.6.66.83) [as  174]  1.266 ms  0.527 ms  0.460 ms

ripe (about as174): as174 - cogent

 

ok.
so,how can you explain all this % of packet loss from cogentco and lu-cix routers?

check the % in the red column,second from left of the image:

 

i hava same problem random disconnects all day and when i check whats wrong :



|------------------------------------------------------------------------------------------
| winmtr statistics |

| host - % | sent | recv | best | avrg | wrst | last |

|------------------------------------------------|------|------|------|------|------|------|

| ip-95-111-104-129.home.megalan.bg - 1 | 7579 | 7575 | 0 | 5 | 181 | 0 |

| 89.190.198.146 - 1 | 7559 | 7555 | 1 | 8 | 524 | 3 |

| intl-megalan.bg - 3 | 6873 | 6680 | 1 | 9 | 212 | 7 |

| de-cix.spnet.net - 1 | 7501 | 7479 | 31 | 40 | 316 | 33 |

| gw-frankfurt.pt.lu - 40 | 2988 | 1795 | 0 | 41 | 152 | 37 |

| 213.135.251.181 - 1 | 7471 | 7442 | 37 | 45 | 223 | 42 |

| 78.141.183.50 - 1 | 7503 | 7479 | 40 | 47 | 255 | 41 |

| 109.105.153.10 - 1 | 7498 | 7475 | 40 | 45 | 245 | 41 |

|________________________________________________|______|______|______|______|______|______|

winmtr v0.92 gpl v2 by appnor msp - fully managed hosting & cloud provider

this gw-frankfurt.pt.lu have some kind of proble 40% loss of packages hope they will fix it soon

 

takeiteasy,

many reasons, i think - some issues with connectivity between cogent and lux, icmp drop on routers (very often reason), heavy load, low network's quality and so on... sorry, but i can't see their monitoring. if you want i can ask innova's team about any additinal info about cogent's networks... maybe they can organize petition to this isp (cogentco), but their response / eta does not depend on me or innova's team.

and some additinal info for you from innova's router on lux-ix:

Spoiler

Code:

router: luxembourg, luxconnect 
command: show route protocol bgp 88.40.63.41 terse


inet.0: 420241 destinations, 1681931 routes (417792 active, 0 holddown, 21005 hidden)
+ = active route, - = last active, * = both

a destination        p prf   metric 1   metric 2  next hop        as path
* 88.40.0.0/15       b 170         85      40000 >149.6.66.81     [color="#ff0000"]174[/color] 6762 3269 i
                     b 170         85      40000 >149.6.66.81     [color="#ff0000"]174[/color] 6762 3269 i
                     b 170         85      40000 >31.204.88.149   56665 [color="#ff0000"]174[/color] 6762 3269 i
                     [color="#00ff00"]b 170         85      40000 >78.141.183.49   6661 3257 6762 3269 i[/color]

so your isp have 4 possible routes to innova, and 3 from them through cogentco (as174):

red - cogent networks (as174): https://apps.db.ripe.net/search/query.html?searchtext=as174#resultsanchor
green - possible way to bypass cogent networks! but priority of this route is lower then others (as your isp 'says' to innova's router through bgp). it's more long way as i see (from ... to):

as51497 - innova (lux)
as6661 - ept-lu (lux)
as3257 - tinet-backbone (germany?)
as6762 - seabone-net (telecom italia sparkle s.p.a.)
as3269 - asn-ibsnaz (telecom italia s.p.a.) - it's your 'home' (regional) networks

i don't know about quality in his case (maybe your isp can change priority for testing)

----

hi, xpycbg.
on your trace

Code:

| gw-frankfurt.pt.lu - [color="#ff0000"]40[/color] | 2988 | 1795 | 0 | 41 | 152 | 37 |

it's not real loss, it's icmp-filtering on this router (drops low-priority packets - for example icmp (ping / trace) packets due to security & performance 'reasons'). look further - signal is ok (not 40% loss on any next hop).
so we can't say exactly the reasons of your dc. can you provide us with some network logs (with real game packets that are not filtered)? wireshark (http://www.wireshark.org/) can help you in this case. please capture your signal from pushing 'play' button to your dc from server. i can to analyze this for you if you want.

 

i have problems with random disconnects too. quite annoying. never had that problem on ncwest, and i'm in norway.

 

informing cogentco about this problem could be an idea,
considering that my isp telecom italia,is pratically the biggest isp in italy,
so you can say that 70% of italian players got this problem.

 

tainted, hi! just send me your network logs with random dc (wireshark logs - see above for the link). if it's 'frost kick' - it will be fixed asap for you, it it's 'game-kick' - we should try a petition to support and other methods in faq / guides.

takeiteasy, can your isp try (for the test) another route to innova / from innova (priority must be setup on routers) - not through cogentco as we saw in my post earlier? and i try to infrom innova's team about petition (it's possibility in fact) to cogentco networks. maybe gatses or cheers will share some info about this offer from us later (petition status or issues with it).

i'm understand, yes.. but lu-cix is a very good internet exchange 'point' as i know, and i don't know better in 'eu' except direct peering ofc (maybe i'm wrong - please correct me if so, any info is valuable)

 

yes,
asking to my isp to try an other routing would be and excellent idea,
but,the real problem is,that telecom italia don't care nothing about their customers,
you can spend days with their telephone operators without solving nothing,
simply cause they are totally ignorant about anything,and if you are lucky enough to get a technician to talk with,he will tell you that telecom italia must only provide basical service,
and don't have time/duty to solve anything else.

you could say "just change your isp",
but,
telecom italia is the only owner of entire italian network cause formerly it was the monopolist,
so even with an other isp,for any problem,they will have always to ask support to telecom italia and send to you their technicians.

crazy yes?wellcome to italian internet providers hell.

 

it's obvious that is not, we understand that its easy and cheaper to have it in luxemburg, but... really, fix this problem cause this is retail server and you have the connection worst than a private one.
the only way to fix your problem, is to get battleping, but really, i dont understand why you seem to find normal that i can connect ru/ro servers better than the eu ones, wich means that your isp or your routes are bad, l2 is a rpg game, so that means that it needs a **** of connection to work, i checked with inet mobile and used no more than max 10 mb(not really that no more than 2 but put 10)for a conexion of 3-4 hours, that means, that the problem is not with the data size, neither the ping, its the routes that the package takes, if the only way to get into luxemburg its going throught that servers of cogenco and lux, really, change the country or the isp

 

hi there,
i also have problem with lags during game. it`s quite strange because on my old laptop (hp, win xp) there is all good but on new machine (lenovo, win 7) i have lags everywhere.
log from winmtr:

|------------------------------------------------------------------------------------------|
| winmtr statistics |
| host - % | sent | recv | best | avrg | wrst | last |
|------------------------------------------------|------|------|------|------|------|------|
| no response from host - 100 | 159 | 0 | 0 | 0 | 0 | 0 |
| kat-bg2.neo.tpnet.pl - 0 | 798 | 798 | 41 | 49 | 318 | 42 |
| kat-r4.tpnet.pl - 0 | 798 | 798 | 41 | 48 | 72 | 55 |
| war-r2.tpnet.pl - 0 | 798 | 798 | 46 | 51 | 151 | 48 |
|bundle-ether5.ffttr1.frankfurtammain.opentransit.net - 0 | 798 | 798 | 61 | 67 | 92 | 64 |
|te0-0-0-6.mpd21.fra03.atlas.cogentco.com - 6 | 663 | 629 | 76 | 79 | 101 | 79 |
| te4-1.ccr01.sxb01.atlas.cogentco.com - 97 | 164 | 6 | 0 | 78 | 79 | 79 |
| te1-1.ccr01.lux01.atlas.cogentco.com - 6 | 651 | 614 | 79 | 104 | 465 | 79 |
| 149.6.66.83 - 7 | 631 | 589 | 78 | 81 | 111 | 80 |
| 109.105.152.35 - 7 | 631 | 589 | 79 | 81 | 119 | 80 |
| 109.105.156.11 - 8 | 619 | 574 | 79 | 82 | 111 | 83 |
|________________________________________________|______|______|______|______|______|______|
winmtr v0.92 gpl v2 by appnor msp - fully managed hosting & cloud provider

that 1 line sometimes show my router ip.
can you tell me radix where is the problem ?

thx

 

i have lags and packiet lost too :


|------------------------------------------------------------------------------------------|
| winmtr statistics |
| host - % | sent | recv | best | avrg | wrst | last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 1577 | 1577 | 0 | 0 | 7 | 1 |
| gda-r1.tpnet.pl - 10 | 1152 | 1046 | 0 | 109 | 4043 | 32 |
| 149.6.66.82 - 11 | 1103 | 982 | 0 | 91 | 3428 | 67 |
|te0-4-0-6.mpd21.fra03.atlas.cogentco.com - 11 | 1110 | 991 | 0 | 105 | 4245 | 35 |
| te1-1.ccr01.lux01.atlas.cogentco.com - 12 | 1095 | 972 | 0 | 121 | 4590 | 58 |
| gda-r1.tpnet.pl - 11 | 1114 | 1000 | 0 | 150 | 4558 | 64 |
| 109.105.152.35 - 11 | 1125 | 1011 | 0 | 145 | 4129 | 62 |
| te4-1.ccr01.sxb01.atlas.cogentco.com - 10 | 1158 | 1053 | 0 | 150 | 4062 | 30 |
| war-r4.tpnet.pl - 9 | 1181 | 1082 | 0 | 144 | 4471 | 579 |
| gda-bg1.neo.tpnet.pl - 11 | 1104 | 984 | 0 | 133 | 4670 | 64 |
| 109.105.156.11 - 1 | 1536 | 1525 | 0 | 86 | 2290 | 41 |
|________________________________________________|______|______|______|______|______|______|
winmtr v0.92 gpl v2 by appnor msp - fully managed hosting & cloud provider


śledzenie trasy do 109.105.156.11 z maksymalną liczbą 30 przeskoków.

1 <1 ms <1 ms <1 ms 192.168.1.1
2 39 ms 41 ms 53 ms gda-bg1.neo.tpnet.pl [83.1.4.1]
3 39 ms 41 ms 42 ms gda-r1.tpnet.pl [80.50.156.1]
4 34 ms 33 ms 34 ms war-r4.tpnet.pl [194.204.175.89]
5 59 ms 57 ms 59 ms bundle-ether6.ffttr1.frankfurtammain.opentransit
.net [193.251.250.169]
6 * * * upłynął limit czasu żądania.
7 63 ms 63 ms 62 ms te4-1.ccr01.sxb01.atlas.cogentco.com [154.54.62.
218]
8 64 ms 65 ms 64 ms te1-1.ccr01.lux01.atlas.cogentco.com [154.54.36.
249]
9 64 ms 65 ms * 149.6.66.82
10 * * * upłynął limit czasu żądania.
11 65 ms 65 ms 65 ms 109.105.156.11

śledzenie zakończone.



badanie 109.105.156.11 z 1000 bajtami danych:
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=87ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
upłynął limit czasu żądania.
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=83ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
upłynął limit czasu żądania.
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
upłynął limit czasu żądania.
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
upłynął limit czasu żądania.
odpowiedź z 154.54.36.249: limit czasu wygaśnięcia (ttl) upłynął podczas tranzyt
u.
odpowiedź z 149.6.66.82: limit czasu wygaśnięcia (ttl) upłynął podczas tranzytu.

odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=141ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=136ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=126ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=81ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=79ms ttl=51
odpowiedź z 109.105.156.11: bajtów=1000 czas=80ms ttl=51

statystyka badania ping dla 109.105.156.11:
pakiety: wysłane = 100, odebrane = 96, utracone = 4
(4% straty),
szacunkowy czas błądzenia pakietów w millisekundach:
minimum = 79 ms, maksimum = 141 ms, czas średni = 81 ms

 

@mad_moose and @misiek20pl:

both your connections pass through atlas.cogentco.com routers,
that's the problem.

 

i know, just why the route goes by the usa to luxemburg? most ppl who have neostrada have this same problem.