ISP утверждает, что в значительной потере пакетов нет ничего плохого. Что я могу сделать?

Question

Днем все обычно хорошо, но ночью все, что требует пропускной способности (у меня оптоволоконное соединение 30 Мбит / с, хотя я не думаю, что это оптоволоконное соединение) или постоянное соединение (так называемое игровое), совершенно бесполезно. Я зафиксировал некоторые трассировки WinMTR, и, очевидно, в нескольких местах происходит потеря пакетов, как только мы минуем мой модем:

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.1 -    0 |  886 |  886 |    0 |    0 |   21 |    0 |
|                           192.168.200.1 -    0 |  886 |  886 |    0 |    0 |    3 |    0 |
|          EV1-DSL-208-102-228-1.fuse.net -   88 |  185 |   23 |    0 | 3315 | 4530 | 4088 |
|                            172.17.74.18 -    2 |  827 |  812 |   27 |   30 |   34 |   30 |
|              EV-ZT-1.EVE1.core.fuse.net -    2 |  839 |  827 |   27 |   30 |   68 |   30 |
|te0-0-2-2.nr11.b016343-1.cvg02.atlas.cogentco.com -    2 |  823 |  807 |   28 |   30 |   35 |   31 |
|te0-0-1-1.rcr11.cvg02.atlas.cogentco.com -    4 |  791 |  767 |   28 |   31 |   36 |   31 |
|te0-2-0-0.rcr21.ind01.atlas.cogentco.com -    3 |  819 |  802 |   30 |   33 |   37 |   34 |
|te0-0-2-2.rcr11.sdf01.atlas.cogentco.com -    2 |  823 |  807 |   32 |   35 |   39 |   36 |
|te0-0-2-2.rcr11.bna01.atlas.cogentco.com -    3 |  819 |  802 |   37 |   39 |   43 |   40 |
|te0-18-0-34.ccr42.atl01.atlas.cogentco.com -    3 |  799 |  777 |   43 |   45 |   50 |   45 |
|   be2173.ccr22.iah01.atlas.cogentco.com -    3 |  819 |  802 |   63 |   66 |   70 |   66 |
|   be2066.ccr22.lax01.atlas.cogentco.com -    2 |  827 |  812 |  100 |  102 |  107 |  102 |
|   be2179.ccr23.lax05.atlas.cogentco.com -    2 |  823 |  807 |   99 |  103 |  109 |  104 |
|            att.lax05.atlas.cogentco.com -    3 |  815 |  797 |  101 |  105 |  122 |  105 |
|                    cr1.la2ca.ip.att.net -    3 |  795 |  772 |   96 |  100 |  105 |  100 |
|                   gar5.lsrca.ip.att.net -    3 |  799 |  777 |   96 |  115 |  402 |  110 |
|               12-122-254-230.attens.net -    4 |  786 |  761 |   96 |  107 |  319 |   99 |
|                            206.16.68.42 -    2 |  823 |  807 |   95 |  106 |  328 |   98 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  177 |    0 |    0 |    0 |    0 |    0 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Как видите, как только мы минуем мой модем (192.168.200.1), я получаю 88% потерь пакетов. Это на самом деле не будет работать для меня.

Это след от сервера Blizzard, но я также получаю потери, пингующие Google.

Однако наиболее показательным является то, что в приведенном выше примере самый первый переход - это адрес fuse.net:

EV1-DSL-208-102-228-1.fuse.net - 88 | 185 | 23

очень очевидно, мой провайдер (fuse.net является доменом Цинциннати Белл). Но они утверждают, что проблема не в их конце, и что мое соединение в порядке (они запустили "тесты"). Когда я звоню, я требую только поговорить со службой технической поддержки высшего уровня (меня направляют к "супервизору", высочайшему уровню поддержки клиентов), отказываясь говорить на уровне поддержки начального уровня (перезагрузки маршрутизатора), но это не не дает никаких результатов.

Что я могу сделать? Если они утверждают, что проблем нет, и отказываются помочь мне, что еще я могу сделать?

У кого-нибудь есть предложения?

Answer 1

Прежде всего, попробуйте проверить связь с вашим локальным маршрутизатором. Если вы потеряете пакеты тогда. Вы будете знать, что проблема находится между вашим ПК и вашим маршрутизатором и не имеет никакого отношения к вашему провайдеру.

Если все в порядке и вы получаете все свои пакеты, то вы можете перейти к следующей части вашей сети. который находится между маршрутизатором и вашим кабинетом. Если это так, есть доказательство. Скажите: «Послушайте, я могу нормально пропинговать мой маршрутизатор с моего ПК [доказательства], поэтому единственное логичное объяснение состоит в том, что это что-то не локальное для моей непосредственной сети»

Их работа состоит в том, чтобы помочь вам - я знаю, это расстраивает, но помочь им помочь вам. Если вы дадите им логический ход мыслей с доказательствами. Они не могут этого отрицать.

Удачи.

Answer 2

Вообще говоря, с MTR (или WinMTR) вам не следует слишком сильно концентрироваться на потере пакетов промежуточных переходов, потому что это обычно вызвано порогами трафика ICMP, предназначенного для них (поскольку обычно этот вид трафика требует от них дополнительных ресурсов). Если вы видите некоторую потерю пакетов при переходе, за которой следует потеря пакета в 0% при следующем переходе, вы можете быть уверены, что это не потеря, которая фактически повлияет на ваш трафик (другими словами, реальная потеря на одном конкретном этапе). переход покажет одинаковую или более потерю пакетов во ВСЕХ следующих переходах до пункта назначения). Кроме того, взгляните на среднее значение задержки, чтобы понять производительность, следя за стандартным отклонением (если оно слишком высокое, средняя задержка не имеет смысла, но я не уверен, что WinMTR может показать его между прочим).

В любом случае, глядя на ваш вывод, я вижу потерю около 2% и задержку около 160 мс до последнего отслеживаемого скачка, ничего, что честно не свидетельствует о непригодности сети .

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

Однако имейте в виду, что MTR не отражает тот же поток, который вы используете со своим сервисом; Чтобы лучше проверить это соединение, вы должны установить тест "iperf", который использует те же ваши сокеты, но это не достижимо, если у вас нет доступа к удаленной сети. При использовании только MTR информация о пропускной способности пропускается, ваш трафик может быть сформирован / ограничен вдоль пути другим способом, нежели тот, который применяется к трафику MTR и т.д.

Опять же, если ваши проблемы связаны не только с этим конкретным сервисом, но и со всем интернет-серфингом, такие тесты, как www.speedtest.net/, могут дать вам отличную информацию.