Jake zelezo na hl. router

[hapi]

Přesně takovouhle kombinaci HW jsem vybral k nám na bránu. Ty desky maji jedinou chybičku. Ethernety na desce jsou připojený až přes chipset. Ty xeony E3 maji 20 linek PCIe na CPU a vedou do PCIe slotů. Škoda toho ale to neni žádná chyba ani to nebude nic spomalovat. Ty xeony se mi hodně líbí.

Co ti to dělá, že ti to nestačí na 80/60Mbit? Máme podobný železo a podobnej počet pravidel a zatim to zvládá. Nám se tu akorát stává, že bezdůvodně při zátěži k 100Mbit začne stroj packet losstovat a přitom CPUčko jede ani ne na polovinu.

[Walkeer]

Dík za návrh, IPMI je hezká věc a možná ji tam přibalím, jseš si jistý že ta deska s rosem pojede? Co síťovky na desce? stačili by na trafik? Myslím že ty komponenty vypadají hodně solidně. Zkuste se k tomu vyjádřit i ostatní zkušení, co si o tom kusu hardware myslíte? Jaké to může mít s ROS limity? Díky.

edit: Možná bych spíš uvítal ATX desku kvůli více pci-e slotům, pro případné rozšíření. takže co tohle SuperMicro X9SCA-F?

tedy spise toto, ne? http://www.newegg.com/Product/Product.a ... -_-Product ta co jsi postnul ma take jen 3, tato ma 4. vygoogli si ty ethernety, ale myslim ze ROS 5.x podporuje vsechny intely

Přesně takovouhle kombinaci HW jsem vybral k nám na bránu. Ty desky maji jedinou chybičku. Ethernety na desce jsou připojený až přes chipset. Ty xeony E3 maji 20 linek PCIe na CPU a vedou do PCIe slotů. Škoda toho ale to neni žádná chyba ani to nebude nic spomalovat. Ty xeony se mi hodně líbí.

Co ti to dělá, že ti to nestačí na 80/60Mbit? Máme podobný železo a podobnej počet pravidel a zatim to zvládá. Nám se tu akorát stává, že bezdůvodně při zátěži k 100Mbit začne stroj packet losstovat a přitom CPUčko jede ani ne na polovinu.

myslim ze ty sitovky spojeni pres chipset brzdit nebude, to DMI 2GBps to jiste zvladne, ale souhlas ze primo do CPU by to bylo elegantnejsi. Jakou verzi ROSu mas? ten packetlos zni jako klasicky problem ze stare verze neumi vyuzit vice jader..

[hapi]

mám tam v5.4. Dělalo to na jakýkoliv verzi MKčka. Nevim jestli je nějaká divná deska nebo si tam něco s tim nerozumí. Každopádně když na vnitřní síti skrz routuju něco ke 100Mbit, latence lezou hoodně nahoru a PL je hodně vysoký. Vůbec netušim proč se to děje. No stejně musí to železo pryč a to s tim xeonem vypadá jako slušnej nástupce.

[dagus]

Tak jsme o tom hardware a použití s ROS nenašl ani čárku Potřeboval bych jistotu jestli to bude fungovat Nemáte tušení kde by mohli psát víc, co ani google nenajde?? V rámci zlepšování hardware je schváleno upgrade shaperů, ale jede to "na můj krk" a když na něm nepojede ROS Nemáte někdo reálný zkušenosti s tím serverovým chipsetem a ROS? Verzi 5.4 bych se až tak nebránil.

[Walkeer]

chipsetu bych se nebal, resil bych sitovky. nebo tady uz nekdo nekdy videl, aby nejakem intel chipsetu nejakej novejsi ROS nejel? Samozrejme bych tam dal to nejnovejsi, tedy 5.x
podle http://wiki.mikrotik.com/wiki/Supported ... t_chipsets ta druha pojede, ta prvni je otaznik. ale ta dualport NIC co jsem postoval by jet mela, je levna a muzes tam dat 4, tedy dohromady 9 portu to neni spatne

[ludvik]

Markování paketů a následný filtr na něj? Zkoušel jsi přímo CLASIFY target v netfilteru? Pak nepotřebuješ filtr ... A potřeba procesoru jde radikálně dolů.
Ještě lze využít přímo hash tabulky v TC, to je ještě výkonější. A vyhodit conntrack, pokud tedy neNATuješ.

Používáme samozřejmě TC (co jiného). Pro samotný shapping pak HTB, ESFQ a FIFO. Protože se shapují oba směry na jednom stroji včetně NATu pak ještě IMQ. Nepoužíváme hash tabulky ale klasické manglování v iptables a rozdělení pomocí filter pravidel v TC v jednoduchém stromu. 41tis. pravidel proto, že náš shaper umožňuje omezit maximální rychlost na každém segmentu sítě a také zajišťuje základní QoS (4 třídy pro každého usera). Těch 41tis. pravidel obsahuje i vlastní filtry v TC.

[Walkeer]

