Шлюз между иновой и retn

сейчас в процессе смены провайдера, дома два инета.
старый провайдер, линк на россию через telia.

Спойлер

http://s019.**********/i618/1205/79/5b2b45b53cd4.png

новый провайдер, линк на россию через retn.

Спойлер

http://s019.**********/i608/1205/e8/8c0e27070e48.png

ситуация с новым провайдером не радует. рискую предположить, что инова соединена с retn перегруженным/некачественным линком. потери пакетов выливаются в ощутимые лаги, играть некомфортно. проблема эта не постоянная, но на выходные, когда только бы и погамать, возникает удручающе часто.

и еще у меня вопрос. казалось бы, потери пакетов мизерные, и при стабильном пинге протокол tcp должен без проблем справляться с этими потерями. между тем, уже с потерями в пару процентов играть невозможно.

 

а в чем вопросы то?

 

да просто хвастается ..

 

админы, у вас линк на retn глючит.

так понятнее ?

 

хвастаться особо нечем. был провайдер утк, телефонная пара прокисла, тянет макс 5 мбит. перехожу на fttb провайдера киевстар, а у него, мало того, что пинги 100 мсек, так еще и потери.

 

а судя по первой картинке - нет.
с чего вы взяли что иннова указывает провайдерам через какой маршрут они должны вести к ней свой траффик?

у нас? скорее у вас.
у меня трасса тоже идет через retn только вот она красивая и не глючит.

PHP:

microsoft windows [version 6.1.7601]
(c) корпорация майкрософт (microsoft corp.), 2009. все права защищены.

c:\users\withdkd>tracert 109.105.134.171

трассировка маршрута к l2frost1.l2.local [109.105.134.171]
с максимальным числом прыжков 30:

  1     1 ms    <1 мс     1 ms  10.3.99.129
  2    <1 мс     1 ms    <1 мс  10.0.0.93
  3     1 ms     1 ms    <1 мс  10.0.0.94
  4    <1 мс     1 ms    <1 мс  10.0.0.35
  5    <1 мс     2 ms     1 ms  ip136-161.mmsn.ru [77.73.136.161]
  6    25 ms    25 ms    25 ms  ae5-240.rt.mr.msk.ru.retn.net [87.245.254.1]
  7    25 ms    26 ms    26 ms  ae0-5.rt.m9.msk.ru.retn.net [87.245.233.30]
  8    26 ms    26 ms    26 ms  gw-innova.retn.net [87.245.255.138]
  9    27 ms    27 ms    26 ms  sw-1-ti-po-4.msk.inn.ru [109.105.128.34]
 10    27 ms    27 ms    26 ms  fw-2-ti-ae-1-57.msk.inn.ru [109.105.128.46]
 11    26 ms    26 ms    28 ms  l2frost1.l2.local [109.105.134.171]

трассировка завершена.

c:\users\withdkd>

провайдеру графики показывали?

 

pinguin, привет.

с маршрутизатора инновы (mmts-9):

Код:

router: moscow, mmts-9 
command: traceroute 87.245.255.138 as-number-lookup wait 1


traceroute to 87.245.255.138 (87.245.255.138), 30 hops max, 40 byte packets
 1  gw-innova.retn.net (87.245.255.138) [as  9002]  [color="#ff0000"]0.142 ms  0.069 ms  0.086 ms[/color]

{master}

и

Код:

router: moscow, mmts-9 
command: ping count 5 87.245.255.138


ping 87.245.255.138 (87.245.255.138): 56 data bytes
64 bytes from 87.245.255.138: icmp_seq=0 ttl=64 time=0.117 ms
64 bytes from 87.245.255.138: icmp_seq=1 ttl=64 time=0.038 ms
64 bytes from 87.245.255.138: icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from 87.245.255.138: icmp_seq=3 ttl=64 time=0.053 ms
64 bytes from 87.245.255.138: icmp_seq=4 ttl=64 time=0.062 ms

--- 87.245.255.138 ping statistics ---
5 packets transmitted, 5 packets received, [color="#ff0000"]0% packet loss[/color]
round-trip min/avg/max/stddev = [color="#ff0000"]0.038/0.063/0.117/0.028 ms[/color]

{master}

очень неплохой линк, я считаю. как вы видите - без потерь, без провисаний, без излишнего ско и энтропии в ответах даже на icmp (уж про media-контент не говорю даже).
более того, взгляните на трассу у человека выше - тоже приличные показатели уже с клиентской машины (т.е. + остальная часть канала).

