Příspěvky

1036

Sítě / Re:TP-LINK Router - OpenWRT

« kdy: 19. 09. 2018, 18:14:58 »

Asi před 8 lety jsem příbuzným koupil TL-WR tuším 741N. Vykašlal jsem se na záruku a preventivně jsem vyměnil uvnitř všechny asi tři elyty za solid polymer. Byla to už ta novější revize (kulatá krabička na mejdlo), co má uvnitř jediný Atheros SoC s integrovaným rádiem a skoro žádné další součástky. Od té doby jede. (Doufám že za trest pojedu pozejtří vyměnit shnilej externí zdroj :-)

1037

Hardware / Re:Server do racku pro malý podnik

« kdy: 19. 09. 2018, 18:04:25 »

... Záruční technici netušili, co to je chyba ECC paměti, pořád zkoušeli bios check, který samozřejmě vždy doběhl...

Zrovna cvičně a spíš pro zábavu řeším s DELLí podporou debilní touchpad na low-endovém funglovém Dell Vostro (nedávno tu poblíž kdosi poznamenal, že značkové SoHo notebooky mají zcela oddělený support od pracovních notebooků).

Naschvál jsem to hlásil v AJ takže se se mnou baví jinak velice příjemný a nápomocný polský supportista.
Dostali ode mne nějaké okomentované screenshoty toho jejich GUI bastlu, dostali přesný popis že se nezobrazí originál Synaptičí SynTPCpl.dll (custom tab ve vlastnostech myšoidního zařízení). Dostali sáček dalších informací, co jsem dokázal došmejdit pod kapotou, natočil jsem jim filmeček co přesně mi vadí...
Zatím jsem jim vyzkoušel všech 5 oficiálně dostupných verzí driveru (Synaptics základ přebalený Dellem, doplněný o jakousi konfigurační utilitu od DELLu) - Synaptics už nedává drivery veřejně přímo jako za starých časů. Nejde vypnout citlivost na dotyk v prostoru "virtuálních tlačítek" (bug), dokonce ta mrcha nemá ani vypínání touchpadu klávesovou zkratkou... (což je zjevně feature) - prostě značkový stroj jak víno, a s technickou podporou se zatím častujeme zbytečnou prací, aby to on mohl konečně eskalovat na někoho s nenulovými pravomocemi a inside informacemi :-)
Ten příjemný 1st-level Polák za to jistě nemůže, přesto jakožto dlouholetý uživatel SoHo noťasů Acer a poslední dobou Lenovo jenom kroutím hlavou...

1038

Sítě / Re:Napětí pro pasivní PoE

« kdy: 19. 09. 2018, 15:10:19 »

Lidem co potřebují něco napájet stejnosměrem a je to pro ně novinka, jsem věnoval jednu krátkou kapitolku pro začátečníky. Třeba to něco vysvětlí.

Netroufám si tvrdit, co je horší otrava, jestli 802.3af nebo nestandardizované pasivní PoE. Asi podle situace a momentálních požadavků. Obecně bacha, co čím napájíte :-) Nejdřív hledejte zmínky o 802.3af/at (=48V), pokud nenajdete tak se jedná patrně o pasivní PoE a hledejte jmenovitý rozsah napájecích napětí. (Jak už pravil pan Caletka, hlavně nepřekročit horní mez.)

Ve Vašem případě řešíte, že potřebujete jedním CAT5e kabelem napájet Mikrotik a teď ještě něco navíc. Problém může být s úhrnnou spotřebou (odběrem proudu). Jako vodítko pro rozumný strop bych opět použil 802.3af/at, kde jako strop vypadá odběr nějakých 350-500 mA, toto rozloženo na dva kontakty RJ45 (dva tam, dva zpátky). Úbytky na vedení si případně můžete spočítat podle Ohmova zákona, pokud se dočtete až k němu. AWG24 má průřez jedné žíly asi 0.2 mm^2 pokud se nepletu. Hlavní problém bych ale viděl v zatížitelnosti kontaktů - aby to nehnilo / nehřálo / nejiskřilo. To by pak totiž přestaly chodit i data.

Čili na 24 V (krát cca 0.5 A) je rozumné maximum nějakých 10-12 W celkové spotřeby. Což je tak 2x základní Mikrotik Routerboard, ale pokud tam bude switch nebo co, tak už bych se měl na pozoru. Pokud to pojede na 12 V, tak krát 0.5A jste zhruba na 6 Wattech, taky odpor vedení bude cca 90 miliOhmů na metr, tzn. na 10 metrech CAT5 kabelu bude při 0.5A asi 0.45 V úbytek... Prostě jeden Mikrotik s odhadovanou spotřebou 3W na 20m třeba ještě prosím, ale víc bych toho tam nevěšel. Pokud je fakt velkej problém, použít košer 802.3af PoE (na 48-55V se protlačí větší výkon) nebo tam natáhnout napájení extra, ať už 230V nebo 12/24V tlustým kabelem, tak můžete ještě laborovat s pasivním injektorem, který hrne napájení všemi čtyřmi páry... ne že bych takový někde potkal.

