Качество Связи
#1076
Отправлено 18 Декабрь 2020 - 04:56
#1077
Отправлено 18 Декабрь 2020 - 06:57
Ошибся, была авария, с 15:13 до 18:45 не работало оборудование на доме.
Логин 604125
#1078
Отправлено 06 Февраль 2021 - 10:37
Засёк вот такие трассировки:
1 1 ms 1 ms 1 ms 213.248.0.28
2 <1 мс <1 мс <1 мс 213.248.7.140
3 2 ms <1 мс 1 ms 213.248.3.249
4 1 ms <1 мс <1 мс 213.248.7.90
5 15 ms 15 ms 15 ms 109.239.137.105
6 15 ms 16 ms 15 ms 213.239.224.38
7 36 ms 36 ms 35 ms 213.239.224.166
8 37 ms * 54 ms 213.239.252.17
9 * 138 ms 45 ms 213.239.252.42
10 40 ms 40 ms 40 ms 213.239.229.134
11 40 ms 40 ms 40 ms 94.130.204.236
1 1 ms 1 ms 1 ms 213.248.0.28
2 <1 мс <1 мс <1 мс 213.248.7.140
3 1 ms 1 ms 1 ms 213.248.3.249
4 1 ms 1 ms <1 мс 213.248.7.90
5 15 ms 15 ms 15 ms 109.239.137.105
6 15 ms 16 ms 16 ms 213.239.224.38
7 36 ms 36 ms 36 ms 213.239.224.166
8 36 ms 35 ms * 213.239.252.17
9 * * * Превышен интервал ожидания для запроса.
10 40 ms 42 ms 40 ms 213.239.229.134
11 40 ms 40 ms 40 ms 94.130.204.236
Ист дас ейн проблем ин Дойчляндия или как-то с нами связано? А то последствия этого я наблюдаю только у себя, у чуваков из других стран ситуация как минимум лучше.
#1079
Отправлено 07 Февраль 2021 - 02:14
Сегодня в 0:57 уже ближе и горячее:
1 1 ms 4 ms 1 ms 213.248.0.28
2 <1 мс * <1 мс 213.248.7.140
3 * 1 ms 1 ms 213.248.3.249
4 1 ms <1 мс * 213.248.7.90
5 15 ms 15 ms 15 ms 109.239.137.105
6 16 ms 15 ms 15 ms 213.239.224.38
7 36 ms 36 ms 36 ms 213.239.224.166
8 41 ms 63 ms * 213.239.252.17
9 46 ms * * 213.239.252.42
10 40 ms 40 ms 40 ms 213.239.229.134
11 40 ms 40 ms 40 ms 94.130.204.236
1 * 1 ms 3 ms 213.248.0.28
2 50 ms <1 мс 46 ms 213.248.7.140
3 2 ms 1 ms <1 мс 213.248.3.249
4 <1 мс <1 мс <1 мс 213.248.7.90
5 15 ms 15 ms 15 ms 109.239.137.105
6 18 ms * 16 ms 213.239.224.38
7 39 ms 37 ms 36 ms 213.239.224.166
8 36 ms 36 ms 35 ms 213.239.252.17
9 75 ms 40 ms * 213.239.252.42
10 41 ms 40 ms 40 ms 213.239.229.134
11 40 ms 40 ms 40 ms 94.130.204.236
#1080
Отправлено 07 Февраль 2021 - 07:25
Ваша трассировка непоказательна, собирайте статистику утилитой mtr(winmtr) или аналогом. Смотреть стоит только на задержки и количество потерь до последнего хоста (до которого выполняется трассировка), если их нет, результаты на транзитных узлах можно не рассматривать.
Сегодня в 0:57 уже ближе и горячее:
1 1 ms 4 ms 1 ms 213.248.0.28
2 <1 мс * <1 мс 213.248.7.140
3 * 1 ms 1 ms 213.248.3.249
4 1 ms <1 мс * 213.248.7.90
5 15 ms 15 ms 15 ms 109.239.137.105
6 16 ms 15 ms 15 ms 213.239.224.38
7 36 ms 36 ms 36 ms 213.239.224.166
8 41 ms 63 ms * 213.239.252.17
9 46 ms * * 213.239.252.42
10 40 ms 40 ms 40 ms 213.239.229.134
11 40 ms 40 ms 40 ms 94.130.204.236
1 * 1 ms 3 ms 213.248.0.28
2 50 ms <1 мс 46 ms 213.248.7.140
3 2 ms 1 ms <1 мс 213.248.3.249
4 <1 мс <1 мс <1 мс 213.248.7.90
5 15 ms 15 ms 15 ms 109.239.137.105
6 18 ms * 16 ms 213.239.224.38
7 39 ms 37 ms 36 ms 213.239.224.166
8 36 ms 36 ms 35 ms 213.239.252.17
9 75 ms 40 ms * 213.239.252.42
10 41 ms 40 ms 40 ms 213.239.229.134
11 40 ms 40 ms 40 ms 94.130.204.236
#1081
Отправлено 07 Февраль 2021 - 08:06
#1082
Отправлено 08 Февраль 2021 - 12:01
Смотреть стоит только на задержки и количество потерь до последнего хоста (до которого выполняется трассировка), если их нет, результаты на транзитных узлах можно не рассматривать.
Вообще, приведённые трассировки -- это результат работы батника, который пингует именно конечный узел и в случае отсутствия в течение двух секунд ответа сразу же делает трассировку. Так тоже не показательно?
#1083
Отправлено 08 Февраль 2021 - 08:30
Сегодняшняя трассировка в 8:19, когда меня чуть не выкинуло сервака:
1 1 ms 1 ms 1 ms 213.248.0.28
2 <1 мс <1 мс <1 мс 213.248.7.140
3 <1 мс <1 мс <1 мс 213.248.3.249
4 6 ms 9 ms 5 ms 213.248.7.90
5 15 ms 15 ms 15 ms 109.239.137.105
6 15 ms 19 ms 16 ms 213.239.224.38
7 34 ms 35 ms 34 ms 213.239.224.166
8 37 ms 34 ms 37 ms 213.239.252.17
9 * * * Превышен интервал ожидания для запроса.
10 39 ms 39 ms 39 ms 213.239.229.134
11 39 ms 39 ms 39 ms 94.130.204.236
#1084
Отправлено 08 Февраль 2021 - 10:46
Да, т.к. не виден участок на котором возникают потери, не видно количество потерь.
Вообще, приведённые трассировки -- это результат работы батника, который пингует именно конечный узел и в случае отсутствия в течение двух секунд ответа сразу же делает трассировку. Так тоже не показательно?
попробуйте mtr-v100-static.zip
Какой из них? https://github.com/W...WinMTR/releases
#1085
Отправлено 10 Февраль 2021 - 12:35
Версия 1.00 у меня не взлетела, ни та, ни другая. Поэтому пришлось юзать исходную 0.92.
Статистика за прошедшие сутки:
Ping.jpg 269,73К 1 Количество загрузок:
О чём это нам говорит?
В общем-то, картина примерно та же, что и с обычных трассировок. И я так и не понял, в чём смысл сбора усреднённой за длительный период статистики, если меня интересует отлов кратковременного сбоя, длящегося от силы секунд 10, и трассировка именно в момент этого сбоя.
#1086
Отправлено 10 Февраль 2021 - 02:05
Это нам говорит о том, что до конечного хоста теряется около 0.13% пакетов, причем потери начинаются с первого узла, более вероятно, на участке от 213.248.0.28 до вашего ПК.
Чтобы подтвердить это или опровергнуть нужны дополнительные проверки, можно тестировать сразу до нескольких ресурсов, также конечно очень полезной информацией является время, когда потери начинаются.
Можете использовать утилиту pingplotter, она делает аналогичную проверку, только отмечает потери на графике и позволяет удобно посмотреть, когда именно были потери.
При наличии такой статистики с большой вероятностью я смогу найти проблему на нашей сети, если она есть.
Если у вас есть доступ к 94.130.204.236, вы также можете делать mtr до вашего роуетра/пк и до каких-то адресов из сети РТК, т.к. обратная трасса может отличаться и иногда позволяет увидеть более полную картину.
Версия 1.00 у меня не взлетела, ни та, ни другая. Поэтому пришлось юзать исходную 0.92.
Статистика за прошедшие сутки:
О чём это нам говорит?
В общем-то, картина примерно та же, что и с обычных трассировок. И я так и не понял, в чём смысл сбора усреднённой за длительный период статистики, если меня интересует отлов кратковременного сбоя, длящегося от силы секунд 10, и трассировка именно в момент этого сбоя.
Сообщение отредактировал Unearth: 10 Февраль 2021 - 02:07
#1087
Отправлено 12 Февраль 2021 - 01:21
Если у вас есть доступ к 94.130.204.236
Нет, доступа у меня нет.
до конечного хоста теряется около 0.13% пакетов
Это много или мало? Особенно если учесть, что это среднее за сутки.
можно тестировать сразу до нескольких ресурсов
Здесь продолжение тестирования целевого сервака, плюс www.yandex.ru и www.google.com:
Ping2.jpg 183,15К
1 Количество загрузок:
Вроде картина одинаковая?
потери начинаются с первого узла, более вероятно, на участке от 213.248.0.28 до вашего ПК
Меня вновь терзают смутные сомнения -- а не всё ли это та же самая проблема с неработающим фулл-дуплексом? На сотке у меня так и вообще всё сыпется, и тестировать ничего не надо, а на гигабите вроде бы нормально, но это на глазок. Я теперь попробую сутки погонять снова на 100 Mbit Half-duplex.
Можете использовать утилиту pingplotter
Я буду юзать вот эту версию. Какие-нибудь рекомендации по настройке будут? Программка-то уже не столь простая. Фрагментацию пакетов разрешать, запрещать? И т. д. И в каком виде результаты представлять? Образец какой-нибудь есть?
#1088
Отправлено 12 Февраль 2021 - 03:42
Это небольшие потери, но если связность полностью теряется на какое-то продолжительное время, то это может быть заметным как раз по разрывам сессий с серверами и т.д.
За последнюю неделю не вижу ни одного падения линка в вашу сторону (кроме перевода на 100 half), лучше верните обратно или тестируйте на 10 или 100 full, на half duplex могут быть дополнительные потери.
Я почти не использовал pingplotter, по-моему может работать без каких-то специфичных настроек. Фрагментация при пакетах ~до 1500байт значения иметь не будет
Результат - или save sample set или просто скриншоты, где будут видны потери
В общем в данный момент примерный участок понятен, больше интересует именно время, когда начинаются потери. pingplotter просто наглядно это рисует на графике.
Нет, доступа у меня нет.
Это много или мало? Особенно если учесть, что это среднее за сутки.
Здесь продолжение тестирования целевого сервака, плюс www.yandex.ru и www.google.com:
Ping2.jpg
Вроде картина одинаковая?
Меня вновь терзают смутные сомнения -- а не всё ли это та же самая проблема с неработающим фулл-дуплексом? На сотке у меня так и вообще всё сыпется, и тестировать ничего не надо, а на гигабите вроде бы нормально, но это на глазок. Я теперь попробую сутки погонять снова на 100 Mbit Half-duplex.
Я буду юзать вот эту версию. Какие-нибудь рекомендации по настройке будут? Программка-то уже не столь простая. Фрагментацию пакетов разрешать, запрещать? И т. д. И в каком виде результаты представлять? Образец какой-нибудь есть?
Сообщение отредактировал Unearth: 12 Февраль 2021 - 03:52
#1089
Отправлено 14 Февраль 2021 - 04:02
За последнюю неделю не вижу ни одного падения линка в вашу сторону
Так я на падения и не жаловался. Если б были падения, то на панели задач оставалось бы всплывающее сообщение "Провайдер сейчас подключён", но этого нет.
лучше верните обратно или тестируйте на 10 или 100 full
Говорю ж, фулл-дуплекс на сотке у меня вообще практически лежит. На десятку переключаться уж совсем как-то неприлично, да и смысла не вижу на ней тестировать -- всё равно я не буду её использовать на постоянной основе. Поэтому остаётся только два варианта -- 100 Half и гигабит, причём гигабит появился лишь с приходом IPoE, а до него я всё время сидел на 100 Half, проблем не было. Но теперь меня выкинуло с сервера и на 100 Half, т. е. и 100 Half и гигабит ведут себя одинаково, значит, проблема не в переключении на гигабит.
Вот статистика на 100 Half (около полутора суток), вроде разницы никакой нет:
Ping3.jpg 168,89К
0 Количество загрузок:
Переключил обратно на гигабит. Ещё один разрыв -- это я ПингПлоттер на свой сервак ставил.
save sample set
Что там под сэмплом подразумевается? Единичный ICMP-запрос, что ли?
ЗЫ.
По поводу MTR меня что-то терзают смутные сомнения, по крайней мере, касаемо версии 0.92. Автор явно не дружит с элементарной арифметикой:
1) Если прога запущена в момент недоступности какого-либо узла, то минимальный пинг для этого узла будет показан как 0.
2) Единственный потерянный пакет = 1% потерь для любого количества отправленных пакетов, начиная от 51 и выше.
3) И что уже не настолько очевидно -- радикальное занижение процента потерь при длительной недоступности узла. Дело в том, что прога отправляет следующий пакет лишь в случае получения ответа на предыдущий, а иначе ждёт 5 секунд. В итоге получается, что она пингует недоступный узел лишь раз в 5 секунд, а не так, как указано в настройках, и, соответственно, не с той частотой, с которой она пингует при доступности узла. В моих примерах получается, что она пингует недоступный узел в 10 раз реже, чем доступный, поэтому и количество потерянных пакетов существенно меньше, чем должно быть.
В выше приведённом примере для 94.130.204.236 процент потерь для 9-го узла рассчитан как (35891 - 12833) / 35891 * 100 = 65. А правильно будет вот так: (243094 - 12833) / 243094 * 100 = 95. На самом деле и это не совсем правильно, но уже куда ближе к истине.
Да и в остальном они с ПингПлоттером расходятся во мнениях. У обоих стоит размер отправляемых данных 56 байт и частота пингования 1 раз в секунду:
WinMTR_vs_PingPlotter.jpg 144,36К 0 Количество загрузок:
Это я пока сам ПингПлоттер проверял. На сбои поставлю крутиться сегодня в полночь.
#1090
Отправлено 15 Февраль 2021 - 11:20
Запустил на Семёрке WinMTR 1.00 -- там всё то же самое. И если подумать получше, то становится ясно, что "задумчивость" WinMTR при недоступности узла вносит погрешность не только в случаи длительной недоступности, но и во все остальные тоже, за исключением случая полного отсутствия потерь. Всё зависит от случайного распределения интервалов пятисекундной "задумчивости" по периодам доступности и недоступности узла. Соответственно, WinMTR показывает точно лишь одно число потерь -- 0%. Всё остальное -- плюс-минус километр, как бог на душу положит. Но для того чтобы просто оценить, есть ли потери или нет, достаточно штатных виндовых команд, и WinMTR полностью теряет смысл.
WinMTR будет давать точные показания только в том случае, если в настройках период пингования будет кратным 5-ти секундам. Но даже минимальные в этом случае 5 секунд -- это слишком много для отлова кратковременных сбоев, поэтому WinMTR -- в топку.
#1091
Отправлено 16 Февраль 2021 - 01:05
Ну вот, наконец. На скринах -- проблемный участок за вчерашние сутки, а сэмпл-сет -- полный, за все 24 часа. Я там пометил, где меня выкидывало (или почти), но, разумеется, я не торчал на этом серваке все 24 часа, поэтому не факт, что не выкидывало бы и на других участках.
Ping.zip 2,4МБ 4 Количество загрузок:
Не второй ли узел сбоит?
Сообщение отредактировал Boris3000: 16 Февраль 2021 - 02:03
#1092
Отправлено 16 Февраль 2021 - 11:41
Мне не удалось найти никаких проблем на оборудовании. Из семпла я увидел 2 ваших отметки, которые у меня не сопоставляются с потерями. PL до конечного узла 0%.
Я бессилен здесь чем-то помочь, можете продолжать диагностировать дальше (напрямую до разных узлов и т.д) , можете обращаться в саппорт. Локальных проблем при детальном изучении я не обнаружил, массовых жалоб нет.
Ну вот, наконец. На скринах -- проблемный участок за вчерашние сутки, а сэмпл-сет -- полный, за все 24 часа. Я там пометил, где меня выкидывало (или почти), но, разумеется, я не торчал на этом серваке все 24 часа, поэтому не факт, что не выкидывало бы и на других участках.
Не второй ли узел сбоит?
#1093
Отправлено 16 Февраль 2021 - 11:57
Из семпла я увидел 2 ваших отметки, которые у меня не сопоставляются с потерями. PL до конечного узла 0%.
Не понял. Ноль потерь только на моей средней отметке, где я написал, что ЧУТЬ не выкинуло. А на двух других -- где именно выкинуло -- конечный узел был полностью недоступен по 20 секунд, что прекрасно видно по высоченным красным пикам на этих отметках:
Ping5.jpg 327,32К 0 Количество загрузок:
Отметки ставятся вручную и стоят, естественно, приблизительно, а не с точностью до секунды.
И что со вторым узлом? Явную корреляцию между моими отметками и подпрыгиванием пинга с джиттером на нём только слепой не заметит. Сегодня был ещё один мощный красный выброс на конечном узле, и снова совпадающий с данными явлениями на втором узле.
Сообщение отредактировал Boris3000: 17 Февраль 2021 - 12:13
#1094
Отправлено 17 Февраль 2021 - 05:11
Да, там где вы отмечаете, что вас выкинуло, видны потери на последних 2 хопах, при этом на предыдущих хопах потерь нет, т.е. выходит что потери или в сети hetzner или на обратной трассе, не в сети РТК.
Задержки-потери только на транзитных узлах связаны с низким приоритетом на обработку icmp, на конечном узле таких проблем нет.
Не понял. Ноль потерь только на моей средней отметке, где я написал, что ЧУТЬ не выкинуло. А на двух других -- где именно выкинуло -- конечный узел был полностью недоступен по 20 секунд, что прекрасно видно по высоченным красным пикам на этих отметках:
Отметки ставятся вручную и стоят, естественно, приблизительно, а не с точностью до секунды.
И что со вторым узлом? Явную корреляцию между моими отметками и подпрыгиванием пинга с джиттером на нём только слепой не заметит. Сегодня был ещё один мощный красный выброс на конечном узле, и снова совпадающий с данными явлениями на втором узле.
Сообщение отредактировал Unearth: 17 Февраль 2021 - 05:11
#1095
Отправлено 17 Февраль 2021 - 05:22
Хотя, если нажать непосредственно на отмеченный красным участок, в поле current выдает ERR уже между 4 и 5 хопом, это аплинк и на нем никаких проблем я не вижу. Для теста зароутил 94.130.204.236/32 через другой аплинк, поскольку на нашей сети проблем я не нашел, это единственное, что можно сделать, потестируйте, будут ли изменения.
Прикрепленные файлы
Сообщение отредактировал Unearth: 17 Февраль 2021 - 05:26
#1096
Отправлено 17 Февраль 2021 - 06:50
Задержки-потери только на транзитных узлах связаны с низким приоритетом на обработку icmp
Это знание настроек конкретных транзитных узлов или гипотеза общего порядка? И может, тогда имеет смысл в настройках выставить UDP или TCP Packets вместо ICMP?
А вообще, для приложений реального времени необязательны именно потери, чтоб начали возникать проблемы -- достаточно задержкам подскочить, скажем, до 500 мс (настоящим, а не только на ICMP), чтоб начались глюки или даже выкидыши.
#1097
Отправлено 17 Февраль 2021 - 09:36
Это знание настроек и общей практики. Есть смысл потестировать через udp. tcp, как мне кажется, стоит использовать, если есть подозрение именно на проблемы с прохождением tcp
Я не вижу какой-то явной проблемы в нашей сети, сообщите после проверки изменилась ли ситуация в лучшую сторону после изменения маршрута, если да, то временно оставлю так, если нет, верну как было.
Если используете еще какой-то ip из сети hetzner можете сравнить результаты до него с результатами до 94.130.204.236
Это знание настроек конкретных транзитных узлов или гипотеза общего порядка? И может, тогда имеет смысл в настройках выставить UDP или TCP Packets вместо ICMP?
А вообще, для приложений реального времени необязательны именно потери, чтоб начали возникать проблемы -- достаточно задержкам подскочить, скажем, до 500 мс (настоящим, а не только на ICMP), чтоб начались глюки или даже выкидыши.
Сообщение отредактировал Unearth: 17 Февраль 2021 - 09:37
#1098
Отправлено 17 Февраль 2021 - 11:49
и общей практики
А, неполная индукция -- королева познания. Но не надо забывать, что она не есть стопроцентно надёжная штука.
если есть подозрение именно на проблемы с прохождением tcp
Не факт, что TCP. Возможно, что UDP. Но уж точно не ICMP, поэтому вообще выглядят странными все эти сканирования ping-ом, когда всегда можно возразить, что это, дескать, не реальные задержки, а просто приоритет у ICMP низкий. Какая-то больно шаманская "методология".
Если используете еще какой-то ip из сети hetzner можете сравнить результаты до него с результатами до 94.130.204.236
Нет, не использую (или просто не знаю), хотя можно взять любой от балды. Но знаю, что других, использующих этот же сервер, не выбрасывает. По крайней мере, единомоментно со мной. Поэтому с вероятностью 99% дело именно в другом маршруте.
ообщите после проверки изменилась ли ситуация в лучшую сторону после изменения маршрута
ОК, пойду мытарствовать дальше.
#1099
Отправлено 17 Февраль 2021 - 04:08
У меня сейчас опять смена маршрутизации произошла -- с 14 до 15 часов поменялись узлы 2, 3 и 7. Это оно само?
#1100
Отправлено 18 Февраль 2021 - 07:50
Вот в упор не понимаю...
Почему когда я идентифицировал себя на 1 линии и назвал причину звонка как "отсутствие линка" меня заставляют подключить ноутбук, вместо роутера? После чего меня опять идентифицируют на 2 линии, после чего мне изволят сообщить что авария маштаба дома.
Ваши сотрудники всерьез полагают что после того как я проверил свой участок линии, прозвонил его lan тестером, проверил работоспособность портов роутера и попробовав другой роутер на всякий случай у меня волшебным образом появится линк если я подключу ноут или комп?
Почему сразу не сказать - юбилейный 6 авария, сделаем примерно тогда то?
1 посетителей читают тему
0 members, 1 guests, 0 anonymous users