Jake zelezo na hl. router

Standardnímu OS je v podstatě fuk, kolik jader to má, v kolika paticích a jestli je to HT nebo není (a tohle poslední je trochu škoda). To, že to windows omezují je umělé omezení z licenčních důvodů - a řekl bych, že od Vist je to omezení na dva procesory fyzické (dřív bývalo na logické). Otázkou ovšem je, s jakým počtem je kompilovaný mikrotik ...

no to právě jedno neni. Dneska už se to snad většinou smazává ale starší duální systemy maji oddělený i ramky a dokonce i chipsety a každej cpu ovládá to svoje a když to má náhodou dělat druhej procesor, museji se tahat data z jednoho cpu do druhýho a to neni to samí jako víc jader v jednom cpu. Jo licencčně je to neco jinýho ale idálání je mít 16 jádro v jendom CPU než 8 jader po dvou cpu. Ono to pak jaksi nefunguje tak optimálně zvlášť když na to neni OS připravenej a neumí to dostatnečně dobře obsloužit. Jo pak tu je právě HT kterej zdvojí každý jádro a HT bejvá defaultně zapnutý takže si prostě myslim že mikrotik používá jenom jedno CPU se zapnutým HT a proto to ukazuje 8 jader. Kdysi na zahraničnim foru někde bylo že mikrotik neni schopnej využít víc cpuček ve více paticích. Jo jsou tam ale nepracujou.

quad core + noHT = 4 core

quad core + HT = 8 core

2x quad core + noHT = 8 core

2x quad core + HT = 16 core

Předpokládal jsem, že se bavíme o SMP architektuře, nikoliv o NUMA. V SMP je vše sdílené, proto také výkon neroste lineárně s počtem procesorů. Dost narůstá režie.

Ale z hlediska OS je opravdu fuk, kolik je tam jader a jak uspořádaných. Pokud není, je to umělé omezení. Nesnaž se to nijak okecávat. Navenek je vztah mezi jádry na jednom křemíku naprosto stejný, jako mezi těmi spojenými venkem přes čipovou sadu. Předpokládám také, že se nebavíme o DOSu.

To, že jeden fyzický procesor s více jádry je lepší, než stejný počet jader ve více "paticích" pravda je. Ale není nijak extra pravda, že by to byl až tak výrazný rozdíl. Zvlášť od doby, co se opustila FSB. Ono také PC je od toho, aby počítalo, ne aby přesouvalo pakety sem tam po sběrnicích ... Pokud jsou data v cache jednoho procesoru a potřebuje s nimi pracovat ten druhý, je z toho poměrně logická výkonnostní penalizace. Ovšem ani u vícejádrových procesorů není/nebývala jedna cache pro všechny, podle toho jaký slepenec to ve skutečnosti byl.

Proto je také pro naše (síťové) potřeby lepší menší počet jader, ale raději vyšší frekvence. Kdyby ale tohle dokázal řešit OS (optimální obsluhu procesorů), jak si myslíš, tak není potřeba např. u síťových karet vymýšlet takové věci, jako vícenásobné rx-queues - kdy sám HW karty doručuje pakety stále na stejné jádro dle konexe (dle nějakého hashe) a tím zajistí právě konzistenci cache, nejsou pak nutné jakékoliv přesuny, jednu konexi řeší stále stejný proces/thread. Ale je pravděpodobné, že takový paket odchází po odroutování jinou síťovkou, tedy vysoce pravděpodobně i jiným jádrem :-)

Šoupání dat se vlastně nevyhneš vlastně ani u nových CPU - L1 i L2 cache má každé jádro svou, společná je pouze L3, která je ovšem znatelně pomalejší ... Je ale také pravdou, že technologie u Intel Nehalem architektury to trochu řeší - co je v L1+L2 je zároveň i v L3, takže mají všechny jádra shodný přístup i k datům těch ostatních. A u víceprocesorových systémů (fyzických) má každá CPU vlastní nesdílený spoj na ostatní (přes QPI). Takže penalizace tam sice je, ale rozhodně ne tak hrozná jako v dobách P4. Viz http://www.pcper.com/reviews/Processors ... terface-an

Nebudu daleko od pravdy, když řeknu, že žádný OS neřeší rozhazování procesů a threadů na jádra podle toho, kde se to jádro fyzicky vyskytuje (lze to ovšem řešit ručním zásahem). Jeho prací je vytěžovat to rovnoměrně. Proto jsou také případy, kdy HT přinese pokles výkonu - prostě se to snaží používat jako skutečné jádro, ale už neví o tom, že to není celé jádro a spoustu věcí (především výpočetních) sdílí s ostatními - a ty pak musí vlastně čekat. Zářný příklad byl pokus ve windows, kde se pustil jeden proces třeba SETI. Myslely si, že mají 50% volného výkonu, byl to jenom jeden proces ... jenže s kompem se nedalo pracovat, to jádro prostě přestalo být použitelné (mluvím o jednojádru s HT). Podobně jsem na tom byl s MS SQL 2000. A u routovací mašiny je dle mě vhodné HT vypnout stoprocentně. Byť u nových systémů už to prý tak hrozné není, ale už jsem to netestoval a moc mi nejde na rozum, jak by dokázal práci s HT optimalizovat.

U MK bude také pravda, že používají nějaké starší jádro. A tam bývalo v defaultu nastavená kompilace pro málo jader (nějakou paměť to šetřilo). U kernelu 2.6.24 to bylo jen 4 (alespoň u archlinuxu), takže v podstatě mělo smysl jen dvoujádro s HT, víc bylo zbytečné (pokud sis to nepřekompiloval sám, nebo to neudělal distributor za tebe). Blbé je, že tuhle informaci mikrotik nedává ... A je to také důvod, proč na tvrdší nasazení NENÍ mikrotik vhodný - prostě do toho není vidět a dokumentace stojí za prd (o supportu ani nemluvě). S čistým linuxem je podstatně lepší šance, že je HW využitý dobře a že si nenaběhneš. Jo, je to větší dřina. Máš ovšem možnost vadný či nevyhovující kousek software vyměnit ... příkladem je např. routing - quagga. A třeba PCQ queues mi tam dost chybí (i když existuje projekt něčeho podobného, ale nevím v jakém je to stadiu). Jednoduchost obnovy MK (resp konfigurace) po nějaké poruše má také něco do sebe.

Vy se tu všichni a všude bavíte o "vysokorychlostním routeru" a přitom je řeč o tocích v řádu pár set megabit maximálně (200+). To jsem dělal na obyčejné P4 2.4GHz s neoptimalizovaným QOS a NAT. U těchto rychlostí je tedy vlastně fuk, jaký HW se pořídí (pokud to není RB).

Ale zkuste si mikrotikem vyřešit toky pro 2500 uživatelů, 700Mbit ve špičkách - na jedné mašině, co dělá NAT i QOS (co uživatel, to třída) zároveň. S vytížením prakticky zanedbatelným ... stačí linux, Xeon X3470 a síťové karty od intelu (s podporou MSI-X). Věříte tomu, že s MK to nepůjde? A to netvrdím, že jsme nějak přehnaně velká síť ... naopak.

Jo, co by mě zajímalo je, jak se dostat na rychlosti tak 2Gbit a výše ... ale takové informace se už hledají blbě a ještě hůř se to testuje.

Si možná nepochopil hapiho.

Jeho otázka zní velice jednoduše:

Když na desce necháš jen jeden CPU, kolik ti mikrotik ukáže jader?

Jenže to nám hapi nejspíš neřekne :-) To musí autor vyzkoušet, vypnout HT (je-li tam) a porovnat. Neřekl nám totiž ani typ procesoru.

Já jenom uváděl na přesnou míru některé nejasnosti.

Si možná nepochopil hapiho.

Jeho otázka zní velice jednoduše:

Když na desce necháš jen jeden CPU, kolik ti mikrotik ukáže jader?

jo já tě chápu ale OS co prostě neumí použít druhou patici nebo jí prostě jednoduše ani nezdetekuje prostě tu druhou patici nebude používat. Ačkoliv víc jader v jedný patici korektně. Proto jsem se ptal jestli je zapnutý HT a tim by bylo jasno jestli mikrotik s tim hnul a nebo to je furt plejtvání prachama. Protože pak nemá smysl kupovat duální desku když stačí cpu s více jádry který je efektivnější po více stránkách.

Zajímá mě jestli MK už konečně je schopný využít víc patic tak proto se ptám.

no to právě jedno neni. Dneska už se to snad většinou smazává ale starší duální systemy maji oddělený i ramky a dokonce i chipsety a každej cpu ovládá to svoje a když to má náhodou dělat druhej procesor, museji se tahat data z jednoho cpu do druhýho a to neni to samí jako víc jader v jednom cpu. Jo licencčně je to neco jinýho ale idálání je mít 16 jádro v jendom CPU než 8 jader po dvou cpu. Ono to pak jaksi nefunguje tak optimálně zvlášť když na to neni OS připravenej a neumí to dostatnečně dobře obsloužit. Jo pak tu je právě HT kterej zdvojí každý jádro a HT bejvá defaultně zapnutý takže si prostě myslim že mikrotik používá jenom jedno CPU se zapnutým HT a proto to ukazuje 8 jader. Kdysi na zahraničnim foru někde bylo že mikrotik neni schopnej využít víc cpuček ve více paticích. Jo jsou tam ale nepracujou.

IMHO je to presne obracene. Kdyz pomineme nejake historicke ultra drahe obskurni systemy, tak vsechny bezne starsi dvou a ctyr paticove servery jsou SMP-UMA, kdy se vsechno taha pres (pomalou) FSB a RAM je pripojena k jednomu (pomalemu) chipsetu a sdilena pro vsechny CPU. To plati vsechny starsi XEONy, stara pentia a take prvni K7 AMD servery. Naopak AMD K-8 Opterony prisly s architekturou SMP-NUMA, tedy kazdy CPU ma svoji RAM pripojenou na vlastni integrovany pametovy radic a propojeni procesoru se nekona po pomale FSB, nybrz po vyhrazene sbernici HyperTransport. S prichodem Nehalemu toto okopiroval i intel, jediny rozdil je, ze misto hypertransportu tam je QPI, coz je +- totez. Jelikoz se vsak jedna o SMP, pro non-NUMA-aware OS se vse jevi jako klasicke SMP, rozhodne by se nemelo stat, ze starsi OS nejaky procesor neuvidi. NUMA-aware OS maji tu vyhodu, ze dokazi prednostne vyuzivat RAM fyzicky pripojenou k tomu kteremu CPU pro procesy, ktere na nem bezi (a seskupovat vlakna oprocesu na jeden fyzicky CPU), coz v idealnim pripade zajisti temer linearni skalovani pametove propustnosti a tedy i vykonu celeho systemu, coz je hlavni vyhoda NUMA oproti stare UMA. Pro typicke pouziti v serverech je tedy rozhodne lepsi mit 2 CPU s 8 jadry v NUMA systemu nez 1 CPU s 16 jadry, protoze ta NUMA ma teoreticky az 2x vetsi pametovou propustnost. To jen pro poradek, nebot poradek, vy kluci pitomy, musi byt :)

http://cs.wikipedia.org/wiki/Non-Uniform_Memory_Access

no a vidíš jak seš chytrej když chceš. No a teď bych chtěl vědět jestli těch 8 jader co ukazuje mikrotik je reálných nebo hyperthreadingových.

no a vidíš jak seš chytrej když chceš. No a teď bych chtěl vědět jestli těch 8 jader co ukazuje mikrotik je reálných nebo hyperthreadingových.

jj :) pokud je na tom stroji povolen hyperthreading ( a CPU ho maji), tak by mel i mikrotik ty virtualni jadra videt, stejne jako jakykoli jiny linux.

o to se nepřu ale jestli to je zapnutý tak by tam mělo bejt vidět 16 jader ne?

Snažil jsem se dopátrat na tom DELLu, jak to to je s tím HT, popřípadě ho vypnout a sledovat rozdíl, ale v BIOSu, jsem k tomu nenašel ani čárku :-(

Nebudu daleko od pravdy, když řeknu, že žádný OS neřeší rozhazování procesů a threadů na jádra podle toho, kde se to jádro fyzicky vyskytuje

V tom si s tebou dovolim nesouhlasit, NUMA-aware OS (moderni linux kernely, solaris a MS Win 2008 R2) by presne toto meli umet, casto je k tomu ovsem take potreba NUMA-aware aplikace (napr. DBMS a pod).

Proto jsou také případy, kdy HT přinese pokles výkonu - prostě se to snaží používat jako skutečné jádro, ale už neví o tom, že to není celé jádro a spoustu věcí (především výpočetních) sdílí s ostatními - a ty pak musí vlastně čekat. Zářný příklad byl pokus ve windows, kde se pustil jeden proces třeba SETI. Myslely si, že mají 50% volného výkonu, byl to jenom jeden proces ... jenže s kompem se nedalo pracovat, to jádro prostě přestalo být použitelné (mluvím o jednojádru s HT).

Zbytek samozrejme souhlas

Snažil jsem se dopátrat na tom DELLu, jak to to je s tím HT, popřípadě ho vypnout a sledovat rozdíl, ale v BIOSu, jsem k tomu nenašel ani čárku :-(

Tak nám to tu nějak upadá, pochlubte se komu už běhá XEON E3 v provozu a jak si na tom stojí v reálném trafiku třeba s mikrotikem. Určitě je na to dost lidí zvědavo. Mně osobně by mi tahle informace hodně pomohla, jelikož je to adept na brzký upgrade shaperu.

Tak nám to tu nějak upadá, pochlubte se komu už běhá XEON E3 v provozu a jak si na tom stojí v reálném trafiku třeba s mikrotikem. Určitě je na to dost lidí zvědavo. Mně osobně by mi tahle informace hodně pomohla, jelikož je to adept na brzký upgrade shaperu.

o tyzden mi konecne dorazi masina s E3 xeon, takze zachvilu mozem poreferovat

Objednal jsem SuperMicro X9SCA-F do toho Xenona E3-1230 dvě giga ecc ramek a ssd 512

měl bych do cca do 14 dnů mít doma, tak to pak složím nahraju tam ROS 5.6 a pak to vyměnim za dosavadní P4ku která mi dle Smokepingu laguje prakticky vždy když síťovkama teče nad 50Mbit...

nejdřív to zkusím na integrovaných intelech, pokud to nepomůže tak zkusím koupit do prvního a druhého PCI-E slotu síťovky samostatný a uvidíme, ale doufám, že integrovaný budou fakat dobře (Hapi mi řikal, že první tři PCI-E sloty v tý desce jsou přímo do procesoru, tudíž by to mohlo odstranit dost nedostatků v podobě severního můstku, kterej dělá většinu problémů co máme se serverama na X86....

tak mam cca 3 týdny nasazený tohle nový dělo.

Zlepšení bylo okamžitě vidět ale rozhodně ne podle mých představ, protože v případě že tam teklo 80Mb a víc tak to stále docela dost lagovalo.

Tak jsem dál vymýšlel kde bude problém. Kupuju 100Mbit a zjistil sem, že můj ISP mi dává tu lajnu na 100Mbit ethernetu. Tak jsem si vyhádal aby mě přepojily na na 1Gbit ethernet no a lagy prakticky vymizeli viz hapiho statistika... takže doporučuju aby jste si při odběru takový kapacity automaticky domlouvali, že chcete být připojeni na co nejrychlejší fyzické vrstvě. myslím, že brát 100Mbit jenom 100Mbitovym rádiem se taky podepíše nekladně. toď moje poznatky. jo a jinak vytížení procesoru je do 10% ve špičce (na staré P4 bylo přes 50)

Na čem máš nainstalován ROS? usb nebo ssd?

Pri akom vytazeni upgradovat hlavny router?

Ja mam CPU v case vecernej spicky (co je casovy usek cca 4hod) na 60% pri 150 - 160Mbps. Prepisuju sa sem QoS a mangle pravidla z ISPADMINa - 2600 queus a 3700 mangles, plus staticky routing 370routes (NAT robi iny stroj ktory ide v spicke na 30%). CPU je Core2Duo 2800MHz.

Medzi routrami aj von do netu nie je ziaden packet loss.

co tam máš za verzi MKčka?

co tam máš za verzi MKčka?

4.16