Pokud taháte napájení venkovním prostředím tak bacha jednak na vodu, jednak třeba taky na blesk. Košer venkovní rozvaděč trochu odolný povětrnosti nemusí být ukrutně drahý, ale možná by ho měl realizovat někdo trochu víc od drátenického fochu.

BTW jestli Mikrotik nebo Ubiquiti je co do spotřeby dost jedno, uvnitř jsou stejné "platformy" švábů od Atherosu. Odledování antény tím asi krmit nebudete.

Jakýkoli spínaný měnič doporučuji "podle palce" dvojnásobně až třínásobně předimenzovat oproti změřené skutečné ustálené spotřebě napájených spotřebičů. Měniče na plný výkon nevydrží dlouho, na druhou stranu štítkové spotřeby bývají nafouklé. A průmyslové měniče MeanWell na DIN lištu nejsou vůbec špatné, za ty prachy dost slušná kvalita, určitě lepší než "běžná černá bradavice do zásuvky". Svorky bývají slušně dokola kryté, případně můžete zdroj zavřít do nějaké plastové krabice. Radši by měl mít dost vzduchu kvůli chlazení. Pokud si netroufáte nasvorkovat tři fousy 230V, nebo to chcete mít všechno legálně v pořádku, pozvěte si na to elektrikáře s padesátkou. (Hehe a nakonec revizáka :-)

1039

Sítě / Re:Ping do LAN na zařízení, které nemá nastavenou GW

« kdy: 19. 09. 2018, 13:10:44 »

Tady je otázka, PROČ některé stroje nemají nastavenu default GW, nebo obecně routing pro VPN na daném přístupovém bodě. Připadá mi to jako opravdu velká hloupost.

Zrovna tady za to mohly jakési provozní důvody, ale zažil jsem i historická zařízení, kde autor před 25 lety prostě rozhodl, že to přes IP sice komunikuje, ale jenom po lokálním ethernetu a basta. Default route to neumí. Nebo je to bug, který ale "nikdy nikomu nevadil"(TM) a novější firmware není. V "průmyslu" dost často narazíte na historické hrůzy na které se nesahá, protože se na ně nesahá. Někdy jsou to boxy dost zvučných značek. A pro trochu komfortu šel bys světa kraj.

1040

Sítě / Re:Jaký wifi router

« kdy: 19. 09. 2018, 12:58:40 »

To František Ryšánek:
Spektrálny analyzátor je možné urobiť aj z klientskej karty ku ktorej sú dostupné zdrojáky ovládača. Najlepšie asi Ralink/Mediatek, ktoré majú prístupné registre MAC/BaseBand procesora včítane tunera. Hral som sa s tým niekedy v minulosti na karte Ralink rt2500. Bolo možné prelaďovať tuner po kroku 1.25 MHz v celom pásme a ešte aj niečo aj mimo pásma. Bohužiaľ som to nedokončil do stavu použiteľnosti pre spektrálny analyzér.
Signál/šum myslíš jednotlivo ako signál a šum, alebo ako hodnotu, ktorá sa zvykne označovať ako SNR?

Hodnota SNR je totiž najdôležitejšia hodnota pri meraní. Vychádza z nej meranie modulačných rýchlosti.
Napriklad tu:  http://lso.fe.uni-lj.si/studij/rk_vs/lab/Radijski%20vmesnik%202,4GHz%20Wi-Fi%20naprav/Revolution%20Wi-Fi%20MCS%20to%20SNR.pdf
Bude sa to ešte líšiť podľa použitia spomenutých inovačných technológíí, ktoré zvyšujú SNR.

...nezměnil jste si nick? Před pár lety tuším na Ábíčku mě na podobné téma kdosi poctil osvětou... ale řeč byla tehdy tuším o tom, že u Ralinku jde nastavit práh "rušení v pozadí", které karta začne vnímat jako užitečný signál (a z důvodu CSMA/CA sama nezačne vysílat). Dotyčný doporučoval tenhle práh zvýšit resp. s tím laborovat, že je šance tímto dosáhnout lepší "efektivity využití éteru" v hustě zabydlené oblasti. Protože factory default je v mnoha situacích "zbytečně citlivý". Ale mám pocit, že ten kolega tehdy mluvil moravsky...

Jinak spektrální analyzátor je mi sám o sobě vlastně k ničemu - v tom smyslu, že s ním "in situ" nezměřím PSV antény. PSV=SWR lze měřit dvěma způsoby:

• přibližně skalárně spektrákem / wobblerem / polyskopem - tady asi není ani striktně potřeba směrová odbočnice, v zásadě asi stačí budit anténu jmenovitou impedancí, buď šumem nebo rozmítaným sínusem
• nebo vektorově, tzn. budit rozmítaným sínusem a snímat si kvadraturně "odražený" signál, tzn. nejlíp asi směrovou odbočnicí -> downmix -> vzorkovat I+Q. Pokud si správně pamatuju, dá se z toho nakreslit Smith Chart pro parametr S11. Poté co si tu odbočnici nakalibrujete...

Pokud bych tohle chtěl po wifině, musela by umět zároveň přijímat i odesílat (full duplex) a neodpálit si při tom vlastní vstup (přijímač). Standardní wifina má v rádiovém front-endu rychlý přepínač TX/RX, tzn. PA/LNA. Tohle je práce spíš pro HackFR One apod. Které ale jako celek do formátu MiniPCI-e kartičky nevecpu. Možná by se dala vyrobit aspoň "měřící hlavice = PA + odbočnice" v tomhle formátu. Takže na to peču, protože pro těch pár kusů ročně nemá cenu si s tím lámat hlavu.

1041

Hardware / Re:Server do racku pro malý podnik

« kdy: 19. 09. 2018, 11:00:39 »

@behemot ad infratstruktura budov: ono totiž tahat dráty je náklad na lidskou práci. To se nikomu nechce. Navíc firma do nájmu se často napřed nastěhuje včetně nábytku, a až pak začne řešit, že potřebuje LANku. Takže se v lepším případě leze po kolenou za nábytkem, který bylo třeba po pečlivém rozmístění dodatečně odstavit. Vrtají se průrazy do zdí v zabydlené kanceláři na už položeném funglovém koberci, kde se kancelářstí zaměstnanci snaží mezitím normálně pracovat. Ty průrazy se vrtají do zdí v baráku, kde není dokumentace o vedeních NN v omítce a není spoleh na dnes normou stanovené "instalační zóny". Externích dodavatelů na tuhle drátenickou práci je jako šafránu (ajtíků i prostých elektrikářů), zejména pokud se jedná o "malou" zakázku. Šéfovi firmy v nájmu se to moc nechce řešit, protože přece nebude investovat do infrastruktury pronajímatele (kromě toho, že IT nerozumí, takže kvalitní rozvod LAN neocení). Nájem byl výhodný, a o to jde především. Vlastníkovi baráku je to už úplně putna - nastěhovali se, havárie ve vodovodu a kanaldě průběžně řeším, dejchaj muj vzduch, tak ať platěj. Tu starou ratejnu stejně nemá smysl nějak extra zušlechťovat, nedejbože v ní nějak systematicky tahat nové dráty, navíc ani ne pro silovou elektriku, ale nějaké otravné slaboproudé špagety... Někdy proběhne pokus o wifi, ústup na CAT5e rozházené po podlaze apod.

V baráku z doby před listopadem by to člověk ještě pochopil. Ale nejhorší je, že projektanti nových budov na to často kašlou úplně stejně. Barák projektuje člověk, který je schopen spočítat statiku a kubíky betonu, ale zeptat se specialistů na různé "sítě" (včetně potrubí), a naprojektovat taky průchody skrz stropy, aby se vyřešily bedněním a výztužemi před betonáží (která se beztak leje monoliticky na místě), aby se nemusel vrtat už hotový nosný beton včetně výztuží (případně otloukat drahé obklady ve zvýšeném přízemí) to by pro mnohé stavaře-projektanty zřejmě znamenalo vyštudovat druhou vejšku. (Nemluvě o architektech, kteří se pohybují v rovině prostorové dispozice, estetiky, uměleckého záměru - těm projektanti "nosí vodu".)

Velmi dobré elektro stoupačky má nepravoúhlé bludiště zvané Pakul. Další světlou výjimkou jsou datacentra stavěná na zelené louce, kde projektant stavební části byl zřejmě polyhistor, nebo měl k ruce multioborového projektanta sítí (a bylo to managementem nějak posichrované, aby se nepostavilo datacentrum bez možnosti natahat sítě).

1042

Hardware / Re:O kolik je Intel Optane výkonější než současné notebookové SSD?

« kdy: 19. 09. 2018, 10:35:53 »

Omluva za exhumaci šťastně zesnulé flame war...

Narazil jsem na tuto debatu tak, že jsem se snažil domáknout něco o reálných vlastnostech reálně dostupných produktů Intel Optane. S tím že mě osobně nijak zvlášť netankuje rychlost, ale tankuje mě odolnost/výdrž za provozu. A přestože Intel detaily moc nekomentuje, tak mám pocit, že se marketingová mlha díky reálnému uvedení na trh přeci jen už trochu rozestupuje.

Konkrétně lze nalézt čísla, jako že konzumní 32GB Optane modulky mají slíbený zapsatelný objem 180 TB (tzn. "TBW"). To je asi 5600 kompletních přepisů. Pokud vezmu jako "benchmark" klasickou MLC flashku, tak ta dovolovala natočit cca 3000 přepisů. Tzn oproti 22nm MLC NAND Flash jsme na první pohled cca na dvojnásobné životnosti. Oproti MLC v jemnější litografii a moderním TLC je ten poměr pro Optane lichotivější.

"Enterprise" verze Optane mají např. 20 PBW při kapacitě 375 GB. To už vychází asi na 50 000 kompletních přepisů. Kapacita 375 GB podle mého znamená, že zbytek do 512 GB je "odložený stranou" jako rezerva na "vadné sektory".

Pro srovnání, technologie SLC NAND Flash mívá taky udáváno řádově 50k mazacích cyklů (kompletní přepis SSD) při citelně menší "rezervě", kapacity SLC SSD se dodnes udávají obvykle v "binárně kulatých" číslech. A pravda je, že optane je asi levnější než SLC a odhadem i rychlejší (kratší "doba vystavení").

Pro srovnání, produktová řada Innodisk iSLC (MLC NAND Flash čipy, kde je nejspíš cca půlka odložena na rezervu) má slíbených 20k přepisů - v první generaci s hrubší litografií to bylo dokonce 30k.

Čili původní představa (možná jenom moje halucinace) že 3D Xpoint znamená neomezeně přepisovatelnou EEPROM, je zjevně zcestná. Reálná SSDčka Optane mají omezenou životnost.

Otázkou zůstává srovnatelnost čísel TBW/PBW mezi NAND Flash a 3D X-point. Z toho, že Intel tato čísla udává, podle mého plyne, že Optane SSD interně používají nějaké hlídání a remapování vadných sektorů, nebo spíš starý dobrý wear leveling. V tom případě je otázkou, jak velká je alokační jednotka pro zápis (1 bajt? nebo 4k jako u Flashek? Nebo něco mezi) a jak velký je "erase blok". Jestli to jede ve dvou patrech jako Flash, nebo třeba jenom jednopatrově. Nejede to třeba zápisy i mazání klasicky po sektorech 512B nebo 4k? S tím souvisí objem a organizace interních metadat pro mapování uživatelského LBA adresního prostoru na fyzické čipy a jejich interně alokovatelnou granularitu - a potažmo rychlost a další chování při zápisu, čtení apod. A především: z detailů této organizace bude plynout "amplifikace počtu přepisů" při zápisu drobnými transakcemi, menšími než "erase block". Tolik ke srovnatelnosti TBW/PBW mezi flashkami a Optane. Je možné, že to číslo bude "za jinak stejných okolností" (konkrétní mix zápisové zátěže) znamenat u každé technologie jinou reálnou dobu fungování.

Je možné, že 3D X-point jde přinejmenším jednotlivě po bajtu *číst*. Z toho by mohla plynout hodně krátká latence - četl jsem správně že desetinová oproti NAND Flash?

A ještě jak jste si tu vjeli do vlasů ohledně závislosti doby buildu čehosi v Javě na různých faktorech... co takhle CAS latency použitých RAMek? Myslím spíš v nanosekundách než v počtech taktů. Pokud běh Java VM reálně znamená procházení rozsáhlého grafu všelijakých referencí / nepřímých odkazů, které značně přesahují kapacitu CPU cache všech tří úrovní, může to celé záviset právě na "vystavovací době" DRAMek. Když musí CPU čekat na přístup na náhodnou adresu do DRAM, lítají vzduchem vysoké desítky wait states. Pokud se dá benchmarkovaná úloha paralelizovat, může více CPU jader využít více kanálů DRAM (a možná líp když nepojedou prokládaně = nebudou "synchronizovat seeky".) Průser je, že CAS latency v nanosekundách se moc nevyvíjí. Tuším v dobách EDO DRAM byla CAS latency nějakých 50 ns. Další vývoj jsem zrovna našel v hezké tabulce u firmy Crucial. For the record: u PC100 SDRAM je udáváno 24 ns, pak skokem zlepšení na 15 ns u DDR, a dál v podstatě už nic, DDR4 je někde na 13.5 ns. Navíc si nejsem jistý, jestli ta čísla nejsou ještě dost optimistická (přímo na nožičkách DRAM čipů nebo tak něco). Nějaká čísla si počítá taky heslo na Wikipedii, ale podle mého jsou odtržená od reality (paměti DRAM s CL pod 10 ns se reálně neprodávají). Napadá mě, proč se do serverů nedělají DIMMy se SRAM namísto DRAM - no zjevně nejsem první koho to napadlo. Odpověď zní: v gigabajtových kapacitách by to stejně nakonec nebylo rychlejší. Čili závěr z toho by mohl být: paralelizovat úlohu a provozovat ji na masivně paralelním CPU s mnoha nezávislými kanály paměťového řadiče (HBM? jak vypadá řadič?)

