Неразбериха с сетевой скоростью материнок на NM10 Express

если попытаться по сети записать

Через что?

Это фигня по сравнению с современными телевизорами, куда корячат 100mbs сетевухи в эпоху 4 и 8к.

Через что?

С десктопа на комп с этой материнкой Intel D510MO по сети.

Компы соединены между собой непосредственно добротным кабелем Cat5e, без всяких свичей и пр.

iperf поди запускаешь в несколько I/O потоков, а копируешь в один? Всё наверняка упирается в TCP window size, погляди в учебниках по сетям - там этот момент описан. Или вот статья как пример:

https://introserv.eu/ru/blog/hosting/kak-oczenit-propusknuyu-sposobnost-tcp-mezhdu-serverami/

Вот калькулятор (1000Mbps, RTT 20ms, 64K window size):

https://www.switch.ch/network/tools/tcp_throughput/?mss=1460&rtt=80&loss=1e-06&bw=100&rtt2=20&win=64&Calculate=Calculate

Bandwidth-delay Product and buffer size
BDP (1000 Mbit/sec, 20.0 ms) = 2.50 MByte
required tcp buffer to reach 1000 Mbps with RTT of 20.0 ms >= 2441.4 KByte
maximum throughput with a TCP window of 64 KByte and RTT of 20.0 ms <= 26.21 Mbit/sec.

Попробуй у себя потюнить window size, чтобы добиться больших скоростей:

https://netbeez.net/blog/tcp-window-size/

Это фигня по сравнению с современными телевизорами, куда корячат 100mbs сетевухи в эпоху 4 и 8к.

Есть такое, подключил телевизор и повесил на стену. Смотрю — 100мбит, уже хотел снимать, кабель проверять, хорошо что загуглил.

Впрочем 100мбит достаточно для 4к, проблем нет. Но странно, когда скорость Wi-Fi выше скорости по проводу.

Но странно, когда скорость Wi-Fi выше скорости по проводу.

Ничего странного нет. Скорость wifi вообще ни к чему не привязана, сравни между собой разные стандарты wifi, например. Кроме того, из-за разделяемой среды передачи ты при работе более пары устройств максимальную скорость на wifi всё равно не получишь - коллизии замучают. А уж если весь эфир соседскими точками забит - то о скорости и стабильности wifi только мечтать.

Я про софт. SSH, Samba, NFS?

В iperf если в 1 поток тестировать - тоже 22 МБ/с?

Странно тут другое. 50 центов зажопили на чуть более дорогую гигабитную микросхему?

Вот это полный писос, пришлось отлельную железку ставить для 4к.

у меня такая же материнка - максимальная скорость 870 мбит по NFS. Это наверно особенность чипсета.

а зачем? навряд кто-то на телеке будет бдрипы смотреть с личного наса. а все остальное онлайн - мыльцо которое влезает в 10-20 мбит с головой. нафига там гигабит?

да и я не уверен, что тамошний SoC справится с декодированием потока 100+ мбит на 4к/8к…

iperf гоняйте. может там тупо в тухлый цпу упирается.

ну и да, если сеть pci, а не pci-e - там потолок порядка 700 мбит +-, причем в сумме аплоад + даунлоад.

Ну так если есть поддержка 8к, значит должен справляться, не так ли?

Декодировать может и какой-то отдельный DSP, хотя зачем. Я в теликах не разбираюсь от слова совсем, но, думаю, там примерно та же компонентная база что и в мобилках. А мобилки 4к играют свободно (и даже пишут), 8к мне не встречалось.

Латенси диска какая? Латенси сети какая? Размер блока какой? Пишется в сколько потоков? Какой сетевой протокол (iscsi, nfs, smb, nvme-tcp, sftp)? Ответьте на все вопросы и сами поймёте в чем причина

agentgoblin

iperf поди запускаешь в несколько I/O потоков, а копируешь в один?
Всё наверняка упирается в TCP window size, погляди в учебниках по сетям - там этот момент описан.

iperf запускаю с самым обычным способом, без изысков - с ключами -s и -c

Что-то тюнинга окон. Рассуждаю как самый обнакновенный юзер, который купил материнку, на которой начертана скорость 1000 Mbs.
А раз так, то почему я должен плясать с бубном для ее достижения?
Я уже заплатил за нее, значит, она должны быть такая «из коробки».

