| 1.1, toor99 (??), 09:24, 04/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Сборка ядра с опцией DEVICE_POLLING
Спорная рекомендация.
Поллинг начинает оправдывать себя при перманентно высокой нагрузке на сеть. Если это высокоскоростной маршрутизатор, к примеру. А так... ну, не знаю. Cомневаюсь, что это оправдано. | | |
| 1.2, jbond (??), 10:08, 04/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Очень даже оправданно, переменноя sysctl kern.polling.user_frac задает процент загрузки сети при котором карта переключается в polling (по умолчанию 50), другое дело, что по умолчанию subj деактивирован и нужно задавать kern.polling.enable=1 иначе проку от сборки его в ядре 0 | | |
| 1.4, Аноним (4), 10:10, 04/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Не знаю как сейчас, но во времена 5.2, если карточка не поддерживала POLLING, то карточка просто не работала...
приходилось убирать этот параметр из ядра... | | |
| 1.6, okijan (?), 10:50, 04/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Проверял кто это дело на SMP???
The DEVICE_POLLING option by default does not work with SMP enabled kernels. When the author of the DEVICE_POLLING code initially commited it he admits he was unsure of the benefits of the feature in a multiple-CPU environment, as only one CPU would be doing the polling. Since that time many administrators have found that there is a significant advantage to DEVICE_POLLING even in SMP enabled kernels and that it works with no problems at all. If you are compiling an SMP kernel with DEVICE_POLLING, edit the file: /usr/src/sys/kern/kern_poll.c and remove the following lines:
#ifdef SMP
#include "opt_lint.h"
#ifndef COMPILING_LINT
#error DEVICE_POLLING is not compatible with SMP
#endif
#endif
Чтука реальная, проверял на fxp и dc, жалко что xl не поддерживается :( | | |
| 1.7, necrophagophobiac (?), 11:00, 04/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 А не знаете почему всё застряло на считанных единицах карт? В мане говорится, что поддержка железом не требуется и достаточно в драйвере... Жду не дождусь xl и bge... :-( | | |
| |
| 2.8, pppp (?), 11:34, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
 Поддержка железом ещё и как требуется -- у карты должен быть аппаратный буфер, в котором она будет хранить пришедшие пакеты до тех пор пока *_poll() из драйвера их заберёт. Соответственно, поллинг возможен даже не в каждой fxp (только в серверных версиях, которые способны хранить до 64 пакетов).
В bge ещё никто и не начинал ничего делать (документации не хватает?) Кстати, лично я не в восторге от этих карт. | | |
| |
| 3.11, anononymous (?), 12:11, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
всё, с первой до последней строчки - не правда и глупости.
если вы сами не разбираетесь в вопросе, то будте так добры -
не вводите других в заблуждение.
пришедшие пакеты не хранятся в памяти карточки. они хранятся в оперативной
памяти хоста.
поллинг возможет в каждой fxp. оперативная память хоста может хранить 64
и больше принятых пакетов до того, как они будут переданы на уровень выше.
но нужен ли всем версиям fxp поллинг ? (иногда может хватить простого link0)
bge сама по себе не нуждается в поллинге. на гигабитных скоростях задержки до 1000
микросекунд на интерфейсах - не есть good. тем более, что bge сами прекрасно представляют, что такое interrupt moderation.
предлагаю вам начать изучать мат-часть. | | |
| |
| 4.13, toor99 (??), 14:45, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
Не пакетов, а кадров, уважаемый. Изучите терминологию. Не хватало еще для полного счастья, чтобы сетевые карты начали сами IP/IPX пакеты обрабатывать. В оперативной памяти хоста хранятся *пакеты*. А *кадры* (фреймы) хранятся в буфере сетевой карты, если он есть.
| | |
| |
| 5.21, anononymous (?), 03:18, 05/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
> Не пакетов, а кадров, уважаемый.
да вы просто прикопались.
> Изучите терминологию. Не хватало еще для полного счастья, чтобы сетевые карты
> начали сами IP/IPX пакеты обрабатывать.
такие слова, как TSO, TOE, вам что-нибудь говорят ?
(я молчу про самостоятельное выставление и валидирование ip4/ip6/tcp/udp чек-сумм)
> В оперативной памяти хоста хранятся *пакеты*.
> А *кадры* (фреймы) хранятся в буфере сетевой карты, если он есть.
буфер сетевой карты, как правило, не очень большой.
всего на пару-тройку пакетов в том же fxp...
| | |
| |
| 6.27, toor99 (ok), 20:00, 05/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
Чего-чего?
Сссылочку мне сюда. С описанием сетевого адаптер, который сам считает чексуммы L3. | | |
| 6.28, toor99 (ok), 20:08, 05/11/2004 [^] [^^] [^^^] [ответить]
| +/– | |
Да, по поводу TCP segmentation offload - то же самое. К *сетевому адаптеру* это имеет удаленное отношение. Всего лишь прослойка между адаптером и стеком. И не пакетов, а фреймов, еще раз вам повторяю. | | |
|
|
| 4.14, pppp (?), 15:34, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
С каждым годом всё хуже и хуже...
Медитируем над функцией fxp_poll() в /sys/dev/fxp/if_fxp.c
Далее выясняем чем занимается макрос CSR_READ_1 (ответ: вызывает bus_space_read_1() из /sys/i386/include/bus_at386.h, а в ней всё довольно очевидно)
ЗЫЖ Пора новый тред по поллингу открывать...
ЗЗЫЖ С терминологией я действительно зарапортовался; конечно, имелись в виду фреймы | | |
| |
| 5.15, Barsuk (??), 16:42, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
 Так любая сетевая от Intel поддерживает поллинг?
и еще по поводу xl, карточки 3кома поллинг не пддерживают или дрова xl для FreeBSD эту функцию не поддерживают? как с этим у Linux например?
PILA 8460BI INTEL EtherExpress Pro 100+ PCI (chip 82559) будет держать Device polling ? и подойдет ли она для конфиуграции и вопроса: http://www.opennet.me/openforum/vsluhforumID1/49717.html
| | |
| |
| 6.17, pppp (?), 20:21, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Так любая сетевая от Intel поддерживает поллинг?
Нет, не любая; а только та, у которой есть аппаратный буфер.
Поддерживают те карты, которые позиционируются как серверные (список, возможно, не полный)
82546 -- 64 КБ (64 кадра)
82545 -- 64 КБ (64 кадра)
82540 -- 64 КБ (64 кадра)
82557
82558
82559
Эти точно поддерживают.
По идее должны поддерживать все карты серии 8254x и 8255x, но у некоторых из них аппаратный буфер может быть значительно меньше -- ftp://download.intel.com/design/network/applnots/ap453.pdf
>и еще по поводу xl, карточки 3кома поллинг не пддерживают или дрова
>xl для FreeBSD эту функцию не поддерживают? как с этим у
>Linux например?
Во всяком случае 3Com Gigabit Server поддерживает (но это не xl, а bge); а 905-е, похоже нет.
Я не очень хорошо ориентируюсь в Linux, но идеи device polling там присутствуют. Правда, почему-то разработчики смотрят только в сторону символьных драйверов (/me shrugs). Под Linux все люди используют не нативный драйвер, а поставляемый Intel в бинарниках (в основном из-за корректной поддержки 802.1q; а также из-за аналога уже упомянутой опции типа link0). В драйверах Intel (бинарных) есть аппаратная поддержка device polling (link0 в FreeBSD), которая работает максимум для 6 кадров, но не требует никакой поддержки от ОС.
>PILA 8460BI INTEL EtherExpress Pro 100+ PCI (chip 82559) будет держать Device
>polling ? и подойдет ли она для конфиуграции и вопроса:
См выше. Подойдёт
> http://www.opennet.me/openforum/vsluhforumID1/49717.html
Согласен с большинством :) Intel + device polling | | |
| |
| 7.19, Barsuk (??), 22:53, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо за такой подробный овтвет! Еще небольшое уточнение:
1. т.е. выходит просто карты серии 3Ком905 не имеют аппаратного буфера? т.е. и под линухом они хуже себя покажут? и FreeBSD здесь не виновата?
2. Будет ли роутер: пень1, озу порядка 32-64Мб, сетевые Intel + device polling, (2 сетки на 100Мбит) показывать работу на уровне аппаратного решения или нужна более серьезная конфигурация? пентиму2 или п3...
Т.е. хватит ли такой конфигурации или при больших нагрузках будут провалы по скорости?
| | |
| |
| 8.25, pppp (?), 14:27, 05/11/2004 [^] [^^] [^^^] [ответить] | +/– | Повторю ещё раз мне кажется, что поллинг там не реализован хотя всякое может б... текст свёрнут, показать | | |
| |
| 9.26, Barsuk (??), 19:34, 05/11/2004 [^] [^^] [^^^] [ответить] | +/– | Циска для домашней сети, с практически нулевым бюджетом, что находишь из того и ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.9, Аноним (4), 12:00, 04/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Вообще в статье так и написано: "Наконец, если у вас есть одна из следующих сетевых карточек, то вы можете включить в ядро опцию DEVICE_POLLING"
это, видать, автор новости случайно приравнял "опцию" к "основным" советам ;) | | |
| 1.10, Аноним (4), 12:05, 04/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Из man polling
SUPPORTED DEVICES
Device polling requires explicit modifications to the device drivers. As
of this writing, the dc(4), em(4), fwe(4), fxp(4), ixgb(4), nge(4),
re(4), rl(4), sis(4), ste(4), vge(4), and vr(4) devices are supported,
with others in the works. | | |
| 1.16, Дмитрий Ю. Карпов (?), 20:10, 04/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Интересно, а может ли сетевая карточка через DMA скидывать кадры в оперативку, имея тем самым буферы, ограниченные только размером оперативки? Или DMA только для IDE? | | |
| |
| 2.18, pppp (?), 20:45, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Интересно, а может ли сетевая карточка через DMA скидывать кадры в оперативку,
>имея тем самым буферы, ограниченные только размером оперативки? Или DMA только
>для IDE?
Может, а некоторые так и делают.
1) У DMA существуют свои ограничения на максимальный размер используемой памяти;
2) Кроме того, что скинуть, надо ещё и следить за тем, кто и когда их будет забирать... Поэтому те кто могут -- скидывают, но как копию своих аппаратных буферов. А зачем -- чтобы разгрузить локальную шину.
3) Вообще-то DMA изначально разрабатывался для звуковых карт и флоповодов...
| | |
| |
| 3.20, Алексей (??), 22:54, 04/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
1)Ограничение ISA DMA - 64К за пересылку - достаточный размер даже для гигабита, в PCI bus master.... нуууу сколько памяти хватит, и сколько тебе позволят шину держать.
2) Для тех девайсов которые умеют DMA/Bus mastering и дрова соответствующие.
При скидывании используется механизм похожий на страничную работу памяти. Одна страница передается, вторая заполняется данными. После заполнения, странцы меняются местами.
3) Говорить что DMA разрабатывалось для флопов, а тем более музыкальных карт это мягко скажем бред... тут стоит подучить архитектуру 8080 и хронологию появлению устройств.
| | |
| |
| 4.24, pppp (?), 14:19, 05/11/2004 [^] [^^] [^^^] [ответить]
| +/– |
>2) Для тех девайсов которые умеют DMA/Bus mastering и дрова соответствующие.
>При скидывании используется механизм похожий на страничную работу памяти. Одна страница передается,
>вторая заполняется данными. После заполнения, странцы меняются местами.
Загвоздка в том, что сетевую карту никто не просит складывать данные в память; она это делает сама, причём в абсолютно непредсказуемые моменты времени...
>3) Говорить что DMA разрабатывалось для флопов, а тем более музыкальных карт
> это мягко скажем бред... тут стоит подучить архитектуру 8080
>и хронологию появлению устройств.
Я тогда ещё и в школу не ходил; и разве что S390 видел. Поэтому и не рассуждаю о том, чего никогда не видел (я о вычислительных устройствах на базе i8080)
| | |
|
|
|
| 1.23, Аноним (4), 09:02, 05/11/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
глюк?!
выставил параметры как указано в статье, т.е. поставил
net.inet.tcp.msl=7500
kern.ipc.somaxconn=32768
после этого перестали работать
unix sockets, и, соответственно, приложения их использующие..., а также перестал работать kavdaemon :( после того как откатил на свои прежние настройки
net.inet.tcp.msl=30000
kern.ipc.somaxconn=1024
все заработало...
| | |
| |
| 2.30, Center (?), 03:18, 14/12/2004 [^] [^^] [^^^] [ответить]
| +/– |
>глюк?!
>
>выставил параметры как указано в статье, т.е. поставил
>net.inet.tcp.msl=7500
>kern.ipc.somaxconn=32768
>
>после этого перестали работать
>unix sockets, и, соответственно, приложения их использующие..., а также перестал работать kavdaemon
>:( после того как откатил на свои прежние настройки
>net.inet.tcp.msl=30000
>kern.ipc.somaxconn=1024
>
>все заработало...
Были аналогиные симптомы на 5.3 после сборки ядра с предустановленным kern.ipc.somaxconn=32768.
Ничего откатывать не стал, а используемые
drwebd и drweb-sendmail вылечил пересборкой и установкой последних версий из портов (4.32.2 и 4.32.1 соотв.)
| | |
| 2.31, dyer (?), 19:43, 24/03/2005 [^] [^^] [^^^] [ответить]
| +/– |
вот это:
kern.ipc.somaxconn=32768 -
диверсия для FreeBSD 4.x максимум 32767
| | |
|
|