1043

Hardware / Re:Server do racku pro malý podnik

« kdy: 19. 09. 2018, 09:33:34 »

"lokalni ajtik" .... novy pojem ve svete IT.

Já vím že krmím trolla ale... bejvaly doby, kdy jsem seděl v Praze, dělal rukama na klávesnici, a málem jsem se styděl vzít do ruky šroubovák. A měl jsem pocit, že se dá všecko udělat na dálku, takže pojem "lokálnosti" byl jaksi nadbytečný.

Dneska Prahu vnímám jako časoprostorovou anomálii - pokud potřebuju odněkud někam v ČR dojet a mám po cestě Prahu, musím naplánovat cestu tak, abych do Prahy nedorazil mezi 6:45-9:30 a mezi 15:00-18:30. A jak pravil Behemot - i mimo korporace malé firmy potřebují základní IT, a já dodávám, že malé firmy se vyskytují i mimo Prahu. Hehe často zrovna "na venkově" je mnohem menší problém, dostat do kanclu optiku, tolik neřešíte prostor pro servery / krámy / lidi atd. Neplatí to paušálně, je třeba být trochu vybíravý.

1044

Sítě / Re:Implementácia a náročnosť SW bridge

« kdy: 19. 09. 2018, 08:23:00 »

Bridge by sel nejlepe s realteky implementovat tak, ze IRQ hned u dalsi sitovky prenastavi TX buffer a necha odesilat paket, tzn. vlastni paket se nemusi ani kopirovat, jen se upravi MAC adresy (u forwardu, u bridge netreba).

Taktak... ovšem modulo případně problémy s dostatečně rychlým uvolňováním takto využitého RX bufferu, jak už jsem psal výše. Důsledně vyprazdňovat RX buffer tím, že budu kopírovat do další TX fronty je IMO odolnější proti přetečení (záleží na kapacitě dotyčné TX fronty a algoritmech okolo).

Zajimave by to mohlo byt pokud by se podarilo hacknout firmware nejakych drazsich sitovek (napr. nejake Broadcomy), tam by totiz slo udelat prenos sitovka-sitovka bez toho aby do toho CPU vubec hrabalo.

Ohledně přímého přenosu síťovka-síťovka: pokud by se jednalo o oddělená PCI zařízení, tak by to IMO znamenalo, že by cílová síťovka musela mít svůj interní TX buffer exportovaný na PCI sběrnici jako IOMEM okno = v některém BARu přiřazenou adresu a velikost okna (a tyto parametry reálně "dekódovat"). Zdrojová síťovka by učinila rozhodnutí, kam paket switchnout, a poslala by ho na cíl (k tomu by potřebovala přístup k "forwardovací tabulce").
Nebo by mohla exportovat svůj RX buffer zdrojová síťovka, pokud by někdo druhý (hostitel?) učinil "forwardovací rozhodnutí" a instruoval cílovou síťovku, odkud si má paket "zobnout" :-)

K tomu vysvětlivka: pokud správně rozumím, DMA přenos z periferie do RAM běží na PCI sběrnici pomocí bus-mastering transakce "write memory", kterou iniciuje sama periferie, tzn. cílová adresa v této transakci ukazuje skrz hositelský PCI root bridge do hostitelovy RAM. Zdrojovou adresu PCI transakce nemají, takže data burstového zápisu do paměti můžou na straně zdroje téct z nějakého FIFO bufferu, který ani není zvenčí adresovatelný/viditelný. Analogicky z RAM do PCI periferie opět stačí paměťové okno v hostitelově RAM, periferie pomocí transakce "PCI read memory" zkonzumuje obsah okna do nějakého interního FIFO bufferu. Při komunikaci mezi periferiemi navzájem musí aspoň jedna periferie exportovat IOMEM BAR.

