Да ладно

А ответка какая?

Почти так же, изредко выше 70 выходит

Устройство абонентское какое?

У меня вот

Wifi свисток tp-link wn722n

Ну он слабенький 150 Мбит модуляция. Реальная скорость в чистом эфире около 70

Вот и Сочи еще присоединилось😊

Здравствуй, Сочи :)

Подскажите, у дешевых железок микротика, правильно ли понимаю, что помимо очередей на интерфейсах (/queue interface) есть ещё аппаратные очереди (кольцевой буфер), контроля над которым нет (хотябы счетчиков отброшенных пакетов)?

Это вопрос скорее про свитч-чип

Но то что 2 часа нет ответа прикольно

кольцевой буфер есть у абсолютно любого сетевого интерфейса

я думал, это очевидно

неважно, дешевые железки или дорогие, микротик или айфон

Подскажите, у дешевых железок микротика, правильно ли понимаю, что помимо очередей на интерфейсах (/queue interface) есть ещё аппаратные очереди (кольцевой буфер), контроля над которым нет (хотябы счетчиков отброшенных пакетов)?

https://wiki.mikrotik.com/wiki/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%B0:%D0%9E%D1%87%D0%B5%D1%80%D0%B5%D0%B4%D1%8C_(Queue)

Note: Начиная с v5.8, появился новый тип none и новый тип очереди по умолчанию only-hardware-queue. У всех RouterBOARD данный новый тип очереди будет установлен в качестве умолчательной очереди интерфейса only-hardware-queue покидает исключительно интерфейс, имеющий аппаратный кольцевой буфер дескрипторов передачи (transmit descriptor ring buffer), который действует как очередь в очереди. Обычно, для постановки в очередь на отправку через кольцевой буфер дескрипторов передачи могут быть помещены не менее 100 пакетов. Размер кольцевого буфера дескрипторов передачи и количество пакетов, которые могут быть поставлены в нём в очередь, варьирует в зависимости от типов Ethernet MAC.

😹😹😹😹😹

"покидает исключительно интерфейс, имеющий аппаратный кольцевой буфер"

не читайте, дети, переводные мануалы

"который действует как очередь в очереди", омфг

кому надо, сверху увидит ссылку на оригнальную статью...мистер кот))

именно, пока ее не открыл - даже не мог догадаться, что имелось в виду :)

А как тогда обстоят дела с wifi интерфейсами? Казалось бы only-hardware-queue микротик не дает поставить на беспроводной интерфейс, но! А где тогда происходит накопление кадров для их агрегации в больший фрейм или ожидание переотправки? Ну и вопрос к которому потихоньку подбираюсь wmm или 802.1p.

> правильно ли понимаю, что помимо очередей на интерфейсах (/queue interface) есть ещё аппаратные очереди (кольцевой буфер), контроля над которым нет (хотябы счетчиков отброшенных пакетов)? да, правильно

> А как тогда обстоят дела с wifi интерфейсами? ровно так же, как с Ethernet. отличия минимальны

Проводил некоторые эксперименты с set priority, и при перегрузке интерфейса приоритетным потоком где-то дропаются пакеты из менее приоритетной. К интерфейсу прилеплено дерево... И пакеты дропаются не там. Вопрос - где? Каков там размер буфера? Как с ним вообще подружиться? Как понять что дроп именно там? Где счетчик?

> микротик не дает поставить это не баг, а фича ©

доступа к ring buffer нет и быть не может, это буфер чисто для нужд самого чипа

максимум, что можно с ним сделать - его целиком очистить (варварство)

ну еще можно сказать, что слишком много пакетов/байт туда класть не надо

если у вас теряется что-то в очередях - ring buffer тут не при делах

К чему я этот вопрос поднял, пытаюсь всё понять - как справедливо разделять и контроллировать доступ к среде. И делать это динамически (или автоматически... как угодно можно назвать)

