В кабеле =). На какой скорости происходит согласование?

Да, забыл сказать про кабели - каждый фирменный пачкорд на 1 Гбит длиной всего в пол-метра.
А как в Линуксе определить скорость согласования?

ethtool p10p1 | grep Speed ?

Вместо p10p1 постав имя своего интерфейса.

На обоих компах показало: Speed: 1000Mb/s

Без коммутатора пробовал? Воткни кабель напрямую в карты, если это возможно,
Шейпера никакого нету?
Как тестишь скорость?

Без коммутатора пока не могу. Шейперов нет, система минимальная.
Тестю копированием MC, rsync, ftp - без разницы.

Но вот какая мысль: может ли конфигурация сети влиять?
Потому что она такая:
1-й комп воткнут в свич и имеет ip=217.11.11.11 и провайдерский шлюз 217.11.11.01
2-й комп воткнут в свич и имеет ip=217.11.11.12 и провайдерский шлюз тоже 217.11.11.01
Третий кабель уходит из свича к провайдеру по кабелю на 100 Мб/с.

И хотя компы связаны между собой трассой на 1000 Мб/с, но может, при копировании пакеты уходят также и к провайдеру (не знаю зачем) и общая скорость падает до 100 ?

ФС какая? Чай нтфс раздел?

И хотя компы связаны между собой трассой на 1000 Мб/с, но может, при копировании пакеты уходят также и к провайдеру (не знаю зачем) и общая скорость падает до 100 ?

Попробуй выдернуть провайдера и прогнать тесты. Может свитч автоматом подстраивается под минимальную скорость?

А маска на обоих?

Кабель заменить пробовали?

Провайдер не вломал люлей за такую схему?
Ты про такую штуку как роутер слышал?

Правильный вариант:

кабель от провайдера приходит в роутер, тогда внутреннюю сетку крутишь как хочешь.

Или у тебя на обеих ПК внешний IP ? если да то и не удивительно что у тебя 100Мб\с, твои пакеты идут сначала на шлюз потом обратно на другой ПК. Другими словами через инет и соточный линк провайдера.
ip=217.11.11.11 - сам придумал?

маска сети к скорости никакого отношения не имеет.
При разных масках он бы попросту «не увидел» оба ПК, без основного шлюза на котором прописаны соответствующие маршруты.

«Попробуй выдернуть провайдера и прогнать тесты.» - плюсую.

«Может свитч автоматом подстраивается под минимальную скорость»
Ни один коммутатор от не управляемого до L3 уровня и т.д АВТОМАТОМ скорости не подстраивает. По сути ему без разницы, если позволяет пропускная способность пропускать поток он его пропускает в полной мере. Речь идет об одном коммутаторе, а не о двух между которыми соточный линк.

Да и к стати, провайдер мог на свиче установить ограничение скорости на портах, ты будешь видеть подключение к сети 1Гб\с а скорость будет скажем 100Мб\с.

При разных масках он бы попросту «не увидел» оба ПК, без основного шлюза на котором прописаны соответствующие маршруты.

А это, кстати, может и быть проблемой. Если из-за маски всё идёт не напрямую комп <-> комп, а через шлюз.

Ни один коммутатор от не управляемого до L3 уровня и т.д АВТОМАТОМ скорости не подстраивает. По сути ему без разницы, если позволяет пропускная способность пропускать поток он его пропускает в полной мере. Речь идет об одном коммутаторе, а не о двух между которыми соточный линк.

По логике вещей, да. Но глюки всякие бывают.

Айпишники здесь я нарисовал от балды, на деле же они нормальные «белые», и каждый комп нормально связывается с Интернет и по ip, и по именам, а также друг с другом по ip. Маски тоже очень правильные.

Да и к стати, провайдер мог на свиче установить ограничение скорости на портах, ты будешь видеть подключение к сети 1Гб\с а скорость будет скажем 100Мб\с.

Да это мой собственный свич, не провайдерский, причем тупой неуправляемый.
Копирование файлов идет между компьютерами через этот свич, поэтому не пойму, зачем копируемым пакетам забегать еще и к провайдеру, что они там забыли?
Я бы выдернул провайдерский кабель из свича, но тогда я потеряю связь с этими компами, потому что доступ к ним через этого провайдера.
А физического доступа (клава, монитор) к этим компам нет, это сервера.

