Справедливое деление канала с фтп сервера (Разные скорости подлючения к серверу)

[156]

Есть фтп сервер, и клиенты, все имеют гигабитное подключение. Так если первый пользователь подключился, то он качает например 45 мегабайт в секунду, потом подключается второй пользователь, он уже качает со скоростью 1-2 мегабайта в секунду, у первого падает до 42-43 мегабайта. Можно ли как то сделать справедливое разделение канала, что бы при подключении пользователей канал делился между ними поровну, или как вариант, в пропорции максимальной скорости их каналов, так если первый подключен на 1 гигабит,а второй на 100 мегабит, то скачивание у них бы шло в соответствии с возможностью их каналов?

[danger08]

Есть фтп сервер, и клиенты, все имеют гигабитное подключение. Так если первый пользователь подключился, то он качает например 45 мегабайт в секунду, потом подключается второй пользователь, он уже качает со скоростью 1-2 мегабайта в секунду, у первого падает до 42-43 мегабайта. Можно ли как то сделать справедливое разделение канала, что бы при подключении пользователей канал делился между ними поровну,

Если клиенты качают одним потоком каждый, то у должно получаться по 45мегабайт в секунду у каждого (если позволяет пропускная способность сети и производительность жесткого диска сервера). Если у второго скорость на минимуме, то здесь возможны следующие варианты:
а) первый клиент качает в несколько потоков, забивая весь канал к серверу;
б) производительности винчестеров сервера банально не хватает для того, чтобы отдавать данным всем;
в) хромает пропускная способность, возможно на промежуточном узле (свитче/роутере и т.п.);
г) на фтп-сервере стоит в настройках общая ширина канала в 45мегабайт (??) в сек, кто первый успел - тот и съел.

Как мне помнится, все нормальные ФТП-сервера позволяют задавать ширину канала для подключения (чтобы одно подключение не съедало канал), или как вариант в зависимости от авторизации пользователя (и/или IP) назначать ширину канала.

или как вариант, в пропорции максимальной скорости их каналов, так если первый подключен на 1 гигабит,а второй на 100 мегабит, то скачивание у них бы шло в соответствии с возможностью их каналов?

см. выше.

[156]

1.Все клиенты качают одним потоком, сам устанавливал клиентов. 2. Производительность сервера ограниченна скоростью чтения в 65 мегабайт в секунду. Но если клиента два, то почему скорость потока не делится на два, в теории каждому по 65/2=32,5 мегабайт ( приблизительно) , по факту получается одному 95% канала, а второму 5% пропускной способности канала, при том что клиенты абсолютно равноправны. Дополнительные сведения. Операционка OpenSuSe11.1 , фтп сервер vsftp , собран RAID-1 . 3. Клиенты и сервер сидят на одном хабе гигабитном D-link 8 портов в одной комнате, максимальная длинна кабеля 10 метров, на хабе светодиоды показывают подключение у всех 1 гигабит. Если первый закончил качать, весь канал переходит ко второму, и если первый опять подключается, то теперь уже ему достается 5% от канала, т.е политика "кто первый встал, того и тапочки". 4. По этому пункту хотелось бы подробнее, что Вы имели ввиду? Я не гуру в настройке vsftp , но там есть только ограничение по максимальной скорости для пользователей , но нету механизма справедливого деления канала ( или я о нём не знаю, что не исключено ). При таком ограничении, это нужно для десяти человек выставить 1000 мегабит делим на 10, каждому по 100 мегабит, а если юзер будет один , то он всё равно будет качать 6-8 мегабай в секунду вместо 65ти. ИМХО это не решение проблемы. п.с. Честно говоря, я ожидал от линуха, который кичится своими возможностями настройки всего и вся , большей адекватности в таком простом вопросе, как справедливое деление канала.

[danger08]

Если первый закончил качать, весь канал переходит ко второму, и если первый опять подключается, то теперь уже ему достается 5% от канала, т.е политика "кто первый встал, того и тапочки".

А вы пробовали тестировать пропускную способность канала от клиентской машины до ФТП-сервера? Какова вообще реальная пропускная способность канала до сервера, если не ориентироваться на лампочки хаба? Реально ли канал выдает 2*45мбайт/сек на гигабитном линке? Попробуйте замерить, например, через iperf.

Если выдает, то скорее всего у вас узкое место - производительность дисковой подсистемы (раз ширины канала заведомо хватает).

4. По этому пункту хотелось бы подробнее, что Вы имели ввиду? Я не гуру в настройке vsftp , но там есть только ограничение по максимальной скорости для пользователей , но нету механизма справедливого деления канала ( или я о нём не знаю, что не исключено ).

Лично мне не доводилось настраивать динамический шейпинг полосы для vsftpd (не было необходимости),
Для pure-ftpd возможно помогут параметры throttle.

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

Конкретно, Linux здесь вовсе не причем (вместо "линукс" с таким же успехом можно написать "*bsd", "windows"), все определяется используемым ПО и вашей настойчивостью в этом вопросе

[156]

Пробовал тестировать канал. Для всех пользователей однозначно- если пользователь один подключен к фтп серверу, то скорость его скачивания максимальна , и составляет 45-64 мегабайт в секунду. А если подключается второй, третий, то начинается описанная в первом топике ситауция. На одном форуме нашел замечание про справедливое деление канала в интернет с помощью тонких настроек в связке squid + iptables , но это так было непонятно... Если расмотреть теоритическую возможность динамического ограничения скорости в связке vsftpd + iptables от количества подключенных пользователей для справедливого деления канала между пользователями... Что скажете?

[rm_]

156
Попробуйте другой свитч. Есть вероятность, что как только один пользователь разогнался, D-Link просто не даёт другому возможности достичь той же скорости, выделяя основные ресурсы уже идущему трансферу.

[danger08]

156
Есть вероятность, что как только один пользователь разогнался, D-Link просто не даёт другому возможности достичь той же скорости, выделяя основные ресурсы уже идущему трансферу.

<OFFTOPIC>
При всем уважении, не видел у d-link такого поведения (приходилось использовать 8-портовые 10/100Мбит DES-1008*, стоят 24-портовые гигабитные и 48-портовые DES-1050*). Да, еще такой момент, 156 говорит, у него 8-портовый гигабитный Dlink, но врядли у него стоит управляемый свитч. Неуправляемых 8-портовых гигабиток у Dlink-a нет.
</OFFTOPIC>

[rm_]

Неуправляемых 8-портовых гигабиток у Dlink-a нет.

А это, стало быть, мираж в пустыне.

[danger08]

Неуправляемых 8-портовых гигабиток у Dlink-a нет.

А это, стало быть, мираж в пустыне.

А ну да, сорри, про эту линейку забыл

[156]

Свич не управляемый, самый обычный, посмотреть на него можно по _http://www.nix.ru/autocatalog/d_link/DLink_DGS1008D_8port_Gigabit_8UTP_1000Mbps_33544.html_ . По поводу влияния свича на скорость передачи (если клиент разогнался, то другому канал недавать) - очень неожиданная версия, что скажут опытные форумчане? ИМХО, преподы на лекциях говорили, что неупраляемый свич тупо берет пакет с одного входа и пересылает его на другой выход, руководствуюясь ип адресом, т.е. если с сервера пришла куча пакетов , на ип1 и на ип2, то следуя Вашей идее, неуправляемый свич режет 95% пакетов , идущих на ип2, и оставляет пакеты идущие на ип1. Как то не ясен механизм такой избирательности. Я почему то думал, что если на свич пришло , то с него и ушло... А может всё таки дело в настройках на сервере? Или я не прав...