Ti z vas co maji vykonove problemy v linuxu, zkouseli jste nejak specialne potunit kernel nebo/a aplikovat nejake spesl patche? Zaslechl jsem tu neco o bindovani IRQ sitovek na konkretni jadra, ale nejaky advanced TCP/IP tuning kernelu ani ne. Pochlubte se prosim.
Take me napadlo ze by mozna nebylo od veci zkompilovat si kernel primo na konkretni CPU, napr. novy sandry bridge ma opet nejake nove instrukce/registry ktere by se mohli mozna hodit. Puvodni specifikace AMD64 je uz preci jen nejaky ten patek stara.
Dale ne vsechny offloading featury sitovek nejsou vzdy defaultne zapnute, zapnout je (a poradne otestovat) to by take mohlo trochu odlehcit procaku.

[hapi]

když jsem před necelim měsícem testoval distribuční debian tak neměl ani náznak problemů s IRQčky. Neměl vůbec žádný problemy. Spíš se flákal i při gigu provozu. I když jsem do manglů dal několik stovek pravidel, ani to s nim nehnulo. CPUčko se flákalo. Spíš ho víc zatěžovalo zjišťování vytížení CPUčka než ten datovej tok.

[Walkeer]

Co to bylo za zelezo? kolik pps? pokud tam je silny procesor, tak by vykonostni problem mel nastat az pri hodne velke zatezi, ale na atomu to asi bude neco jineho. Specialne tam bych to chtelo vyuzit vsechny instrukce co umi, ne jen generic i586/AMD64

[hapi]

starý C2D E5200 na DDR2. pps už nevim. Silnej procesor to neni.

viewtopic.php?f=7&t=7499&p=70358&hilit=E5200#p70358

Jo atom je uplně něco jinýho spíš podobný i486 i když to má nový instrukce ale technologicky hodně zastaralej kus křemíku.

[fedy]

mám tam v5.4. Dělalo to na jakýkoliv verzi MKčka. Nevim jestli je nějaká divná deska nebo si tam něco s tim nerozumí. Každopádně když na vnitřní síti skrz routuju něco ke 100Mbit, latence lezou hoodně nahoru a PL je hodně vysoký. Vůbec netušim proč se to děje. No stejně musí to železo pryč a to s tim xeonem vypadá jako slušnej nástupce.

tipuju, ze by se ti to mohlo stat i s xeonem ... budto jsou spatne rozhozene IRQ (cat /proc/interrupts) na kanaly sitovky , nebo spatna implementace shapovani a CPU prilis dlouho ceka na softirq ... a nebo oboji dohromady




jak to tady ctu, tak Vas s Mikrotikem na hranicnich routerech a shaperech musim litovat ...

ja shapuju 300 mbps , 150kpps , 2500 useru pomoci quadcore xeon e5620 s linuxem, IAOT PCIe integrovane sitovky, TC s hash tabulkama a ikdyz tomu prilozim zbytek do 1gbps stropu sitovek pomoci iperf, tak stejne vsechny jadra ukazuji 1% vytizeni takze by me samotneho zajimalo, kde ten box ma strop ... jinak je to Cisco UCS C200 (salamounsky - Cisco , ale preci Linux ) shaper funguje jako ciste pruchozi bridge, routuju na compu vedle...

jak uz zminoval mac78 - s mikrotikem na stozar

[Maxik]

Nevim co vas nuti vsecko honit pres 1 router kdyz potrebujete takove toky je lepsi to rozdelit na 2 masiny a je vyreseno, staci mnohem slabsi a levnejsi HW

[fedy]

Nevim co vas nuti vsecko honit pres 1 router kdyz potrebujete takove toky je lepsi to rozdelit na 2 masiny a je vyreseno, staci mnohem slabsi a levnejsi HW

...a ja zase nechapu, proc mit 2x zelezo , kdyz jedno (30-40kKc) spravne nastavene obslouzi s prehledem mnohem vic, nez co tady vetsina lidi potrebuje. ikdyz - jsou lidi schopny cpat do hranicniho routeru i wifi karty, tam uz je veskera pomoc marna . ale tady se zda, ze se vetsina lidi potyka pouze a jen s RouterOS !

[hapi]

jenom tak pro zajímavost. Měl jsem na hlavní bráně problem uroutovat přes jeden ethernet víc jak 100Mbit. Natahovaly se pingy, packet lost. Teď jsme posílili konektivitu a bylo třeba aby brána jela bez problemu. Problem se vyřešil když jsme vyndaly dva single ethernety a nahradili ho jednim duálnim. Proč? no, chipset G31 ještě tehdy měl jedno pcie do severního můstku a druhý pcie do jižního. Ethernet na jižnim můstku podával žalostný výkony a po výměně ethernetů se dokonce cca o polovinu snížilo i zatížení CPUčka. Aktuálně tlačíme do 100Mbit do 25% zatížením každýho jádra (E5200) a jede to bez problému.

[dagus]

Musím potvrdit, po výměně síťovek za PCI-E se zvedla propustnost z 65Mb na 130Mb/s a cpu šlo z 70% na 30%. Intel core2duo e4500 2.2ghz, jen se nám děl problém, že když jsem dal jednu 1gb pci-e a dvě 1g pci síťovky tak to zdechlo, a mašina s ROS 3.30 měla problém s pcie 1g kartou s chipsetem realtek, prostě to padalo. Po updatu na 4.17 vše v poho.