Есть FreeBSD 4.7-STABLE, 3 сетевушки - 2 3Com 905B-TX и одна 3Com905C-TX. Последняя выставлена принудительно в 10baseT/UTP full-duplex, но этого самого полного дуплекса я на не вижу. Тестирую с помощью iperf. Вешаю на этот интерфейс виндовый бокс через кроссовер, на обоих хостах запускаю по серверу iperf и по клиенту, генерирующего трафик. Так вот, при наличии входящего потока трафик с FBSD падает приблизительно до 3 Mbit/sec, а с виндовой машины строго 10Mb (с учетом потерь). Клиент iperf позволяет запустить одновременно несколько потоков . При запуске 4-х потоков с FBSD и одного потока с винды я получаю нормальный дуплекс по 10М в обе стороны. Мне бы хотелось получить такую картину при запуске по одному потоку с обоих хостов. Что можно посмотреть, настроить?Что я делал. Замена сетевой карты на интелевую результата не дает. Я увеличивал maxsockbuf до 2 Мб, буфер tcp.sendspace увеличил почти вдвое. Трафик не шейпится, в ФВ никаких ограничений на этот интерфейс нет. На остальных интерфейсах такого не наблюдается.
Люди, помогите! :-)
Вроде форум живой, люди общаются. Неужели ни у кого нет идей? Может недостаточно информации с моей стороны?
>Вроде форум живой, люди общаются. Неужели ни у кого нет идей? Может
>недостаточно информации с моей стороны?ifconfig интерфейс
и
netstat -w время -Iинтерфейсспасут?
>ifconfig интерфейс
>и
>netstat -w время -Iинтерфейс
>
>спасут?Нет. ifconfig показывает 10Mbit <full-duplex>, а netstat
bash-2.05a$ netstat -w 1 -I xl2 -d
input (xl2) output
packets errs bytes packets errs bytes colls drops
812 0 1229368 406 0 21924 0 0
814 0 1232396 407 0 21978 0 0
813 0 1230882 407 0 21978 0 0
813 0 1230882 407 0 21970 0 0
814 0 1232396 407 0 21978 0 0
813 0 1230882 407 0 21978 0 0
813 0 1230882 406 0 21924 0 0
814 0 1232396 407 0 21978 0 0
813 0 1230882 407 0 21978 0 0
813 0 1230882 406 0 21924 0 0
814 0 1232396 407 0 21978 0 0
813 0 1230882 407 0 21978 0 0
>>ifconfig интерфейс
>>и
>>netstat -w время -Iинтерфейс
>>
>>спасут?
>
>Нет. ifconfig показывает 10Mbit <full-duplex>, а netstat
>
>bash-2.05a$ netstat -w 1 -I xl2 -d
>
>input (xl2)
> output
>
> packets errs bytes
> packets errs
>bytes colls drops
> 812
>0 1229368
> 406 0
> 21924 0
>0
> 814
>0 1232396
> 407 0
> 21978 0
>0
> 813
>0 1230882
> 407 0
> 21978 0
>0
> 813
>0 1230882
> 407 0
> 21970 0
>0
> 814
>0 1232396
> 407 0
> 21978 0
>0
> 813
>0 1230882
> 407 0
> 21978 0
>0
> 813
>0 1230882
> 406 0
> 21924 0
>0
> 814
>0 1232396
> 407 0
> 21978 0
>0
> 813
>0 1230882
> 407 0
> 21978 0
>0
> 813
>0 1230882
> 406 0
> 21924 0
>0
> 814
>0 1232396
> 407 0
> 21978 0
>0
> 813
>0 1230882
> 407 0
> 21978 0
>0если хотят дать информацию, показывают вывод от ifconfig -a
и netstat при нагруженном интерфейсе в сомнительный момент.
нагружать лучше через ftp, два варианта: download и потом upload
>если хотят дать информацию, показывают вывод от ifconfig -a
>и netstat при нагруженном интерфейсе в сомнительный момент.
>нагружать лучше через ftp, два варианта: download и потом uploadПожалуйста.
bash-2.05a$ ifconfig -a
xl0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
inet *.*.82.81 netmask 0xfffffff0 broadcast *.*.82.95
ether 00:50:da:c6:8e:41
media: Ethernet autoselect (100baseTX)
status: active
xl1: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
inet *.*.66.82 netmask 0xfffffffc broadcast *.*.66.83
ether 00:50:da:35:53:a4
media: Ethernet 10baseT/UTP <full-duplex>
status: active
xl2: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
inet *.*.82.97 netmask 0xfffffff0 broadcast *.*.82.111
ether 00:01:02:f2:0e:2f
media: Ethernet 10baseT/UTP <full-duplex>
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552А вот кусок netstat'а. Нагрузку я даю, как уже писал, iperf. Можно верить на слово, что при использовании ftp картина аналогична. Испытание ведется между xl2 и посаженной через кроссовер на него виндой. Далее будет виден переход, когда один из клиентов заканчивает свою работу. Строка запуска netstat -w 1 -I xl2 -d
input (xl2) output
packets errs bytes packets errs bytes colls drops
916 0 1230440 630 0 348840 0 0
914 0 1227412 619 0 348786 0 0
921 0 1229322 623 0 367054 0 0
915 0 1228926 629 0 348786 0 0
915 0 1228926 619 0 347326 0 0
920 0 1227808 621 0 366954 0 0
915 0 1228926 629 0 348786 0 0
915 0 1228926 619 0 347326 0 0
921 0 1229322 622 0 366954 0 0
915 0 1228926 629 0 348840 0 0
915 0 1228926 619 0 348786 0 0
921 0 1229322 623 0 367008 0 0
915 0 1228926 629 0 348832 0 0
915 0 1228926 620 0 348840 0 0
920 0 1227808 623 0 366954 0 0
915 0 1228926 627 0 348786 0 0
915 0 1228926 619 0 347326 0 0
921 0 1229322 623 0 366954 0 0
915 0 1228926 628 0 348840 0 0
915 0 1228926 619 0 348786 0 0
921 0 1229322 624 0 367008 0 0
input (xl2) output
packets errs bytes packets errs bytes colls drops
916 0 1230440 628 0 348840 0 0
915 0 1227440 621 0 348874 0 0
921 0 1229322 624 0 366954 0 0
915 0 1228926 627 0 348840 0 0
915 0 1228926 619 0 348786 0 0
920 0 1227808 624 0 366954 0 0
915 0 1228926 627 0 348840 0 0
915 0 1228926 619 0 348786 0 0
(*)
826 0 994874 666 0 546044 0 0
405 0 26730 809 0 1224826 0 0
406 0 26762 810 0 1226386 0 0
405 0 26696 810 0 1223358 0 0
405 0 26730 810 0 1224872 0 0
405 0 26730 809 0 1226340 0 0
405 0 26730 809 0 1224826 0 0
404 0 26664 809 0 1223312 0 0
405 0 26730 809 0 1224826 0 0
405 0 26730 809 0 1224826 0 0
405 0 26730 809 0 1226340 0 0
405 0 26730 809 0 1224826 0 0
405 0 26730 809 0 1224826 0 0
input (xl2) output
packets errs bytes packets errs bytes colls drops
405 0 26730 810 0 1224826 0 0
405 0 26730 809 0 1223358 0 0
405 0 26730 809 0 1224826 0 0
405 0 26730 809 0 1226340 0 0
404 0 26664 809 0 1223312 0 0
405 0 26730 809 0 1226340 0 0
405 0 26730 809 0 1224826 0 0
404 0 26664 809 0 1223312 0 0
405 0 26730 811 0 1226340 0 0
407 0 26862 812 0 1230882 0 0
407 0 26862 813 0 1230882 0 0
406 0 26796 812 0 1229414 0 0
361 0 23826 719 0 1069336 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
^CВидно, что перекашивает исходящий поток. Потоки идут одновременно до (*), потом входящий поток заканчивается. То что видно на входе после (*) - ответы серверной части iperf.
sysctl -a|grep rfc
?
>sysctl -a|grep rfc
>?bash-2.05a$ sysctl -a|grep rfc
net.inet.tcp.rfc1323: 1
net.inet.tcp.rfc1644: 0
>>если хотят дать информацию, показывают вывод от ifconfig -a
>>и netstat при нагруженном интерфейсе в сомнительный момент.
>>нагружать лучше через ftp, два варианта: download и потом upload
>
> Пожалуйста.
>
>bash-2.05a$ ifconfig -a
>xl0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> inet *.*.82.81 netmask 0xfffffff0
>broadcast *.*.82.95
> ether 00:50:da:c6:8e:41
> media: Ethernet autoselect (100baseTX)
>
> status: active
>xl1: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> inet *.*.66.82 netmask 0xfffffffc
>broadcast *.*.66.83
> ether 00:50:da:35:53:a4
> media: Ethernet 10baseT/UTP <full-duplex>
> status: active
>xl2: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
> options=3<rxcsum,txcsum>
> inet *.*.82.97 netmask 0xfffffff0
>broadcast *.*.82.111
> ether 00:01:02:f2:0e:2f
> media: Ethernet 10baseT/UTP <full-duplex>
> status: active
>lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
> inet 127.0.0.1 netmask 0xff000000
>
>ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
>sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
>
>А вот кусок netstat'а. Нагрузку я даю, как уже писал, iperf. Можно
>верить на слово, что при использовании ftp картина аналогична. Испытание ведется
>между xl2 и посаженной через кроссовер на него виндой. Далее будет
>виден переход, когда один из клиентов заканчивает свою работу. Строка запуска
>netstat -w 1 -I xl2 -d
>смотри netmask/broadcast на xl0 и xl2, что-то подсказывает что в этом
проблема, из-за чего каша с пакетами в таблице ядра
>смотри netmask/broadcast на xl0 и xl2, что-то подсказывает что в этом
>проблема, из-за чего каша с пакетами в таблице ядраДа нет. Это 2 подсети по 16 адресов, иущие подряд. С этим все нормально. Я тут другие грабли нашел. Если ты знаком с iperf, то у него есть опция -w, для TCP это TCP Window size. Так вот, если ее не использовать, то поток с фри на винду идет лучше (больше в два раза). Если ее использовать на фревом клиенте, то получаем предупреждение (на винде такого не бывает):
bash-2.05a$ iperf -c *.*.82.99 -w 300K
------------------------------------------------------------
Client connecting to *.*.82.99, TCP port 5001
TCP window size: 301 KByte (WARNING: requested 300 KByte)
------------------------------------------------------------Видимо iperf не очень аккуратно работает с параметрами TCP на фре. Методом ползучего эмпиризма я выяснил, что при указании на виндовом клиенте -w 16K (по умолчанию виндовый клиент устанавливает TCP window size = 8K) получаем нормальный дуплекс в обе стороны по 10Мб.
Продолжаю копать в сторону буферов TCP на обеих платформах, нашел интересную ссылку http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm , посмотрим что из этого выйдет.
>>смотри netmask/broadcast на xl0 и xl2, что-то подсказывает что в этом
>>проблема, из-за чего каша с пакетами в таблице ядра
>
> Да нет. Это 2 подсети по 16 адресов, иущие подряд.
>С этим все нормально. Я тут другие грабли нашел. Если ты
>знаком с iperf, то у него есть опция -w, для TCP
>это TCP Window size. Так вот, если ее не использовать, то
>поток с фри на винду идет лучше (больше в два раза).
>Если ее использовать на фревом клиенте, то получаем предупреждение (на винде
>такого не бывает):
>
>bash-2.05a$ iperf -c *.*.82.99 -w 300K
>------------------------------------------------------------
>Client connecting to *.*.82.99, TCP port 5001
>TCP window size: 301 KByte (WARNING: requested 300 KByte)
>------------------------------------------------------------
>
>Видимо iperf не очень аккуратно работает с параметрами TCP на фре. Методом
>ползучего эмпиризма я выяснил, что при указании на виндовом клиенте -w
>16K (по умолчанию виндовый клиент устанавливает TCP window size = 8K)
>получаем нормальный дуплекс в обе стороны по 10Мб.вот почему было предложено использовать ftp
про iperf thx, буду теперь иметь ввиду, обычно только unix <-> unix проверял>Продолжаю копать в сторону буферов TCP на обеих платформах, нашел интересную ссылку
>http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm , посмотрим что из этого выйдет.понято, ну в Unix'ах tcp/ip стек таким потоком дует что M$ и не снилось,
когда они наконец нарисуют нормальный стек в своих OS?
Если в ifconfig все ok, то со стороны Unix'а перекоса быть не должно,
а что там в M$ со стеком... одному Биллу известно."Новая вера - M$. Новый бог - Билл Гейтс" (c) lavr :)