1
Sítě / Re:WireGuard pro domácí síť
« Poslední příspěvek od Pentheus kdy Dnes v 05:13:58 »michaelscz // přesně takhle to používám teď a problém mám s TV co zmiňuje k3dAR.
Poslední příspěvky
2
Sítě / Re:SMB client - multichannel support
« Poslední příspěvek od Michal Šmucr kdy Dnes v 02:10:50 »Tak ještě další věci.
Teď jsem si všiml, že v předchozím příspěvku jsem psal o tom povolení sysrq a cifsFYI přes sysfs.. To jsem omylem zkopíroval z historie terminálu, kde to bylo pro ukecanější debug přes dmesg, což by to info o spojeních v DebugData nemělo být třeba, pardon.
Dělal ještě test s víc jádry, resp cifs moduly.
U 5.15 a CIFS modulem 2.33 (Oracle UEK) to chodí přes jednu síťovku jak pro čtení, tak i zápis.
To, co jsem psal předtím, že zápis využije obě síťovky, fungovalo s kernelem 5.11 a CIFS modulem 2.50 (jak Oracle UEK Next, tak OpenSUSE Tubmleweed).
Teď jsem si všiml, že v předchozím příspěvku jsem psal o tom povolení sysrq a cifsFYI přes sysfs.. To jsem omylem zkopíroval z historie terminálu, kde to bylo pro ukecanější debug přes dmesg, což by to info o spojeních v DebugData nemělo být třeba, pardon.
Dělal ještě test s víc jádry, resp cifs moduly.
U 5.15 a CIFS modulem 2.33 (Oracle UEK) to chodí přes jednu síťovku jak pro čtení, tak i zápis.
To, co jsem psal předtím, že zápis využije obě síťovky, fungovalo s kernelem 5.11 a CIFS modulem 2.50 (jak Oracle UEK Next, tak OpenSUSE Tubmleweed).
3
Studium a uplatnění / Re:Kniha o C či C++
« Poslední příspěvek od František Ryšánek kdy Dnes v 00:29:43 »Knihy mého mládí jsou dnes do jisté míry zastaralé. Mám na ně ale hezké vzpomínky :-)
Třeba Beginning Linux Programming. Nakousne spoustu témat, ale tak akorát, aby se člověk zakousl a dál už študoval po svém / jinde. Třeba kapitola o libpthread (vláknové synchronizaci) je ve skutečnosti velice "nekompletní" - tehdy mi dost pomohl článek na Linuxových novinách (linux.cz) který dnes už nenajdu ani skrz wayback machine... škoda. Ta kniha má kapitoly o všem možném, doporučuji.
Další byla Thinking in C++ od Bruce Eckela. Bejvala zadarmo na mindview.com, dneska se válí kopie různě po webu. Volume 1 základy, Volume 2 "pokročilá" témata. Volume 2 jsem nedočetl - přišlo mi, že jsem u konce s dechem buď já, nebo možná autor :-) Hlavně to co byla před 25 lety pokročilá témata, to je dnes buď dětská hra, nebo bizardní slepá vývojová větev. Navíc mi ve zpětném ohledu připadá, že ta kniha byla sice čtivá, ale ne úplně systematická... A některá tehdejší dogmata se rozplynula jak pára nad hrncem apod. Některé věci se změnily, hlavně do standardní knihovny přibývají užitečné objekty, které si dřív člověk musel obstarat po svém. V dnešní době dost užitečný zdroj aktuálních informací je cppreference.com (online referenční příručka standardního C++, prakticky každé heslo končí examplem).
Ohledně posixových vláken a synchronizačních primitiv mám pocit, že se nedávno dostala prakticky nastojato do standardu C++, akorát už se jim neříká libpthread :-) Je to maličko komické ve světě Windows, kde komunikace mezi vlákny vypadá v rámci WinAPI nativně dost jinak.
A nakonec, čtivé bylo už evangelium podle Briana a Dennise: The C Programming Language (Kernighan and Ritchie). I tady se za těch cca 40 let tu a tam něco změnilo, ale ne natolik, aby starému textu nebylo rozumět :-)
Třeba Beginning Linux Programming. Nakousne spoustu témat, ale tak akorát, aby se člověk zakousl a dál už študoval po svém / jinde. Třeba kapitola o libpthread (vláknové synchronizaci) je ve skutečnosti velice "nekompletní" - tehdy mi dost pomohl článek na Linuxových novinách (linux.cz) který dnes už nenajdu ani skrz wayback machine... škoda. Ta kniha má kapitoly o všem možném, doporučuji.
Další byla Thinking in C++ od Bruce Eckela. Bejvala zadarmo na mindview.com, dneska se válí kopie různě po webu. Volume 1 základy, Volume 2 "pokročilá" témata. Volume 2 jsem nedočetl - přišlo mi, že jsem u konce s dechem buď já, nebo možná autor :-) Hlavně to co byla před 25 lety pokročilá témata, to je dnes buď dětská hra, nebo bizardní slepá vývojová větev. Navíc mi ve zpětném ohledu připadá, že ta kniha byla sice čtivá, ale ne úplně systematická... A některá tehdejší dogmata se rozplynula jak pára nad hrncem apod. Některé věci se změnily, hlavně do standardní knihovny přibývají užitečné objekty, které si dřív člověk musel obstarat po svém. V dnešní době dost užitečný zdroj aktuálních informací je cppreference.com (online referenční příručka standardního C++, prakticky každé heslo končí examplem).
Ohledně posixových vláken a synchronizačních primitiv mám pocit, že se nedávno dostala prakticky nastojato do standardu C++, akorát už se jim neříká libpthread :-) Je to maličko komické ve světě Windows, kde komunikace mezi vlákny vypadá v rámci WinAPI nativně dost jinak.
A nakonec, čtivé bylo už evangelium podle Briana a Dennise: The C Programming Language (Kernighan and Ritchie). I tady se za těch cca 40 let tu a tam něco změnilo, ale ne natolik, aby starému textu nebylo rozumět :-)
4
Hardware / Re:Zvuková karta pro Linux
« Poslední příspěvek od Marvin kdy Dnes v 00:27:26 »Převodník USB->TOSLINK (optický) od chiňana stojí pár $$$, některé umí i 24bit/192kHz.
S/PDIF výstup na RCA (koax) by měl mít oddělovací pulsní transformátorek, ale často bývá ušetřen a zemní smyčka zůstává.
Jako USB zařízení to musí mít ve frontě vzorky na milisekundy, aby to stále mělo co vysílat, nějakou latenci to přidává.
S/PDIF výstup na RCA (koax) by měl mít oddělovací pulsní transformátorek, ale často bývá ušetřen a zemní smyčka zůstává.
Jako USB zařízení to musí mít ve frontě vzorky na milisekundy, aby to stále mělo co vysílat, nějakou latenci to přidává.
5
Sítě / Re:SMB client - multichannel support
« Poslední příspěvek od Michal Šmucr kdy 21. 11. 2024, 23:53:40 »V poslední době jsem neměl moc potřebu tohle řešit, protože jsem používal buď rychlejší rozhraní nebo bonding (a víc klientů), ale je to zajímavé.
Zkusil jsem si to nasimulovat a musím říct, že se to chová dost specificky.
Pokus jsem dělal jen teď na QEMU/KVM virtuálu, kde jsem pak zalimitoval rychlost dvou síťovek na fyzický počítač (který byl zároveň CIFS klientem) na cca 1Gbit.
SMB multichannel připojení se povedlo.
Pro jistotu jsem to ověřil přes
Při čtení ze serveru to pak jelo pokaždé pouze přes adresu a síťovku, kterou jsem použil při připojování CIFS sdílené složky (tedy v mém případě první).
Ať jsem nastavoval, co chtěl, měnil způsoby čtení (iodepth, vlákna..), zkoušel různé nastavení SAMBY na serveru atp.
Monitoroval jsem na serveru i device statistiku přes sar (ze sysstatu) a data šla vždy jen přes jednu síťovku.
Ano podle toho by se zdálo, že to opravdu nefunguje (minimálně na agregaci rychlosti, failover jsem nezkoušel)
Nicméně pak jsem testoval zápis.
Pokud to bylo jednovláknový zápis s iodepth=1 (nebo třeba jednoduchý zápis z urandom přes dd), tak se to chovalo úplně stejně jako čtení - vše přes první síť.
Ale když jsem zvedl iodepth třeba na 4, nebo na server zapisoval víc souborů naráz, tak to vysaturovalo obě linky na max.
I při kopírování souboru v Nautilu (GNOME) na server to šlo v pohodě až na 220MB/s - kopírování tady evidentně také naplní delší frontu IO operací a ty pak jedou přes obě spojení/adresy.
Takže v tomhle testovacím prostředí to vypadá, že multichannel smysl má i z Linuxového CIFS klienta, ale jen pro zápis.
Možná by na to čtení teoreticky mohlo mít vliv i to, že mám s těmi virtuály specifickou topologii sítě s bridgem a pokud bych to opakoval třeba na dvou fyz. počítačích, kdy by měl každý dvě fyz. síťovky, tak by se to mohlo chovat odlišně.. Ale moc bych na to nesázel. Plus jsem dělal teď jen rychlý test, nehledal jsem nikde ve fórech, mailing listech atp.
Zkusil jsem si to nasimulovat a musím říct, že se to chová dost specificky.
Pokus jsem dělal jen teď na QEMU/KVM virtuálu, kde jsem pak zalimitoval rychlost dvou síťovek na fyzický počítač (který byl zároveň CIFS klientem) na cca 1Gbit.
SMB multichannel připojení se povedlo.
Pro jistotu jsem to ověřil přes
echo 1 >/proc/sys/kernel/sysrq
echo 1 >/proc/fs/cifs/cifsFYI
cat /proc/fs/cifs/DebugData
...kde pak bylo následující:
Server interfaces: 2 Last updated: 570 seconds ago
1) Speed: Unknown
Capabilities: None
IPv4: 192.168.202.240
Weight (cur,total): (1,1)
Allocated channels: 1
[CONNECTED]
2) Speed: Unknown
Capabilities: None
IPv4: 192.168.202.134
Weight (cur,total): (1,1)
Allocated channels: 1
[CONNECTED]
Při čtení ze serveru to pak jelo pokaždé pouze přes adresu a síťovku, kterou jsem použil při připojování CIFS sdílené složky (tedy v mém případě první).
Ať jsem nastavoval, co chtěl, měnil způsoby čtení (iodepth, vlákna..), zkoušel různé nastavení SAMBY na serveru atp.
Monitoroval jsem na serveru i device statistiku přes sar (ze sysstatu) a data šla vždy jen přes jednu síťovku.
Ano podle toho by se zdálo, že to opravdu nefunguje (minimálně na agregaci rychlosti, failover jsem nezkoušel)
Nicméně pak jsem testoval zápis.
Pokud to bylo jednovláknový zápis s iodepth=1 (nebo třeba jednoduchý zápis z urandom přes dd), tak se to chovalo úplně stejně jako čtení - vše přes první síť.
Ale když jsem zvedl iodepth třeba na 4, nebo na server zapisoval víc souborů naráz, tak to vysaturovalo obě linky na max.
I při kopírování souboru v Nautilu (GNOME) na server to šlo v pohodě až na 220MB/s - kopírování tady evidentně také naplní delší frontu IO operací a ty pak jedou přes obě spojení/adresy.
Takže v tomhle testovacím prostředí to vypadá, že multichannel smysl má i z Linuxového CIFS klienta, ale jen pro zápis.
Možná by na to čtení teoreticky mohlo mít vliv i to, že mám s těmi virtuály specifickou topologii sítě s bridgem a pokud bych to opakoval třeba na dvou fyz. počítačích, kdy by měl každý dvě fyz. síťovky, tak by se to mohlo chovat odlišně.. Ale moc bych na to nesázel. Plus jsem dělal teď jen rychlý test, nehledal jsem nikde ve fórech, mailing listech atp.
6
Hardware / Re:Zvuková karta pro Linux
« Poslední příspěvek od František Ryšánek kdy 21. 11. 2024, 23:28:13 »Pokračuji v debatě už notně off topic a trochu se za to stydím:
Pochybuju :-)
Mimochodem by se pak na motherboardu musela nějak "izolovaně překračovat" analogová vs. digitální zem, mezi kterými by se hemžilo všechno možné od DC po pár MHz (v desítkách milivoltů, pokud ne víc).
A stejně by to nebylo dokonalé z hlediska odrušení té "samostatně vedené analogové země", protože by byla částečně v souběhu s tou pracovní zemí silovou, takže by se tam ledacos indukovalo skrz magnetické pole...
Ani řešení pomocí symetrického analogového vstupu neztlumí rušení úplně do nuly, protože CMRR je konečné číslo. Jasně, může to pomoct docela dost, zejm. pokud to rušení nejde moc vysoko nad akustické pásmo (aby to vstup "stíhal odčítat", aby mu na to stačila šířka pásma / rychlost přeběhu). Na 50Hz brum to stačí s velkým přehledem.
Tímto nechci tvrdit, že jsme ve sporu :-) Sám jste zmínil galvanické oddělení, což je i moje oblíbená metoda řešení zemních smyček.
Díky za dovzdělání, tohle mi unikalo :-) Jestli správně chápu, granularita 125us je vlastnost highspeed fyzické vrstvy? Oproti fullspeed, kde je natvrdo 1 ms. A bInterval je celočíselný násobek tohoto vrozeného kvanta.
Jasně: 1) Axagon chytřejší dražší brácha, 2) Axagon hloupější levnější brácha.
Já mám toho dražšího, a moje hodnocení je pohříchu subjektivní. Měřit tomu zkreslení a šum jsem nezkoušel, mj. protože nemám čím (leda smyčkou).
Zkusím přiložit .TXT dump lsusb -v. Říká, že výrobcem čipu je VIA, a že fyzická vrstva je USB 1.1. Ona je to možná přesněji "USB 2.0 na full-speed rychlosti" :-) což je prakticky totéž. V tom případě pro mě platí ta 1 ms.
Když jsem zkoušel googlit USB PID 0x3417, našel jsem kdesi zmínku, že dotyčný čip je VT1620A. Parametrově by to vcelku odpovídalo. A tenhle šváb je skutečně jenom USB full-speed.
Google mi našel taky (pěkně uleželý) paperlaunch čipu VIA Envy VT1730, který byl údajně jako jeden z prvních high-speed. Ale nedaří se mi, nalézt s ním nějaké produkty.
Heh taky mám jednu čínskou destičku s TPA3116. Zkoušel jsem s ní budit takové sranda bedničky osazené Visaton BG-20-8, a jako zdroj signálu právě tenhle zmíněný USB dongle. Šumělo to relativně slyšitelně, třeba z podání vyššího konce pásma jsem taky nebyl úplně odvařenej... ale fakt je, že jsem nad tím mávnul rukou a třeba napájecí zdroje jsem nezkoumal. Po téhle Vaší recenzi se k tomu myslím ještě vrátím :-)
Do sluchátek ten USB dongle nešumí.
:-O
To nezní marně! Akorát... vytáhnout z počítače S/PDIF výstup znamená buď začít motherboardem (okolo 3kKč už se najdou s S/PDIF výstupem) nebo přidat soundblaster s tímhle výstupem, a co pak s tím dál: buď převést levným DAC donglem za pár šupů na analog (a dát si pozor na země a napájení), nebo koupit receiver okolo 10 kKč jenom abych měl zes nativně s tímhle vstupem...
Jinak - 50Hz železné trafo má velkou výhodu, že neprodukuje VF rušení.
Jakýkoli spínaný měnič/adaptér, klidně ve třídě II a "medical grade", má slabý průsak (směs 50 Hz a VF). Pár desítek až stovek mikroampérů. Pokud by byl zájem o medical-grade napájecí adaptér, a dalo by se to zpřevodovat konektorově (a skladbou výstupů), tak tyto jsou k nalezení v TME, k dispozici je filtr "použití: pro lékařské aplikace". Zde k tématu jsou relevantní nejspíš kategorie stolní napájecí zdroje (formát "notebooková cihlička") nebo adaptéry do zásuvky.
...
Jenom mi vrtá hlavou, proč výrobci desek nepřipojí zem zvukovky/USB portu odděleně přes jeden/více GND pinů/kabelů ATX konektoru, aby se to spojilo až v tom proletovaném hnízdě v PSU, kam vede i PE vodič. Ale možná to někteří tak dělají, netuším.
Pochybuju :-)
Mimochodem by se pak na motherboardu musela nějak "izolovaně překračovat" analogová vs. digitální zem, mezi kterými by se hemžilo všechno možné od DC po pár MHz (v desítkách milivoltů, pokud ne víc).
A stejně by to nebylo dokonalé z hlediska odrušení té "samostatně vedené analogové země", protože by byla částečně v souběhu s tou pracovní zemí silovou, takže by se tam ledacos indukovalo skrz magnetické pole...
Ani řešení pomocí symetrického analogového vstupu neztlumí rušení úplně do nuly, protože CMRR je konečné číslo. Jasně, může to pomoct docela dost, zejm. pokud to rušení nejde moc vysoko nad akustické pásmo (aby to vstup "stíhal odčítat", aby mu na to stačila šířka pásma / rychlost přeběhu). Na 50Hz brum to stačí s velkým přehledem.
Tímto nechci tvrdit, že jsme ve sporu :-) Sám jste zmínil galvanické oddělení, což je i moje oblíbená metoda řešení zemních smyček.
Citace
CitacePravda je, že USB má i v "interruptovém" přenosovém režimu de facto periodický polling v taktu 1 ms, plus tam budou nějaké buffery (=latence) takže "ten můj USB dongle" v tomhle ohledu není dokonalý,
Tak dražší profi USB zvukovky používají highspeed bInterval i 125us, což je úplně v pohodě. Samozřejmě USB MIDI dongle pojede na lowspeed, tudíž min. 1ms již na připojení. Na druhou stranu i ta PCI zvukovka má nějakou latenci obsluhy přerušení...
Díky za dovzdělání, tohle mi unikalo :-) Jestli správně chápu, granularita 125us je vlastnost highspeed fyzické vrstvy? Oproti fullspeed, kde je natvrdo 1 ms. A bInterval je celočíselný násobek tohoto vrozeného kvanta.
Citace
CitaceCo se týče čistoty výstupu a šířky pásma k basům, stojím si za tím že ten konkrétní model generického USB donglu co jsem uvedl, se 24bit DAC/ADC, není vůbec marnej, i ve srovnání se svým hloupějším 16bitovým bráchou (vypadá stejně, jenom nemá v obj.kódu "HQ").
Máš prosím konkrétní link?
Jasně: 1) Axagon chytřejší dražší brácha, 2) Axagon hloupější levnější brácha.
Já mám toho dražšího, a moje hodnocení je pohříchu subjektivní. Měřit tomu zkreslení a šum jsem nezkoušel, mj. protože nemám čím (leda smyčkou).
Zkusím přiložit .TXT dump lsusb -v. Říká, že výrobcem čipu je VIA, a že fyzická vrstva je USB 1.1. Ona je to možná přesněji "USB 2.0 na full-speed rychlosti" :-) což je prakticky totéž. V tom případě pro mě platí ta 1 ms.
Když jsem zkoušel googlit USB PID 0x3417, našel jsem kdesi zmínku, že dotyčný čip je VT1620A. Parametrově by to vcelku odpovídalo. A tenhle šváb je skutečně jenom USB full-speed.
Google mi našel taky (pěkně uleželý) paperlaunch čipu VIA Envy VT1730, který byl údajně jako jeden z prvních high-speed. Ale nedaří se mi, nalézt s ním nějaké produkty.
Citace
CitacePokud tam bude na výstupu zes ve třídě D, tak bych moc neřešil, jestli je DAC 16b nebo 24b,
Jenom k těm D - dneska už se to hodně posunulo. Takové TPA335x 100+ W za 40USD včetně bedny má velice slušné parametry, i ty superlevné TPA3116 minikrabičky hrají velice slušně (mám jich doma několik).
Heh taky mám jednu čínskou destičku s TPA3116. Zkoušel jsem s ní budit takové sranda bedničky osazené Visaton BG-20-8, a jako zdroj signálu právě tenhle zmíněný USB dongle. Šumělo to relativně slyšitelně, třeba z podání vyššího konce pásma jsem taky nebyl úplně odvařenej... ale fakt je, že jsem nad tím mávnul rukou a třeba napájecí zdroje jsem nezkoumal. Po téhle Vaší recenzi se k tomu myslím ještě vrátím :-)
Do sluchátek ten USB dongle nešumí.
Citace
A moderní Dčka ve zkreslení při výkonu a celkové vychovanosti v zátěži už jasně nad lineáry vedou, viz např. https://www.audiosciencereview.com/forum/index.php?threads/purifi-eval2-eigentakt-mono-amplifier-kit.54938/
:-O
Citace
CitacePokud se týče výstupu do zesu, ještě bych zmínil, že existuje optický digitální propoj TOSLINK resp. S/PDIF. Je to sice spíš záležitost spotřební elektroniky než profi audia, ale zemní smyčku to přeruší. Nemám představu, jestli to třeba nepřidává nějakou latenci.
Latence bych se asi nebál, vysílač bude mít téměř nulovou, přijímač např. DIR9001 uvádí latenci 3 vzorky, tedy nic.
To nezní marně! Akorát... vytáhnout z počítače S/PDIF výstup znamená buď začít motherboardem (okolo 3kKč už se najdou s S/PDIF výstupem) nebo přidat soundblaster s tímhle výstupem, a co pak s tím dál: buď převést levným DAC donglem za pár šupů na analog (a dát si pozor na země a napájení), nebo koupit receiver okolo 10 kKč jenom abych měl zes nativně s tímhle vstupem...
Jinak - 50Hz železné trafo má velkou výhodu, že neprodukuje VF rušení.
Jakýkoli spínaný měnič/adaptér, klidně ve třídě II a "medical grade", má slabý průsak (směs 50 Hz a VF). Pár desítek až stovek mikroampérů. Pokud by byl zájem o medical-grade napájecí adaptér, a dalo by se to zpřevodovat konektorově (a skladbou výstupů), tak tyto jsou k nalezení v TME, k dispozici je filtr "použití: pro lékařské aplikace". Zde k tématu jsou relevantní nejspíš kategorie stolní napájecí zdroje (formát "notebooková cihlička") nebo adaptéry do zásuvky.
7
Sítě / Re:WireGuard pro domácí síť
« Poslední příspěvek od k3dAR kdy 21. 11. 2024, 23:06:57 »[...] a na všech klientech (mobil, notebook apod) mám konfiguraci, kde je důležité:
[Peer]
AllowedIPs = 0.0.0.0/0
[...]
a jak to nastavi na te TV? (tedy pokud to neni TV s Androidem) :-)
8
Sítě / Re:SMB client - multichannel support
« Poslední příspěvek od MiroslavPragl kdy 21. 11. 2024, 21:33:54 »Dik.
Jak uz jsem psal, kdyby neumel vubec, byl bych s tim OK. Ale zere me, ze umi udelat 2 klientske sockety proti 2 serverovym IP/if, jen ne z ruznych zdrojovych IP/if.
Je to skoda, smb je solidni protokol/filesystem. Mozna nejlepsi.
MP
P.S. Proc to delam: dostal jsem vyrazenou SAS paskovou mechaniku, jsou brzo vecery, hraju si:
- Pro Win jsem nenasel solidne optimalizovany tar (da na 2gigabitove siti ledva 1 gigabit, evidentne mu nesedi \\.\tape0).
- V linuxu je zase brzdou sit (viz vyse), tar jsem musel naspeedovat pres mbuffer, jinak s malymi soubory je to tragedie na kvadrat.
- Veeam community jede pres \\.\tape0 jak z praku,kesuje si sam, pokud mechanika komprimuje tak mu nestaci ani ty 2 Gb, ale je to moloch s proprietarnim formatem a principialne neumi o moc vic nez ten dedek tar. Nechci nechci. Nechci nechci.
Jak uz jsem psal, kdyby neumel vubec, byl bych s tim OK. Ale zere me, ze umi udelat 2 klientske sockety proti 2 serverovym IP/if, jen ne z ruznych zdrojovych IP/if.
Je to skoda, smb je solidni protokol/filesystem. Mozna nejlepsi.
MP
P.S. Proc to delam: dostal jsem vyrazenou SAS paskovou mechaniku, jsou brzo vecery, hraju si:
- Pro Win jsem nenasel solidne optimalizovany tar (da na 2gigabitove siti ledva 1 gigabit, evidentne mu nesedi \\.\tape0).
- V linuxu je zase brzdou sit (viz vyse), tar jsem musel naspeedovat pres mbuffer, jinak s malymi soubory je to tragedie na kvadrat.
- Veeam community jede pres \\.\tape0 jak z praku,kesuje si sam, pokud mechanika komprimuje tak mu nestaci ani ty 2 Gb, ale je to moloch s proprietarnim formatem a principialne neumi o moc vic nez ten dedek tar. Nechci nechci. Nechci nechci.
9
Sítě / Re:WireGuard pro domácí síť
« Poslední příspěvek od michaelscz kdy 21. 11. 2024, 20:51:39 »Tak jinak, chci v domácí síti mýt šifrované spojení mezi routerem a PC,TV atd jak toho docílit ?
Jde to, mám to tak. Mám doma na Mikrotiku jen jeden WG interface (nevím, proč děláš další interface) a na všech klientech (mobil, notebook apod) mám konfiguraci, kde je důležité:
[Peer]
AllowedIPs = 0.0.0.0/0
tím jde primárně všechno přes ten tunel, i když jsem na wifi ve stejné síti. Na mobilu tak mám WG zapnutý pořád a neřeším to a defacto jedu pořád přes WG tunel i když jsem mimo wifi a jedu přes LTE.
10
Sítě / Re:SMB client - multichannel support
« Poslední příspěvek od ja. kdy 21. 11. 2024, 20:36:39 »Ako tu už bolo spomenuté, libsmbclient (súčasť samby) nepodporuje multichannel. Multichannel podporuje samba iba na strane serveru.
Modul z jadra možno áno, ale to nie je to, čo Ubuntu (gvfs, kio) používajú.
Multichannel samozrejme môžu podporovať aj klienti a to je presne to, čo robí napríklad Windows alebo MacOS. Viacero sieťových rozhraní je pritom len jedna alternatíva, ďalšou je použitie sieťových rozhraní s asymetrickou kapacitou (napr. klient má 2.5 GbE a server niekoľko 1 GbE rozhraní; keď klient vytvorí 2-3 spojenia multichannel, pôjde mu to rýchlejšie aj s jedným rozhraním), alebo ďalšou alternatívou je použitie iných transportov ako tcp (RoCE/RDMA, ktoré sú z pohľadu protokolu ďalší kanál). Ďalšia možnosť je teaming/bonding, keď klient chce vyťažiť jeho kapacitu, tak nutne potrebuje viacero tcp spojení. Dokonca aj keď má zariadenie len jednu sieťovku, ktorej bandwidth je menší ako naproti na serveri, môže multichannel priniesť zrýchlenie, pretože RSS.
No ale presne toto je to, čo libsmbclient používaný v linuxových DE nevie. Niektoré, nebudem teraz ukazovať prstom, jeden dokonca robí kontraproduktívne veci, ako je rozsekanie trafficu na 64kB segmenty, čím spoľahlivo zabije možnosť mať viacero paralelných async requestov (ktoré libsmbclient vie).
Modul z jadra možno áno, ale to nie je to, čo Ubuntu (gvfs, kio) používajú.
Multichannel samozrejme môžu podporovať aj klienti a to je presne to, čo robí napríklad Windows alebo MacOS. Viacero sieťových rozhraní je pritom len jedna alternatíva, ďalšou je použitie sieťových rozhraní s asymetrickou kapacitou (napr. klient má 2.5 GbE a server niekoľko 1 GbE rozhraní; keď klient vytvorí 2-3 spojenia multichannel, pôjde mu to rýchlejšie aj s jedným rozhraním), alebo ďalšou alternatívou je použitie iných transportov ako tcp (RoCE/RDMA, ktoré sú z pohľadu protokolu ďalší kanál). Ďalšia možnosť je teaming/bonding, keď klient chce vyťažiť jeho kapacitu, tak nutne potrebuje viacero tcp spojení. Dokonca aj keď má zariadenie len jednu sieťovku, ktorej bandwidth je menší ako naproti na serveri, môže multichannel priniesť zrýchlenie, pretože RSS.
No ale presne toto je to, čo libsmbclient používaný v linuxových DE nevie. Niektoré, nebudem teraz ukazovať prstom, jeden dokonca robí kontraproduktívne veci, ako je rozsekanie trafficu na 64kB segmenty, čím spoľahlivo zabije možnosť mať viacero paralelných async requestov (ktoré libsmbclient vie).
