nuclearcat Опубликовано 7 июля, 2009 · Жалоба Пишу программу для "одностороннего" мониторинга. Т.к. по своей сути каналы передачи данных искусственно "обьединяются" величиной "пинга", и частенько какие-то выводы о некачественности делаются на основе RTT (т.е. полного кольца пакета). Я поставил себе задачу промониторить канал асимметрично. Т.е. я мониторю временные отклонения как на передачу, так и прием. Естественно для этого нужна программа с обоих сторон. Программа при определенных отклонениях или отвале одного из "направлений" будет запускать скрипт, которым скажем просигнализирует админу, и возможно переключит канал. Как это выглядит. Вывод обычного пинга: 64 bytes from gxinsat (x.x.x.x): icmp_seq=1 ttl=62 time=320 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=2 ttl=62 time=320 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=3 ttl=62 time=322 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=4 ttl=62 time=320 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=5 ttl=62 time=319 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=6 ttl=62 time=322 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=7 ttl=62 time=355 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=8 ttl=62 time=320 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=9 ttl=62 time=320 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=10 ttl=62 time=320 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=11 ttl=62 time=321 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=12 ttl=62 time=321 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=13 ttl=62 time=321 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=14 ttl=62 time=321 ms 64 bytes from gxinsat (x.x.x.x): icmp_seq=15 ttl=62 time=323 ms Информативно, но не очень. Вывод моей программы. Отклонения на "прием" с точки замера: Качественный спутниковый канал, сервер "замера" находится на площадке оператора Jul 8 02:26:01 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 384 Jul 8 02:26:02 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384 Jul 8 02:26:03 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384 Jul 8 02:26:04 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384 Jul 8 02:26:05 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384 Jul 8 02:26:06 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384 Jul 8 02:26:07 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 384 Jul 8 02:26:08 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 384 Jul 8 02:26:09 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 384 Jul 8 02:26:10 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 385 Jul 8 02:26:11 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 0, max_rtt 385 Jul 8 02:26:12 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 385 Jul 8 02:26:13 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 385 Jul 8 02:26:14 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 387 Jul 8 02:26:15 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 387 Jul 8 02:26:16 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395 Jul 8 02:26:17 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 2, max_rtt 395 Jul 8 02:26:18 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395 Jul 8 02:26:19 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 2, max_rtt 395 Jul 8 02:26:20 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395 Jul 8 02:26:21 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395 Jul 8 02:26:22 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395 Jul 8 02:26:23 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395 Jul 8 02:26:24 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395 Jul 8 02:26:25 sunfire-1 distnetmond: <insatgx> 3 max jitter, last 1, max_rtt 395 А это на передачу, через ливанских горе-провайдеров (Alcatel wireless с Half-Duplex 10Mbit/s интерфейсом, про остальное хозяйство молчу) Jul 8 01:28:03 globax2 distnetmond: <carrier1leb> 4 max jitter, last 4, max_rtt 389 Jul 8 01:28:03 globax2 distnetmond: <carrier1leb> 4 max jitter, last 0, max_rtt 389 Jul 8 01:28:04 globax2 distnetmond: <carrier1leb> 4 max jitter, last 3, max_rtt 389 Jul 8 01:28:04 globax2 distnetmond: <carrier1leb> 4 max jitter, last 2, max_rtt 389 Jul 8 01:28:05 globax2 distnetmond: <carrier1leb> 5 max jitter, last 5, max_rtt 389 Jul 8 01:28:05 globax2 distnetmond: <carrier1leb> 5 max jitter, last 2, max_rtt 389 Jul 8 01:28:06 globax2 distnetmond: <carrier1leb> 5 max jitter, last 4, max_rtt 389 Jul 8 01:28:06 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389 Jul 8 01:28:07 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389 Jul 8 01:28:07 globax2 distnetmond: <carrier1leb> 5 max jitter, last 4, max_rtt 389 Jul 8 01:28:08 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389 Jul 8 01:28:08 globax2 distnetmond: <carrier1leb> 5 max jitter, last 5, max_rtt 389 Jul 8 01:28:09 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389 Jul 8 01:28:09 globax2 distnetmond: <carrier1leb> 5 max jitter, last 3, max_rtt 389 Jul 8 01:28:10 globax2 distnetmond: <carrier1leb> 5 max jitter, last 2, max_rtt 389 Jul 8 01:28:10 globax2 distnetmond: <carrier1leb> 5 max jitter, last 0, max_rtt 389 Jul 8 01:28:11 globax2 distnetmond: <carrier1leb> 5 max jitter, last 1, max_rtt 389 Jul 8 01:28:11 globax2 distnetmond: <carrier1leb> 5 max jitter, last 2, max_rtt 389 Jul 8 01:28:12 globax2 distnetmond: <carrier1leb> 6 max jitter, last 6, max_rtt 389 Jul 8 01:28:12 globax2 distnetmond: <carrier1leb> 6 max jitter, last 2, max_rtt 389 Jul 8 01:28:13 globax2 distnetmond: <carrier1leb> 9 max jitter, last -3, max_rtt 389 Jul 8 01:28:13 globax2 distnetmond: <carrier1leb> 9 max jitter, last 1, max_rtt 389 Jul 8 01:28:14 globax2 distnetmond: <carrier1leb> 9 max jitter, last 4, max_rtt 389 Jul 8 01:28:14 globax2 distnetmond: <carrier1leb> 9 max jitter, last 2, max_rtt 389 Jul 8 01:28:15 globax2 distnetmond: <carrier1leb> 9 max jitter, last 4, max_rtt 389 Jul 8 01:28:15 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389 Jul 8 01:28:16 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389 Jul 8 01:28:16 globax2 distnetmond: <carrier1leb> 9 max jitter, last 4, max_rtt 389 Jul 8 01:28:17 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389 Jul 8 01:28:17 globax2 distnetmond: <carrier1leb> 9 max jitter, last 5, max_rtt 389 Jul 8 01:28:18 globax2 distnetmond: <carrier1leb> 9 max jitter, last 0, max_rtt 389 Jul 8 01:28:18 globax2 distnetmond: <carrier1leb> 9 max jitter, last -2, max_rtt 389 Jul 8 01:28:19 globax2 distnetmond: <carrier1leb> 9 max jitter, last -1, max_rtt 389 Jul 8 01:28:19 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389 Jul 8 01:28:20 globax2 distnetmond: <carrier1leb> 9 max jitter, last 1, max_rtt 389 Jul 8 01:28:20 globax2 distnetmond: <carrier1leb> 9 max jitter, last 5, max_rtt 389 Jul 8 01:28:21 globax2 distnetmond: <carrier1leb> 9 max jitter, last 3, max_rtt 389 Jul 8 01:28:21 globax2 distnetmond: <carrier1leb> 9 max jitter, last 1, max_rtt 389 Jul 8 01:28:22 globax2 distnetmond: <carrier1leb> 9 max jitter, last -2, max_rtt 389 Хорошо видно, что даже на этом маленьком отрезке, при очень малой загрузке (ночь), jitter составляет ~10ms. Днем этот канал кошмарит по черному. Конечно может быть там еще дисперсия от шейпера, который не позволяет "превышать" доступную полосу, но я это скорее всего проработаю через мониторинг "после шейпера". Т.к. опорный оффсет часов для точек замера берется случайным образом (из первого полученного значения), возможны минусовые минимальные значения, это нормально и учитывается. Еще есть проблема связанная с "уходом" частоты практически на любом компе, потому желательно засинхронизировать часы, а точнее подстроить частоту часов, чтоб часы "не отставали" и "не спешили". В некоторых случаях уход часов может составлять до 20ms на 1 минуту(TSC, это около 333ppm, возможно конечно и в пределах нормы), в случае HPET это было 3ms (соответственно это и составит погрешность показаний). Но методом несложных вычислений (еще дополню программу по этому поводу) и визуального наблюдения результатов можно вычислить взаимный "уход" часов точек замера. Замечание: уход нетермостатированного кварца, который установлен в компе, зависит от его температуры. P.S.S. NTP по асинхронным каналам, с разной задержкой на прием и на передачу IMHO ошибается, т.к. рассчитывает на задержку по симметричному алгоритму. Получить точное время в случае ассимметрии похоже можно только с помощью хорошего GPS приемника на realtime системе. Если допишу тулзу до удобочитаемого состояния - выпущу под GPL. Возможно будет актуально многоногим друзьям, которые хотят увидеть каждый "канал" отдельно. В принципе даже симметричникам это может пригодится, чтоб четко увидеть "горлышко" на любом из направлений. Кому-нить "позамерять" канал? Сырки текущей версии дам, обьясню, что и как... если есть желание поэкспериментировать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 7 июля, 2009 · Жалоба Забыл добавить. Программа позволяет определить перегрузку канала оператора в определенном направлении. Т.к. пакеты скорее всего будут буферизоваться не всегда - велика вероятность что прийдет пакет с минимальной и с максимальной задержкой. Скажем для Cisco hold-queue в 75 пакетов (вроде оно обычно по умолчанию), среднем размере пакета в 500 байт, и канале в мегабит задержка может составить до 300ms, что программа и покажет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 июля, 2009 · Жалоба Дурная мысль: если пинг до нью-йорка из Москвы (RTT) 140ms, расстояние ~7505 км (итого 15010) получается скорость передвижения данных составит 107214 км/ч. Это всего лишь в ~10000 раз медленнее скорости света. Пора применять специальную теорию относительности по отношению к данным? :-D Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pety Опубликовано 8 июля, 2009 · Жалоба Почему 107214 - километры в ЧАС? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chainick Опубликовано 8 июля, 2009 · Жалоба А где сама программа? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 июля, 2009 · Жалоба Почему 107214 - километры в ЧАС? Буквы перепутал, км/c Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 июля, 2009 · Жалоба Ну, хотя исходники не готовы на публичное выкладывание.... но их там немного, посему: http://www.nuclearcat.com/files/distchanmon-0.2.tgz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 8 июля, 2009 · Жалоба Казалось бы, при чем тут hold-queue... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 июля, 2009 · Жалоба что будет при перегрузке интерфейса? где будут "задерживаться" пакеты? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 8 июля, 2009 · Жалоба Точно не в ней, поверь мне. В общем то тебе это не так и важно. Ты пиши, пиши, посмотрим что получится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 июля, 2009 · Жалоба tgz - реалии жизни. E1 - 2 Mbps у аплинка, нам выделен мегабит. Бендвич как оказалось шарится и не dedicated, хотя платим по полной. Программка помогла. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 8 июля, 2009 · Жалоба 1. При чем тут асимметрия? Была ли она? 2. Православный iperf вам тут бы не помог? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 8 июля, 2009 · Жалоба 1)перегруз был на upload 2)Нет, с помощью iperf можно проводить только периодический мониторинг канала, и расчет идет на то, что гонишь поток с определенной скоростью, эта программа складывает логи за весь период работы,обьем данных для замеров очень мал, и реагирует только тогда, когда мне нужно, т.е. когда подрос rtt/jitter выше нормы - шлет sms (в текущем публичном снапшоте этой функции нет). Кроме того мне очень не нравится gettimeofday и еще несколько вещей :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pety Опубликовано 8 июля, 2009 · Жалоба Почему 107214 - километры в ЧАС?Буквы перепутал, км/c Это я к "Это всего лишь в ~10000 раз медленнее скорости света". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 8 июля, 2009 · Жалоба А я вот как-то к smokeping привык, и вполне его хватает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 8 июля, 2009 · Жалоба А у меня уже давно меряет зависимость rtt от заюзанной полосы. Только при большом джиттере в ответ дает не совсем среднее rtt по всем пакетам, последние идут с большим весом. По icmp кстати тестировать бесполезно. http://wlan.mipt.ru Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 9 июля, 2009 · Жалоба Ну у меня завернуло в проксю, показало результаты прокси-акселератора. Считать jitter с помощью TCP, надеясь на "трезвость" tcp стека и браузера - вообще помоему наивно. Если я включу CORK, результаты уже будут искажены. А он у меня частенько включен на некоторых прокси. На ICMP надеятся можно, но не всегда. В моем случае используется UDP, плюс я подстраиваю шедулер с обоих сторон. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 9 июля, 2009 · Жалоба В том и фича, что действие алгоритма нагла легко обойти. TCP стек гарантированно трезв для одного пакета из cwnd штук, и этого достаточно. Мешает прокся - http://wlan.mipt.ru:любой порт. А мерять по tcp правильнее всего - его 80 % по каналам идет. И никто не гарантирует, что для tcp, udp, icmp разные очереди где-нибудь не настроены. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 9 июля, 2009 · Жалоба А вы тестировали с включенным TCP_CORK и(или) TCP_QUICKACK ? Я могу сделать "коннектилку" и протестировать, но если как-то можно просто tcp коннектом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 10 июля, 2009 · Жалоба А мерять по tcp правильнее всего - его 80 % по каналам идет. И никто не гарантирует, что для tcp, udp, icmp разные очереди где-нибудь не настроены. Так же никто не гарантирует, что в разные очереди не попадает TCP разных портов, размеров пакетов и прочее. Мерять надо только по UDP, TCP опционально, когда UDP по каким-то причинам невозможен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 10 июля, 2009 · Жалоба У меня текущая точность +-1.5ms, иногда выше. Все зависит от ухода часов на компах... этот вопрос тоже проработаю, хотя нетермостатированные часы синхронизировать - гиблое дело. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 11 июля, 2009 · Жалоба Что там у тебя от ухода часов зависит то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 11 июля, 2009 · Жалоба Смещение часов одной точки измерения относительно другой Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tgz Опубликовано 12 июля, 2009 · Жалоба Такс... Давай тогда тезисно алгоритм. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 12 июля, 2009 · Жалоба Там проще пареной репы все Есть точка А, есть точка B Условно часы в точке A идут с равной скоростью как и в точке B но смещены на величину X. Смещение включает в себя как просто разницу так и величину Tdist, которая равна минимальному количеству времени необходимому для перемещения пакета из одной точки в другую. Так как каналы связи не идеальны, есть еще Toverload возникающий по причине перегрузки оборудования по пути следования пакета. Соответственно мы отправляем скажем 60 пакетов и минимальное время прохождения пакета из А до B будут предположительно равны Tdist. Отклонения от Tdist соответственно составят jitter. Измерения производятся в одну сторону, т.к. RTT (время передвижения пакета из А и B и снова назад в A) слишком непостоянная и неточная величина. Кроме того есть вероятность что связь в разные стороны проходит по разным линиям связи, с разными характеристиками. НО! У каждого осциллятора(кварц) компьютера есть смещение частоты часов. Это смещение может достигать 500ppm(эта цифра взята из даташитов HPET), т.е. в худщем случае за 60 секунд взаимный разброс часов составит 3.6ms. Можно конечно (и видимо попробую сделать в будушем) подсчитать этот уход подсчетом т отклонения минимумов каждую минуту и где-то за 5 минут мы получим Foffset. Но т.к. в компах применяются нетермостатированные генераторы эта величина может колебаться. Поэтому пока я поступил проще, каждые 60 секунд я сбрасываю Tdist. К слову уход часов основанных на TSC (core 2 duo архитектура, constant_tsc в наличии) составлял около 333ppm, а HPET около 50ppm. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...