traceroute сделай от одного компа к другому, ага.

Айпишники здесь я нарисовал от балды, на деле же они нормальные «белые», и каждый комп нормально связывается с Интернет и по ip, и по именам, а также друг с другом по ip. Маски тоже очень правильные.

Повесь алиасом серые адреса и посмотри с какой скоростью они будут общаться.

Трассировка с одного компа на другой дала примерно такую картину:

traceroute 95.55.80.11
traceroute to 95.55.80.11 (95.55.80.11), 30 hops max, 60 byte packets
1 ip-4613.my.provider.ru (95.55.80.11) 0.146 ms !X 0.103 ms !X 0.074 ms !X

или такую:

tracepath 95.55.80.11
1: ip-47dc.my.provider.ru (95.55.80.22) 0.233ms pmtu 1500
1: ip-4613.my.provider.ru (95.55.80.11) 0.571ms !H
1: ip-4613.my.provider.ru (95.55.80.11) 0.578ms !H

Resume: pmtu 1500

где 95.55.80.11 - один компьютер, 95.55.80.22 - второй.

Серые альясы попробую повесить завтра.

Вы где все, ау? :)

Второе испытание - повесил на оба компы альясы eth0:0 такого содержания (IPADDR, ессно, разные):

DEVICE=eth0:0
BOOTPROTO=static
BROADCAST=10.0.0.15
ONBOOT=yes
IPADDR=10.0.0.220
NETMASK=255.255.255.240
NETWORK=10.0.0.0
IPV6INIT=no

