Re: BSD 6.1 & polling

From

Eugene Grosbein (2:5006/1)

To

Oleg Gawriloff

Date

2007-01-01T01:50:34Z

Area

RU.UNIX.BSD

Reply-To: eugen@grosbein.pp.ru

31 дек 2006, воскресенье, в 19:52 KRAST, Oleg Gawriloff написал(а):

 VG>> Да, это дохрена. На моём роутере поток 11-12 тысяч в секунду в одну
 VG>> сторону, полные 100 мегабит (качают-с). Неудивительно, что твоё железо
 VG>> даёт не более 35.
 OG> Тогда перефразируем вопрос: Как смаршрутизировать 36000 пакетов (туда и 
 OG> обратно. Суммарно 72000) (дающих суммарный трафик в 80Мбит (туда и
 OG> обратно, 
 OG> суммарно 160Мбит)? Т.е. железо не справляется, понятно. Какое железо 
 OG> необходимо то? Циска 7600 уже заказана, но она будет только в мае, до
 OG> этого 
 OG> времени еще дожить нужно.

В 2003-м Luigi писал в net@:

> Even not using any special kernel modules, a simple loop over 
> a sendto() on a udp socket can achieve around 500kpps on a 2.4GHz 
> box (em or bge). With some tricks and a sufficiently fast PCI 
> bus you can reach some 750kpps but then it really depends 
> on how fast is your PCI bus.

То есть, процессор в 2.4Ghz способен создать в линии поток в 500000 пакетов
в секунду при помощи сетевых em или bge. Отмаршрутизировать, наверное, порядка
половины этого, 250000 пакетов в секунду.

Тогда же он писал:

> the fxp has a problem which does not allow it to go above 103/110/120kpps 
> depending on which descriptor model you use, no matter how fast 
> the CPU is.

И еще про fxp, повторюсь - данные трехлетней давности:

> The problem is in the hardware, not in the driver. Apparently the chip 
> wastes a lot of time (couple of microseconds if i remember well) 
> between reading the descriptor and then transmitting the data. 
> This extra delay is in parallel with some other chip activity, so 
> for larger frames (say 256 bytes) it is completely masked and packets 
> are transmitted at the nominal rate, but smaller packet are sent as if 
> the interframe gap were larger than the standard. 
> 
> At the time i did a lot of experiments to make sure that the NIC 
> was not stalled by the cpu not supplying frames in time, etc., and 
> all tests confirmed the above diagnosis. 
> BTW it is not something that has to do with flow control frames, 
> because enabling/disabling them does not change the throughput (and you 
> can see the frames when they are not disabled). 
> 
> Changing the way descriptor are used (there are two different 
> formats, one has something like the data right after the descriptor) 
> helped increase the performance to 120kpps, whereas the standard 
> freebsd driver is stuck at something between 103 and 110kpps. 
> 
> Not that it matters terribly, just useful to know when you have 
> to push small frames at line rate and you find you can't with those 
> cards. There are others (e.g. intel/dec 2114x, 3com's xl, possibly 
> others, plus probably all of the gbit units when used at 100Mbit) 
> which work fine at line rate with 64-byte frames.

Но тебе еще далеко до 103kpps, так что смотри на возможности уменьшения
оверхеда по CPU или на апгрейд CPU. Или на кривые набортные карты.
Interrupt coalescence (ifconfig link0) еще может помочь.
С поллингом непонятная ситуация, он вообще-то должен _сильно_ помочь.
Ты ставил HZ в 1000 или в 2000?

Eugene
-- 
За то, что сердце в человеке
Не вечно будет трепетать
--- slrn/0.9.8.0 (FreeBSD)
 * Origin: Svyaz Service JSC (2:5006/1@fidonet)
SEEN-BY: 50/12 400/814 450/159 1024 461/43 132 640 469/999 4616/3 4625/8
SEEN-BY: 4641/444 5000/76 5000 5006/1 8 9 10 14 16 17 5007/1 5010/70 5011/13
SEEN-BY: 5012/46 5015/28 5019/26 5020/18 175 194 400 545 982 1057 1909 1922
SEEN-BY: 5020/2238 2395 2871 4441 5021/29 5025/3 5026/14 45 5027/12 5030/1080
SEEN-BY: 5030/1957 5034/10 13 5035/38 5036/1 5045/7 5049/1 5051/15 5054/1 4 8
SEEN-BY: 5054/9 11 28 35 36 37 45 66 67 70 75 84 85 5059/9 5060/88 5061/15
SEEN-BY: 5062/10 5063/3 5064/7 5066/18 5075/5 5076/1 5077/70 5084/9 5085/13
SEEN-BY: 5095/20 5096/18 6001/10

PATH: 5006/1 5020/400 545 5054/1 37