Нужно ли в ядре 3.2 оптимизировать TCP/IP

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

Да, к тюнингу надо лезть на скоростях в районе 10Гбит, даже на гигабите особого смысла не имеет.

Или если с GPRS'а сидеть.

io поотптимизируй

А для GPRS то там что тюнинговать? Очень было бы интересно узнать, актуально...

Если вопрос поставлен таким образом, то нет, не нужно

В порядке уменьшения действенности:

0. обновить ядро до 3.10+ и завести fq_codel
1. перейти на westwood или yeah tcp.
2. через ifconfig уменьшить txqueuelen как можно ниже (<=32)
3. tcp_slow_start_after_idle
4. tcp_fastopen

В начале нужно провести анализ проблемы и выяснить, что именно тормозит на самом деле

Ну если подумать то варианты:
1. дисковый кэш
2. samba
3. ядро
4. сетевая карта
5. кабель
6. проблемы у пользователя

Нельзя сделать никакие выводы по указанным данным. Нужны конкретные цифры по тормозам. Есть например такая утилита, как ping. Можно подойти методом исключения. Сеть, например, можно исключить передавая данные по другому протоколу, например FTP, но опять же меряя скорость и сравнивая, для одних и тех же файлов, разумеется, с разных компьютеров. Проверить также следует не только сервер, но и сетевое оборудование на пути данных. samba/ядро следует задвинуть в самый конец списка - их тюнингуют не на таких нагрузках/требованиях. Также стоит посмотреть на загрузку сервера когда тормозит сеть. Ну и так далее. То есть без анализа проблемы обойтись не получится.

Есть например такая утилита, как ping

И что нужно делать с получаемыми из неё данными, что на что умножать?

Пользователи, подключённые по ethernet 100Мбит:

--- 192.168.21.1 ping statistics ---
41 packets transmitted, 41 received, 0% packet loss, time 39997ms
rtt min/avg/max/mdev = 0.275/0.336/0.616/0.057 ms

--- 192.168.21.2 ping statistics ---
42 packets transmitted, 42 received, 0% packet loss, time 41000ms
rtt min/avg/max/mdev = 0.340/0.520/0.594/0.073 ms

Пользователи, подключённые по IEEE 802.11 b/g/n:

--- 192.168.21.6 ping statistics ---
61 packets transmitted, 61 received, 0% packet loss, time 60082ms
rtt min/avg/max/mdev = 0.909/7.445/101.031/16.845 ms

--- 192.168.21.8 ping statistics ---
62 packets transmitted, 62 received, 0% packet loss, time 61072ms
rtt min/avg/max/mdev = 0.857/5.781/74.581/12.272 ms

Сеть, например, можно исключить передавая данные по другому протоколу, например FTP

Меня больше интересует, чтобы скорость была приемлемая при передаче по тому протоколу, который используется у нас в сети. Вывод о тормозах сети я сделал после жалоб пользователей у которых 1С (файловое хранилище баз) и «Консультант» стал открываться медленнее чем в другом офисе где стояла Windows Server. Ещё была идея протестировать скорость копируя по самбе гигабитный файл и замеряя время копирования. Только утилита для этого какая-нибудь нужна, а то не с секундомером же мерять.

Ну, в начале нужно исключить то, что можно легко проверить. Некоторые ftp клиенты тебе сами скорость посчитают, на самом деле. Если скорость будет соотвествовать ожидаемой по FTP, а на самбе значительно меньше - значит нужно крутить самбу. Иначе самбу крутить смысла не имеет и надо крутить что-то другое.

Пингом можно измерять задержки в сети (RTT). У тебя в норме.

Некоторые ftp клиенты тебе сами скорость посчитают, на самом деле.

Подскажи, пожалуйста, какой-нибудь. Чтобы был под винду и бесплатный. Кстати давно интересовался, можно ли самбу на ftp полностью заменить, чтобы никакого широковещательного трафика. Чтобы печатать можно было по ftp и «Консультант» запускать.

лучше уж SFTP
пользуюсь под Windows
Секурно, быстро!

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

FTP только для файлов. Для печати из винды samba не нужна, достаточно CUPS и ipp/lpr, неоднократно проверено. Даже где-то хаутушка была.

SFTP медленнее чем FTP и плохо подходит для измерения скорости.