Перезапустил network. Появились интерфейсы eth0:0
Но чего-то компы не пингутся по этим адресам :(

свич, говоришь?

а разве второго уровня osi достаточно для твоих целей?

значит прийдеться топать к серверам, выткнуть провайдера и прописать на одном 192.168.0.10\24 и 192.168.0.11\24 на втором.
Проверить.

«Айпишники здесь я нарисовал от балды» вот в этом то и дело, мы то не знаем какие у них маски, может они вообще в разных сетях.
Твои IP точно на одну последнюю цифру отличаются?

Если маски разные то 100% всё ходит через шлюз и вот тебе твои 100Мб\с

Чем скорость меряется? iperf?

значит прийдеться топать к серверам, выткнуть провайдера и прописать на одном 192.168.0.10\24 и 192.168.0.11\24 на втором.

А какой при этом указать BROADCAST ?

вот в этом то и дело, мы то не знаем какие у них маски, может они вообще в разных сетях.

для ip=95.55.80.11/22 маски одинаковы и равны 255.255.254.0

Твои IP точно на одну последнюю цифру отличаются?

Да, на последнюю (вернее, на последнюют тетраду)

BROADCAST=10.0.0.15
IPADDR=10.0.0.220

WTF? Поставь NETMASK=255.255.255.0 и BROADCAST=10.0.0.255 и не выделывайся. Или правильно расчитай BROADCAST.

да кокой BROADCAST!!!

На обеих ПК -> route del default gw

PC1 -> ifconfig eth0 192.168.0.10/24
PC1 -> ifconfig eth0 192.168.0.11/24

PC1 ping 192.168.0.11
PC2 ping 192.168.0.10

Твой «свич», он управляемый или нет? Если неуправляемый, то просто настрой маршрутизацию правильно на своих двух компах. Если управляемый, то дополнительно его настроить нужно.

«ip r» покажи с обоих компов.

Выдываемые белые адреса статические или динамические?

Для примера:

127.0.0.1 - шлюз провайдера
127.0.0.10 - белый адрес комп1
127.0.0.20 - белый адрес комп2

на первом компе
ip r a 127.0.0.20 dev eth0

на втором компе
ip r a 127.0.0.10 dev eth0

на первом компе
# ip r
default via 127.0.0.1 dev eth0
127.0.0.20 dev eth0  scope link

на втором компе
# ip r
default via 127.0.0.1 dev eth0
127.0.0.10 dev eth0  scope link

andrewzvn :
Кто еще выделывается-то - указал эти настройки, пинги по альясам пошли, только белые eth0 почему-то пропали из внешнего доступа - из Интернета они стали недоступны :evil:

Отвязал альясы - снова Инет восстановился. В-общем, запутали вы меня, советов много и очень много, уже не понимаю, что делать :(

Кто еще выделывается-то - указал эти настройки, пинги по альясам пошли, только белые eth0 почему-то пропали из внешнего доступа - из Интернета они стали недоступны :evil:

А чего ты хотел добится изменяя основной адрес? Нужно DEVICE=eth0:1

Про выделыватся я имел ввиду использование масок сети не кратных 255. И давай вывод ifconfig в студию.

Да уже грохнул альясы eth0:0, потому что запутался окончательно.
Привожу компы в исходное доальясовское состояние, а то они ведут себя теперь как-то неадекватно.
Разве что начать все сначала...

eth0:0 - не алиас, а синоним eth0.

MTU

MTU на интерфейсах какой?

Если 1500, то гигабита не будет.

Нужно включать jumbo frames. MTU 6000-9000, сколько карточки и свич потянут.

Если 1500, то гигабита не будет.

А можно поподробней откуда это следует?

гон

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.24  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:1e:67:6a:88:b1  txqueuelen 1000  (Ethernet)
        RX packets 975953559  bytes 149742842615 (139.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1103008755  bytes 714491864348 (665.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  memory 0xc1b00000-c1b20000 

Не совсем точно выразился.

Физически соединится на гигабите, но при использовании простых карточек, делающих прерывание на каждый пакет и не умеющих checksum offload, реальная скорость обмена будет значительно ниже 100 Мбайт в секунду.

Хотя у ТС 8-9Мбайт в секунду, что слишком мало даже для такого случая...

Скорость трансфера как мерилась?

iperf?

Или просто копирование по NFS/Samba?

Нужно померить iperf или хотя бы

nc -l 8888 </dev/zero на одном компе и

nc xx.xx.xx.xx 8888 |pv >/dev/null на втором

Это покажет что-то более менее практическое, но не ограниченное жестким диском и файловой системой.

И все-таки, что говорит

ethtool eth0

А разве для этого случая не используется NAPI:
http://www.ibm.com/developerworks/ru/library/l-linux_kernel_32/

Поэтому в Linux был добавлен набор API для обработки подобных потоков пакетов, поступающих с высокоскоростных интерфейсов, который получил название NAPI (New API). Его идея состоит в том, чтобы осуществлять приём пакетов не методом аппаратного прерывания, а методом программного опроса (polling), точнее, комбинацией этих двух возможностей:

polling используется, если его включить...

ТС пока что не озвучил ни моделей своих сетевых карточек, ни параметров модулей ядра, ни конфига ядра, так что однозначно утверждать, что polling включен нельзя.

Еще хорошо бы глянуть настройки из /proc/sys/net/core

polling используется, если его включить...

эээ, а в каком месте он включается или выключается?

UPD: Вопрос не праздный. Мне тут надо на некой arm-плате получить 1000мбит (ну или хотя бы близко к теоретическому максимуму в 960). Все что я смог выжать на iperf это 915. Почти, но не убедительно, хочется 950 хотя бы. Подозреваю, что достаточно потоньше настроить всякие параметры, но к сожалению нигде не нашел связи между значениями параметров и их влиянием на скорость.

Включаться/выключаться может

1. В конфиге ядра

2. Параметрами модуля

пример forcedeth

915 - очень хорошо. У меня на некоей arm-плате больше ~500 с jumbo-фреймами и поллингом выжать не удалось никак. А при одновременной работе жесткого диска (nfs) все становится еще печальнее (~30 мегабайт в секунду), хотя независимо друг от друга сетка около 45-47 мегабайт в секунду, жесткий диск - 100 мегабайт в секунду.

Какой у вас модуль?

Модуль от производителя SoC, названия у него я не видел (в компилен в ядро).
А вообще это marvell.

А насчет отключения полинга. Я конечно настолько досканально не копал модуль, но судя по сумрачному еврейскому креативу, отключить это крайне не просто.

===================================
Двайте все забудем и начнем сначала. Очень подробно.
Есть 1-Гигабитный свич TP-Link TL-SG1005D - простой, неуправляемый. Когда-то проверялся виндами, окологигабитную скорость выдавал.
В свич воткнуты два компа с бортовыми сетевухами на 1 GB/s и короткими фирменными гигабитными пачкодами, менять их пробовал.
В этот же свич воткнут 100-Мбитный кабель, ведущий к провайдеру.

В обоих компах указаны шлюз и DNS провайдера.
Оба имеют белые адреса вида 95.55.80.11, 95.55.80.22 с маской 255.255.254.0 и имеют доступ как в Интернет, так и из Интернета.

Материнки такие:

1)Intel DH57JG, dmesg про которую сообщает следующее

 
e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) MAC
e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:00:19.0: eth0: MAC: 9, PHY: 9, PBA No: FFFFFF-0FF
  alloc irq_desc for 22 on node -1
  alloc kstat_irqs on node -1

2) Intel Atom D510MO, dmesg про которую сообщает такое

r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
r8169 0000:01:00.0: setting latency timer to 64
  alloc irq_desc for 30 on node -1
  alloc kstat_irqs on node -1
r8169 0000:01:00.0: irq 30 for MSI/MSI-X
r8169 0000:01:00.0: eth0: RTL8168d/8111d at 0xf8a42000, MAC, XID
 081000c0 IRQ 30
r8169 0000:01:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming:
 ko]