А раз ее нет, значит, или микруха RTL8111D кривая (о ней кстати, у нас уже отписались:

Карточки на чипах RTL8111/8168, можно сказать, эталон проблеммного железа.
С ними регулярно какие-то проблемы, причём и под виндой бывают.

либо драйверописаки криворукие.

Но вот вам другой пример, специально поинтересовался у человека, у которого два компа:
- ASUS H87I-Plus
- GA-Z170X-Gaming 3
и при копировании больших файлов по SAMBA (венда, увы) трансфер между жесткими дисками без всяких плясок стабильно держится на уровне ~112 MB/s.

Почему у меня так не получается??

Гигабитная микросхема тащит за собой обвес для гигабита и требования к разводке платы. Тактовая хоть и остаётся 125МГц, но кодирование на гигабите сильно сложнее, что влечёт соответствующие требования к линиям передачи. В итоге 50 центов становятся, условно говоря, 5 долларами. Тебе может такое подорожание не критично, но массовый потребитель жабой удавится.

И если можно сэкономить - то почему бы не сэкономить? Для 4К сотки хватает, поэтому принцип разумной достаточности - более дешёвая микросхема, более дешёвый обвес, более простая разводка платы и т.п. Это ладно бы на ТВ был второй порт, как на SIP-телефонах, чтобы ПК подключать за ним и экономить ethernet-розетку не стене. А тут у тебя оконечный девайс, который даже сотку не выберет на свои нужды.

Рассуждаю как самый обнакновенный юзер, который купил материнку, на которой начертана скорость 1000 Mbs.

Не надо рассуждать как тупая обезьяна, рассуждай как инженер или хотя бы как продвинутый пользователь.

при копировании больших файлов по SAMBA (венда, увы)

Временно поставь в учебных целях венду на свои ПК и попробуй на ней скорость. Я не в курсе, может самба в венде умеет как-то оптимизировать канал или окном вилять без участия юзера. Может в самой ОС окно по дефолту шире.

В конце-концов, попробуй качать файлы разными программами, да хоть ту же самбу подыми на Линуксе. Фундаментальные причины я тебе сказал, ссылки дал. Дальше думай сам, что с этим делать. Мир жестокое место и не зависит от чьих-то фантазий.

https://ru.wikipedia.org/wiki/Jumbo-кадр

Бро, посмотри на цены современных телеков, какие 5 центов, какие 5 долларов? Даже 500 долларов погоды не делают )))

Ещё раз - тебе не делают, а массовому потребителю делают. Я не раз был свидетелем выбора девайса за 10200 вместо девайса за 10500, ВЕДЬ ТРИСТА РУБЛЕЙ НА ДОРОГЕ НЕ ВАЛЯЮТСЯ.

Да что там - ради 50 рублей скидки люди шерстят интернет-магазины и регаются на чёрт знает каких мутных помойках, ведь ЭКОНОМИЯ.

Рассуждаю как самый обнакновенный юзер, который купил материнку, на которой начертана скорость 1000 Mbs.

10 Mbit-сетевухи в реальности никогда не выдавали такой скорости. 6-8, может быть.

Ещё одна ссылка для размышлений. https://en.m.wikipedia.org/wiki/I/O_Acceleration_Technology . Про хайэнд сервера игнорируй, i/oat почти в любом современном чипсете есть, нужно только его включить в бивисе.

Почитал каменты. Окно ТСР, джамбо-фреймы, хорошо. Но все равно есть подозрение, что ТС пропихивает файл сквозь SSH и удивляется.

8к 10-30мбит и 8к 100+мбит две больших разницы какбы.

если iperf по tcp в один поток показывает под гигабит - то сетевуха тут таки ни при чем, от слова вообще.

а вот тухлый некроатом, который толком не может прожевать трафик - может быть очень даже причем…

более того - стриминговые сервисы (а именно для них тв предназначен в первую очередь) не выдают поток хотя бы приближающийся к 100 мбитам. просто потому, что у большинства клиентов он через их канал не пролезет, и потому что дорого такой поток генерить, и хранить где-то такое кол-во данных дорого, и незачем если можно ужать в разы и никто из клиентов этого особо не заметит. а значит, смысла от гигового порта нет вообще.

