[jab]

IvanI - все зависит от задач. У меня просто нет такого количества свободного "приличного" железа (и места его разместить) для тестов, чтоб догнать до 3.5г

Если кто-то даст хотяб три машинки - поставим GlobalOS и затестим.

Стоит тут Core i7 свободный... :-) как раз под nat.

[nuclearcat]

IvanI - все зависит от задач. У меня просто нет такого количества свободного "приличного" железа (и места его разместить) для тестов, чтоб догнать до 3.5г

Если кто-то даст хотяб три машинки - поставим GlobalOS и затестим.

Стоит тут Core i7 свободный... :-) как раз под nat.

jab - попробуем? пообщаемся в IM/почте? Или здесь?

 

Можно поставить GlobalOS с флешкой, могу просто сказать чего набирать и смотреть, могу и сам удаленно настроить...

Кстати в линупсе можно сделать с помощью conntrackd полностью redundant nat.

[alks]

сюда пишите -- думаю многим будет весьма интересно...

[Умник]

Full cone NAT никакого отношения не имеет к SAME, насколько я понимаю. Если Full cone NAT == 1-to-1 NAT, то см. NETMAP. Либо по два правила (SNAT+DNAT) на IP, который нужно за-full-конить. :) Поправьте меня, если я не прав.

[nuclearcat]

Умник - вариантов много, может вы и правы... я на самом деле тщательно не смотрел код, не было необходимости

[jab]

jab - попробуем? пообщаемся в IM/почте? Или здесь?

 

Можно поставить GlobalOS с флешкой, могу просто сказать чего набирать и смотреть, могу и сам удаленно настроить...

Кстати в линупсе можно сделать с помощью conntrackd полностью redundant nat.

Там уже фря стоит, а я пока стенд готовлю для нагрузки...

[nuclearcat]

А фрю можно не трогать, просто бутнутся с флешки с GlobalOS и затестить, сравнить...

[jab]

А фрю можно не трогать, просто бутнутся с флешки с GlobalOS и затестить, сравнить...

Невозможно сохранить чистоту эксперимента, так как генераторы нагрузки все-равно будут мои.

[nuclearcat]

Как раз это чистый эксперимент, генераторы то не на том же сервере... как я понимаю?

Я предлагаю на ваш i7 воткнуть GlobalOS USB, выполняющий тот же функционал

[Умник]

Кстати, у i7 L2 кеш - 4 штуки (по количеству ядер). Для задач маршрутизации лучше, когда кеш пошарен (например, как на Quad - между парами ядер). Хотя может быть за счет большого объема L3 кеша будет выигрыш?

[ugluck]

могу генератор одолжить, да и сам бы поприсутствовал

Изменено 6 мая, 2009 пользователем ugluck

[jab]

Кстати, у i7 L2 кеш - 4 штуки (по количеству ядер). Для задач маршрутизации лучше, когда кеш пошарен (например, как на Quad - между парами ядер). Хотя может быть за счет большого объема L3 кеша будет выигрыш?

Пока есть только результаты ubench в попугаях - CPU: 1920000 ( 2.9Ghz ), что не может не радовать.

[IvanI]

CPU: Intel® Core2 Quad CPU Q9650 @ 3.00GHz

 

FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Mon May 4 18:33:11 MSD 2009 ivan@border.aaa.com:/usr/src/sys/amd64/compile/bor1 amd64

Ubench CPU: 1507228

Ubench MEM: 243190

--------------------

Ubench AVG: 875209

 

 

2 * CPU: Intel® Xeon® CPU E5420 @ 2.50GHz

 

FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Mon May 4 19:44:10 MSD 2009 ivan@nat1.aaa.com:/usr/src/sys/amd64/compile/www amd64

Ubench CPU: 2506743

Ubench MEM: 173358

--------------------

Ubench AVG: 1340050

 

 

[jab]

Ubench CPU: 1849444

Ubench MEM: 571210

--------------------

Ubench AVG: 1210327

[IvanI]

с памятью у i7 клево

[jab]

 

Ну я грубо прикинул, гигабит pf ната in+out ( со scrub и stateful behavior ) примерно соответствует Ubench CPU: 800K

Это абстрактно, без привязки к разматыванию ядреных ниток на восемь ядреных банок, и прочему оверхеду.

[bsdelnik]

Ну я грубо прикинул, гигабит pf ната in+out ( со scrub и stateful behavior ) примерно соответствует Ubench CPU: 800K

Это абстрактно, без привязки к разматыванию ядреных ниток на восемь ядреных банок, и прочему оверхеду.

Jab, IvanI а ipfw nat не быстрее будет?

[nuclearcat]

Кстати шареный кеш L2 из-за арбитра медленнее в Core 2 Duo / Quad. Помоему вместо 10 циклов - 14.

[jab]

 

На каких типах задач ?

[nuclearcat]

Тяжело сказать, я нашел только:

Of course, no improvement ever comes easily. Here, the processor die had to be made larger to unload the CPU bus and solve the coherency problem: the Smart Cache arbiter in the Core Duo die is about one third the size of a single execution core. You can note it’s not easy to manage a shared cache. Using a sophisticated operation algorithm, the cache has also become slower, with a 40% higher latency. The L2 cache latency of the Pentium M on the Dothan core is 10 cycles, while the same latency for the Core Duo is 14 cycles. Intel tried to make up for that by improving the data pre-fetch mechanism for L2 cache, so there’s little difference between the Pentium M and Core Duo on single-threaded applications under the same conditions.

