связка FreeBSD 5.1 + ProFTPD 1.2.8 со стандартными настройками. Выявил, что скорость аплоада и даунлоада на ФТП сервер отличается примерно в 3 раза! (К примеру аплоад - 500Кбит, а даунлоада 150Кбит. Причем при одинаковых условиях: нагрузка на сеть, сам сервер, вплоть до длинны кабеля :))
Подскажите, в каком направлении рыть. Спасибо.
>связка FreeBSD 5.1 + ProFTPD 1.2.8 со стандартными настройками. Выявил, что скорость
>аплоада и даунлоада на ФТП сервер отличается примерно в 3 раза!
>(К примеру аплоад - 500Кбит, а даунлоада 150Кбит. Причем при одинаковых
>условиях: нагрузка на сеть, сам сервер, вплоть до длинны кабеля :))
>
>Подскажите, в каком направлении рыть. Спасибо.положи на время proftpd в down и запусти родной ftpd чтобы посмотреть
есть изменения в скорости upload и download, если нет - дело не в демонах,
а скорее всего в настройках сетевого железа.
>положи на время proftpd в down и запусти родной ftpd чтобы посмотреть
>есть изменения в скорости upload и download, если нет - дело не
>в демонах,
>а скорее всего в настройках сетевого железа.
!!! попробовал! поражен, ситуация изменилась с точностью до наооборот! UP стал - 150К , DOWN - 500К ! вот этого я не понял.
Да, может это важно? родной ftpd запускается через inetd а proftpd я запускаю как демона.
>связка FreeBSD 5.1 + ProFTPD 1.2.8 со стандартными настройками. Выявил, что скорость
>аплоада и даунлоада на ФТП сервер отличается примерно в 3 раза!
>(К примеру аплоад - 500Кбит, а даунлоада 150Кбит. Причем при одинаковых
>условиях: нагрузка на сеть, сам сервер, вплоть до длинны кабеля :))
>
>Подскажите, в каком направлении рыть. Спасибо.Мы наступали на эти грабли. :)
При download'е сервер вынужден читать файл напрямую с диска, а при upload'e файл буферизируется в памяти. Отсюда и разница.
Попробуй положить корень ftp сервера на виртуальный диск. Скорости должны сравняться.
>При download'е сервер вынужден читать файл напрямую с диска, а при upload'e
>файл буферизируется в памяти. Отсюда и разница.
>Попробуй положить корень ftp сервера на виртуальный диск. Скорости должны сравняться.Хм. Вариант интерестный, но у меня на анонимном ФТП фактически пара папок, в которых находятся действительно большие файлы, размеры которых исчисляются сотнями метров. :( у меня столько оперативки нет :)
>>При download'е сервер вынужден читать файл напрямую с диска, а при upload'e
>>файл буферизируется в памяти. Отсюда и разница.
>>Попробуй положить корень ftp сервера на виртуальный диск. Скорости должны сравняться.
>
>Хм. Вариант интерестный, но у меня на анонимном ФТП фактически пара папок,
>в которых находятся действительно большие файлы, размеры которых исчисляются сотнями метров.
>:( у меня столько оперативки нет :)парни, ну вы как с луны прямо, тестирование by ftp:
при download скачивание производить в /dev/null
при upload на fs расположенную в RAMпараллельно смотреть netstat -Iiface -w 1 (ошибки и коллизии)
ifconfig iface | auto или в жестких рамках == тому же что на свитче/хабе
>параллельно смотреть netstat -Iiface -w 1 (ошибки и коллизии)
>
>ifconfig iface | auto или в жестких рамках == тому же что
>на свитче/хабе1) проверил, никаких ошибок, коллизий, "дроп"нутых пакетов нет :(
2) везде стоит авто ...
>>параллельно смотреть netstat -Iiface -w 1 (ошибки и коллизии)
>>
>>ifconfig iface | auto или в жестких рамках == тому же что
>>на свитче/хабе
>
>1) проверил, никаких ошибок, коллизий, "дроп"нутых пакетов нет :(
>2) везде стоит авто ...боюсь в этом и беда что "auto", я редко встречал чтобы net-card нормально
догорились с хабом или свитчем по negotiation (miibus/PHY).man 4 драйвер_твоей_карты
смотри media types и mediaopt, в зависимости от карты и того что она
поддерживает, я обычно начинал игры с 10baseT/UTP half-duplex:
смотрел как встал хаб, лучше управляемый свитч и начинал игры с соседней
на свитче-хабе машиной (заведомо с правильными режимами работы netcard<->hub/switch) и смотрел download/upload с freebsd <-> machine
и machine <-> freebsd (клиенты использовать СТРОГО native-родные от системы)
Потом mediaopt - full-duplex (если карта позволяет), сравнивал, затем
100 и тд и тп.Пример: dec (intel чипе) <-> cisco-switch (с жестко 100 full-duplex)
[alone]~ > ifconfig dc0
dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 62.84.100.160 netmask 0xffffff00 broadcast 62.84.100.255
inet6 fe80::200:1cff:feb0:e394э0 prefixlen 64 scopeid 0x1
ether 00:00:1c:b0:e3:94
media: Ethernet 100baseTX <full-duplex>
status: active
[alone]~ >Intel 10/100 Pro тоже с Cisco свитчем жестко выставлены параметры:
[proxy]~ > ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 62.84.100.8 netmask 0xffffff00 broadcast 62.84.100.255
inet 62.84.100.19 netmask 0xffffffff broadcast 62.84.100.19
inet 62.84.100.21 netmask 0xffffffff broadcast 62.84.100.21
inet 62.84.100.20 netmask 0xffffffff broadcast 62.84.100.20
ether 00:a0:c9:5d:4f:89
media: Ethernet 100baseTX <full-duplex>
status: active
[proxy]~ >Intel 10/100 Pro с каким-то г...ом типа Compex (с договором было никак,
только жесткие режимы):[unix1]~ > ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 159.93.17.121 netmask 0xfffff000 broadcast 159.93.31.255
inet6 fe80::250:8bff:fe5b:ae06%fxp0 prefixlen 64 scopeid 0x1
inet 159.93.25.88 netmask 0xffffffff broadcast 159.93.25.88
inet 159.93.17.129 netmask 0xffffffff broadcast 159.93.17.129
inet 193.124.144.1 netmask 0xffffff00 broadcast 193.124.144.255
ether 00:50:8b:5b:ae:06
media: Ethernet 100baseTX <full-duplex>
status: active
[unix1]~ >
>боюсь в этом и беда что "auto", я редко встречал чтобы net-card
>нормально
>догорились с хабом или свитчем по negotiation (miibus/PHY).
в жесткую (хоть на 10 хоть на 100 и тд и тп) все тоже самое ... никаких коллизий, и тд ...
>связка FreeBSD 5.1 + ProFTPD 1.2.8 со стандартными настройками. Выявил, что скорость
>аплоада и даунлоада на ФТП сервер отличается примерно в 3 раза!
>(К примеру аплоад - 500Кбит, а даунлоада 150Кбит. Причем при одинаковых
>условиях: нагрузка на сеть, сам сервер, вплоть до длинны кабеля :))
>
>Подскажите, в каком направлении рыть. Спасибо.Bilo takoje (ska4ivaje6 vse normalno, a vot zaka4at problema). Problema bila v nastroikah setevih kart, konkretnei v rezimah ih raboti (skorost+halt/full duplex). Pozle soglasovanije vsego okruzenija vse vstalo na svoi mesta.