LINUX.ORG.RU

Тормозит сетевое соединение в одном напарвлении


0

1

Есть 2 машины соединенные гигабиткой напрямую, назавем их «A» и «B». У «A» какая-то непонятная встроеная сетевуха не видимая lspci, dmesg выдает название forcedeth. У «B» - Реалтек RTL8111/8168B. Проблема заключается в следующем: сильно падает скорость при скачивании с машины «A». iperf показывает что загрузка с «A» проходит в районе 100 мбит\с, тогда как аплоад с «B» на «A» выдает гигабит. Реальная скорость еще меньше, пробовал скачивать файлы по ftp, sftp, http, nfs - получалось около 150-200кбайт\с. В обратном же направлении таких проблем не наблюдается. Пробовал разные кабели. Подключался к «A» с третего компа, результат тот же, что как бы намекает что проблема в сетевом соединении у «A». У «A» есть еще 2 сетевые карты к 2-м провайдерам. Трафик между ними проходит на обычной скорости. Скорей всего проблема решится использованием еще одной сетевой карты, но пока под рукой нет, да и жалко не использовать уже встроеную. Раньше работало нормально, значит либо я что-то поломал, либо сетевуха накрылась.

CentOS 6 x86_64

dmesg на тот интерфейс периодически выдает eth2: link down. eth2: link up


>Раньше работало нормально, значит либо я что-то поломал, либо сетевуха накрылась.

Ну дак попробуйте на старом ядре. Хотя, если регулярно down/up, скорее сетевуха накрылась.

Как её не видит lspci? Если есть pci id, можно погуглить, forcedeth это NVIDIA nForce chipset?

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

Вот вывод lspci:

00:00.0 RAM memory: nVidia Corporation MCP61 LPC Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3)
00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1)
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2)
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:08.1 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2)
00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control
01:06.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] (rev 8b)
01:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
02:00.0 VGA compatible controller: ATI Technologies Inc RV380 0x3e50 [Radeon X600]
02:00.1 Display controller: ATI Technologies Inc RV380 [Radeon X600] (Secondary)

Те две сетевухи что RTL-8169 и VT6105/VT6106S это другие которые смотрят в сторону провайдеров. А встоеную, через которую подключена локалка, я не вижу.

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

00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)

Пробуйте другое ядро, наверное, можно с livecd.

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

>00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
Не заметил сразу его :). Просто ставил ценось как залог стабильности, и превращать ее во франкенштейна не очень хочется. Кароче поставил другую реалтековскую сетевуху рядом, пока так.

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

>и превращать ее во франкенштейна

Если рядом для теста положить ещё одно ядро и initrd для него, то до франкенштейна будет далеко, зато, если подтвердится, что дело именно в ядре (а не в железе), то можно будет писать багрепорт...

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

Ну, в общем, да. Так и поступлю. Спасибо за совет.

ALeo ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.