pozor. Je rozdíl mezi 10xQueue po třeba 10Mbit a 1xQueue po 100Mbit. První příklad se rozdělí mezi 10 "procesů" takže to dokáže efektivně rozprostříd ideálně mezi 10 jader. No ale druhej případ už ne a zůstane to vyset na jednom jádře protože "proces" je jenom jeden a nedá se dělit dál.
Vem si že máš 4 jádrovej xeon. Pro jednoduchost si vemem že jedno jeho jádro je 9x rychlejší než jedno jádro CCR1036. Co plat že výsledný výkon je stejný když chci třeba shapovat průtok k serveru na 500Mbit. Xeon to dá v pohodě protože queue si sedne na jedno jádro a protože je 9x rychlejší tak to zvládne v pohodě. CCRku to přetíží jedno jádro a je vymalováno. A teď si vem že máš 100 queue front po 5Mbit, jo to už CCRku sedí víc a proto taky většina lidí nic nehlásí v tomhle případě. Jenomže pak přijde ftipálek s UDPčkem a třeba 50.000 pakety za sekundu a sundá ti to tak jako tak. Xeon to unese protože on si jednoduše přehodí tuhle queue na jedno jádro a ostatní přesune na ostatní jádra a je v pohodě protože jedno jeho jádro je 9x rychlejší a tak těch 50.000pps v pohodě zvládne a ještě si bude říkat "to je nuda".
CCRko pak vypadá takhle (vypadávaji pingy, občas se nedá dostat na CCRko, občas se rebootne, často laguje komunikace což je vidět na screenu honzam na grafech ethernetu):
kdežto starší xeon si dává tohle (vidíš? do jedný queue teče 270kpps a xeon žije, ccrko nezvládlo ani 80kpps):
a když je ten problém větší, tak se na CCRko ani nedostaneš. Xeon vždy běží dál. Nebo třeba na CCRku ani nemůžeš pustit torch aby si zjistil odkud co teče a zaříznul to. Na xeonu jo. A když už to torchneš a zarazíš problémovej tok tak zase CCRko vyhnije na tom že on stejně musí ty data přijmout a dropnout takže se nic nezmění ale xeon si jede vesele dál.
Ono stačí aby si shapoval na tom 200 lidí po 10Mbit a pak přes to měl jednu čilou firmu s konektem 200Mbit kterou taky shapuješ a pokud to aspoň trochu budou využívat k 200Mbit tak krásně poznáš jak je CCRko k hovnu. Přesěn jak píše mato1. Latence lítají, packet losty jak na běžícím pásu atd.. Stejně tak jako mít CCRko před servery který jsou poslední dobou dost často terčem DDOS útoků... tak přesně tady CCRko nemá co dělat protože zařezávání toho DDOS útoku znefunkční CCRKo který tam má bejt právě kvůli ochraně a odfiltrování těhle věcí. Ten router musí bejt to poslední co padne protože on spravuje ten tok a to CCRko nezvládne.
Xeon ber jako x86 platformu a pokud možno ne atomy, zacate atd.. ale sandy/ivy bridge a haswell. Potažmo i některý trochu starší věci. Daleko horší je ale třeba to, že někteří haní x86 která jim léta dosluhuje a po výměně za CCRko si říkaji jak je to najednou super ale už neřeknou že na x86 měly MKv3 kterej nemá ani potuchu o multicpu a využívá takovýho quad xeona jenom z 25-40 procent. Stačí upgrade na MKv6 a rázem se zapojí všechny jádra a je to zase rychlík.
Já neříkám že je CCRko špatný. Já jenom říkám že na sítový operace ho mikrotik vůbec neměl použít. Já bych ho osobně viděl někde pro webový služby pro hromadu malejch requestů prostě jako server, to na co je určený. Ano, ono efektivně umí vysokorychlostě čistě routovat ale od routeru se v případě potřeby potřebuje aby v případě nouze něco s datovym tokem udělaly a to CCRko už nezvládne. To je jako že CCRko začali lidi dávat na BGP routery a za pár týdnů přišly z brekem že trvá půl dne než nahrábne to kvantum rout... proč asi? protože to je čistě sekvenční, jednovláknová operace kde CCRko prostě nemůže nikdy vyhrát. Xeon to bude mít za zlomek času. Bohužel tady mikrotik nejspíš uměle omezuje pro x86 dostupnou ramku a odmítá vydat x64.
Já nikoho přesvědčovat nechci. Já jenom říkám že za 20k je to kurva drahý a koupim za to raději něco na x86 co má větší užitnou hodnotu. To že někdo si neumí postavit router s podobnou velikostí, spotřebou atd. už je jiná písnička. Já vím že to jde.
