Comments 33
Мне кажется, сеть, в которой микробёрсты случаются постоянно, уже нельзя назвать на 100% не перегруженной.
Поэтому рекомендуется не только включать QoS, но и не превышать oversubscription, который, если мне не изменяет память, составляет 1:20 для пользователей и 1:4 для аплинков.
Поэтому рекомендуется не только включать QoS, но и не превышать oversubscription, который, если мне не изменяет память, составляет 1:20 для пользователей и 1:4 для аплинков.
Что значит постоянно? В посте показаны очень большие цифры, если мы возьмём буфер, например, 4Мб, то он может быть отослан за 33ms.
При этом если свитч не на два порта (как в примере в посте), а, например, на 24, то если половина портов утилизует одновременно треть доступной полосы (в интервале 33мс), то буфер будет заполнен за 8ms. А отправлять буфер можно за 33ms. То есть в течение 33-8=25мс пакеты будут дропаться.
При этом если сами бёрсты мелкими и с большой скважностью (например, два микробёрста в секунду), при средней утилизации в 30%, то мы будем иметь два выпадающих квадратика в секунду при формальной утилизации в 30%.
Заметим, изменение размера буфера с одной стороны ситуацию улучшает, с другой стороны на коммутаторах бывает и 48 портов, а в этом случае всё ещё хужее.
При этом если свитч не на два порта (как в примере в посте), а, например, на 24, то если половина портов утилизует одновременно треть доступной полосы (в интервале 33мс), то буфер будет заполнен за 8ms. А отправлять буфер можно за 33ms. То есть в течение 33-8=25мс пакеты будут дропаться.
При этом если сами бёрсты мелкими и с большой скважностью (например, два микробёрста в секунду), при средней утилизации в 30%, то мы будем иметь два выпадающих квадратика в секунду при формальной утилизации в 30%.
Заметим, изменение размера буфера с одной стороны ситуацию улучшает, с другой стороны на коммутаторах бывает и 48 портов, а в этом случае всё ещё хужее.
Мне кажется, сеть, в которой микробёрсты случаются постоянно
Они в любой сети случаются постоянно. Ну где есть TCP. У кого-то бывают и всплески на сотни тысяч pps сплошь из SYN пакетов, если сеть завирусованная.
но и не превышать oversubscription, который, если мне не изменяет память, составляет 1:20 для пользователей и 1:4 для аплинков.
Эти цифры условны. У меня в крупных офисах переподписка (сейчас посчитал) около 1:10000. Умирают ли они? Нет, всё прекрасно — утилизация боттлнеков небольшая и роутерный QoS отрабатывает хорошо.
И в ЦОДе бывает 1:48. Опять же, надо к вопросу с умом подходить, исходить из задач. Где-то 1:1.3 будет вызывать проблемы.
sherv, хорошая, годная статья, приятно читать. Добро пожаловать в писатели :)
Спасибо. Только 200ms задержки мне кажется сильно оптимистичная оценка. Я имею в виду, что большинство коммутаторов роняют пакеты много раньше.
Именно так. 200ms было просто взято для примера.
Реальные порядки куда менее радужные. Как пример для одного из вендоров — на 24 1G порта выделяется ~2.5MB памяти под буферы в сумме. Я не знаю в деталях как эта память делится между портами, но если предположить топорный сценарий с фиксированным выделением 100KB под каждый порт — для перегрузки и начала потерь хватит бёрста длительностью меньше 1ms.
Реальные порядки куда менее радужные. Как пример для одного из вендоров — на 24 1G порта выделяется ~2.5MB памяти под буферы в сумме. Я не знаю в деталях как эта память делится между портами, но если предположить топорный сценарий с фиксированным выделением 100KB под каждый порт — для перегрузки и начала потерь хватит бёрста длительностью меньше 1ms.
Я не знаю в деталях как эта память делится между портами
Много вариантов. Например, может быть 24мб на всю коробку, shared buffer, динамически распределяющийся между портами.
Где-то бывает ingress queueing, когда наполняются буфера на принимающих пакеты портах (если смотреть верхнюю картинку, то нижние два порта), а исходящий буфер на исходящем порту чисто символический и фактически не используется.
С моей точки зрения это более правильно. Если сеть быстрая, легче кадр перепослать (силами tcp), чем ждать 200мс внезапной задержки.
Неужели нашелся в спб хоть один оператор знающий про microburst?
Удивительное рядом…
Удивительное рядом…
Наверное, тут стоит задуматься о качестве современного образования. У меня нет профильного образования, но то что я слышал от коллег и знакомых — людей учат старым технологиям, которые уже давно не актуальны, плюс преподавательский состав не имеет современной боевой практики. Вот и не может никто рассказать толком про такие тонкости.
У меня тоже образование не из связи. Однако дорогу осилит идущий. И рассказать много кто может, были бы достойные слушатели.
Но как показывает практика учиться никто не хочет. Ни связи, ни мэнеджменту, ни остальному. И это какой-то бич питерских телекомов.
Инерция сознания…
Но как показывает практика учиться никто не хочет. Ни связи, ни мэнеджменту, ни остальному. И это какой-то бич питерских телекомов.
Инерция сознания…
На мой взгляд старые технологии актуальны до сих пор. По сути, идеология создания процессорной техники не сильно меняется уже очень долгое время (закон Мура пока в действии). Современные воплощение, по сути, экстенсивно расширили это на сотни порядков, следуя классическим принципам — ускорения, распараллеливания, конвейеризации и специализации. Конечно спорить с фактом об общем падении уровня образования и оторванности институтов от реальных проектов, я не буду. То есть применить свои знания, если они вдруг есть, теории к практике очень сложно, потому что практика так и осталась основана на той же теории, но выглядит фантастически в её современном воплощении.
microburst это стык как раз связи и выч.техники и больше тут именно выч.техники, не имея профильного образования по связи, а именно по выч.технике, и некоторую часть обучения проведя за стендами с временными диаграммами, понимать что 1 секунда это как средняя температура по больнице, очень просто.
А связь, посмотрим что SDN принесёт в отрасль, возможно это будет тот самый качественный переход.
microburst это стык как раз связи и выч.техники и больше тут именно выч.техники, не имея профильного образования по связи, а именно по выч.технике, и некоторую часть обучения проведя за стендами с временными диаграммами, понимать что 1 секунда это как средняя температура по больнице, очень просто.
А связь, посмотрим что SDN принесёт в отрасль, возможно это будет тот самый качественный переход.
А это сетевой нейтралитет не нарушает кстати?
Так можно начать давать приоритет ssh на http/https, затем приоритет http над торрентами например.
И ещё глупый вопрос, нужно ли заниматься настройкой QoS на WiFi-роутере конечному пользователю? (при условии что роутером пользуется один человек)
Так можно начать давать приоритет ssh на http/https, затем приоритет http над торрентами например.
И ещё глупый вопрос, нужно ли заниматься настройкой QoS на WiFi-роутере конечному пользователю? (при условии что роутером пользуется один человек)
В некотором смысле наверное можно сказать что нарушает, но в данной ситуации это происходит не для прямого извлечения выгоды, а просто для нормального оказания услуги — это техническое нарушение. Реальным нарушением духа понятия нейтралитета будет предпочтение трафику одного сервиса одного поставщика перед другими. То есть если у вас дата-центр где все хостят веб-приложения, и кому то из них вы за плату предоставляете приоритет. Кто-то скажет, что это нормальные рыночные отношения, и будет по своему прав, но это отдельная тема, и я бы не хотел растекаться мыслью по комментарию.
Подводя итог скажем так — нейтралитет понятие придуманное людьми, а мы живём в макромире. Оборудование работает в своём микромире, и там понятие нейтралитета из нашего макромира не имеет смысла.
WiFi в этом сценарии ничем не отличается от проводных сетей — потери происходят не в воздухе же, а конкретно в железе. Если у вас там есть условия для возникновения микробёрстов то для защиты от них QoS настраивать надо. Но с одним абонентом это сравнительно маловероятно, да и на качество WiFi в большей степени действуют другие факторы, например соседские эксперименты с разобранной микроволновкой.
Подводя итог скажем так — нейтралитет понятие придуманное людьми, а мы живём в макромире. Оборудование работает в своём микромире, и там понятие нейтралитета из нашего макромира не имеет смысла.
WiFi в этом сценарии ничем не отличается от проводных сетей — потери происходят не в воздухе же, а конкретно в железе. Если у вас там есть условия для возникновения микробёрстов то для защиты от них QoS настраивать надо. Но с одним абонентом это сравнительно маловероятно, да и на качество WiFi в большей степени действуют другие факторы, например соседские эксперименты с разобранной микроволновкой.
Поддерживаю вопрос.
UFO just landed and posted this here
нормальный там синтаксис, просто сам предмет мозголомный, и толком никем не понмаемый
А так, уверяю вас, многие семьи спасло бы от разрушения управление исходящим трафиком (что вполне доступно на openwrt на куче железа) в виде постановки раздаваемых торрентов в последнюю очередь, чтоб ютуб у других не тормозил из-за потеряных ackов.
А так, уверяю вас, многие семьи спасло бы от разрушения управление исходящим трафиком (что вполне доступно на openwrt на куче железа) в виде постановки раздаваемых торрентов в последнюю очередь, чтоб ютуб у других не тормозил из-за потеряных ackов.
Столкнулся с этим в Ростелекоме (Реутов).
Когда раньше был в БилайнТВ, то всё работало через роутер даже без отдельного свитча.
В ростелекоме же даже на тарифе 50мбит стоит начать что-то качать, как IPTV начинает квадратить. Zyxel Keenetic Giga 2, IGMP proxy.
Техподдержка не может сказать, используется ли QoS, есть ли Vlan Id. Их рекомендация использовать IPTV на отдельном порту бессмысленна, так как 3 точки тв+интернет выливается уже в 6 портов.
Когда раньше был в БилайнТВ, то всё работало через роутер даже без отдельного свитча.
В ростелекоме же даже на тарифе 50мбит стоит начать что-то качать, как IPTV начинает квадратить. Zyxel Keenetic Giga 2, IGMP proxy.
Техподдержка не может сказать, используется ли QoS, есть ли Vlan Id. Их рекомендация использовать IPTV на отдельном порту бессмысленна, так как 3 точки тв+интернет выливается уже в 6 портов.
UFO just landed and posted this here
Очень зависит от схемы сети и района. В некоторых да, но вот представьте что у вас сеть на GEPON по FTTH, классический OLT на сегодня — это 4 аплинка (в лучшем случае, я обычно встречаю 1-2) по 1GB и 256 абонентов на ONUхах тоже гигабитных итого соотношение 1:64 а теперь представьте что время футбольного чемпионата и народ смотрит один и тот же канал в FullHD массово. Тут без калькулятора можно посчитать что будет с аплинком при использовании TCP-HTTP, его зальет под крышку и у всех все будет тупить, при использовании мультикаста провайдер даже не заметит особого роста трафика на аплинке, так что для разных сетей разные технологии.
UFO just landed and posted this here
Рамок нет, мы например отдаем и так и так, в районы на волокне в отдельный порт ONU мультикастом, в районы на меди гоним через астру по http, при этом если у абонента вдруг проблемы с роутером за 300 рублей после ONU (отдельный вопрос нахрена он там), то отдаем и ему по http, этот вопрос решается по заявке, но таких абонов около 2% на волоконном секторе. С точки зрения инженера нет серебряной пули, очень зависит от района, типа подключения, типа железа и еще хреновой кучи факторов, если мы хотим давать именно качественный канал а не просто услугу для вида, так что и микроберсты считать приходится и размеры буферизации для http и кос крутить и затухания на волокне учитывать и еще около 40 параметров мониторить с каждого порта абонента. По поводу плееров, мы рекомендуем абонентам список конкретных моделей плееров, под которые есть своя прошивка и медиапортал, список можно как узнать по телефону техподдержки так и на сайте + в офисе компании их же продаем через офис, для тех кто не хочет заморачиваться с перепрошивкой так что модели гарантированно протестированы с мультикастом. Если абонент привез с али не понятный свисток за 5$ то ему ни один провайдер не гарантирует качественный IPTV по любой технологии, так как эти чудеса массовой промышленности вообще не тянут HD каналы и тут как не отдавай будет и картинка сыпаться и звук крякать. В общем не такое оно черно-белое как вам кажется.
По поводу размеров и конфигурации буферов в различных коммутаторах есть вот такая таблица: http://people.ucsc.edu/~warner/buffer.html
Конечно, сделали её «по слухам», но на безрыбье и такие сведения могут оказаться полезны.
Конечно, сделали её «по слухам», но на безрыбье и такие сведения могут оказаться полезны.
Sign up to leave a comment.
Миф о бесполезности QoS без перегрузки сети