Azért ez még sajnos csak a jéghegy teteje, mint minden az elbaszott informatikában, a részletekben rejtőzik el.
Mint pl. az x86 alapú többmagos rúterek teljesítményproblémái. Mert amíg annyival elintézzük a kérdést, hogy: áá, gond 1 szál se, az ARM-on ott van a fastpath meg a dedikált ASIC hardver a rútolás cpu-függetlenítéséhez, x86-on meg azt mondjuk az csípőből/izomból fogja bírni". Aztán megveszel egy embedded x86 boardot, mert nehogymár egy nagy asztali gép zúgjon, mert "csak" rútolni, "csak" tűzfalnak kell, elég lesz oda egy mini x86/x64 SBC (Single board computer). Csak aztán az olyan "egyszerű" dolgok, mint NAT, QoS, neadjisten vmi suricata IDS/IPS, na ezek Gigabit internet sebességnél már megeszik az embedded 1-2Ghz-es x86 CPU-t reggelire.
Aztán jön a marketing, hogy ugyan valóban csak gyenge szar 1-1.5-2Ghz a cpu, de van belőle 4 mag, azok együtt elbírnak a melóval! Meg intel IGB 200 chip-es a LAN, azon van 4 hardveres TX/RX queue, vagy ha megaloman vagy akkor IGB300 azon meg már 8 TX/RX queue van! Akkor a csomagütemező Receive Side Scaling-el (RSS) szét tudja osztani 4 cpu-ra a forgalmat, megoldott a gond!
Igen, csak azt sehol nem írják, hogy a Gbit internet-elérés a végfelhasználónak a PPPoE protokollon jön be (azaz amikor username+password kell az internetre "betárcsázáshoz" pl. Digi-nél), na ez az RSS szabvány whitepaper-ben is a szokásos ködösítéssel nincs kimondva egyértelműen, de végül csak nem kompatibilis az RSS-el. Ilyenkor minden pppoe forgalmat a hash algoritmus csak a default ID 0 queue-ba fog küldeni, tehát ilyenkor hajadra kenheted az RSS-t, meg a multi-queue NIC-et, meg a sokmagos processzort: 1 mag 100% koppon ki van hajtva, a másik 3 vagy 7 meg 0%-ob unatkozik.
VPN pont ugyanez a téma, azok is a többség 1 szálúra vannak korlátozódva. A crypto-t CPU-ban hardveres AESNI-vel gyorsítást pedig elvileg 1 időben ugyancsak 1 proceszormag futtathatja, pont azért h. ne legyenek mindenféle cach-timing jellegű hibák kihasználhatóak a párhuzamosan többi magon is futó AESNI-nél.
Az interneten népszerű benchmarkoknak az a fix becsípődése (BSD router Project pl.) hogy ők nagy szolgáltatói rúter szemléletű méréseket végeznek. Nem az 1 gép esetén elérhető bandwidth maximalizálást! Azaz ahol sok kis felhasználó forgalmát szimulálják egy rúteren átfolyatva. Ahol a rúter csak buta csomagtovábbító robot. Így megvan a kényelmes feltételezés, hogy a rúternek az a dolga h. a csomagot a bejövő interfészéről egy kimenő interfészére dobja tovább. QoS, tűzfal, NAT, IDS/IPS, ez mind nem létezik, ilyesmi nem része az ideális tesztkörnyezetüknek. Továbbá megvan a kényelmesen sok egymástól független (egyenként amúgy elég alacsony sávszélességű) network flow, amit a spéci ilyen felhasználásra tervezett hardver+szoftver szépen szét tud osztani multi-queu NIC, multi-core processzor. Így a mérésük máris hozza azokat az átviteli sebességeket, amiket te egy kis hálózatban, ha a célod csupán 1-2 v. pár kliens, már nem fogsz tudni soha hozni. Értsd a különbséget a mért teszt-eset és a te valós felhasználási modelled között! Bónusz pont h. a BSD router project szerint A-ról B gép-re küldött 1Gbit/sec forgalom az a mért rúteren 2Gbit/s teljesítményt jelent: 1gbit/s a bejövő interfészen+1gbit/sec a kimenő interfészen.
Szóval a végén ugyanoda lyukadunk ki: csak a legdrágább legbikább processzorral felszerelt vas fogja tudni a teljesítményt, ha akármit is be akarsz kapcsolni egy rúteren.