Совершенно верно. Методология предполагает тестирование каналов, а не базовой станции все таки, для этого существуют другие системы, в том числе распределенные. Например, когда в нужных точках устанавливаются сенсоры, а управляются они из центра. Из самого простого что приходит в голову — TWAMP во всех его проявлениях.
Было бы здорово, если бы заинтересованные хабражители написали бы сюда, в личку или на почту (для тех кто не зарегистрирован) какие практические аспекты хотели бы видеть. Т.е. я могу конечно сделать «ванильный» тест и приложить сриншоты, но это будет не многим лучше чем текущий формат. Хотелось бы несколько оживить материал, придать ему динамики.
Что вы имеете ввиду? Ведь если рассматривать беспроводные мосты, радиодоступ и даже wifi всего лишь как транспортную среду, то тестирование канала ничем не отличается. Я имею ввиду, что если вы покупаете канал с определенными параметрами и для вас это «черный» ящик, то тестируя его на соответствие параметрам, для вас как наблюдателя нет никакой разницы «а что в черном ящике?». Если же имеется ввиду wifi сети и тестирование с уклоном на их топологию, например эмуляции 20..200..2000 клиентов, то конечно же этот тест не показателен.
Можно сказать так, что самый влиятельный параметр — это время теста, задаваемое пользователем, что очевидно. Если вы задаете какое-то время, то для каждого выбранного размера фрейма будет выполнятся сове тестирование, что увеличивает общее время тестирования пропорционально количеству фреймов.
Полагаю, что вопрос не ограничивается желанием пользователя установить время тестирования, так что можно рассмотреть зависимость от других параметров.
Возьмем для примера, пропускную способность. Поскольку она измеряется так
изначально проверяется заданная скорость
если есть потери, то скорость тестового потока уменьшается в половину
если потерь нет, то увеличивается на половину текущей
если снова потери, то снова уменьшается и так далее
то задача нахождения «обеспеченной» скорости фактически решается численным методом за полиномиальное время, т.е. временные затраты на ее решение определяются достаточной для нас точностью этого измерения.
Для тестов задержки и back-to-back фактором времени будет необходимая повторяемость (для задержки 1 тест в 60 сек, а для back-to-back требуется не менее 50 измерений)
Если интересна реальная цифра — могу без проблем запустить настоящий тест и приложить скриншоты с параметрами теста и результатами.
Очевидно, что если компьютер поставить на базе архитектуры AMD64 (проц amd или intel), то он будет дешевле и быстрее, чем любые специализированные процессоры, просто из-за массовости производства.
Вы не поверите на сколько вы близки к истине. Juniper вообще изначально имеет на борту комп x86 с переработанной FreeBSD и не скрывает этого, а к компу присоединен DataPlane, который через шину (и драйвер) общается с ОС в обоих направлениях. CISCO тоже раньше ставила процы от моторолы, а на днях довелось разобрать (вроде 3750) коммутатор, так там intel и amd (я так понимаю от серии зависит) на MCU уже давно.
Давайте без намеков, вы правильно подметили. По сути, я не писал, что GCC плохой, как не писал и то, что он хороший. Намек на статью был в контексте, что у разных компиляторов различное качество кодогенерации. Сейчас мы об этом качестве не говорим. Если мы обратимся к оригинальной статье с оригинальным кодом, который мы здесь обсуждаем, то можно увидеть, что статья написана в 2012 году, т.е. тоже не самая свежая. А как вы верно подметили, пять лет назад GCC, возможно, был не такой хороший (или плохой), как сейчас. Соответственно вывод о том, что генерируется идентичный код (с циклом и переходом), в то время не совсем корректно. Для текущей ситуации в настоящем времени допускаю, что итог работы будет идентичным. Ваше же заявление выглядело довольно категорично, поэтому я и привел ссылку тоже мнение, опирающееся да, на субъективную оценку, но в поле нескольких рассмотренных кодогенераторов.
Не всегда зло. Автор скорее всего понимал и экономил память программ. В контроллере с таким количеством памяти goto может занимать сильно меньше места чем if/case statemets. Однако преждевременно так оптимизировать не стоит!
From 172.16.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1480)
ping: local error: Message too long, mtu=1480
То, что вы задаете в опции -s в man описывается как:
-s packetsize
Specifies the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
Т.е. опция задает размер пакета (на самом деле payload, полезной части) и трансформирует его в реальный ICMP пакет со всеми заголовками. Таким образом в скобках указывается реальный размер сформированного пакета. Именно он и должен «протиснуться» в минимально доступный MTU канала.
Как видим, в первом случае пакет вообще не прошел. Во втором, ICMP честно сказал, что нужна фрагментация (происходит это где-то на границе MTU).
Опытным путем — это путем постепенного уменьшения MTU? Можно откусывать по 1.
Что касается вашего случая, то вполне вероятно, что где-то съедено еще 12 байт. Можно предположить, что канал в vlan'е — это 4 байта, к которому добавлен mpls-vpn — еще 8 байт, итого 12. Т.е. получается VLAN+MPLS_VPN+PPPoE=4+8+8=20, соответственно при настройке хоть одного коммутатора на пцти пакета на максимальный MTU 1500 мы получаем 1500-20=1480. Вроде все сходится. Но это лишь предположение.
На самом деле не думаю, что провайдер будет делать секрет из значения MTU, если вы его спросите, разве что ребята в саппорте могут быть реально не в курсе дела и ваш вопрос им покажется из области секретных материалов.
В большинстве случаев для домашних пользователей это не очень актуально, поскольку есть механизмы, позволяющие оборудованию определить MTU, например Path MTU Discovery, если мы говорим о классическом Ethernet. Кроме того, интернет провайдеры берут не себя большую часть головной боли, связанной с согласованием MTU. Например, как в вашем случае с PPPoE, при проектировании и строительстве сети оператор, скорее всего, учитывает совместимость сети с оборудованием, т.е. в классическом представлении выглядит это так: на сети MTU 1500, соответственно для PPPoE MTU понижается до 1492 (PPP Protocol ID (2) + PPPoE header (6) = 8). В качестве проверки вы можете выполнить ping, как указано в статье, указав размер пакета 1492 и ping должен пройти. В GNU/Linux можно выполнить команду:
Ну как я написал чуть выше, в рамках эксперимента я прокидывал через TOR openvpn, что позволило пропускать через TOR любой трафик. Напрямую в TOR udp трафик я действительно не знаю как направить.
Вы описали свой подход с точки зрения деанонимизации при неявном или неожиданном поведении программного обеспечения, т.е. защиты от «сюрпризов». Он действительно работает.
Я же задал свой вопрос исходя из контекста статьи и предполагал, что вы как-то решили задачу «заворота» трафика любого типа в TOR.
Простите пожалуйста, но в чем заключалось «опингвинивание» этой платы? Если только в том, чтобы собрать из стандартного тулчейна стандартную прошивку fw.bin, то какое-то странное «опингвинивание».
Скорость пересылки (особенно NAT) на больших пакетах не очень интересна, а как дела обстоят с загрузкой и потерями на «мелких» пакетах совсем на раскрыто, а было бы реально интересно, поскольку позволило бы судить о «внутренностях» карты.
Полагаю, что вопрос не ограничивается желанием пользователя установить время тестирования, так что можно рассмотреть зависимость от других параметров.
Возьмем для примера, пропускную способность. Поскольку она измеряется так
то задача нахождения «обеспеченной» скорости фактически решается численным методом за полиномиальное время, т.е. временные затраты на ее решение определяются достаточной для нас точностью этого измерения.
Для тестов задержки и back-to-back фактором времени будет необходимая повторяемость (для задержки 1 тест в 60 сек, а для back-to-back требуется не менее 50 измерений)
Если интересна реальная цифра — могу без проблем запустить настоящий тест и приложить скриншоты с параметрами теста и результатами.
Вы не поверите на сколько вы близки к истине. Juniper вообще изначально имеет на борту комп x86 с переработанной FreeBSD и не скрывает этого, а к компу присоединен DataPlane, который через шину (и драйвер) общается с ОС в обоих направлениях. CISCO тоже раньше ставила процы от моторолы, а на днях довелось разобрать (вроде 3750) коммутатор, так там intel и amd (я так понимаю от серии зависит) на MCU уже давно.
Не обязательно все, но те, что превышали ваш MTU — да. Далеко ведь не все пакеты посылаются с максимальным MTU.
То, что вы задаете в опции -s в man описывается как:
Т.е. опция задает размер пакета (на самом деле payload, полезной части) и трансформирует его в реальный ICMP пакет со всеми заголовками. Таким образом в скобках указывается реальный размер сформированного пакета. Именно он и должен «протиснуться» в минимально доступный MTU канала.
Как видим, в первом случае пакет вообще не прошел. Во втором, ICMP честно сказал, что нужна фрагментация (происходит это где-то на границе MTU).
Опытным путем — это путем постепенного уменьшения MTU? Можно откусывать по 1.
Что касается вашего случая, то вполне вероятно, что где-то съедено еще 12 байт. Можно предположить, что канал в vlan'е — это 4 байта, к которому добавлен mpls-vpn — еще 8 байт, итого 12. Т.е. получается VLAN+MPLS_VPN+PPPoE=4+8+8=20, соответственно при настройке хоть одного коммутатора на пцти пакета на максимальный MTU 1500 мы получаем 1500-20=1480. Вроде все сходится. Но это лишь предположение.
На самом деле не думаю, что провайдер будет делать секрет из значения MTU, если вы его спросите, разве что ребята в саппорте могут быть реально не в курсе дела и ваш вопрос им покажется из области секретных материалов.
Здесь про nginx.
Здесь про Apache.
Вы все верно описываете, я про это и писал.
Вы описали свой подход с точки зрения деанонимизации при неявном или неожиданном поведении программного обеспечения, т.е. защиты от «сюрпризов». Он действительно работает.
Я же задал свой вопрос исходя из контекста статьи и предполагал, что вы как-то решили задачу «заворота» трафика любого типа в TOR.
Простите пожалуйста, но в чем заключалось «опингвинивание» этой платы? Если только в том, чтобы собрать из стандартного тулчейна стандартную прошивку fw.bin, то какое-то странное «опингвинивание».
Скорость пересылки (особенно NAT) на больших пакетах не очень интересна, а как дела обстоят с загрузкой и потерями на «мелких» пакетах совсем на раскрыто, а было бы реально интересно, поскольку позволило бы судить о «внутренностях» карты.