pavlabor 1 939 Опубліковано: 2011-03-10 16:35:50 Share Опубліковано: 2011-03-10 16:35:50 Уровневая структура пакета, подразумевает инкапсуляцию данных. В связи с этим, любое передающее устройство должно полностю подготовить пакет к транспорту на езернет уровне. Никто не знает кто будет принимать пакет на другой стороне. Поетому все должно быть предсказуемо, то есть согласно протокола. Писюк, это один из приемников, который ОБЯЗАН, разбуть пакет чтобы обработать. В зависимости от задачи, производится распаковывания пакета. для тупого роута, а писюк можно настроить и так, разбувается только езернет уровень, а скажем для прокси, он разбирается еще больше. То есть это не есть вопрос. Вот обратил внимание на такую инфу, карточка вроде деловская http://torg.od.ua/index.php?productID=146 Что тут интересного не считая перечисления того что я ненашол в карточке? Во! Support caches up to 64 packets descriptors per queue Двухголовая карточка... Зачем ей кеш на 64 дескриптора? Есть идеи? Разработчики пошли довольно стремным путем для разгона. Лично я ожидал, учитывая выше приведеную опцию, что разгон пойдет по технологии анализа заголовков, построения фабрики коммутации на базе сетевой карты, и прямого управления регистрами этой фабрики коммутации. И в таком случае кеш необходим, потому что пакет был скомутирован сетевой картой с порта в порт, а дескриптор помещен а очередь для дальнейшей обработки процом. По такой технологии работает цыска, да и все коммутаторы выше второго уровня. Но возможно текущая метода разгона трафика на писюках и принесет свои плюсы, время покажет. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 709 Опубліковано: 2011-03-10 16:45:30 Share Опубліковано: 2011-03-10 16:45:30 Уровневая структура пакета, подразумевает инкапсуляцию данных. В связи с этим, любое передающее устройство должно полностю подготовить пакет к транспорту на езернет уровне. Никто не знает кто будет принимать пакет на другой стороне. Поетому все должно быть предсказуемо, то есть согласно протокола. Писюк, это один из приемников, который ОБЯЗАН, разбуть пакет чтобы обработать. В зависимости от задачи, производится распаковывания пакета. для тупого роута, а писюк можно настроить и так, разбувается только езернет уровень, а скажем для прокси, он разбирается еще больше. То есть это не есть вопрос. Вот обратил внимание на такую инфу, карточка вроде деловская http://torg.od.ua/index.php?productID=146 Что тут интересного не считая перечисления того что я ненашол в карточке? Во! Support caches up to 64 packets descriptors per queue Двухголовая карточка... Зачем ей кеш на 64 дескриптора? Есть идеи? Разработчики пошли довольно стремным путем для разгона. Лично я ожидал, учитывая выше приведеную опцию, что разгон пойдет по технологии анализа заголовков, построения фабрики коммутации на базе сетевой карты, и прямого управления регистрами этой фабрики коммутации. И в таком случае кеш необходим, потому что пакет был скомутирован сетевой картой с порта в порт, а дескриптор помещен а очередь для дальнейшей обработки процом. По такой технологии работает цыска, да и все коммутаторы выше второго уровня. Но возможно текущая метода разгона трафика на писюках и принесет свои плюсы, время покажет. Какая фабрика коммутации, какие разгоны, зачем все это на сетевке?? Как-то вас из крайности в крайность кидает.. Есть сегодняшние вполне рабочие сетевые чипы, легко пропускающие положенные 1 или 10Г. Под linux и дрова совершенно стабильные и красивые, с bsd попозжее видимо тоже все красиво будет. Ссылка на сообщение Поделиться на других сайтах
pavlabor 1 939 Опубліковано: 2011-03-10 16:56:23 Share Опубліковано: 2011-03-10 16:56:23 Какая фабрика коммутации, какие разгоны, зачем все это на сетевке?? Как-то вас из крайности в крайность кидает.. Есть сегодняшние вполне рабочие сетевые чипы, легко пропускающие положенные 1 или 10Г. Под linux и дрова совершенно стабильные и красивые, с bsd попозжее видимо тоже все красиво будет. Меня интересует не сегодня, а завтра. Сори если чем обидел. Удачи. Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2011-03-10 17:00:29 Share Опубліковано: 2011-03-10 17:00:29 Уровневая структура пакета, подразумевает инкапсуляцию данных. В связи с этим, любое передающее устройство должно полностю подготовить пакет к транспорту на езернет уровне. Никто не знает кто будет принимать пакет на другой стороне. Поетому все должно быть предсказуемо, то есть согласно протокола. свич этим не занимается. для тупого роута, а писюк можно настроить и так, разбувается только езернет уровень, а скажем для прокси, он разбирается еще больше. причем тут прокси? вопрос идет о маршрутизации Лично я ожидал, учитывая выше приведеную опцию, что разгон пойдет по технологии анализа заголовков, построения фабрики коммутации на базе сетевой карты, и прямого управления регистрами этой фабрики коммутации. И в таком случае кеш необходим, потому что пакет был скомутирован сетевой картой с порта в порт, а дескриптор помещен а очередь для дальнейшей обработки процом. По такой технологии работает цыска, да и все коммутаторы выше второго уровня. есть такие сетевушки. только стоимость их на текущий момент порядка 1k$ за гиговый порт. вы готовы платить такие суммы? Ссылка на сообщение Поделиться на других сайтах
pavlabor 1 939 Опубліковано: 2011-03-14 11:09:32 Share Опубліковано: 2011-03-14 11:09:32 Opteron 6100 and Xeon 5600 series have different memory controller architectures. For best performance, you have to populate DIMMs in groups of 8 on a 2-processsor Opteron 6100 series server, while you have to populate DIMMs in groups of 6 on a 2-processor Xeon 5600 series server. I ran the test in this video with 8x2GB in the AMD server, and 6x4GB in the Intel. I re-ran the test with 8x4GB in the AMD server and got about the same result (33,900 MB/s on the AMD). Вот такая сказка... http://www.amd.com/us/products/server/processors/six-core-opteron/Pages/six-core-processors-with-amd-chipset.aspx http://market.yandex.ua/model.xml?hid=91020&modelid=6325035 http://cgi.ebay.com/TYAN-S8812WGM3NR-AMD-SP5100-AMD-SR5690-DDR3-DIMM-/300516937042?pt=LH_DefaultDomain_0&hash=item45f8348d52 http://www.overclockers.ru/hardnews/36648/AMD_predstavlyaet_processory_Opteron_61xx.html Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2011-03-14 11:41:11 Share Опубліковано: 2011-03-14 11:41:11 Вот такая сказка... Эксперимент неадекватен. Как минимум конфигурацией памяти, которую собственно тестируют. Ссылка на сообщение Поделиться на других сайтах
Laa 0 Опубліковано: 2011-03-14 20:25:14 Share Опубліковано: 2011-03-14 20:25:14 У меня freebsd 8.2 amd64 на core i5 4G ram, на этой машине были две сетевушки: Mar 5 07:12:37 billing kernel: em0: <Intel(R) PRO/1000 Network Connection 7.1.9> port 0xdc00-0xdc1f mem 0xeffe0000-0xefffffff,0xeffc0000-0xeffdffff irq 16 at device 0.0 on pci3 Mar 5 07:12:37 billing kernel: em0: Using an MSI interrupt Mar 5 07:12:37 billing kernel: em0: [FILTER] ... Mar 5 07:12:37 billing kernel: em1: <Intel(R) PRO/1000 Legacy Network Connection 1.0.3> port 0xec00-0xec3f mem 0xf7fe0000-0xf7ffffff,0xf7fc0000-0xf7fdffff irq 16 at device 1.0 on pci5 Mar 5 07:12:37 billing kernel: em1: [FILTER] накрутил net.isr и тд чтобы как-то разрулить нагрузку по ядрам. Разруливалось неплохо в принципе. Но потом появилась одна карточка ET dual port server adapter на два порта. Выглядит так: Mar 12 06:17:46 billing kernel: igb0: <Intel(R) PRO/1000 Network Connection version - 2.0.7> port 0xd880-0xd89f mem 0xf3da0000-0xf3dbffff,0xf3400000-0xf37fffff,0xf3dd8000-0xf3ddbfff irq 16 at device 0.0 on pci1 Mar 12 06:17:46 billing kernel: igb0: Using MSIX interrupts with 5 vectors Mar 12 06:17:46 billing kernel: igb0: [iTHREAD] Mar 12 06:17:46 billing last message repeated 4 times Mar 12 06:17:46 billing kernel: igb0: Ethernet address: 00:1b:21:4a:4e:1c Mar 12 06:17:46 billing kernel: igb1: <Intel(R) PRO/1000 Network Connection version - 2.0.7> port 0xdc00-0xdc1f mem 0xf3de0000-0xf3dfffff,0xf3800000-0xf3bfffff,0xf3ddc000-0xf3ddffff irq 17 at device 0.1 on pci1 Mar 12 06:17:46 billing kernel: igb1: Using MSIX interrupts with 5 vectors Mar 12 06:17:46 billing kernel: igb1: [iTHREAD] Mar 12 06:17:46 billing last message repeated 4 times Не в пиковое время на igb0: # netstat -w1 -h -I igb0 input (igb0) output packets errs idrops bytes packets errs bytes colls 25K 0 0 21M 24K 0 16M 0 24K 0 0 19M 24K 0 16M 0 25K 0 0 21M 24K 0 15M 0 25K 0 0 20M 24K 0 15M 0 24K 0 0 20M 24K 0 16M 0 25K 0 0 20M 24K 0 16M 0 23K 0 0 19M 22K 0 14M 0 25K 0 0 21M 23K 0 15M 0 top -SHP показывает: last pid: 92551; load averages: 0.25, 0.28, 0.21 up 2+15:13:04 22:13:17 153 processes: 5 running, 122 sleeping, 2 zombie, 24 waiting CPU 0: 4.9% user, 0.0% nice, 0.0% system, 19.5% interrupt, 75.6% idle CPU 1: 4.9% user, 0.0% nice, 1.2% system, 2.4% interrupt, 91.5% idle CPU 2: 2.4% user, 0.0% nice, 1.2% system, 1.2% interrupt, 95.1% idle CPU 3: 2.4% user, 0.0% nice, 3.7% system, 1.2% interrupt, 92.7% idle Mem: 472M Active, 1108M Inact, 662M Wired, 572K Cache, 418M Buf, 1711M Free Swap: 2048M Total, 2048M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K CPU2 2 58.9H 97.56% {idle: cpu2} 11 root 171 ki31 0K 64K RUN 3 59.1H 93.26% {idle: cpu3} 11 root 171 ki31 0K 64K CPU1 1 58.7H 92.87% {idle: cpu1} 11 root 171 ki31 0K 64K CPU0 0 51.7H 79.39% {idle: cpu0} 12 root -68 - 0K 384K WAIT 0 442:43 16.06% {irq261: igb1:que} 12 root -68 - 0K 384K WAIT 0 140:42 4.59% {irq256: igb0:que} 12 root -68 - 0K 384K WAIT 1 122:21 3.66% {irq257: igb0:que} 12 root -68 - 0K 384K WAIT 2 122:30 3.47% {irq258: igb0:que} 12 root -68 - 0K 384K WAIT 3 123:02 3.17% {irq259: igb0:que} 0 root -68 0 0K 224K - 1 30:16 0.49% {igb1 que} 0 root -68 0 0K 224K - 2 16:59 0.10% {igb0 que} 1594 root 76 0 65844K 28744K select 1 9:02 0.00% {mpd5} 0 root -68 0 0K 224K - 1 8:06 0.00% {dummynet} 929 root 60 0 25784K 19888K select 0 5:16 0.00% zebra 12 root -32 - 0K 384K WAIT 2 5:05 0.00% {swi4: clock} 1664 root 44 0 26932K 7468K select 3 5:02 0.00% snmpd 1461 bind 44 0 140M 130M ucond 1 4:03 0.00% {named} 1461 bind 44 0 140M 130M ucond 2 4:03 0.00% {named} 1461 bind 44 0 140M 130M ucond 1 4:02 0.00% {named} 1461 bind 44 0 140M 130M ucond 1 4:02 0.00% {named} Статистика по прерываниям: # vmstat -i interrupt total rate irq1: atkbd0 375 0 irq0: 1 0 stray irq0 1 0 irq21: atapci2+ 1731836 7 cpu0: timer 455343656 2000 irq256: igb0:que 0 1723037558 7568 irq257: igb0:que 1 817785911 3591 irq258: igb0:que 2 816455836 3586 irq259: igb0:que 3 827039286 3632 irq260: igb0:link 3 0 irq261: igb1:que 0 1955252087 8588 irq262: igb1:que 1 11240652 49 irq263: igb1:que 2 10827474 47 irq264: igb1:que 3 15654927 68 irq265: igb1:link 4 0 cpu1: timer 455343525 2000 cpu3: timer 455343524 2000 cpu2: timer 455343525 2000 Total 8000400181 35140 На igb1 у меня локаль с юзерами - dhcp + pppoe. Из отличий igb1 от em1: по графикам мртг при всем том же пропали ошибки, их было немного, но они были. Правда полета всего несколько дней, но на em1 ошибки были в первый же вечер активной нагрузки, в райное нескольких десятков ошибок. Это при ппс порядка 35 кппс. После установки dual port et визуально по графикам появились ппсы под 50кппс в первый же вечер. Раньше еле до 40кппс доходило в пики за многие месяцы. Но это субъективное мнение. Не нравится на et dual port что второй порт, который раздает pppoe и dhcp не параллелится на все четыре ядра, а только на одном преимущественно. В то же время на выхлопе igb0 не идеально, но параллелится на четыре очереди и по сравнению с em0 (intel pt) все четыре очереди потребляют на этом же железе вроде даже больше %WCPU. Вопросы: где почитать о том как подтюнить сетевушку чтобы нагрузка на портах лучше параллелилась? з.ы. может кому-то что-то по et dual port интересно на фре 8.2 -- спрашивайте, стоит, работает -- могу еще чего рассказать. Ссылка на сообщение Поделиться на других сайтах
KaYot 3 709 Опубліковано: 2011-03-14 20:41:47 Share Опубліковано: 2011-03-14 20:41:47 ET не распараллеливает pppoe трафик(это не IP), можете и не пытаться. Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2011-03-14 20:45:25 Share Опубліковано: 2011-03-14 20:45:25 Не в пиковое время на igb0: # netstat -w1 -h -I igb0 input (igb0) output packets errs idrops bytes packets errs bytes colls 25K 0 0 21M 24K 0 16M 0 это не нагрузка для этой карты Статистика по прерываниям: прерываний многовато. добавьте в /boot/loader.conf hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.enable_aim=0 hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=8000 hw.igb.rx_process_limit=1000 hw.igb.fc_setting=0 станет чуть поменьше. у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к Не нравится на et dual port что второй порт, который раздает pppoe и dhcp не параллелится на все четыре ядра, а только на одном преимущественно. это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют. Ссылка на сообщение Поделиться на других сайтах
jack 25 Опубліковано: 2011-03-14 21:47:31 Автор Share Опубліковано: 2011-03-14 21:47:31 прерываний многовато. добавьте в /boot/loader.conf hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.enable_aim=0 hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=8000 hw.igb.rx_process_limit=1000 hw.igb.fc_setting=0 станет чуть поменьше. у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к что для ET еще посоветуете подкрутить? или можно понаглеть, и увидеть конфиги? Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2011-03-14 21:57:00 Share Опубліковано: 2011-03-14 21:57:00 что для ET еще посоветуете подкрутить? или можно понаглеть, и увидеть конфиги? конкретно относящегося к igb больше ничего, собственно там больше крутить нечего. значения 1000-2000-4000-8000 выбраны эмпирическим путем, на наге где-то даже есть обсуждения и споры по поводу них, но работает) Ссылка на сообщение Поделиться на других сайтах
Laa 0 Опубліковано: 2011-03-15 06:42:12 Share Опубліковано: 2011-03-15 06:42:12 Не в пиковое время на igb0: # netstat -w1 -h -I igb0 input (igb0) output packets errs idrops bytes packets errs bytes colls 25K 0 0 21M 24K 0 16M 0 это не нагрузка для этой карты Дык знаю. Пока на том сервере в пики до 50кппс доходит, но лучше пусть серверок с запасом будет работать, чем на пределе. Статистика по прерываниям: прерываний многовато. добавьте в /boot/loader.conf hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.enable_aim=0 hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=8000 hw.igb.rx_process_limit=1000 hw.igb.fc_setting=0 станет чуть поменьше. у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к ok. сперва почитаю в if_igb.c об этом, потом решу добавлять или нет и сколько. Спасибо. А вот такой вопрос, sysctl -a не показывает в своем выводе hw.igb.rxd и кое-что еще, хочу понять, установка таки повлияет на что-то? Обычно то, что в loader.conf все показывает sysctl. Может этих переменных и нет в ядре и установка их ничего не изменит? Не нравится на et dual port что второй порт, который раздает pppoe и dhcp не параллелится на все четыре ядра, а только на одном преимущественно. это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют. ну я это и подозревал. Ссылка на сообщение Поделиться на других сайтах
Laa 0 Опубліковано: 2011-03-15 07:15:28 Share Опубліковано: 2011-03-15 07:15:28 ... прерываний многовато. добавьте в /boot/loader.conf hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.enable_aim=0 hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=8000 hw.igb.rx_process_limit=1000 hw.igb.fc_setting=0 станет чуть поменьше. у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к .. А что за переменные: hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=8000 ??? Я их в исходниках драйвера не нашел, в выводе sysctl -a тоже нет. Где о них почитать? Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2011-03-15 07:45:19 Share Опубліковано: 2011-03-15 07:45:19 А что за переменные: hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=8000 ??? Я их в исходниках драйвера не нашел, в выводе sysctl -a тоже нет. Где о них почитать? хм. действительно... похоже их убрали в последних драйверах. так что можно их убрать из рассмотрения. у меня они просто кочевали долго из системы в систему, когда-то были актуальны. Однако при указанных строчках имеем 5к прерываний. включаем sysctl dev.igb.0.enable_aim=1 и имеем 8-9к прерываний. выключаем sysctl dev.igb.0.enable_aim=0 и получаем вообще волшебство: 22092 igb0:que 0 Ссылка на сообщение Поделиться на других сайтах
Laa 0 Опубліковано: 2011-03-15 08:06:37 Share Опубліковано: 2011-03-15 08:06:37 Спасибо. Поставил у себя на лету dev.igb.1.enable_aim=0 и dev.igb.0.enable_aim=0 и судя по top -SHP стало постепенно становится меньше нагрузки в WCPU. Ну то есть, {irq261: igb1:que} при значении 1 было больше 8%, а при значении 0 стало около 7%. В это время на igb1 была пппое нагрузка + dhcp в районе 18-22кппс. Решил оставить = 0 и понаблюдать в пиковое время что будет. Ссылка на сообщение Поделиться на других сайтах
pavlabor 1 939 Опубліковано: 2011-03-15 08:08:45 Share Опубліковано: 2011-03-15 08:08:45 прерываний многовато. добавьте в /boot/loader.conf hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.enable_aim=0 hw.igb.low_latency=2000 hw.igb.ave_latency=4000 hw.igb.bulk_latency=8000 hw.igb.rx_process_limit=1000 hw.igb.fc_setting=0 станет чуть поменьше. у меня на одном тазике в два раза больше трафика (читай пакетов), а прерываний 5-3-3-3к что для ET еще посоветуете подкрутить? или можно понаглеть, и увидеть конфиги? man igb В зависимости от версии драйвера, расписывает возможные регулировки, помещается в /boot/loader.conf В /etc/sysctl.conf, помещаются общие настройки для системы немного тут можно почитать http://dadv.livejournal.com/49013.html http://nix-sa.blogspot.com/2010/12/sysctl.html Еще подсказку можно получить так # sysctl -d dev.igb.0.enable_aim dev.igb.0.enable_aim: Interrupt Moderation Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2011-03-15 08:58:24 Share Опубліковано: 2011-03-15 08:58:24 http://dadv.livejournal.com/49013.html http://nix-sa.blogspot.com/2010/12/sysctl.html надо не забывать только что у сысоева оптимизация больше под сервер приложений (веб), а не под роутер. тут скорее wawa надо пытать Ссылка на сообщение Поделиться на других сайтах
Laa 0 Опубліковано: 2011-03-15 09:06:46 Share Опубліковано: 2011-03-15 09:06:46 На сайте Интела еще в феврале появились драйвера для igb версии 2.0.8, кто знает что в них нового? А-то на сайте и в архиве нету changelog-а. Может кто-то тут юзал уже в тестах их? Ссылка на сообщение Поделиться на других сайтах
natiss 16 Опубліковано: 2011-03-15 12:07:12 Share Опубліковано: 2011-03-15 12:07:12 это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют. а как жеш IPv6 ? Ссылка на сообщение Поделиться на других сайтах
KaYot 3 709 Опубліковано: 2011-03-15 12:33:32 Share Опубліковано: 2011-03-15 12:33:32 это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют. а как жеш IPv6 ? А он у вас в ОГОшном модеме используется?) Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2011-03-15 13:34:34 Share Опубліковано: 2011-03-15 13:34:34 а как жеш IPv6 ? это кстати вопрос интересный. можно попробовать задать интеловцам. Ссылка на сообщение Поделиться на других сайтах
natiss 16 Опубліковано: 2011-03-15 13:34:56 Share Опубліковано: 2011-03-15 13:34:56 это фича. чип ET делит пакеты на очереди на основе IP заголовков пакетов, у PPPoE трафика данные заголовки отсутствуют. а как жеш IPv6 ? А он у вас в ОГОшном модеме используется?) Да, используется! И вам рекомендую Ссылка на сообщение Поделиться на других сайтах
KaYot 3 709 Опубліковано: 2011-03-15 13:50:27 Share Опубліковано: 2011-03-15 13:50:27 а как жеш IPv6 ? это кстати вопрос интересный. можно попробовать задать интеловцам. В даташите на боард заявлены все те же оффлоады/чексумы и RSS для IPv4/IPv6 TCP/UDP. Ссылка на сообщение Поделиться на других сайтах
natiss 16 Опубліковано: 2011-03-15 14:01:25 Share Опубліковано: 2011-03-15 14:01:25 В даташите на боард заявлены все те же оффлоады/чексумы и RSS для IPv4/IPv6 TCP/UDP. А MSI-X ? собственно Ссылка на сообщение Поделиться на других сайтах
adeep 212 Опубліковано: 2011-03-15 14:47:16 Share Опубліковано: 2011-03-15 14:47:16 А MSI-X ? собственно а вы мне объясните чем rss от msi-x по сути отличается?) имхо в данном случае rss это как раз то, что распихивает пакеты в очереди msi-x Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас