Poslední příspěvky

Stran: 1 2 3 [4] 5 6 ... 10
31
Sítě / Re:Funkční 10GbE řešení pro TrueNAS Scale
« Poslední příspěvek od František Ryšánek kdy Dnes v 08:13:36 »
Hele nepadla tady jedna zásadní věc: vidíte na počítadlech vadně přijatých paketů (err) na síťovkách číslo vyšší než 0 ?
Pokud ano, hledejte problém na fyzické vrstvě (transceivery, vlákna, kompatibilita transceiverů proti síťovkám).
Pokud je tam nula, tak máte fyzickou vrstvu nejspíš v pořádku.

Tady někdo popisuje podobný problém a udává velmi podobné hodnoty jako Vy - a pak si všiml, že má 10Gb síťovku linknutou na PCI-e jenom šířkou x1 :-)

lspci -s 03:00.0 -vv | grep LnkSta:
             LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)

Ve vašem případě by nejspíš lspci navíc přidalo kyselý dovětek "downgraded" = že se zařízení dohodlo pod svoje možnosti.
Číslo zařízení jsem zadal natvrdo, abych dostal hodnotu jenom pro své konkrétní zařízení. Jedná se vlastně o pozici na sběrnici, najdete ji ve výpisu lspci bez parametrů.

Testoval bych předně linux proti linuxu. Oddělíte tak windowsové špecifiká od skutečných HW problémů.

Pak mě napadá, zakázat procesoru hlubší C-states. V linuxu na AMD nejspíš processor.max_cstate=1 (nebo i =0, třeba jenom na chvilku). Jinak pro to bývá položka v BIOS SETUPu, ta platí i pro Linux (i pro Windows). Výsledek ukáže tuším turbostat z balíku linux-cpupower (Debian/Ubuntu). A možná bych neváhal vyzkoušet pcie_aspm=off.

Man iperf3 zmiňuje pár dalších zajímavých věcí.

Například, že -P (paralelní streamy) ve skutečnosti jede na jediném CPU jádře, protože iperf3 je jednovláknový :-( takže víc jader tím nevytížíte.

Dále bych zmínil -Z  (zero copy), což by mohlo trochu omezit režii.

Pak jsem si všiml -w/--window -- tady si nejsem jist, zda se uplatní také u UDP. Jinak na TCP by si iPerf měl správnou velikost okna ustálit sám...

Dále manuál zmiňuje možnost, nastavit afinitu k CPU jádru parametrem -A. Mohlo by se hodit, nechat běžet iPerf na jádře, které obsluhuje interrupty od síťovky - viz "cat /proc/interrupts" . Ačkoli je pravda, že hardware síťovek a ovladače se snaží provádět "interrupt amalgamation" (moderation) aby se stroj neudávil jenom obsluhou IRQ. Tohle se děje zhruba od gigabitu výš, na 10Gb hardwaru zcela určitě. Tuším se toho týká keyword NAPI, což je nějaký generický framework linuxového kernelu pro tyhle kejkle - využívají ho drivery síťovek, konkrétně drivery od Intelu ho tuším zmiňují při bootu v dmesg (osobně jsem to pozoroval u gigových síťovek, 10Gb mi tolik rukama neprochází). Jinak se historicky vyskytlo také API zvané netpoll, což je ale asi trochu jiné zvířátko, je třeba ho v aplikacích používat explicitně a iperf3 ho zjevně neumí. Kdoví, zda je to vůbec ještě aktuální - zda to někdy opustilo stádium out-of-tree patche.

Našel jsem takový lehce povrchní starší článek od RedHatu, jak ladili průchodnost (pakety za sekundu) zřejmě na téže síťovce, co máte Vy. Není tam moc zaklínadel v příkazovém řádku, ale jako rozcestník = seznam dalších tipů by to mohlo být použitelné.
32
Sítě / Re:Tunelování IP adresy pro firemní notebook
« Poslední příspěvek od Marek Staněk kdy Dnes v 08:12:26 »
Hele tohle ja teda naprosto nechapu ...

Mas nejakej nastroj, ten nastroj ti dala firma, ta firma chce abys ten nastroj nejak pouzival. Pokud se neda pouzivat k praci kterou chteji abys na tom delal, tak to jednoduse namelduj do ty firmy. Pokud to chces pouzivat nejak jinak nez pro firemni ucely, tak se nediv, az ti daji § hrube poruseni pracovnich povinosti.

Naprostej souhlas.
1) je to problém firemního IT oddělení, a oni jsou jediní kompetentní se tím zabývat
2) jakýkoli kutění s tím je porušením asi tak miliónu interních závazných směrnic a recept na §ZávPorPracKáz
3) i když to rozchodí, tak jakýkoli problém na poli kyberbezpečnosti padne na JEHO hlavu včetně odpovědnosti za náhradu škody v rozsahu dle Zákoníku Práce, tzn 4,5x průměr měsíčního platu s možností okamžitého vyhazovu a škraloupu u HR, o kterém se dozví každý další eventuální zaměstnavatel, který zvedne telefon a zavolá si o referenci
4) tím předem neznámý osobě dává do ruky kanón, kterým ho půjde kdykoli odstřelit a zbavit se ho, jakmile ho kdokoli začne mít nerad
33
/dev/null / Re:Šíření dat na velkou vzdálenost
« Poslední příspěvek od ktk kdy Dnes v 08:09:47 »
Hosi delate si srandu, ale mam doma letitou klavesnici s mysi, logitech to vyrabel, jsou bezdratovy, a kdyz jsem to kdysi kupoval (1 GHz duron byl tenkrat bezny domaci PC), v popisu stalo, ze to komunikuje ultrazvukem. Pravda, pres cely pokoj dosahnout, to je problem. Mam a pouzivam ji dodneska, psa to nijak neobtezuje. (Ale ten nejspis neslysi ultrazvuk, ten slysi jen zvuky co souvisi s jidlem :)
34
/dev/null / Re:Šíření dat na velkou vzdálenost
« Poslední příspěvek od Marek Staněk kdy Dnes v 07:57:46 »
Vždyť je už několik let prakticky ověřeno IPoAC.
https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