Ага. Я вспомнил что у атомных чипсетов как раз I\OAT нет, так что он прерываниями захлёбывается. Джамбофреймы реально могут помочь, но их все устройства в сегменте должны уметь, как и сам свитч, и их надо всюду самому включать.

thesis

Но все равно есть подозрение, что ТС пропихивает файл сквозь SSH и удивляется.

Ты умничка! :=)

NiTr0

а вот тухлый некроатом, который толком не может прожевать трафик - может быть очень даже причем…

И ты тоже! :=)

Дайте мне некоторое время для...

thesis и NiTr0, вы просто молодцы - своими догадками попали прямо в точку! ;=)

Я совершенно упустил из виду, что передача по SSH требует жертв изрядных ресурсов - они-то и сожрали оба ядра Атома: top на обоих изображал по ~100%.

А когда перешел на обмен по FTP, скорость легко достигла 91 Mbps!
Хотя ядра все равно были прилично загружены - одно ~100%, второе шаталось около ~67%.

Спасибо за помощь и участие в решении проблемы! :=)

Теперь осталась проблема выбора протокола обмена с бекап-сервером на этом слабеньком Атоме.
Брать то ли FTP, то RSYNC, NFS будет несколько громоздко.

Чтобы вы посоветовали?

NFS будет несколько громоздко

А все-таки попробуй. Я подозреваю, примитивный сетап без шифрования и аутентификации как раз тебя устроит.

На заметку: давно не проверял, но подозреваю, что scp/sftp/fish/etc через openssh (а возможно и прочие реализации) до сих пор тормозит на совершенно любом железе. Так уж оно написано, видимо.

А все-таки попробуй.

В чем будет выигрыш по сранению с FTP/RSYNC?
Понимаю, что если сооружать многокомпьютерную локалку, то NFS как раз для нее и задумана.
Но у меня по сути получается всего лишь двухточка.
А авторизация параноику нужна всенепременно, мало ли какой кулхацкер в сеть пролезет (гипотетически, через вайфай).

В сравнении с FTP - простота настройки, в сравнении с rsync - это ФС, по которой удобно лазить.
Ну а вообще как тебе угодно, конечно.

rsync = ssh

rsync -e «ssh -c arcfour» может немного поднять скорость.

rsync = ssh

Это да, если по простой схеме и соответственно с ключиком "-e"
Но если поднять rsync-сервер, то ssh участовать не будет.

это и были тесты Iperf. 781 мбит было на этой конкретной плате. 1 гбит она не асилит.

Вы о чем, где и у кого было? У меня по FTP было 113 МБ/с - это реальный трансфер, а не мифическая скорость битов.

и при этом писали

максимальная скорость 870 мбит по NFS

при потолке гигабитной сети где-то 920-960 мбит со всеми оверхидами…

Раз уж у тебя всё равно два компа напрямую соединены включи на обоих джамбофреймы в 9000 байт. Будет быстрее и меньше прерываний генерироваться, для Атома актуально тащемто.

ip link set eth0 mtu 9000

Раз уж у тебя всё равно два компа напрямую соединены

Ну, если быть точным, то теперь через Гигабитный свитч.

Меньше прерываний - понимаю, это хорошо.
Интересно, их как-то можно помониторить?

А эту волшебную команду нужно на обоих компах выполнить?
И она как, запоминается после ребута, или нужно всунуть в какой-нить атозапуск?

Ну, если быть точным, то теперь через Гигабитный свитч.

Он наверняка неуправляемый конечно же. Но вполне может джумбы поддерживать.

Меньше прерываний - понимаю, это хорошо.
Интересно, их как-то можно помониторить?

cat /proc/interrupts

Как фильтровать и считать сам разберёшься я думаю, скрипт напишешь. Ну и чисто визуально у ядра процент загрузки должен при полной загрузке канала стать поменьше.

А эту волшебную команду нужно на обоих компах выполнить?

На всех компах в ethernet сети, то бишь подключённых к одному свитчу. Если свитч конечно в джумбы сможет. Но он сможет, я верю. У меня какой то неуправляемый был, и он мог.

Да, чуть не забыл, ВАЖНО. Если у тебя в этот же свитч роутер подключен, на его LAN интерфейсе тоже нужно изменить mtu. Иначе без инета останешься. WAN интерфейс конечно же не трогай, это уже не твоя «зона ответственности».