доступом к среде заведует чип, туда лезть не надо

вы можете только сформировать поток данных для отправки в среду, который не превзойдет производительность этой среды

Ну тогда переформулирую... Как справедливо распределить эфирное время? Клиентам с низкими модуляциями даль меньший приоритет, но сохранить необходимую гарантированную полосу, клиентам с большими модуляциями дать больший приоритет (ну естественно в виде дерева с некоторым количеством потомков). Логично, что для этого надо знать верхнюю планку емкости канала, которая не постоянна, по этому дерево должно быть на интерфейсе. Ну и потомки очереди должны классифицировать трафик стейшнов (можно решить вланами и аксесс листами с диапазонами сигналов).

Но на деле получается что при короткой очереди не происходит толком вытеснения менее приоритетной очереди.

Дело в том что в отношении радио производители вводят всякие ухищрения начиная от поллинга и берста (буфера) и т.п. И управляются они драйверами. Все вопросы по физике к производителю. Тонкой Настройкой может быть параметры этих буферов и время поллинга например. Но все равно к производителю драйверов.

Вот с вдс интерфейсами было бы удобно работать, но! Для них выходит что нельзя построить общее дерево? Каждый как отдельный интерфейс, и только буфер чипа внутри себя сам управляется с данными по принципу первый пришел первый уйдешь, если трафик не мечен приоритетами.

А уж как вы в физику передадите большой роли не сыграет. Там все равно усредниться все ваши хотелки

То есть бесполезно вообще ковыряться в этом направлении?

Какой тогда самый оптимальный вариант работы на перегрузках интерфейса?

Ну не совсем. Вы можете до передачи на интерфейс как то определить очередь например.

именно

а какая у вас задача?

На преегрузках не дать слабым клиентам утилизировать много эфирного времени

увы жизнь - боль

не получится

Ну доступ к среде определён физикой.

только жестко отключать тех, кто слабый

Да

не давать использовать слабые модуляции

В идеале конечно хотелось бы разбить даунлинк фрейм ровно по количеству клиентов с равным интервалом (временным) :)

Но...

Ну ок, а если в лоб. 802,1p &

?

так это ж про занятие среды

а вам наоборот надо, не дать занять среду

причем в зависимости не от трафика, а от модуляции

так не выйдет, увы

Ну сильный всёравно всю не съест, тут вопрос тогда как слабому не дать совсем помереть

А с вдсами я правильно понимаю что дерева вообще никак не получится?

Спасибо больше за ликбез! В принципе оправдались мои самые худшие опасения😃

А с вдсами я правильно понимаю что дерева вообще никак не получится?

тут я пас

Из практики - трафик в вдсе не классифицируется на самом влан интерфейсе (если дерево вешать на него). Но мало ли, может что не так делаю. Тут просто ещё больше вопросов возникает. Кто и как получает доступ к буферу, коли нет единой "дырки" в которую льется трафик. Хотя может она там есть, прост абсолютно не управляема

Если вы так хотите то нужно переходить на цифровые синхронные станции. Но блин от них отказываются в пользу шпд для обеспечения большей общей пропускной способности.

можно сделать два канала

один для сильных духом, второй для слабых

(это гипотеза, я хз будет ли работать)

вещать одинаковый ssid

и принудительно деассоциировать тех, кто из слабых стал сильным или наоборот

наркоманский сценарий, кнешн

естественно, понадобится два радио

искусственно задать модуляции на каждом

я так вот пробовал по вланам разбрасывать и они в свою очередь имели приоритеты

Роганулся во первых с бродкастом (один пакет попадает в каждый влан и рассылается столько раз, сколько вланов есть)

и самое гллавное расстройство - дважды тегированный трафик - зло

очередь интерфейса не умеет его понимать как ip (pcq не работает)

и вылетая с какогонибудь влана на клиенте он уже не поймется. Приходилось лепить ещё больше костылей