LINUX.ORG.RU

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

 ,


2

3

Речь об семействе Intel материнках на базе чипсетов NM10 Express.
Например, классика жанра - Системная плата Intel® D510MO для настольных ПК
Во всех спецификациях для нее указывается примерно следующее:

 Интегрированный сетевой адаптер 10/100/1000
И оказалось, что реальная скорость между такой материнкой и другой, даже покруче, действительно отображается как 1000 Mbs, если измерять утилитой, например, iPerf3.

Но если попытаться по сети записать на диск этой материнки, то скорость с трудом поднимается до ~22 MB/s.

Казалось бы, медленный диск? А вот и нет - внутри этой материнки скорость копирования большого файла с одного диска на другой стартует на скорости 100 MB/s, а потом постепенно снижается и стабильно держится на уровне 50 MB/s.

Непонятно.... Поэтому сделал другой тест - примонтировал кусок памяти в Атоме, и начал заливать в него с другого компа большой файл.
Тут скорость ЖД уж никак не участвует - память намного шустрее.

Так вот, скорость и в этом случае не превышает 22 MB/s. Куда же она девается??

★★★★

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

Anoxemian ★★★★★ ()
Ответ на: комментарий от YAR

Через что?

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

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

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

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/

agentgoblin ()
Ответ на: комментарий от Anoxemian

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

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

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

MaZy ★★★★★ ()
Ответ на: комментарий от MaZy

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

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

agentgoblin ()
Ответ на: комментарий от chukcha

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

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

YAR ★★★★★ ()
Ответ на: комментарий от Anoxemian

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

einhander ★★★★★ ()

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

OpenMind ★★★★ ()
Ответ на: комментарий от shalom_

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

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от OpenMind

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

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от NiTr0

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

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

shalom_ ()

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

no-dashi-v2 ()
Ответ на: комментарий от agentgoblin

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.

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

chukcha ★★★★ ()
Ответ на: комментарий от shalom_

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

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

agentgoblin ()
Ответ на: комментарий от chukcha

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

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

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

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

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

agentgoblin ()
Ответ на: комментарий от agentgoblin

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

Anoxemian ★★★★★ ()
Ответ на: комментарий от Anoxemian

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

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

agentgoblin ()
Ответ на: комментарий от chukcha

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

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

tiinn ★★★★★ ()

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

thesis ★★★★★ ()
Ответ на: комментарий от shalom_

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от chukcha

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

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от agentgoblin

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

NiTr0 ★★★★★ ()
Ответ на: комментарий от NiTr0

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

Jameson ★★★★★ ()
Ответ на: комментарий от thesis

thesis

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

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

NiTr0

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

И ты тоже! :=)

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

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

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

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

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

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

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

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

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

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

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

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

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 3)
Ответ на: комментарий от thesis

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

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

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

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

thesis ★★★★★ ()
Ответ на: комментарий от NiTr0

rsync = ssh

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

chukcha ★★★★ ()
Ответ на: комментарий от OpenMind

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

chukcha ★★★★ ()
Ответ на: комментарий от OpenMind

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

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

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

NiTr0 ★★★★★ ()

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

ip link set eth0 mtu 9000
Jameson ★★★★★ ()
Ответ на: комментарий от Jameson

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

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

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

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

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

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

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

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

cat /proc/interrupts

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

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

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

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

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

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

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

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

Jameson ★★★★★ ()
Последнее исправление: Jameson (всего исправлений: 5)
Ответ на: комментарий от chukcha

Успех конечно на 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 ★★★★★ ()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

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

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

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

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

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

chukcha ★★★★ ()
Ответ на: комментарий от chukcha

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

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

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

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

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

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

Jameson ★★★★★ ()
Ответ на: комментарий от NiTr0

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

OpenMind ★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.