ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Alexander Sheiko                     2:5020/400     28 Feb 2004  05:35:51
 To : Sultan Azhiguzhayev
 Subject : Re: device polling
 -------------------------------------------------------------------------------- 
 

 Привет Sultan!
 
 Fri, 27 Feb 2004 13:14:22 +0300 ты писал к Alexander Sheiko:
 
 [Skip]
 
  SA> я предполагаю, что при малой интенсивности трафика пакеты будут
  SA> обрабатываться с несколько большей задержкой, а при слишком большой
  SA> интенсивости - потери пакетов.
 
 Х.З. По крайней мере - визуально я ничего плохого не заметил.
 
 Кстати, на http://www.nag.ru, по поводу сабжа была заметка. Думаю - всем
 будет интересно:
 
 =========Beginning of the citation==============
 Софтроутер
 
 Материал прислал Фдуч.
 
 Hесколько наблюдений по поводу уже 6-ти летнего использования софтовых
 рутеров на FreeBSD.
 
 Если надо рутить (только рутить) 3-5 сегмента 10мбпс, то с этим нормально
 справляется любой пентиум с любыми pci сетевухами.
 Если появилось 100Мб, то карточки realtek и им подобные сразу на свалку. О
 том, какое это "чудо" в плане дизайна чипа читайте в комментариях драйвера
 if_rl. Мы используем intel. 3com тоже можно, однако его дрова не
 поддерживают очень важную функцию, о которой ниже.
 Основная проблема при пропускании сквозь себя 100Мб - это затыкание рутера
 по прерываниям. Дело не в 100 мегабитах, а в количестве пакетов и
 соответственно прерываний. Top и systat -v 1 вам поможет понять, что рутер
 затыкается. 8000 прерываний в секунду и ваш p3-700 уже труп. Однако во
 FreeBSD есть полезная фича - DEVICE_POLLING. Обязательно включаем ее на
 рутере. Карточки работают не по прерываниям, а принудительно опрашиваются
 ядром. В итоге к примеру 4*100Мб, как говорится, на full wire speed идет
 легко. Подробнее смотреть на странице разработчика ipfw, dummynet и прочих
 вкусных штук во FreeBSD Луиджи Риззо.
 Hужно считать трафик. Мы это делаем ipacctd. Вещь классная, удобная,
 безглючная. Однако у нее есть одна проблема - подсчет идет через divert и на
 каждый пакет идет переключение контекста. От чего он существенно занимает
 процессорное время. Замечено, что если ipacctd в топе висит с 30% - срочно
 пора менять камень. Есть еще ng_ipacctd, который сделан в виде ядерного
 модуля и не щелкает контексты. Однако он менее гибок в использовании - может
 считать только весь трафик на интерфейсе, а нам это не всегда надо.
 Фаервол. ipfw - штатный от фри рулит. Hовая его генерация ipfw2 (в фре 4.8
 надо включать руками - man ipfw, в 5.х штатный) еще более производителен.
 Вобщем, по фаерволу никогда не замечал затыков.
 Squid. В идеале конечно нужно ставить на отдельную машинку, памяти поболее,
 и винт пошустрее. К примеру, даже в небольшой конторе на p1 32M запрос через
 сквид идет заметно медленней, чем напрямую.
 
 Итак, что мы имеем на сегодняшний день на примере 2х конкретных рутеров:
 p1-166 16M. 1*100 3*10. Только рутинг. ~1Т в месяц
 p4-1800 512M. 4*100. Hесколько vlanов. Фаервол ~3000 записей, подсчет
 входящего трафика на 1-ом интерфейсе (~600Гб в месяц). Суммарно
 проручмвается ~4Тб в месяц. Тут же висит squid.
 
 Следуя традиции данного выпуска, приведу и тут перефразированную поговорку
 про джипы. "Чего только не придумают русские, что бы не покупать Cisco"
 (чего только не придумают русские что бы не строить нормальные дороги).
 
 http://info.iet.unipi.it/~luigi/polling/
 =========The end of the citation================
 
 --
 Саша.
 --- ifmail v.2.15dev5.3
  * Origin: Kiev University (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Re: device polling   Alexander Sheiko   28 Feb 2004 05:35:51   device polling   Sultan Azhiguzhayev   28 Feb 2004 14:45:09