вимірювати однобічну затримку / тремтіння / втрату пакетів


10

У мене збільшується затримка та StDev через перевантаженість маршруту та втрату пакетів , але прямий та зворотний контури йдуть по різних мережах (наприклад, один - init7.net, а інший - he.net), тому зрозуміти це дуже важко яка мережа або хост несе відповідальність за перевантаженість, втрату пакету, тремтіння та збільшення затримки.

Чи є спосіб зменшити провину після того, як вперед та назад mtrне вдалося визначити точного винуватця, а контакти NOC @ або не реагують, або заявляють, що не зазнають втрат на розглянутому шляху? (Я використовую OpenBSD.)

Я навіть намагався mtrбезпосередньо звертатися з деякими клієнтами обох мереж, які, можливо, відчували перевантаженість, але насправді не могли знайти жодних проблем таким чином, тим більше, що, наприклад, у he.net є багато POP, і часто різні маршрути проходять між заданим входом і виходом POP, тому коли я намагаюся mtrїх хостів (як, наприклад, церква) безпосередньо на виході POP, до якого я можу втрачати пакети в їхній мережі, для досягнення іншого шляху he.net той самий POP, і втрата пакетів не відбувається, що не викликає нічого цікавого (крім можливої ​​думки, що вони дійсно можуть перевантажувати деякі маршрути, при цьому забезпечуючи, щоб інші залишалися незавантаженими, все ігноруючи NOC @ запити від не-замовників).


Чи допомогла вам якась відповідь? якщо так, то слід прийняти відповідь, щоб питання не з’являлося вічно, шукаючи відповідь. Крім того, ви можете надати та прийняти власну відповідь.
Рон Моупін

Відповіді:


9

Один із способів зробити це ICMP Timestamp, який знаходиться в мілісекундах з півночі UTC. Це має додаткову перевагу в тому, що вам не обов’язково потрібно контролювати обидва кінці, до тих пір, поки далекий кінець не буде розгорнуто, є велика ймовірність, що це спрацює.

Однак, щоб мати надійні однобічні вимірювання, потрібно надійно однаковий час в обох кінцях. Оскільки часова марка ICMP має точність лише 1 мс (що майже не достатньо для багатьох застосувань, але достатньо для цього), досить легко знайти навіть не співпрацюючі хости, де часова мітка ICMP надасть корисні дані.

Якщо ви керуєте обома кінцями, переконайтеся, що ви синхронізуєте NTP лише з одним сервером і одним сервером. Абсолютний годинник не дуже важливий, просто важливо, щоб ви відчували якомога ближче один і той же час.

Якщо часової позначки ICMP недостатньо, дуже просто написати 10 рядків ruby ​​/ perl / python або навіть C, щоб зробити вимірювання, коли ви керуєте обома кінцями.

Я не можу запропонувати програмне забезпечення для одночасного вимірювання часових міток ICMP, hping2 підтримує надсилання часової мітки ICMP, але чомусь не виводить однонаправлені значення. Я написав патч для hping2, щоб відобразити затримки в одну сторону.


Вау, ваша hping --icmp-tsзайва арифметика така кривава! Занадто ліниво отримати джерела та перекомпілювати двійкове, я отримав собі оболонку вашої hping-патча ( stackoverflow.com/q/20172028/1122270 ), і це показує досить постійний час у шляху init7 до гетцнера та різниця на карті на шляху he.net від hetzner! Зрештою, я маю остаточний доказ того, що init7 говорить правду! Хоча я б заперечував із тим самим сервером ntp лише для цього: просто переконайтеся, що ntpd живий (мені взагалі не довелося змінювати жодні налаштування, але значення виглядають розумними).
cnst

1
Якщо ви дбаєте про точний час на стіні, вам потрібно хоча б 3 сервери NTP (щоб мати змогу виявити помилковий тикер, 2 сервери NTP - це найгірший варіант, який ви могли зробити). Але тут нам не байдуже час на стіні, ми дбаємо про те, щоб чітко позначити ці ж годинники незалежно від стіни. Тож для однобічного вимірювання оптимальні результати отримують від точних годин, час стіни не має значення. Раді почути, що ви отримали результати!
ytti
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.