Blahé paměti na ISA sběrnici tuším chyběla "autonomní adresní fáze", a pro nasměrování DMA přenosu do konkrétní oblasti RAM byla třeba spolupráce DMA řadiče v čipsetu hostitelského systému, potažmo konkrétní periferie měla pro sebe trvale vyhrazený DMA kanál atd.

PCčko s ochranou paměti pomocí MMU má tzv. fyzický adresní prostor na adresních vodičích pouzdra CPU, a interně si spravuje jeho mapování na virtuální paměťové prostory (kernel a jednotlivé user-space procesy, bokem do toho vstupuje stránkování, swapáč apod). Adresní prostor sběrnice PCI je teoreticky další, opět nezávislý, adresní prostor. Pokud by se PCI periferie bavily mezi sebou napřímo, budou se bavit v kontextu adresního prostoru PCI sběrnice. Překlad fyzického adresního prostoru hostitele na adresní prostor sběrnice PCI provádí PCI root bridge (AKA root complex AKA host bridge).

Adresy IOMEM oken na PCI (skutečně dekódované PCI periferiemi) tedy nejsou nezbytně shodné s adresami ve fyzickém adresním prostoru CPU. Že to hostitelský systém může zařídit tak, aby adresní prostor PCI byl 1:1 s fyzickým adresním prostorem CPU, to je jiná věc. Není to pravidlem. Potažmo než chcete z hostitelského CPU (klidně z linuxového kernelu) sahat nějakému PCI zařízení do IOMEM okna, musíte zavolat "ioremap" nebo jak se to jmenuje. Dostanete virtuální adresu, která Vám bude v programu fungovat. (Analogickou mapovací funkci umí i v DOSu DPMI extender, ovšem tuším nikoli 16bitový PCI BIOS.) Osobně jsem nikdy neprogramoval PCI DMA, takže si nejsem jistý, co všechno je třeba udělat, aby si periferie mohla sahat do hostitelské RAM - čekal bych tam nějaké "inverzní" mapování/dekódování adres zajištěné PCI root bridgem, možná na tom spolupracují MTRR registry... co já vím.

Matně si vybavuju, že snad PCI sběrnici mělo na přelomu století v backplanu Cisco 7200 series (router) - ale co s čím po té sběrnici komunikovalo, to si netroufám tvrdit. Je fakt, že Cisco je průkopníkem všelijakých offloadů a akcelerací.

1045

Sítě / Re:Implementácia a náročnosť SW bridge

« kdy: 17. 09. 2018, 20:48:50 »

Frantisku, muzu se zeptat jestli mate svuj vlastni generator dlouhych odpovedi nebo pouzivate nejakou externi sluzbu?    ;)Pisete vzdy zajimave a k veci a strasne moc textu...

No ale to je prave super, clovek se aspon dozvi neco noveho a ma nad cim premyslet. Za me rozhodne palec nahoru k podobnym postum. A taky chci podekovat, ze s tim prispevovatel da takovou praci.

Pánové už dost, já se tou chválou červenám ;-) Vedle zřejmé grafomanie by se jistě našly i nějaké další diagnózy. A stavu pacienta zrovna neprospívá, že má luštění počítačových hádanek v popisu práce. Ono je otázka, jestli by nebylo přínosnější, kdyby za mnou namísto toho roztržitého luštění a písmáctví zůstávala nějaká hmatatelnější tvorba. Momentálně mi okolnosti nedopřávají delší attention span.

1046

Sítě / Re:Literatura k proniknutí do sítí

« kdy: 17. 09. 2018, 15:52:20 »

Skutečně hezkých a obrázkových věcí je na webu jako šafránu. Zrovna jsem jednu trochu snesitelnou knížku našel - zkuste nejdřív prolistovat obrázky. Koukal jsem taky na RFC-1180, ale řekl bych pro začátečníka dost tuhé čtení.

Ta kniha vysla uz pred asi 25 lety, coz je pochopitelne znat. Zaklady popisuje moc pekne, ovsem rada uvadenych temat se jiz v dnesni praxi temer nevyskytuje a nove veci v ni pochopitelne byt nemohou

Přesně tak. Ke starým knížkám mám nostalgický vztah, hlavně když jsou v nich hezké obrázky. Ale když pak zjistím, že se do knihy nestihl dostat ani CIDR, je mi smutno.

Stejně tak stará RFCčka s čísly okolo 1000 byla ještě relativně čitelná - protože nebyla až tak suše akademická a ty protokoly nebyly ještě evolucí tolik nabobtnalé. Bohužel když se dneska člověk začne učit odtamtud, dopouští se archeologie.

