Возвращаясь к "тормознутости" pfsense
-
1. на машине с Pfsense сетевухи гигабитные? Если да, то проверь, согласование интерфейсов показывает гигабит в сторону провайдера? На стомегабитных интерфейсах не будет сотки по TCP - максимум 30.
2. Поставь пакет через вебморду shellcmd.
Пропиши через интерфейс этого пакета
sysctl net.inet.ip.dummynet.pipe_slot_limit=200
Перезагрузись.По умолчанию в этом параметре стоит 100. Есть подозрение, что из-за этого даже без лимитера в Rules ядро режет скорость до сотки.
-
Конфиг машины: i865+1G_RAM(1channel)+Northwood_3,06GHz+5 x Intel 100 Pro (2 enable)
Основной рабочий протокол торрентов - UDP, так что, при экстремальных настройках клиента можно и гигабитный канал загрузить по полной - это не проблема.
По поводу п.2: спасибо за подсказку, но можно разжевать по подробнее, что этот параметр определяет? Да и лимитеры не созданы. -
Максимальная ширина одного канала dummy. Есть предположение, что даже без создания pipe лимитера он может действовать. Это можно проверить, выключив nat и pf вообще, подсоединив pfsense к провайдеру через другой роутер с натом.
-
1. на машине с Pfsense сетевухи гигабитные? Если да, то проверь, согласование интерфейсов показывает гигабит в сторону провайдера? На стомегабитных интерфейсах не будет сотки по TCP - максимум 30.
2. Поставь пакет через вебморду shellcmd.
Пропиши через интерфейс этого пакета
sysctl net.inet.ip.dummynet.pipe_slot_limit=200
Перезагрузись.По умолчанию в этом параметре стоит 100. Есть подозрение, что из-за этого даже без лимитера в Rules ядро режет скорость до сотки.
Убедительная просьба топикстартеру отписаться, поможет ли это решение. Проверил бы сам, но такого широкого канала не имею.
-
Для проверки достаточно поставить вместо провайдера машину с iperf сервером, за pfsense - машину с iperf-клиентом. Лучше всего, чтобы на 3 машинах сетевки были гигабитные.
-
1. В первом посте забыл указать, что на каждом из тестов, дополнительно выполнялось несколько циклов измерения скорости соединения при помощи сервиса speedtest.net (естественно, с выгруженным торрент-клиентом и очищенной таблицей соединений). Порядок значений speedtest соответствовал цифрам при торрент-загрузках.
2. После проведённых нескольких серий экспериментов по предложенной netormoz метОде, сколько нибудь видимых улучшений ситуации я не увидел. Для увеличения нагрузки на внешний канал и сенс была задействована вторая машина, которая тоже торрентом тянула аналогичный файл. Указанный netormoz'ом параметр менялся на 200, 500 и даже на экстремальное значение 1000. Только при значении 1000, средняя скорость возросла на несколько процентов (субъективно, т.е. при данном методе тестирования, может быть, просто инструментальная погрешность).
Так что, проблема всё ещё имеет место быть. -
Продолжаем эксперимент.
Выставляем вышеуказанный параметр 200.
Делаем 2 лимитера 100 Мбит/c in и out c параметром Queue Size 100 slots.
Назначаем лимитеры в правилах LAN
Перезагружаемся -
приобретя канал к провайдеру с полосой 100Мбит/с
А скажите, пожалуйста, от провайдера метод авторизации при этом какой? (белый ип, динамика, PPoE…. и т.п)
Просто у меня с той же пропускной способностью от провайдера, pf справляется очень даже хорошо на 90-91 мбит, причем в тех же торрентах реальная постоянная цифра 10мб/c.
-
У меня гигабитные карты (правда, модулей для них из коробки в pfsense не оказалось - но это другая тема) - тестировал через запросы на локальный ftp сервер. Получал честные 470-80 Мбит/c на upload и download. А вот с лимитерами на 100 Мбит/c pfs работал где-то на 25 Mбит/c только плюс проблема ассиметричности пропуска траффика. Все решил вышеуказанным способом, корректируя размер slots c 50 до 100 и изменив ограничение скорости pipe со 100 на 200. В данном случае есть подозрение, что slots в 50 по умолчанию применяется и без лимитеров. А корректировать его величину можно только, включив лимитер - поэтому и предлагаю продолжить эксперимент.
Вообще не вижу проблемы заменить карты на поддерживаемые гигабитные для Freebsd 8.1 и забыть об этой проблеме. Цена вопроса от 15 уе и выше. Ваши сотки точно входят в перечень поддерживаемого hardware для 8.1? -
добавлю свои "5 копеек"
вот так у меня получается на локальном сервере
а вот с чего это снято2.0.3-RELEASE (i386) (nanobsd)
CPU: Intel Pentium III (601.37-MHz 686-class CPU)
real memory = 134217728 (128 MB)
re0: <realtek 8169="" 8169s="" 8169sb(l)="" 8110s="" 8110sb(l)="" gigabit="" ethernet="">(WAN через PPPoE)
vr0: <via 10="" vt6105="" rhine="" iii="" 100basetx="">(LAN)
ad0: 996MB <samsung cf="" ata="" 04="" 05="" 06="">at ata0-master PIO4 (это вместо винта)очень даже не плохо как мне кажется. только загрузку проца я показать не могу. не может pfsense её посчитать на этом камне, нуль, говорит у меня загрузка ;D</samsung></via></realtek>
-
WAN через PPPoE
Ростелек и через рррое? У них же вроде везде IPoE?
И, кстати, ссылки на speedtest уже давно моветон:
- Я поставил кеш сервер, который клиенту, если у него 50, выдает 100.
- Кэш чего? Спидтеста?..
- Да, оно тягает jpg файлики, у файликов есть определенный паттерн, по нему и кеширует.
- Круто :-))
http://forum.nag.ru/forum/index.php?showtopic=77077
Тестам с торрентами доверия больше, т.к. это и есть реальная задача, а не её эмуляция (speedtest). -
не, в нашей деревне только PPPoE. Даже предлагают медь на GPON махнуть и там сделать PPPoE.
Я им и денег предлагал, говорят "не положено!",
а одна девочка из саппорта сказала "этот VLAN устарел, а у нас новая технология PPPoE!", я тогда перестал с ними спорить.На вопрос зачем им пароль при безлимитном интернете и месячной абонплате, ответить затрудняются.
Про торрент то оно понятно, но вопрос был "тормознутость", если уж p3-600 способен прокачивать 100 мегабит сферических коней в вакууме, то p4-3000 должен быть способен на большее ;D
-
Выписка мз
FreeBSD 8.1-RELEASE Hardware NotesIntel PRO/100 Mobile Cardbus (versions that use the X3201 chipset)
хм….может быть, там чипсет не такой -
2 panika:
-авторизация IP, белый.
-как я писал в первом посте, тестировал прокачку на 2х системах: pfsense 2.0.3 и zeroshell 2.0 RC3 (linux). Железо было одно - просто перетыкал винты.2 netormoz:
-экспериментировать по данному вопросу пока некогда - нужно решить ещё несколько вопросов.
-у меня старые добрые intel_100_pro на pci, драйвера на которые давным-давно обкатаны.2 aleksvolgin:
из нескольких перебранных спидометров, в том числе и тех, которым несколько лет назад я полностью доверял, только этот давал результат замера скорости очень близкий к графику замера скорости на сетевом интерфейсе (WinXP->диспетчер задач->сеть), то же показывал и сенс на графике загрузки wan. Это же подтверждают и торренты. -
2 netormoz:
-экспериментировать по данному вопросу пока некогда - нужно решить ещё несколько вопросов.
-у меня старые добрые intel_100_pro на pci, драйвера на которые давным-давно обкатаны.А старые добрые интел дают дают сотку с выключенным натом, как я просил проверить? Если проверки не было - то это просто теория ради собственного самоуспокоения. Драйвера могли быть обкатаны давно - но кто на них видел сотку?
-
Тестировал на тестовой машине.
Коре 2 дуо 1.8 4 гига рам ссд вит 30гигов.
2 сетевухи. Шина pci.
Сетевухи длинк дге 530 на марвеле.
Линк гигабит. Нат включен. Гонял данные и через рртр и через нат. Использовались два компа с ссд винтами. Протокол смб 2.- торент во внешку.
Уперся в пропускную способность шины pci 32 битные карты по спецификации дали общую пропускную на 275 мегабит, загрузка проца для обоаботки потока составила 45%
После установки интеловской карты на pci express с аппаратным офлоад и тисипи фрагментэйшн дали при прокачке по виланам по одному интерфейсу 750 мегабит, сказывалось и старый смб 1 и то что вторая машина была виртуальной и винт стоял на рэйде 1 и писалось в vhd. Загрузка проца при этом не превысила 15%. Сказались аппаратные обработки сетевухи.
Так, что по поводу тормознутости, спешу не согласиться. Скорее всего у тебя проблема кроется в мобильном процессоре, который заточен под энергосбережение, посему не в состоянии обработать поток и посмотри внимательно, умеют ли твои карты на аппаратном уровне обрабатывать сеть, возможно собака порылась именно тут. Есть еще один момент. На многоядерных системах очереди потока с разных интерфейсов паралелятся, в твоем случае может возникать затык из-за обработки очереди двух интерфейсов одним потоком, плюс затраты на нат.
- торент во внешку.
-
Выписка мз
FreeBSD 8.1-RELEASE Hardware NotesIntel PRO/100 Mobile Cardbus (versions that use the X3201 chipset)
хм….может быть, там чипсет не такойПричина не в этом чипсете
-
2 netormoz:
-экспериментировать по данному вопросу пока некогда - нужно решить ещё несколько вопросов.
-у меня старые добрые intel_100_pro на pci, драйвера на которые давным-давно обкатаны.А старые добрые интел дают дают сотку с выключенным натом, как я просил проверить? Если проверки не было - то это просто теория ради собственного самоуспокоения. Драйвера могли быть обкатаны давно - но кто на них видел сотку?
Только-что на zeroshell'e с отключенным qos повторил загрузку торрентом того-же имиджа. По показаниям торрент-клиента скорость загрузки 11,2 мегабайта/сек (это естественно, целевой трафик, без служебного) и это полностью соответствует отрисовке загрузки сетевого интерфейса машины с торрент-клиентом. Не думаю, что во фре драйвера для таких старых карт как у меня (i82558) обкатаны хуже, чем в линухе. Вопрос по матери/процу/шине/сетёвкам отпадает, поскольку данные, приведённые в этом посте показывают, что железо тянет без проблем - проблема в самой оси или настройках. Так что, давайте искать проблему здесь.
2 netormoz:
провёл предложенный вами эксперимент, но безрезультатно,точнее - всё осталось как было. Но я вполне допускаю, что не учёл какие то конкретные параметры. Если не затруднит, уточните параметры по лимитеру. -
Теперь надо Pfsense поставить за отдельной машиной с натом, а на pfs
system:advanced:firewall and nat:disable all packet filtering ставим галку.
Делаем из него просто роутер - и качаем 100 Мб -
Сделал просто: отключил фильтрацию/нат/шейпер/лимитеры, LAN и WAN сбриджевал (думаю, большой разницы с маршрутизацией в плане производительности нет). Топология такова: комп->сенс->локалка, файловый сервер (smb, http). Результат: загрузка файла с сервера по smb: прямое подключение - 70 Мбит/с, через сенс - 10-12 Мбит/с (при ещё одной параллельной загрузке другого файла скорость возрастает вдвое); при загрузке по http: прямое подключение - 50 Мбит/с, через сенс - см. результат smb. При этом, при прямом подключении график загрузки достаточно ровный, а через сенс - имеет игольчатый вид (расчёска) со средней скоростью, той что я указал.
Вот так засада :o.