Перейти к содержимому
Калькуляторы

какой прирост в pps даст задействование трех каналов памяти CPU вместо двух?

Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо.

т.е. лучше вообще один канал использовать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не хочется вынимать процессор физически,

1. можно на этапе загрузки linux как бы отключить один процессор - чтобы linux задействовал только один процессор и посмотреть какой прирост в pps получиться?

Или без физического вынимания программно эту хотелку не реализовать?

2.Если память у одного процессора вынуть, и прибить прерывания с сетевой к процессору который с памятью - это может равнозначно походить на тест системы с одним процессором или все равно оба процессора в системе вяжутся аппаратно и снижают производительность. Если память у одного проца вынуть то numa node в linux остается одна.

 

В этой ветке говорили что лучше иметь один проц но быстрый, для задачи пропуска pps.

Хочется решить - заморачиваться покупкой более быстрого процессора или нет.

Оставляли по одному ядру у двух CPU в BIOS и получили что одно ядро вместо 600 kpps пропустило 1,5 млн pps. память в этом случае была у двух процессоров.

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кто-нибудь тестировал VPP в качестве NAT Box`a ?

https://wiki.fd.io/view/VPP/SNAT

 

Сейчас в процессе альфа-тестов accel-ppp + VPP-NAT на одной машине (соединены через виртуальный ip link veth)

в первом приближении схема рабочая, с некоторыми оговорками (PPTP - не работает, GRE - не НАТится вообще).

 

но пилить high availability ещё предстоит, очень не хватает банального VRRP или небанального OSPF/BGP (на sandbox пока не решился), есть BFD, но реализовать с ним еще тот ребус.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну вроде как для НАТа не нужны OSPF/BGP.

ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну вроде как для НАТа не нужны OSPF/BGP.

ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо...

 

BFD есть, а к нему можно статический маршут прицепить. Куда интереснее насколько лучше/хуже по сравнению с линуксовым NAT оно справляется с udp или tcp-syn флудом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну вроде как для НАТа не нужны OSPF/BGP.

ну если failover не надо, и пофиг на хомяков когда это посреди ночи встанет колом (все-таки альфа) - то да, ospf/bgp для ната не надо...

а что значит колом? linux остановиться? watchdog

Вам конечно виднее - у Вас есть представление о том что должно быть на машинке с НАТ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

какой прирост в pps даст задействование трех каналов памяти CPU вместо двух?

Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо.

т.е. лучше вообще один канал использовать?

Речь ведь про LGA 1366? Лучше использовать 2 канала.

Между 1 и 2 каналами разница в ПСП в 1.5 раза.

А вот между 2 и 3 разница ПСП в пару процентов.

Третий канал платформе приделали сугубо для поддержки большего объема памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

какой прирост в pps даст задействование трех каналов памяти CPU вместо двух?

Околонулевой, или отрицательный. Пропускная способность растет минимально, латентность растет ощутимо.

т.е. лучше вообще один канал использовать?

Речь ведь про LGA 1366? Лучше использовать 2 канала.

Между 1 и 2 каналами разница в ПСП в 1.5 раза.

А вот между 2 и 3 разница ПСП в пару процентов.

Третий канал платформе приделали сугубо для поддержки большего объема памяти.

спс

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

BFD есть, а к нему можно статический маршут прицепить.

можно, но коряво как-то.

 

Куда интереснее насколько лучше/хуже по сравнению с линуксовым NAT оно справляется с udp или tcp-syn флудом.

там вроде как просто буфер на N записей, из которого самые старые замещаются новыми. т.е. - непредсказуемое время жизни сессий.

 

ну и + отсутствуют какие-либо нат хелперы.

 

а что значит колом?

да все что угодно. на выбор: краш самого vpp (полное отсыхание сети как следствие); lockup в vpp (тот же результат по факту); вис системы целиком; всплывшая бага, ломающая л3 форвардинг и т.п.

 

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

 

ну и да, в при использовании более одного ядра вылезут еще и тараканы dpdk (он вроде как нестабилен в multithreading).

 

не, можете пробовать, но как по мне - для какого-либо практического использования оно еще слишком сырое и недоделанное. хоть и активно пилится. правда - в какую-то странную степь (пихать MPLS и прочее, не доделав человеческую дин.маршрутизацию - как-то слишком уж упорото ИМХО).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

(пихать MPLS и прочее, не доделав человеческую дин.маршрутизацию - как-то слишком уж упорото ИМХО).

 

Правельно. В оригенальном linux MPLS появился не давно. Но, правельно что они с этого начинают.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но, правельно что они с этого начинают.

начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но, правельно что они с этого начинают.

начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн).

Взглините на это: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

FRRouting+VPP

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

FRRouting+VPP

vpp sandbox, который отдельный проект и в данный момент с текущим срезом vpp, судя по слухам, не работает...

ну и да, удивлен что они таки реализовали втягивание системных роутов. потому как в офф мануале все вяжется плясками с бубном: https://wiki.fd.io/view/VPP_Sandbox/router

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

vpp sandbox, который отдельный проект и в данный момент с текущим срезом vpp, судя по слухам, не работает...

А почему тогда в документации всё работает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но, правельно что они с этого начинают.

начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн).

Взглините на это: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

FRRouting+VPP

 

Unfortunately the VPP's router plugin is not being actively maintained and is not part of the official VPP repository, being maintained separately in the VPP Sandbox (VPPsb) [5]. Its latest versions are broken since a few changes were made in the VPP API, so we're going to use older versions of VPP/VPPsb where things are known to work.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А почему тогда в документации всё работает?

документация видать обновляется еще реже, чем vpp sandbox. работало на момент написания - и здорово.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А почему тогда в документации всё работает?

документация видать обновляется еще реже, чем vpp sandbox. работало на момент написания - и здорово.

А что именно там не работает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Но, правельно что они с этого начинают.

начинать надо было бы с биндингов к какому-нибудь демону маршрутизации или к системной таблице маршрутизации. а не лепить GTP-U вместо этого (типа кто-то из мобильных опсосов возьмет и прикрутит альфа-релиз в продакшн).

Взглините на это: https://github.com/FRRouting/frr/wiki/Alternate-forwarding-planes:-VPP

FRRouting+VPP

 

По поводу реализации BGP в VPP в рассылку написали

 

hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP.

We use ODL's BGP implementation:

http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-user-guide.html

 

https://wiki.fd.io/view/Hc2vpp

 

To configure BGP you may use RESTCONF or NETCONF protocols (no CLI).

You can find request examples in the link from my previous email to have general overview.

BGP configuration in HC has few differences. Please find details in:

https://gerrit.fd.io/r/#/c/7814/

After merge job for 7814 finishes, you should find rendered adoc at:

https://docs.fd.io/hc2vpp/1.17.07-SNAPSHOT/hc2vpp-parent/release-notes-aggregator/user_running_honeycomb.html#_using_bgp

 

Как я понял консоли как у cisco нет, и через файл как bird этот BGP не сконфигурить. Тупая копи-паста не годна.

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А что именно там не работает?

пост выше прочитайте, написано же...

 

hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP.

бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP.

бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет?

на яве структуры и типы данных значительно тяжелее чем в си?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

hc2vpp 1.17.07 (to be released this week) will provide BGP support for VPP.

бгп на яве?.. интересно сколько интересно ему памяти надо будет для пары FV? в 4 гига хотя бы влезет? или 8-16 надо будет?

на яве структуры и типы данных значительно тяжелее чем в си?

А реально ли сделать BGP на bash'е?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тестируем сервер при помощи https://trex-tgn.cisco.com/trex/doc/trex_manual.html

Сервер должен работать как Nat.

Если через сервер пускать реальный трафик, то всё корректно работает.

Проблема появляется при тестах с помощью TREX, проходящий через тестируемый сервер трафик упорно не хочет натиться.

 

Может кто сталкивался. В чём может быть проблема?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на яве структуры и типы данных значительно тяжелее чем в си?

само собой. интерпретируемый байт-код, ООП, все дела.

 

поинтересуйтесь сколько ресурсов жрут ява-приложения, сравните с не-ява аналогами. разница эдак на порядок...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тестируем сервер при помощи https://trex-tgn.cisco.com/trex/doc/trex_manual.html

Сервер должен работать как Nat.

Если через сервер пускать реальный трафик, то всё корректно работает.

Проблема появляется при тестах с помощью TREX, проходящий через тестируемый сервер трафик упорно не хочет натиться.

 

Может кто сталкивался. В чём может быть проблема?

 

Очень вероятно в том, что trex не statefull генератор, а NAT в линуксе реализован на основе отслеживания состояния сессий (connection tracking)

Т.е., например, чтобы стартанула nat сессия для обычного tcp соединения connection tracking механизм должен засечь SYN пакет, а trex их не шлет.

Да и просто одного syn тоже будет недостаточно, нужен ответный syn-ack. Пробуйте warp17. В нем реализован tcp стэк и очень быстрый. Миллионы соедений, огромный pps. У меня тесты linux nat на ура прошли с его помощью.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тестируем сервер при помощи https://trex-tgn.cisco.com/trex/doc/trex_manual.html

Сервер должен работать как Nat.

Если через сервер пускать реальный трафик, то всё корректно работает.

Проблема появляется при тестах с помощью TREX, проходящий через тестируемый сервер трафик упорно не хочет натиться.

 

Может кто сталкивался. В чём может быть проблема?

 

Очень вероятно в том, что trex не statefull генератор, а NAT в линуксе реализован на основе отслеживания состояния сессий (connection tracking)

Т.е., например, чтобы стартанула nat сессия для обычного tcp соединения connection tracking механизм должен засечь SYN пакет, а trex их не шлет.

Да и просто одного syn тоже будет недостаточно, нужен ответный syn-ack. Пробуйте warp17. В нем реализован tcp стэк и очень быстрый. Миллионы соедений, огромный pps. У меня тесты linux nat на ура прошли с его помощью.

В нём нету даже MPLS!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.