Морфеус68 Опубликовано 20 января, 2020 (изменено) · Жалоба Добрый день! В аппартный Ethernet свитч на hAP AC2 (RBD52G-5HacD2HnD-TC) включены NAS Synology SD118 и телевизор Panasonic 40DXR600. NAS по Гбит, ТВ - по 100Мбит. На NASe стоит медиасервер PLEX, фильмы с которого и крутят на ТВ. По непонятным причинам на ТВ иногда хаотически возникают задержки/прерывания звука/картинки. NAS не нагружен - CPU < 15%, RAM = 45%. Трафик между устройствами не прыгает более 60Мбит. Однако на порту куда включён NAS имею стабильный рост пакетов Rx Overflow. Rx Overflow есть независимо от того, как смотрю фильмы на ТВ - что через клиента Plex, что через DLNA. По умолчанию управление потоком было выключено. После включения с дефолтным буфером ничего не изменилось. Почитав разные источники начал играться с типом и размером буфера... Поставил для этого порта pfifo на 10000 пактов - стало немного лучше. Но всё равно Rx Overflow постоянно растёт, пусть и не так быстро. При просмотре контента с других потребителей, подключённых к другим портам свича или по WiFi, на порту NASa Overflow нет совсем. Могут ли проблемы при воспроизведении быть связаны с Overflow? Правильно ли я настраиваю тип буфера: Queue->Queue Type->New Queue: pfifo; 10000. Далее Queue->Interface Queues->применяем только что созданную на нужный интерфейс. Перезагрузка нужна??? Что ещё можно покрутить/посмотреть? Что посоветуете в данной ситуации? Заранее спасибо! Изменено 20 января, 2020 пользователем Морфеус68 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 20 января, 2020 · Жалоба 4 hours ago, Морфеус68 said: По умолчанию управление потоком было выключено. После включения с дефолтным буфером ничего не изменилось. А счетчик Tx Pause после включения flow control не растет ? На NAS-е jumbo фреймы не включены случайно ? Hw Offload на портах в бридже по факту включен ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 20 января, 2020 · Жалоба 57 минут назад, McSea сказал: А счетчик Tx Pause после включения flow control не растет ? На NAS-е jumbo фреймы не включены случайно ? Hw Offload на портах в бридже по факту включен ? Если контроль включаю только на rx - pause нет. Если включаю и на rx - появляется rx pause. Jumbo Frame на НАСе выключен. Где посмотреть hw offload на бридже? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 20 января, 2020 (изменено) · Жалоба 20 minutes ago, Морфеус68 said: Где посмотреть hw offload на бридже? В Bridge/Ports буква H в статусе (колонка рядом с номером порта). С включенным hw offload коммутация выполняется свитч чипом, и вряд ли настройки буферов/очередей в ROS имеют значение. Для проверки можете переключить порт NAS на 100 мбит, тогда не должно быть ошибок переполнения. Изменено 20 января, 2020 пользователем McSea Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 21 января, 2020 (изменено) · Жалоба 17 часов назад, McSea сказал: Для проверки можете переключить порт NAS на 100 мбит, тогда не должно быть ошибок переполнения. Всё верно - переключил NAS на 100Mbit и Rx Overflow пропали! Это конечно костыль, а как сделать так, что бы и 1Gbit был и ошибок не было? :) Тут пидкинули цитату с форума производителя: Цитата mikrotik forum:-----------If you have a slower interface in the middle of a path you will get overflowsas soon as the interface is to slow to forward all packets.This happens even on lightly loaded interfaces if you have bursts which fill up the buffers.You can reduce this with rx/tx flow control.If enabled the router which gets to much packets sendback pause frames to tell the sending next hop to reduce packet rate.You may try different queuing strategies/buffer sizes. But to big queues might add latency and causebuffer bloat problems.Best is to increase bandwidth of the overloaded link.------------ Получается, что можно попытаться зарезать на порту NASa полосу для ТВ до 100Mbit и попробовать вкючить 1Gbit? Или на самом NASe? Изменено 21 января, 2020 пользователем Морфеус68 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 21 января, 2020 · Жалоба TX/RX flow control может помочь, но надо, чтобы он был включен также на самом NAS-е. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 21 января, 2020 (изменено) · Жалоба 56 минут назад, McSea сказал: TX/RX flow control может помочь А на каких портах его правильно включать? На TV или на NASe? И Rx или Tx? А такая конструкция не заработает: queue simple add name=for_NAS dst=ether3 target=ether4 max-limit=100M/100M Что бы жёстко не ставить порт NASa в 100Mbit Изменено 21 января, 2020 пользователем Морфеус68 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 21 января, 2020 · Жалоба 14 minutes ago, Морфеус68 said: А на каких портах его правильно включать? На TV или на NASe? И Rx или Tx? Что вы flow control боитесь, включайте весь и везде, из за него редко когда проблемы бывают. В данном случае главное чтобы он был включен на порту, куда NAS подключен, и на самом NAS-e. Иначе NAS будет просто игнорировать паузы, которые ему микротик будет посылать, и продолжать передачу. И у интела и у реалтека давно уже в виндовых драйверах он по умолчанию включен, насчет линукса не знаю, проверьте. Насчет очередей - с включенным hw offload это работать не будет, ROS этот трафик не видит, с выключенным будет лишняя ненужная загрузка процессора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 21 января, 2020 · Жалоба 7 минут назад, McSea сказал: Что вы flow control боитесь, включайте весь и везде Я правильно понимаю, что показатель Rx/Tx Pause - это не ошибки, а кол-во пактов ожидавШИХ отправки в результате очереди? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 21 января, 2020 · Жалоба Попробуйте опустить порт до нас-а в 100 мбит. Поди тупо переполнение буфера происходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 21 января, 2020 · Жалоба 4 минуты назад, vurd сказал: Попробуйте опустить порт до нас-а в 100 мбит. ДА, именно так - на 100Mbit всё работает стабильно и без ошибок! Но как забороть 1Gbit? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 21 января, 2020 · Жалоба 2 минуты назад, Морфеус68 сказал: ДА, именно так - на 100Mbit всё работает стабильно и без ошибок! Но как забороть 1Gbit? Поставить свитч, где больше буфера. У вас нас отдает быстрее чем клиент может принять, пакеты встают в очередь. Еще может попробовать ограничить скорость с наса в сторону телика, поставьте там полисер на 60 мегабит, нас поутихнет, телик съест. Так и телик заработает и гигабит сохранится. (экспериментально) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 21 января, 2020 · Жалоба 1 минуту назад, vurd сказал: поставьте там полисер на 60 мегабит уже двигаю мозги в эту сторону... Спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 21 января, 2020 (изменено) · Жалоба 3 hours ago, Морфеус68 said: Я правильно понимаю, что показатель Rx/Tx Pause - это не ошибки, а кол-во пактов ожидавШИХ отправки в результате очереди? Это не ошибки, в TX это кол-во pause фреймов, которые микротик послал NAS-у с "просьбой" приостановить передачу (единица передачи в ethernet называется не пакет, а фрейм). Поэтому на NAS-е также должен быть flow control включен, чтобы он "понял", что от него микротик хочет. Почитайте что-нибудь про это, хотя бы в википедии, там все очень просто. Это все надо пробовать, т.к. стандарты стандартами, а комбинации конкретного железа с софтом имеют свои "особенности". Изменено 21 января, 2020 пользователем McSea Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 22 января, 2020 · Жалоба 12 часов назад, McSea сказал: Поэтому на NAS-е также должен быть flow control включен, чтобы он "понял", что от него микротик хочет. А вот с этим похоже проблемы... Смотрю на NASe: > sudo ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes Как понимать его <pause frame use> - No|Symmetric Receive-only|Symmetric Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 22 января, 2020 · Жалоба 5 hours ago, Морфеус68 said: Как понимать его <pause frame use> - No|Symmetric Receive-only|Symmetric Symmetric Receive-only - только RX т.е. будет обрабатывать входящие pause фреймы, что как минимум требуется в данном случае Symmetric - RX и TX т.е. также будет сам посылать pause фреймы при заполнении буфера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 22 января, 2020 (изменено) · Жалоба Цитата Поэтому на NAS-е также должен быть flow control включен, чтобы он "понял", что от него микротик хочет. Похоже драйвер сетевой карты в NASe не поддерживает изменение параметров Rx/Tx pause: >sudo ethtool -a eth0 Pause parameters for eth0: Cannot get device pause settings: Operation not supported Буду копать в сторону шейпинга через tc... Изменено 23 января, 2020 пользователем Морфеус68 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 23 января, 2020 (изменено) · Жалоба Вообщем, походу сетевая карта в телевизоре какая-то кривая - ставлю на порту в сторону ТВ жёстко 100Mbit без Negotiation и получаю ошибки и фрагментацию. Если включаю Negotiation, но при этом оставляю в выборе ТОЛЬКО 100Mbit - всё ок, никаких ошибок и фрагментации нет! Пока что остался на 100Mbit на порту NASa - ошибок нет и потерь при воспроизведении тоже. P.S. Вчера обновил Mikrotik до 6.44.2 - не помогло! Изменено 23 января, 2020 пользователем Морфеус68 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
McSea Опубликовано 23 января, 2020 · Жалоба 6 hours ago, Морфеус68 said: Вчера обновил Mikrotik до 6.44.2 - не помогло! Не помогло т.к. не от чего - у вас абсолютно нормальная ситуация с переполнением, обычная если из трафик идет из гигабитного порта в 100-ку. Используйте TCP и достаточный буфер в приложении, которое видео воспроизводит, и никаких проблем не будет. TCP сам скорректирует скорость при наличии потерь, не говоря уж о том, что он гарантирует доставку всех пакетов. Я так понимаю, с flow control на NAS-e не проверяли ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 23 января, 2020 · Жалоба 45 минут назад, McSea сказал: Я так понимаю, с flow control на NAS-e не проверяли ? Не взлетело! >ethtool -a eth0 Pause parameters for eth0: Cannot get device pause settings: Operation not supported Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 27 января, 2020 (изменено) · Жалоба Ну вообщем на NASe забороть не получилось - что бы делать шейпер с ограничением по отдельному IP надо предварительно маркировать трафик через mangle. Без него работает только по подсетям целиком. Все сделал через Simple Queue на Mikrotik - работает. Всем спасибо за помощь! Изменено 27 января, 2020 пользователем Морфеус68 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 27 января, 2020 · Жалоба 2 часа назад, Морфеус68 сказал: Ну вообщем на NASe забороть не получилось - что бы делать шейпер с ограничением по отдельному IP надо предварительно маркировать трафик через mangle. Без него работает только по подсетям целиком. Все сделал через Simple Queue на Mikrotik - работает. Всем спасибо за помощь! По отдельному IP [admin@MikroTik_RB750] > queue simple print Flags: X - disabled, I - invalid, D - dynamic 0 name="Notebook to PC" target=192.168.100.252/32 dst=192.168.100.100/32 parent=none packet-marks="" priority=8/8 queue=pcq-upload-default/pcq-download-default limit-at=0/0 max-limit=75M/0 burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 27 января, 2020 · Жалоба 3 часа назад, fractal сказал: По отдельному IP Вы меня не поняли - на NASe НЕ получилось сделать по отдельному IP. На Mikrotik всё завелось! Спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 27 января, 2020 · Жалоба 1 час назад, Морфеус68 сказал: Вы меня не поняли - на NASe НЕ получилось сделать по отдельному IP. На Mikrotik всё завелось! Спасибо! аа, извиняюсь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Морфеус68 Опубликовано 27 января, 2020 · Жалоба Спасибо всем! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...