также смотрю на скриншоты - если честно почти не верю, что указанные потери на шлюзе (зона ответственности retn кстати) - есть реальные потери. в принципе вы сами это отметили, для tcp + l2 критичным это быть не должно. поэтому рекомендую вам либо уточнить данные на основе захвата игровых пакетов программой wireshark (увидите эффективное время "запрос-ответ"), либо попробовать поискать причину в другом или иначе. выбор за вами. если какая информация от меня еще нужна - сообщайте.

 

1. мне нечего показать провайдеру. на второй картинке видно, что по пятый хоп включительно потерь нету, а это уже далеко за пределами ответственности провайдера.
2. трассировка ваша хороша, конечно. из трех (!!!) пакетов ни один не потерялся, какая радость. я привел статистику на 300 пакетов, потери - 4%.
3. я ни слова не написал о том, что инова что - то указывает провайдерам.
4. первой картинкой я как бэ доволен, у меня по ней нет вопросов. это мой старый провайдер, на нем пакеты не теряются, на россию (и на инову в том числе) он заходит через telia. но этим провайдером не могу больше пользоваться, канал узкий, и шире он давать не может. потому перехожу на другого... ну я ж написал уже все...
5. вот зачем написать, лишь бы что - то написать, ни слова по теме ?

 

Спойлер

в линейку давно играли ? сейчас три процента потерь - это уже все, вешалка. мне кажется, что раньше так не было.
вот свеженькое напинговал, не до сервера, а до шлюза, до которого и вы 5 пингов отправили.
http://s019.**********/i644/1205/e2/b1997291d591.png

 

не было. сейчас трафик в обоих направлениях вырос в разы и клиент стал критичен к трассе.

 

кстати попутно глянул тот же lg с retn площадки до innova (т.е. аналог прямого запроса, а не обратного, как привел выше) - там дисперсия в ответе на icmp очень большая (но опять же при полном отсутствии пока потерь), так что у вас, скорее всего, pingplotter это и поймал. нестабильность + шейпер. проверьте все же на игровых пакетах непосредственно - это куда интереснее, как мне кажется. как для вас - не знаю, судите самостоятельно.

шлюз - зона ответственности retn, увы. как он отвечает, как шейпит трафик и использует ли эту методику сейчас - я не знаю.
что касается стат. данных - можно изменить команду на count 1000, но больше информации для нас это не даст, увы. и да, я не играю вообще - так что верю на слово, считаете что 3% критичны, значит критичны. не вижу смысла спорить с этим.

в любом случае, мои рекомендации остаются прежними, ибо pingplotter-у, winmtr, lg я не верю в данном случае ни капли. привел лишь как контраргумент и не более.

 

PHP:

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

|                                      winmtr statistics                                   |

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

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

|                             10.3.99.129 -    0 |  501 |  501 |    0 |    0 |   65 |    0 |

|                               10.0.0.93 -    0 |  501 |  501 |    0 |    0 |   19 |    1 |

|                               10.0.0.94 -    0 |  501 |  501 |    0 |    0 |    2 |    0 |

|                               10.0.0.35 -    0 |  501 |  501 |    0 |    0 |    2 |    0 |

|                       ip136-161.mmsn.ru -    0 |  501 |  501 |    0 |    0 |    2 |    0 |

|           ae5-240.rt.mr.msk.ru.retn.net -    0 |  501 |  501 |   25 |   25 |   64 |   25 |

|             ae0-5.rt.m9.msk.ru.retn.net -    0 |  501 |  501 |   25 |   25 |   71 |   25 |

|                      gw-innova.retn.net -    0 |  501 |  501 |   25 |   28 |  118 |   25 |

|                 sw-1-ti-po-4.msk.inn.ru -    0 |  501 |  501 |   25 |   26 |   53 |   26 |

|              fw-2-ti-ae-1-57.msk.inn.ru -    3 |  453 |  441 |   26 |   26 |   28 |   26 |

|                       l2frost1.l2.local -    0 |  501 |  501 |   26 |   26 |   28 |   26 |

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

~500 пакетов до того же хоста.
что то потерялось по пути, но в целом статистика неплохая.

 

завязываем мериться icmp
хочется более предметного разговора на основе захвата игровых пакетов. так и retransmission и lost segments "чекнем", да и delta в request / response. сразу будет видно - есть ли реальные потерьки и кому лучше об этом сообщить.

 

Спойлер

первый раз вижу результат winmtr, в котором в колонке "sent" разные цифры. у меня всегда там было одно и то же для всей трассы. как удалось такого добиться ?

 

с 3% потерь это неудивительно. как только в столбе с потерями цифры стали меняться - количество пакетов в sent уменьшилось для одной строки.

 

если не играете, то вам, конечно, море по колено. а играющим перехват пакетов крайне противопоказан пс.

 

