NiTr0 Опубликовано 21 января, 2019 · Жалоба 6 часов назад, Justas сказал: То есть, я всё правильно понял, что дело в неправильной архитектуре сети и большими буферами стараются "сгладить" косяки архитектуры? Ну, то есть, по хорошему нужно переводить порты коммутатора агрегации, смотрящие в ядро, с 10G на 40G, а порты, смотрящие на доступ, с 1G на 10G, но из-за экономии стараются вытянуть из 1/10G еще хоть что-то? "по-хорошему" - надо переводить абонентов на 10G. и тогда возможно буфер пакетов не будет сильно сказываться (при условии, что к абоненту трафик будет идти через 10G, причем - только один, никаких LACP и никаких обменов абон-абон). иначе - на любом переходе 10G->1G будут проблемы если у свича куриные мозги. 6 часов назад, Saab95 сказал: Кто когда-то арендовывал вланы у крупных операторов знают, что у них постоянно возникают проблемы с блокировкой мультикаста или еще некого трафика да, как там у некротика с мультикастом? все так же дропает? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sheft Опубликовано 21 января, 2019 · Жалоба 17 часов назад, darkagent сказал: Чтоб не ощущать проблем никаких с микроберстами, сеть от поставщика контента до последней мили должна быть гомогенной, но такое не реально даже в теории. Любое перекладывание из большей емкости в меньшую чревато выплескиванием потока. Наглядно такое можно представить взяв бутылку, воронку, и кастрюлю воды... Тогда получается что проблема фундаментальная и появилась ещё во времена 1-2 мбитных клиентов с концентраторами и аплинками на 10 мегабит, второй круг с 10мбитными клиентами и сотками на магистралях... сейчас круг третий? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 января, 2019 · Жалоба Проблема не однозначная. Для TCP - в целом пофик на потери, клиент уменьшит скорость и перезапросит, тут скорее лучше подропать чем оно будет засирать линки и дропаться где то возле клиента. Для UDP/мультикаста - зло, ибо перепосылать в случае стримов некому. Но в целом нефик абоненту мультикаст лить и тогда всё просто. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 21 января, 2019 · Жалоба 17 минут назад, Ivan_83 сказал: Но в целом нефик абоненту мультикаст лить и тогда всё просто +100 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 21 января, 2019 · Жалоба 19 минут назад, Ivan_83 сказал: Для TCP - в целом пофик на потери ну не совсем, если мозги свича куриные, а порт нагружен поболее 50% от полоски - абоны в ЧНН начинают звонить с вопросами "чозанафиг, где мои мегабиы, почему ютуп икает на фуллхд а на спидтесте стыд и срам". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 21 января, 2019 · Жалоба 58 минут назад, sheft сказал: Тогда получается что проблема фундаментальная и появилась ещё во времена 1-2 мбитных клиентов с концентраторами и аплинками на 10 мегабит, второй круг с 10мбитными клиентами и сотками на магистралях... сейчас круг третий? Что-то я вспомнил чувака который многие месяцы выяснял кто ему шейпит UDP, где-то тут на форуме была тема. И вспомнил как на нормальном радиолинке ping -s64000 давало потери, а -s 1400 -i0.001 нет. В момент выстреливания очереди пакетов не хватало буфера по TX, микробёрст не пролазил. А живым трафом мост пригружался на 300-350 метров спокойно без потерь. Может истина где-то тут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 22 января, 2019 · Жалоба 10 часов назад, Ivan_83 сказал: Для TCP - в целом пофик на потери, клиент уменьшит скорость и перезапросит, тут скорее лучше подропать чем оно будет засирать линки и дропаться где то возле клиента. Представьте что будет, если входной канал у оператора 10Г, и процент дропов на сети 5%. Это 500М трафика зазря теряется. Тут выгоднее шейпить в центре, раздувая буфер, и выдавать скорость абонентам. Ведь в случае дропов у абонента будут все те же самые проблемы, что и с увеличением общей задержки, а вот со стороны оператора будет перерасход входящего трафика. 11 часов назад, NiTr0 сказал: да, как там у некротика с мультикастом? все так же дропает? :) Кто вообще такое сказал что микротик дропает мультикаст? Никогда не было такого. Если транспорт L3 то уже не важно, что там внутри передается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 января, 2019 · Жалоба 50 минут назад, Saab95 сказал: Представьте что будет, если входной канал у оператора 10Г, и процент дропов на сети 5%. Это 500М трафика зазря теряется. Тут выгоднее шейпить в центре, раздувая буфер, и выдавать скорость абонентам. Ведь в случае дропов у абонента будут все те же самые проблемы, что и с увеличением общей задержки, а вот со стороны оператора будет перерасход входящего трафика. Я бы на твоём месте не фантазировал а почитал про TCP congestion control. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 22 января, 2019 · Жалоба Исходя из того что в существующих чипах с объёмом буфера не густо, правильнее было бы искать свитч корректно использующий буфер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 января, 2019 · Жалоба @Стич Если будете искать Huawei, то надо искать свитч, который поддерживает команду qos burst-mode enhanced/shared. Не все свитчи/не все платы это умеют http://support.huawei.com/hedex/pages/EDOC110002054831180AFU/02/EDOC110002054831180AFU/02/resources/dc/qos_burst-mode_system_view.html (тут для CE-свитчей, но и для других есть такая команда) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Стич Опубликовано 22 января, 2019 · Жалоба А кто подскажет скоко стоит Huawei для задачи топика и с qos burst-mode enhanced/shared Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 22 января, 2019 · Жалоба 2 минуты назад, Стич сказал: А кто подскажет скоко стоит Huawei для задачи топика и с qos burst-mode enhanced/shared как договоришься. gpl не смотри, там космос по хлеще циски, на деле может оказаться не сильно дороже длинка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 22 января, 2019 · Жалоба 17 минут назад, s.lobanov сказал: @Стич http://support.huawei.com/hedex/pages/EDOC110002054831180AFU/02/EDOC110002054831180AFU/02/resources/dc/qos_burst-mode_system_view.html (тут для CE-свитчей, но и для других есть такая команда) Даже не знаю что и сказать о цене на CE6870EI Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 января, 2019 · Жалоба @Brainiac Я же написал, что эта команда и на других свитчах есть. Просто дока на CE-свитчи доступна публична (без логина на сайте). Не у всех есть логин на сайт huawei Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 22 января, 2019 · Жалоба 1 час назад, Brainiac сказал: Даже не знаю что и сказать о цене на CE6870EI [S6320]dis this | i qos qos burst-mode enhanced slot 0 [S6320]qos burst-mode ? enhanced An interface can occupy only dynamic buffer in this mode extreme An interface can occupy not only dynamic buffer but also static buffer in this mode думаю и в младших моделях можно откопать что-то такое, но лучше уточнить у менеджеров хуавея. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 января, 2019 · Жалоба 8 часов назад, Saab95 сказал: Если транспорт L3 то уже не важно, что там внутри передается. дадада, от только л3 - это маршрутизация. а мультикаст маршрутизировать микротик отродясь нормально не может. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 22 января, 2019 (изменено) · Жалоба 20 часов назад, NiTr0 сказал: "по-хорошему" - надо переводить абонентов на 10G. и тогда возможно буфер пакетов не будет сильно сказываться (при условии, что к абоненту трафик будет идти через 10G, причем - только один, никаких LACP и никаких обменов абон-абон). иначе - на любом переходе 10G->1G будут проблемы если у свича куриные мозги. Не понимаю. Простите. Есть современный коммутатор агрегации с т.н. неблокируемой архитектурой (способен передавать Ethernet-фреймы через свои порты с той же скоростью, с которой они на него поступают по всем портам одновременно), воткнутый в коммутатор ядра на скорости 10G. 20 линков в сторону конечных свитчей доступа на скорости 1G воткнуты в него. Утилизация каждого порта доступа - 400 мбит дуплекс (300 Мбит в сторону доступа/100 Мбит в сторону ядра). Итого 20портов х 400Мбит = 8000 Мбит/с, то есть на магистральном 10G-порте мы наблюдаем 6000 Мбит/с входящего и 2000 Мбит/с исходящего потока. Свободная канальная ёмкость есть с запасом. Пакет на 1500 байт, влетающий в магистральный порт этого свитча, передан коммутатором ядра и принят нашим свитчем на скорости 10G. Далее свитч на принятой скорости, согласно своей неблокируемой архитектуре, тут же передаёт этот пакет для пересылки на необходимый 1G-порт доступа, из которого этот пакет вылетает уже со скоростью 1G согласно скорости линка. Ведь так? Скажем, согласно спецификации линейки D-Link 3420, коммутационная матрица у него - 88 Гбит/с, а скорость перенаправления пакетов: 65,47 Mpps. Как заявляет производитель, при соблюдении этих ограничений, а также ограничений по потолку скорости портов, попадания в буфер рассматриваемого нами пакета и дропов пакетов целом не происходит. Именно по этой причине буфера 2 мегабайта на свитч, очевидно, достаточно, ведь использован буфер будет лишь в моменты несоблюдения установленных ограничений. То есть, производитель какбэ намекает, что нужно соблюдать архитектуру (не упираться в полку) и не превышать лимиты свитча в целом. Однако практика говорит об обратном. Правильно ли я понимаю, что производитель что-то умалчивает и буферизация происходит независимо от нагрузки на коммутатор, а заявляемая "неблокируемая архитектура" на деле не такая уж и неблокируемая? Изменено 22 января, 2019 пользователем Justas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 22 января, 2019 · Жалоба 24 минуты назад, Justas сказал: Не понимаю. Микроберсты, которые не увидеть с усреднением трафика до минут - ни кто не гарантирует, что в "условную секунду времени" на ОДИН из 20 портов 1G из ядра с 10G не прилетит "чуть более 1G", получим дроп. Вот тут и помогает широкий буфер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 января, 2019 · Жалоба 13 минут назад, Justas сказал: Пакет на 1500 байт, влетающий в магистральный порт этого свитча, передан коммутатором ядра и принят нашим свитчем на скорости 10G. Далее свитч на принятой скорости, согласно своей неблокируемой архитектуре, тут же передаёт этот пакет для пересылки на необходимый 1G-порт доступа, из которого этот пакет вылетает уже со скоростью 1G согласно скорости линка. Ведь так? ну прилетел, ушел в порт на передачу. пока передается - прилетел еще один. и еще один. и еще 10 пакетов. а первый только-только в порт пролез к этому моменту. куда все остальные делись? далее, в гиговый порт начинает лезть второй пакет. а с аплинка за это время еще 10 пакетов прилетело. куда они делись? в порт начинает пролазить третий пакет. а с аплинка еще 10 пришло. куда они делись? тут-то буфер и заканчивается - и все новые пакеты дропаются. 16 минут назад, Justas сказал: Правильно ли я понимаю, что производитель что-то умалчивает и буферизация происходит независимо от нагрузки на коммутатор нет. буферизация происходит тогда, когда пакеты прилетают со скоростью большей, чем уходят в порт. тут производитель не врет. вот только проблема в том, что ваши 400 мбит которые вы наблюдаете - это средний трафик. ну т.е. прилетело за секунду 33 тыс.пакетов по 1500 байт - получили 400 мбит. при этом - вполне может прилететь сразу пачкой 33000 пакетов на 10 гбитах за 40 мс, а потом 960мс линк простаивает, и средняя скорость опять же будет 400 мбит на графике. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 22 января, 2019 (изменено) · Жалоба 20 минут назад, bike сказал: ни кто не гарантирует, что в "условную секунду времени" на ОДИН из 20 портов 1G из ядра с 10G не прилетит "чуть более 1G" То есть, если сама архитектура сети и администраторы сети дадут гарантию отсутствия "чуть более 1G", то есть гарантию соответствия архитектуры сети её возможностям, то проблема себя не проявит? 16 минут назад, NiTr0 сказал: ну прилетел, ушел в порт на передачу. пока передается - прилетел еще один. и еще один. и еще 10 пакетов. а первый только-только в порт пролез к этому моменту. куда все остальные делись? далее, в гиговый порт начинает лезть второй пакет. а с аплинка за это время еще 10 пакетов прилетело. куда они делись? в порт начинает пролазить третий пакет. а с аплинка еще 10 пришло. куда они делись? тут-то буфер и заканчивается - и все новые пакеты дропаются. Насколько я понимаю, неблокируемая архитектура свитча подразумевает приём и передачу любого количества пакетов одновременно на скорости, на которой эти пакеты были приняты при условии наличия свободной ёмкости портов, с которых они были приняты или на которые эти пакеты переданы. 16 минут назад, NiTr0 сказал: нет. буферизация происходит тогда, когда пакеты прилетают со скоростью большей, чем уходят в порт. тут производитель не врет. вот только проблема в том, что ваши 400 мбит которые вы наблюдаете - это средний трафик. ну т.е. прилетело за секунду 33 тыс.пакетов по 1500 байт - получили 400 мбит. при этом - вполне может прилететь сразу пачкой 33000 пакетов на 10 гбитах за 40 мс, а потом 960мс линк простаивает, и средняя скорость опять же будет 400 мбит на графике. Если оставить в стороне графики, ведь я могу снимать данные с портов в режиме реального времени. Какие показатели нагрузки на сеть должны быть соблюдены, чтобы буфер коммутатора не использовался вовсе? Изменено 22 января, 2019 пользователем Justas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 22 января, 2019 · Жалоба 19 минут назад, NiTr0 сказал: нет. буферизация происходит тогда, когда пакеты прилетают со скоростью большей, чем уходят в порт. тут производитель не врет. Вы про cut-through? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 22 января, 2019 · Жалоба 8 минут назад, Justas сказал: ведь я могу снимать данные с портов в режиме реального времени Статистика с усреднением в 1 мс? Расскажите, как и на каком оборудовании это можно сделать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Justas Опубликовано 22 января, 2019 (изменено) · Жалоба 12 минут назад, bike сказал: Статистика с усреднением в 1 мс? Расскажите как и на каком оборудовании это можно сделать? Я не специалист в измерениях. Полагаю, есть анализаторы потоков. Тот же tcpdump покажет количество пакетов для данной задачи достаточно точно. Если проблема себя проявляет явно, то и поймать ее анализатором будет несложно. Поймать превышение 1G на порте несложно. Вопрос в другом. Изменено 22 января, 2019 пользователем Justas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 22 января, 2019 · Жалоба 10 минут назад, Justas сказал: Я не специалист в измерениях. Полагаю, есть анализаторы потоков. Тот же tcpdump покажет количество пакетов для данной задачи достаточно точно. Если проблема себя проявляет явно, то и поймать ее анализатором будет несложно. Поймать превышение 1G на порте несложно. Вопрос в другом. Тут вопрос не в превышении полосы, а в том, что в один момент времени может прилететь трафика в порт больше, чем может в него пролезть в текущий момент. Хороший пример микроберста Вам уже давали выше: 43 минуты назад, NiTr0 сказал: вот только проблема в том, что ваши 400 мбит которые вы наблюдаете - это средний трафик. ну т.е. прилетело за секунду 33 тыс.пакетов по 1500 байт - получили 400 мбит. при этом - вполне может прилететь сразу пачкой 33000 пакетов на 10 гбитах за 40 мс, а потом 960мс линк простаивает, и средняя скорость опять же будет 400 мбит на графике. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 22 января, 2019 · Жалоба 26 минут назад, Justas сказал: Полагаю, есть анализаторы потоков. Чем они помогут? Измерять нужно именно на порту коммутатора. А с порта коммутатора дистанционно получать значения счетчиков можно не меньше, чем за минуту. Интерактивно на некоторых коммутаторах можно установить и меньший период (30 или 10 секунд), но микровсплески это все равно не покажет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