Еще: http://www.xbitlabs.com/articles/cpu/displ...e-qx9650_4.html в конце, интересно про улучшения доступа к unaligned data в L2 (т.е. если попали данные в разные cache line)

И вот тут: http://www.computerlounge.co.nz/forum/Defa...posts&t=147

 

[jab]

Пока что я через lo0 выжал только 3.2Mpps(in+out)/3.4GBps(in+out) пакетами по 1000bytes при одном правиле ipfw ( без особого тюнинга системы )

оставив при этом 45% cpu idle. Тачка генерит потоки четырьмя netblast сама в себя. Включение одного правила ipnat на lo0 дает падение в 3%

( при 4 states ;). Дальше где-то закопан bottleneck под названием "пока мы попадали в кэш". Буду пока считать это теоретическим потолком,

от которого отсчитывается overhead в драйверах сетевух и непопадание в кэш. Стоят старые сетевухи 1000/PT поддерживающие одну rx queue,

новые 82576 еще не доехали.

[nuclearcat]

Как интересно netblast шлет сам в себя? посмотрел исходник - он даже bind не делает на порт

Программка конечно простая до жути, но все что она делает, это проверяет удачен или нет send.

Весьма сомнительный способ измерять pps, особенно если sendto подвержен локам (multiqueue network card + SMP)

[nuclearcat]

Еще

The only real disappointment with Nehalem’s new cache hierarchy is its L1 cache. The bandwidth of the instruction cache hasn’t been increased—it’s still 16 bytes per cycle compared to 32 on Barcelona. This could create a bottleneck in a server-oriented architecture since 64-bit instructions are larger than 32-bit ones, especially since Nehalem has one more decoder than Barcelona, which puts that much more pressure on the cache. As for the data cache, its latency has increased to four cycles compared to three on the Conroe, facilitating higher clock frequencies. To end on a positive note, though, the engineers at Intel have increased the number of Level 1 data cache misses that the architecture can process in parallel.

If this translation stage were necessary at each memory access, it would make access much too slow. As a result, engineers returned to the principle of physical addressing by adding a small cache memory directly on the processor that stored the correspondences for a few recently accessed addresses. This cache memory is called a Translation Lookaside Buffer (TLB). Intel has completely revamped the operation of the TLB in their new architecture. Up until now, the Core 2 has used a level 1 TLB that is extremely small (16 entries) but also very fast for loads only, and a larger level 2 TLB (256 entries) that handled loads missed in the level 1 TLB, as well as stores.

 

Nehalem now has a true two-level TLB: the first level of TLB is shared between data and instructions. The level 1 data TLB now stores 64 entries for small pages (4K) or 32 for large pages (2M/4M), while the level 1 instruction TLB stores 128 entries for small pages (the same as with Core 2) and seven for large pages. The second level is a unified cache that can store up to 512 entries and operates only with small pages. The purpose of this improvement is to increase the performance of applications that use large sets of data. As with the introduction of two-level branch predictors, this is further evidence of the architecture’s server orientation.

http://www.tomshardware.com/reviews/Intel-...m-cpu,2041.html

[jab]

Как интересно netblast шлет сам в себя? посмотрел исходник - он даже bind не делает на порт

Программка конечно простая до жути, но все что она делает, это проверяет удачен или нет send.

Весьма сомнительный способ измерять pps, особенно если sendto подвержен локам (multiqueue network card + SMP)

Интересно, а на кой роутеру bind ? :-) Насколько я понимаю порты находятся уровнем выше чем IP.

 

netblast 127.0.0.1 1000 100

 

pps я измеряю как обычно netstat'ом

 

[nuclearcat]

Ну по первых аргументов больше

fprintf(stderr, "netblast [ip] [port] [payloadsize] [duration]\n");

Скажем если

netblast 127.0.0.1 1234 1000 100

То

12:42:06.790297 IP 127.0.0.1.44259 > 127.0.0.1.1234: UDP, length 1000

12:42:06.790309 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 1234 unreachable, length 556

12:42:06.790321 IP 127.0.0.1.44259 > 127.0.0.1.1234: UDP, length 1000

12:42:06.790333 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 1234 unreachable, length 556

12:42:06.790345 IP 127.0.0.1.44259 > 127.0.0.1.1234: UDP, length 1000

12:42:06.790356 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 1234 unreachable, length 556

12:42:06.790370 IP 127.0.0.1.44259 > 127.0.0.1.1234: UDP, length 1000

12:42:06.790382 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 1234 unreachable, length 556

12:42:06.790395 IP 127.0.0.1.44259 > 127.0.0.1.1234: UDP, length 1000

12:42:06.790405 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 1234 unreachable, length 556

12:42:06.790417 IP 127.0.0.1.44259 > 127.0.0.1.1234: UDP, length 1000

12:42:06.790427 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 1234 unreachable, length 556

 

jab - если нет bind, src port будет random. Соответственно ты шлешь пакеты на 127.0.0.1:1234, а на этом порту никого нет.

 

Роутер будет корячится и слать icmp port unreachable. Что уже нарушает чистоту эксперимента.

Даже если ты забиндишь порт - надо будет делать recv(), что тоже... не совсем то.