не помню, чтобы пс хоть как-то мешало решению / исследованию технической проблемы силами администрации проекта за 2+ года как минимум. если у вас есть примеры обратного - поделитесь, я не в курсе к сожалению.

в любом случае, если есть хотя бы капля переживаний по этому поводу, я с вами только соглашусь, безопасность аккаунта / соблюдение правил - святое. могу предложить тогда помощь tgms-группы (человека я постараюсь вам найти), они сделают все за вас через teamviewer (логи все равно будут смотреть я и они), а если доверия такого рода нет - то сделаете вы под их "присмотром", т.е. без любой опаски за соблюдение пс. единственный минус - я бы хотел помочь быстрее вам (как и все остальные тут, я думаю), а вот присутствие tgm-группы в те же праздники гарантировать я совершенно не могу, а успеют ли глянуть вас сегодня - не знаю. дайте мне знать - нужна ли их поддержка или же обсуждение продолжим здесь самостоятельно?

 

для меня удивительно. как бы ни терялись пакеты, sent всегда одно для всей трассы. вот моя трассировка, потери есть, sent отличается на единичку в том месте, где я нажал кнопку stop. а ваша трассировка о чем то говорит, но я не знаю, о чем.

Код:

|------------------------------------------------------------------------------------------|
|                                      winmtr statistics                                   |
|                       host              -   %  | sent | recv | best | avrg | wrst | last |
|------------------------------------------------|------|------|------|------|------|------|
|                              172.16.0.2 -    0 | 1469 | 1469 |    0 |    0 |   15 |    0 |
|                           46.185.26.253 -   73 | 1469 |  400 | 16500 | 7046 | 21406 | 17656 |
|                br0-lvv2.ip.kyivstar.net -    0 | 1469 | 1469 |   15 |   30 |   46 |   31 |
|                         ams-ix.retn.net -    1 | 1469 | 1456 |   46 |   49 |  109 |   46 |
|             ae1-9.rt.m9.msk.ru.retn.net -    2 | 1469 | 1453 |   93 |   94 |  156 |   93 |
|                      gw-innova.retn.net -    1 | 1468 | 1454 |   93 |  100 |  203 |   93 |
|                 sw-1-ti-po-4.msk.inn.ru -    1 | 1468 | 1454 |   93 |   93 |  109 |   93 |
|              fw-2-ti-ae-1-57.msk.inn.ru -    3 | 1468 | 1433 |   93 |   93 |  125 |   93 |
|                       l2frost1.l2.local -    1 | 1468 | 1455 |   93 |   93 |  109 |   93 |
|________________________________________________|______|______|______|______|______|______|
   winmtr - 0.8. copyleft @2000-2002 vasile laurentiu stanimir  ( stanimir@cr.nivis.com )

 

у вас версия 0.8 winmtr, она куда меньше (и мне больше сейчас нравится, но она менее технологична).

в 0.8 трассирование серверов идет в 1 программном потоке. т.е.
1) устанавливается destination - целевой сервер
2) устанавливается ttl = i, где i инкрементируется в цикле в зависимости от кол-ва хопов до цели
3) отсылается icmp-пакет с нужным ttl / осуществляется прием ответа и замер дельты
4) инкрементируется ttl, подготавливается пакет и снова к 3 пункту.

в 0.9 алгоритм перевели на многопоточку (если посмотрите в processexplorer, то увидите на более длинной трассе большее кол-во отдельных потоков). т.е. свели его к
1) устанавливается destination - целевой сервер
2) создаются несколько потоков (равное кол-ву хопов до целевого сервера), каждый из них формирует свой icmp-пакет с конкретным ttl равным номеру промежуточного узла по маршруту
3) все потоки отсылают свои пакеты, осуществляют прием и замеру дельты параллельно друг с другом.

именно поэтому в 0.8 трасса идет плавно - сначала отвечают ближайшие узлы, потом далее и далее. инкремент там и будет +1, как у вас на скриншоте.
а в 0.9 показатель sent будет меняться у узлов фактически параллельно. поэтому если на одном из них резкий скачок "пинга" или еще того хуже - таймаут (потеря и т.п.), то часть узлов получит больше пакетов, а "проблемный" узел - меньше, т.к. его программный поток (т.е. поток, который "пингует" с помощью нужного ttl-а данный узел) ожидает от него ответа пока все остальные выполняют прием / передачу.

Спойлер

http://*********/37926307/image.png

так что трасса 0.9 версии - очень закономерна, как и сказал ее автор выше. это из-за таймаутов ожидания на узле =) все тут просто и без мистификаций.

 

ага понял спасибо