1047

Sítě / Re:Literatura k proniknutí do sítí

« kdy: 17. 09. 2018, 11:06:14 »

Mám pocit že Satrapovo IPV6 je příjemně čtivé dílko, ale spíš pro člověka, který už zná základy / předchozí historii, tzn. především IPv4 a Ethernet a třeba taky líznul DNS, BGP apod. (S nějakým PPP, SLIP, HDLC, Frame Relay atd. bych asi začátečníka neprudil.)

Skutečně hezkých a obrázkových věcí je na webu jako šafránu. Zrovna jsem jednu trochu snesitelnou knížku našel - zkuste nejdřív prolistovat obrázky. Koukal jsem taky na RFC-1180, ale řekl bych pro začátečníka dost tuhé čtení.

1048

Sítě / Re:Implementácia a náročnosť SW bridge

« kdy: 17. 09. 2018, 10:51:20 »

Zkusmo jsem zagooglil ohledně Zero Copy Networking - ale tenhle termit je zjevně vyhrazen pro jednu oblast ve vyšších vrstvách, konkrétně pro kopírování mezi kernel space a user space, tzn. "baví se můj user space prográmek po síti a chtěl by rychle".

V našem případě se bavíme o soft-bridgi, což je v linuxu modul v kernelu, paket vůbec neopustí kernel. Čili dotaz zjevně zní: "kolikrát se sk_buff zkopíruje v RAMce 'zbytečně' mezi RX DMA a TX DMA?" Jasnou odpověď jsem nenašel a nemám čas ji hledat, kdyžtak se zkuste dál už potápět sám. Níže uvedu pár odkazů, odkud by snad šlo začít.

Google našel blogpost obsahující pár výživných diagramů. Obrázek je za tisíc slov. Další dva doprovodné blogposty jsou vyčerpávající, čistě textové a popisují RX a TX řetězce - ideální čtení před usnutím, pokud máte problém usnout.

Některé podrobnosti osvětlují dvě hesla na Linux Foundation Wiki, ohledně networking control flow v kernelu (hledejte nadpisy ohledně "Layer 2" nebo text "bridge") a ohledně NAPI (hledejte text "DMA"). Pokud mi paměť slouží, NAPI infrastruktura byla před lety zavedena pro snížení frekvence interruptů od síťových rozhraní.

Pokud se týče vlastního kernelového modulu, který realizuje bridge, můžete se pokochat přímo aktuálními zdrojáky. Je to hrst jednotlivých souborů. Můžete začít třeba od toho, co modul dělá při natažení do kernelu (= kam se zavěšuje), nebo se podívejte na funkce, realizující forwardování paketů... Ono k Vašemu dotazu tam na první pohled není vidět mnoho, protože skutečné "maso" je skryto za hradbou interního kernel networking API.

V textech popisujících linuxové síťoviny se často vyskytuje klíčové slovo SKB nebo struct sk_buff. Jedná se zjevně o "kus paměti obsahující jednotlivý paket". Pokud je to jen trochu možné, předávají si funkce navzájem jenom pointer (odkaz), celý buffer se pokud možno nekopíruje. Otázkou tedy je, kdy a z jaké oblasti paměti se sk_buff naalokuje a za jakých okolností se uvolní, jaká je jeho "životnost" / životní cyklus.

Zatím co jsem si tak občas přečetl v dokumentaci PCI zařízení, RX DMA funguje velmi zjednodušeně tak, že v PCI zařízení nakonfigurujete bázovou adresu + délku okna v hostitelské paměti, a v tomto okně se Vám následně vynořují data = příchozí pakety, jeden za druhým. Modernější síťovky (nejméně např. Realtek 8168, tzn. žádný výkřik raketové technologie) umí běžet podle scatter-gather seznamu, takže DMA okno nemusí být ani spojité. Tak či onak, to cílové DMA okno nebo sg-list je cyklické, používá se na způsob kruhového bufferu (ring buffer). Klíčový je fakt, že síťovka se v RX směru sama rozhoduje, kdy se do DMA pustí, a teprve až když je přenos hotový, pošle "vám" (driveru síťovky v hostitelském kernelu) interrupt, že nějaká data přišla. To znamená, že "Vaše" hlavní starost je, data z ring bufferu pokud možno rychle někam odklidit, protože síťovka na Vás dlouho čekat nebude (pokud Vás v kroužku "doběhne", tak nevyzvednuté pakety přepíše, nebo se zastaví a další přišedší pakety začne zahazovat). Proč to říkám: protože pokud byste si usmyslel, že odchozí pakety skrz TX DMA budete posílat přímo z "příchozího DMA ring bufferu", abyste ušetřil kopírování, bude Vám vyprazdňování tohoto "bufferu s dvojím využitím" záviset na chování odchozích směrů do jednotlivých TX portů. Jednak by se ten ring buffer uvolňoval "napřeskáčku", druhak tam jaksi není garance, že se konkrétní paket vůbec někdy uvolní. Musel byste nad tím běžet nějaký softwarový "garbage collector" který bude pakety přímo v ring bufferu timeoutovat. Ten ring buffer by musel být veliký a jak by se pakety vyřizovaly "napřeskáčku" tak by "řídnul", jasně měl byste nad ním další spojové seznamy / fronty / indexy apod., ale přesto by Vás základní struktura "spojový seznam" mohla začít omezovat i co do výkonu apod.