И она как, запоминается после ребута, или нужно всунуть в какой-нить атозапуск?

Ессно не запоминается, нужно разобраться каким конфигом у тебя сеть настраивается и штатно там прописать mtu. Если это NetworkManager то там можно прямо в его графической морде сетевухе нужный mtu прописать.

Сначала попробуй на обоих компах руками, вот той командой что я показал, только ессно имя интерфейса используй своё. Проверь через ifconfig, применилось ли изменение, поменялось ли значение mtu у интерфейса. Если компы друг друга пингуют после этого — прекрасно, тестируй скорость, ищи как и в каком конфиге в твоём дистрибутиве mtu прописывается (штатный способ ЕСТЬ, ОБЯЗАН быть, и колхозить мою команду в автозапуск не нужно, нужно по человечески сделать).

Если не пингуют — либо верни штатный mtu 1500, либо просто перезапусти оба интерфейса.

Успех конечно на 100% не гарантирован, во первых свитч может уметь только baby jumbo, то бишь 1500+, не более 1600 (точно узнать можно посмотрев в его спецификации, там должен быть указан максимальный размер jumbo frame, у tp-link он например 10k, если эта характеристика вообще отсутствует — значит не умеет).

Во вторых сетевая карта может отказаться назначать большой mtu или начать глючить с ним, «стрёмное» железо бывает, но обычно mtu 9000 умеют все, а вот выше уже не факт. Интеловские карты аж 16k могли ЕМНИП.

Ну и в третьих, важно как у тебя интегрированная сетевая соединяется с чипсетом. Если там PCI-E х1 линк — всё в порядке, но старые чипсеты вполне могут и параллельный PCI юзать через мост. И тут ты в шину упрёшься, что с джумбами, что без джумбов. Можно нагуглить блоксхему на твой чипсет и там посмотреть как что подключается. Ну или выхлоп lspci изучить.

Есть ещё тема с принудительным включением i/oat, но атомные чипсеты в него не умеют, а в тех что умеют поддержка по умолчанию выключена, так как появляется неустранимая аппаратная уязвимость доступа к памяти через механизмы DMA. Но если на безопасность насрать можно вручную включить использование i/oat, тоже помогает снизить нагрузку на камень. Но лучше всего её снижают сетевые карты умеющие в TCP\IP и прочий offload, но такое в десктопное железо не встраивают, это прерогатива серверных матерей и\или дискретных «серверных» сетевых карт.

Jameson
Да, интересная и поучительная история, спасибо!

Свитч да, неуправляемый, простенький - TL-SG1005D.
Наверняка 1-й версии, потому что покупал давненько, а теперь их наклепали, кажись, аж до 9й версии, наверное «оптимизировали» и удешевляли.

На атомной материнкие не -E, а обычная PCI, вот здесь блок-схема чипсета.
На материнке, как уже говорил, стоит RTL8111D (или RTL8111DL, не присматривался), интеловцы пожлобились - на свою же интеловскую материнку вхерачили риалтековскую сетевуху, хотя своих полно.

Ладно, если 100% успех не гарантирован, как думаешь, если таки он будет, насколько разгрузится проц?

Потому что нужной скорости без SSH уже и так добился, может эти новые хитроумные пляски и не стоят того.

На атомной материнкие не -E, а обычная PCI, вот здесь блок-схема чипсета.

Ты в шину упираешься значит, прироста скорости не будет. А вот нагрузка на проц может снизиться.

Ладно, если 100% успех не гарантирован, как думаешь, если таки он будет, насколько разгрузится проц?

Введи две команды на двух компах и проверь сам. Зачем гадать, когда можно узнать?

Потому что нужной скорости без SSH уже и так добился, может эти новые хитроумные пляски и не стоят того.

Хитроумная пляска требует всего минуту на проверку, стоит она того или нет. Это не БИОС похаченой прошивкой шить, это две команды ввести и пингануть. И если не пингуется — вернуть mtu взад и забыть. Ты размышляешь на эту тему дольше чем проверка работоспособности займёт. Изменить mtu на интерфейсе это не «rocket science», это штатный функционал его настройки.

эту цифру показало при тесте, и при копировании NFS. Настолько это точно - я не знаю.