Соответственно ifconfig:

1)

eth0    Link encap:Ethernet  HWaddr MAC  
          inet addr:95.55.80.11  Bcast:95.55.80.255  Mask:255.255.254.0
          inet6 addr: fe80::MAC/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:350206085 errors:0 dropped:9 overruns:0 frame:0
          TX packets:490576111 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:73056714652 (68.0 GiB)  TX bytes:641763396628 (597.6 GiB)
          Interrupt:20 Memory:f0400000-f0420000 

2)

 eth0   Link encap:Ethernet  HWaddr MAC  
          inet addr:95.55.80.22  Bcast:95.55.80.255  Mask:255.255.254.0
          inet6 addr: fe80::MAC/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:214705621 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27552800 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1723310843 (1.6 GiB)  TX bytes:1983914442 (1.8 GiB)

Файловые системы ext4.
Копирование с винта на винт дает скорость 100...155 Мбайт/с, т.е. вполне достаточно, чтобы загрузить Гигабитную сетку.

Один из компьютеров является бекап-сервером, на который нужно организовать быстрое перекачивание данных со второго, т.е. нужен 1 Гбит/с.
Команда ethtool etho | grep Speed на обоих компьютерах выдает одинаковый результат - Speed: 1000Mb/s
Но реально по FTP/SSH/RSYNC идет 8-9 Мбайт/сек и ни копейкой больше, впечатление, что работа идет на 100 Мбит/с.
Почему?

Ой, realtek!

Тут врядли что поможет.

Но для начала попробуйте так:

ifconfig eth0 mtu 9000

на обоих компах.

И снова померьте скорость.

У моего SOC используется драйвер mv643xx_eth.c Ядро довольно давно не пересобирал, сейчас глянул - с тех пор есть некоторые улучшения. Надо попробовать пересобрать, может поднимется скорость еще немного. Сейчас с mtu 1500 получается примерно 11-12 мегабайт в секунду против 40-45 при mtu 9000.

Что ж вы так на Риалтеки-то... Конечно, это не Intel, но даже они не снижают скорость в 10 раз. И под виндой они шпарили более-менее.
Щас сменю MTU и померяю.

Гм, вот как раз на Риалтеке команда ifconfig eth0 mtu 9000 выполнилась, а на Интеле уперлась:

# ifconfig eth0 mtu 9000
SIOCSIFMTU: Недопустимый аргумент

http://ark.intel.com/products/55351/Intel-82578DC-Gigabit-Ethernet-PHY

Похоже не судьба. jumbo frames support: no

Похоже не судьба. jumbo frames support: no

Иными словами, свежайшее ядро Linux выпуска 2013, в отличии от древней винды, не дотянуло до поддержки этой карты? :(

Где «ip r» с обоих компов?