Taky stojí za zamyšlení, že jak RX DMA ring buffer tak fronty pro TX DMA tvoří jádra kritických sekcí. Předávají si nad nimi veslo hardware síťovky s kernelem. A páchat nějaký složitý management nad kritickou sekcí s DMA... no nevím.

Přijde mi docela sjízdné, při vybírání paketů z RX DMA ring bufferu rovnou provést forwardovací rozhodnutí (pro nás funkce handle_bridge() zmíněná v literatuře) a na základě zvoleného TX portu provést jednu kopii v RAMce do odpovídající TX fronty. Pokud má forwardovací rozhodnutí deterministickou a dostatečně omezenou dobu provedení, nemusel by to být problém, a možná to přesně takto funguje.

Ještě mám pocit, že "kopie z paměti do paměti" by mohl akcelerovat Intel I/OAT DMA engine. Software jenom staví sg-list a o zbytek se nestará. Tahle fičurka se vyskytuje v "serverových" motherboardech (Xeon CPU) ale tuším jsem to jednou chtěl vyzkoušet a měl jsem dost smíšené výsledky. Na některém HW to nešlo zapnout, nebo to mělo v kernelu nějak omezenou použitelnost pro velmi málo oblastí/driverů apod. Ono i to heslo na wikipedii nad tím v závěru ohrnuje nos.

Ten link na PDF co poslal Honza je zajímavé čtení - ovšem týká se zjevně offloadu "těžšího kalibru", kdy za vhodných okolností je paket switchnut přímo externím switchem (který s linuxovým kernelem na nějaké úrovni symbioticky spolupracuje) tzn. na PCI DMA do+z hostitelské RAM vůbec nemusí dojít. Je zajímavé vědět, že taková jemně vrstvená infrastruktura pro externí offload v kernelu existuje, nicméně bych řekl, že takto postavený hardware je zajímavý hybrid: switch ASIC zjevně s PCI apod. rozhraním k hostitelskému CPU. Toto nevídám moc často. Mnohem běžněji vídám schéma, kdy soběstačná switchovací matice má jeden MAC port vůči hostitelskému management CPU = vlastně VLAN trunk v podobě [S|R|G]MII rozhraní včetně MDIO kanálu. V tom případě se nejedná ani tak o nějaký chytristický offload, jako spíš o externí switchovací matici, kterou standardní Linux na mngt CPU víceméně na dálku konfiguruje :-)

1049

Hardware / Re:Server do racku pro malý podnik

« kdy: 14. 09. 2018, 17:41:35 »

Jj, lokalni ajtik je lokalni nestesti.

Já bych to nepaušalizoval. U nás se zase říkalo "odborník je člověk, který přijel z jiného města". Lokální ajtík nemusí jezdit daleko, není otrávený že bude daleko šoférovat místo aby makal na problémech, ostatně to cestovné a čas na cestě pocítí také zákazníkova peněženka.

Poznal jsem lokální ajtíky různého kalibru - jak co do ega tak co do faktických schopností. Taky znám skupiny různě specializovaných lokálních ajtíků, kteří si navzájem dohazují kšefty. Lokální ajtík s přehledem v širším oboru a s kontakty na specialisty je pro koncového zákazníka možná užitečnější, než úzký specialista na vyprošťování konkrétního OS z vadných stavů.

1050

Hardware / Re:Server do racku pro malý podnik

« kdy: 13. 09. 2018, 16:21:06 »

Několikrát v diskuzi zazněl "odkaz" na specializovanou firmu, která mi poradí. Pokud by se toho někdo rád chopil, nechte mi na sebe prosím telefon případně budu rád za referenci na konzultační firmu s cenovou politikou vhodnou pro malé a střední podniky 

Různě po vlastech českých je spousta menších ajtíků na volné noze. Zeměpisně by to mělo být kde?