Comments 14
UFO just landed and posted this here
> планировщик Windows решал, что пора прервать выполнение нашей программы.
В смысле программы, отправляющей запросы?
В смысле программы, отправляющей запросы?
Да, программы отправляющей и принимающей запросы.
Я совсем запутался. Одна программа и отправляет и принимает? ICMP? :) Опишите подробнее схему эксперимента, если не сложно. И сколько запросов в секунду слали.
И еще на код интересно взглянуть.
И еще на код интересно взглянуть.
Тестовая программа использовала WinPcap для посылки и приёма ICMP Timestamp. Схема эксперимента до крайности проста — посылаем запрос и ждем ответа на него, спим n миллисекунд,…, выводим результаты по мере поступления. Данные собирались с большого количества машин.
Точные цифры задержек, как и код, сейчас привести не могу — всё осталось на работе.
Точные цифры задержек, как и код, сейчас привести не могу — всё осталось на работе.
UFO just landed and posted this here
а что минусуете, господа. «изобрести» масштабирование окна в 21ом веке это та ещё хохма, оно в протоколе присутствует с момента его создания.
Проблема не в масштабировании окна, которое, кстати, не сразу появилось в rfc по tcp, а вышло в виде отдельного RFC 1323 в 1992 году (через 11 лет после RFC 793), а в том, как его масштабировать. Алгоритмов весьма много, почитать можно тут — en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm
А вот ссылка на разработанный и исследовательским центром Microsoft алгоритм — research.microsoft.com/apps/pubs/default.aspx?id=70189 документ 2005 года.
Кстати, в виде патчей этот алгоритм доступен и для Linux.
А вот ссылка на разработанный и исследовательским центром Microsoft алгоритм — research.microsoft.com/apps/pubs/default.aspx?id=70189 документ 2005 года.
Кстати, в виде патчей этот алгоритм доступен и для Linux.
UFO just landed and posted this here
Расскажите пожалуйста полностью суть проводимого эксперимента. В частности я не понял следующее:
— Какие машины использовались в качестве измерителей (такие же хосты с Windows судя по WinPcap);
— Как Вы боролись в программе получателе с Task schedule? Играли какими-то приоритетами выполнения или запускали приложение в Single mode?
— О каком сервере ICMP идет речь? Это дополнительный ICMP сервер или это плюшки самого драйвера TCP/IP?
— Возможно ли портировать ваше приложение под Minix или QNX и повторить данный эксперимент там? Или хотя бы на какой-то RT Linux.
Вообще статья достаточно интересная. Спасибо Вам за публикацию исследований.
Жалко, что это не первый и не последний «сюрприз» от Microsoft.
— Какие машины использовались в качестве измерителей (такие же хосты с Windows судя по WinPcap);
— Как Вы боролись в программе получателе с Task schedule? Играли какими-то приоритетами выполнения или запускали приложение в Single mode?
— О каком сервере ICMP идет речь? Это дополнительный ICMP сервер или это плюшки самого драйвера TCP/IP?
— Возможно ли портировать ваше приложение под Minix или QNX и повторить данный эксперимент там? Или хотя бы на какой-то RT Linux.
Вообще статья достаточно интересная. Спасибо Вам за публикацию исследований.
Жалко, что это не первый и не последний «сюрприз» от Microsoft.
Вы правильно поняли, в качестве измерителей использовались Windows машины.
С таск шедьюлером бороться не пришлось, с ним просто пришлось считаться.
За ICMP отвечает драйвер стека tcpip.sys
Да, портирование вполне возможно на любую ОС в которой есть pcap. Разницы в результате не будет, так как через WinPcap посылаются вручную собранные пакеты и ОС, на которой выполняется тестовое приложение, не должна по идее вносить значительных искажений.
С таск шедьюлером бороться не пришлось, с ним просто пришлось считаться.
За ICMP отвечает драйвер стека tcpip.sys
Да, портирование вполне возможно на любую ОС в которой есть pcap. Разницы в результате не будет, так как через WinPcap посылаются вручную собранные пакеты и ОС, на которой выполняется тестовое приложение, не должна по идее вносить значительных искажений.
> Разницы в результате не будет, так как через WinPcap посылаются вручную собранные пакеты и ОС, на которой выполняется тестовое приложение, не должна по идее вносить значительных искажений.
То есть tcpip.sys в точности отдает пакеты в момент запроса через pcap без различного рода передачи управления другим драйверам. Просто мне кажеться, что измерить реальное время отправки пакета и организовать одинаковый их поток (равномерный) это если только писать на уровне драйвера какой-то код. Или делать ICMP-устройство отсылающее 1 раз в ms пакет.
Хотя видимо я не понял сути вашего эксперимента.
То есть tcpip.sys в точности отдает пакеты в момент запроса через pcap без различного рода передачи управления другим драйверам. Просто мне кажеться, что измерить реальное время отправки пакета и организовать одинаковый их поток (равномерный) это если только писать на уровне драйвера какой-то код. Или делать ICMP-устройство отсылающее 1 раз в ms пакет.
Хотя видимо я не понял сути вашего эксперимента.
Ум. по умолчанию в винде начиная с ХР, кажется, фаервол наглухо по ICMP блокирует даже пинги, но говоря уже про icmp time и прочее.
По крайней мере, у меня политиками на все машины принудительно настроено отвечать на пинг в фаерволе, пока я на это не напоролся (да, всус и на всех машинах применены все апдейты)
По крайней мере, у меня политиками на все машины принудительно настроено отвечать на пинг в фаерволе, пока я на это не напоролся (да, всус и на всех машинах применены все апдейты)
Sign up to leave a comment.
Особенности поведения нового TCP/IP стека Windows