Určitě by to šlo ohnout i na krysy, kočky, psy, gazely, bizony, nebo třeba plejtváky myšoky.
Využívat na to ptáky jako čápa bílého se úplně nedoporučuje, protože latence je zhruba rok, funguje to jen mezi konkrétním místem v Evropě (vracejí se na svoje hnízdo) a hnízdišti v severní Africe, přičemž je třeba routovat podle pohlaví čápa (samci zimují v Maroku, samice v Etiopii) a často se stává, že v Africe nosiče uloví a sežerou.
35
Vývoj / Re:Jak začít s Node.js?
« Poslední příspěvek od rrrado1 kdy Dnes v 07:51:38 »
Lambdy má JavaScript odjakživa.
Myslel som arrow syntax
36
Sítě / Re:IoT předplacená SIM na rok pro ČR
« Poslední příspěvek od jfila kdy Dnes v 07:24:02 »
Kontrolní otázka, jaký je rozdíl mezi LTE a LTE-M? Je pro LTE-M potřeba jiný modem?
37
Sítě / Re:Funkční 10GbE řešení pro TrueNAS Scale
« Poslední příspěvek od Jan Fikar kdy Dnes v 07:16:22 »
iperf3 má nějaké problémy s Windows a neukazuje dobře
38
/dev/null / Re:sireni dat na velkou vzdalenost
« Poslední příspěvek od František Ryšánek kdy Dnes v 07:02:55 »
Taky by to mohlo šumět pseudonáhodnou preambuli = sekvenci bitů, kterou by znal jenom vysílač a přijímač. Potom pár datových bitů s přehnanou mírou forward error correction. Na přijímací straně korelační demodulátor. Pokud full duplex tak ještě odečítání lokálního echa. Akorát případné směrování zářiče plandajícího pod balónem by byl asi oříšek. Hihihi gyroskop hnaný vrtulí...
39
/dev/null / Re:sireni dat na velkou vzdalenost
« Poslední příspěvek od Zopper kdy Dnes v 07:00:26 »
Můžeš zkusit časovat výbuchy sopky, nebo dopady dostatečně velkých meteoritů. Nebo možná by šlo i modulovat zemětřesení. Ten seizmický signál pak budeš moct zachytit v podstatě kdekoliv na stejné planetě.

Jako alternativní možnost, ale pozor, už to asi mají patentováno Pratchettovci, je, že když umře dědičný monarcha, jeho potomek se stává monarchou okamžitě, i když o tom ještě neví. Nikde se nepíše o zpoždění kvůli šíření signálu/kauzality rychlostí světla. Z toho plyne, že kralony (též císařony, ty částice, které přenáší informaci o momentální hlavě státu) se musí pohybovat rychleji, než světlo, nejspíš okamžitě překonají jakoukoliv vzdálenost. Takže pokud potřebuješ FTL komunikaci na mezihvězdné vzdálenosti, bude zřejmě potřeba nějak opatrně mučit nějakého menšího krále, abys moduloval emisi kralonů, a jeho potomka mít zamknutého v jejich detektoru. To ale podle všeho bude jen jednosměrná komunikace, takže potřebuješ druhý takový pár, pokud tedy chceš obousměrnou komunikaci.
40
Sítě / Re:MikroTik a IPv6 a IPv4 u UPC
« Poslední příspěvek od Radek Zajíc kdy Dnes v 06:58:33 »
> 1) "oželet" zařízení které neumí IPv6.
pokud:
- na routeru nakonfigurujete DHCPv6 klienta a prefix delegation (navod viz treba tady, interface samozrejme bude jiny - https://www.appleking.cz/blog/jak-nastavit-mikrotik-router-pro-terminator-od-cetin)
- na LAN nastavite prefix ziskany tim DHCPv6 klientem (tez viz navod)
- firewall na routeru bude propoustet IPv6 provoz

pak zarizeni v LAN budou mit IPv6 konektivitu. Ale porad se dostanou jen do IPv6 internetu.
Zaroven musite zarizenim v LAN poskytnout IPv6 DNS server, nejlepsi kompatibilitu ma dnes asi pouziti RDNSS - nastaveni viz tady: https://help.mikrotik.com/docs/spaces/ROS/pages/40992815/IPv6+Neighbor+Discovery

Pokud budete chtit v IPv6-LAN klientum zaridit i pristup do IPv4 sveta, musite pouzit nejakou verejne dostupnou nat64 gateway a dns64 server ukazujici na tuto gateway. Ja znam jen zminovany nat64.net. Tedy pokud jako RDNSS (DNS server sireny v IPv6 router advertisementech) nastavite nektery z DNS serveru vypsanych na nat64.net, klienti v LAN budou diky teto sluzbe mit pristup do IPv4 internetu.

Stran: 1 2 3 [4] 5 6 ... 10