[NickUA]

Нужна 2-х портовая гигабитная сетевая карта для сервера. На сайте Intel нашел две модели которые мне подходят: одна на Intel® 82576, вторая на Intel® i350. i350, вроде, более новый чип, но я не могу найти никаких отзывов о нем. Подскажите, в чем заключается отличие этих двух карт?

Изменено 28 октября, 2012 пользователем NickUA

[Abram]

Самому интересно стало.

http://www.intel.com/content/dam/doc/product-brief/gigabit-et-et2-ef-multi-port-server-adapters-brief.pdf

http://www.intel.com/content/dam/doc/product-brief/ethernet-i350-server-adapter-brief.pdf

Особых различий не вижу. Хотя 82576 все равно почему-то дороже.

[passer]

http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-controller-i350-datasheet.pdf

 

Похоже нечто среднее между 82576 и 82580. У 82576 16 очередей против 8 в i350.

 

 

[ruri]

А кто-нибудь видел на них сертификат в сфере связи или декларацию ?

[s.lobanov]

Вы сертификат на сервер покажите, а какая там карта стоит эти тупицы даже и не подумают посмотреть/проверить

 

Самому интересно стало.

http://www.intel.com/content/dam/doc/product-brief/gigabit-et-et2-ef-multi-port-server-adapters-brief.pdf

http://www.intel.com/content/dam/doc/product-brief/ethernet-i350-server-adapter-brief.pdf

Особых различий не вижу. Хотя 82576 все равно почему-то дороже.

 

Размеры ring буфера можно разные?

[Abram]

s.lobanov,

Где-то писали уже, что у i350 меньше очередей.

[doubtpoint]

s.lobanov,

Где-то писали уже, что у i350 меньше очередей.

Из приведенных pdf следует, что у обоих по 8 на порт.

А кто ни будь пользуется этими queury?

[replicant]

А кто ни будь пользуется этими queury?

А как вы собираетесь ими не пользоваться, если CPU многоядерный?

[Ivan_83]

queury

query = запрос

queue - очередь.

[doubtpoint]

Имелось ввиду конечно очередь.

 

По поводу многоядерных(многопоточных). Я так понимаю, в этом случае, надо смотреть MSI-X

>Dynamic allocation of up to 25 vectors per port

Ну и наверное, в современный сервер можно наставить довольно много таких карт(портов больше потоков) и это будет не столь важный момент.

 

А вопрос именно про очереди. Это наверное анализ приоритетов пакетов.

>Multiple queues: 8 queues per port

>Network packet handling without waiting or buffer overflow providing efficient packet prioritization

 

Кто ни будь использует приоритизацию?

Изменено 8 февраля, 2013 пользователем doubtpoint

[replicant]

Имелось ввиду конечно очередь.

 

По поводу многоядерных(многопоточных). Я так понимаю, в этом случае, надо смотреть MSI-X

>Dynamic allocation of up to 25 vectors per port

Ну и наверное, в современный сервер можно наставить довольно много таких карт(портов больше потоков) и это будет не столь важный момент.

 

А вопрос именно про очереди. Это наверное анализ приоритетов пакетов.

>Multiple queues: 8 queues per port

>Network packet handling without waiting or buffer overflow providing efficient packet prioritization

 

Кто ни будь использует приоритизацию?

 

Скорее наоборот. Сделано это с той целью, чтобы не ставить много сетевок в современные многоядерники, а делать комбинированные очереди или с раздельными векторами и продолжать пользоваться одной сетевкой по максимуму выжимая из ее гигабитного потенциала, что в 90% случаев хватает и редко приходится доставлять вторую, потому что объединение двух портов позволяет полноценно дать 2 к 2 Гбит/с. 2 к 2 - это уже очень большой трафик для одного тазика, но можно использовать и 4-х портовую версию, что легко позволит дать еще больше трафика и соответствует уже примерно аплинку оператора с 10к абонами.

 

А вот сетевок, которые этого не умеют, приходилось ставить несколько и развязывать все это в bond или применять любой другой алгоритм объединения, чтобы развесить прерывания на максимум ядер.

 

Если под приоритетами понимать что-то типа LLI=80 как в мануале к драйверу, то не стоит этого делать. Эффект практически нулевой, если не отрицательный.

 

Как говорится "Лучший QoS - двукратный запас по пропускной способности".

Изменено 9 февраля, 2013 пользователем replicant

[Ivan_83]

А вопрос именно про очереди. Это наверное анализ приоритетов пакетов. >Multiple queues: 8 queues per port >Network packet handling without waiting or buffer overflow providing efficient packet prioritization

Нету там анализа приоритетов и быть ему там вредно.

Приоритеты могут выставляться на л2 и л3 - если они разные на разных уровнях, то кому верить?

Много кто вообще не ставит приоритетов или рубит их на доступе, тогда получится все пакеты попрут в одну очередь а другие очереди будут стоять.

[doubtpoint]

Приоритеты могут выставляться на л2 и л3 - если они разные на разных уровнях, то кому верить?

Кому верить, это как раз решает администратор соответствующими настройками.

Но я понял, что приоритетов ни кто не использует. А было бы удобно, например торент трафик или трафик качальщиков загнать с меньшим приоритетом.