Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 ... 12 13 [14] 15 16 ... 84
196
Hardware / Re:Může uspání jader CPU způsobit problém?
« kdy: 07. 02. 2023, 09:15:50 »
Zkuste utrousit víc informací :-)

Co je zač ten motherboard, jak stará platforma, nebyl by novější BIOS? Zažil jsem na starším notebooku, že se občas nedokázal probudit ze suspendu, a určitého pozitivního vlivu bylo možno dosáhnout hraním s acpi_osi.

Je to funglovka, nebo má něco naběháno? = snažíte se to rozchodit čerstvé, nebo Vám to pár let fungovalo a najednou to zlobí? Pokud B je správně, tak na software se nesahalo, nebo proběhl nějaký upgrade/update distra?

Z čeho to startuje? Nemůže být problém v tom, že se neprobudí disk?

197
Sítě / Re:Ethernet přes koaxiální kabel
« kdy: 04. 02. 2023, 19:50:26 »
Tady jsem našel nějakej čipset podle normy ITU G.hn. Koukám, že to jede svého druhu TDMA. Resp. je tam i zmínka, že to umí autodetekovat podmínky na lince a případně zvolit FDMA... není moc podrobné to povídání :-)

198
Sítě / Re:Ethernet přes koaxiální kabel
« kdy: 04. 02. 2023, 17:40:45 »
Jak by vůbec mohl fungovat duplex po drátě, případně bez polarizací?

Duplex vlastně potřebuje dva komunikační kanály. Což jsou třeba dvě nosné frekvence (bez překryvu pásma) - tady je ale v reálném světě problém, pokud potřebuju na nějakém frekvenčním kanálu vysílat do vzduchu (velkým výkonem) a zároveň na sousedním kanálu přijímat ze vzduchu (jakýsi šepot z dálky) - první stupně rádia nebývají příliš selektivní a zpracovatelná úroveň signálu není neomezená, prakticky by se za těchto okolností vstup přijímače snadno zahltil vysílaným sousedním kanálem.

Plný duplex na metalickém vedení se dá zařídit i sdíleným kanálem (klidně širokopásmově), tzn. po jediném koaxu či signálovém páru: na principu odečítání lokálního echa (near end echo cancelation). Vysílaný signál známe, tak si ho ze simultánního příjmu digitálně odečteme. Nicméně to echo projde analogovou doménou, takže je potřeba namodelovat taky vlastnosti té analogové "lokální smyčky". Aby to odečtení fungovalo, k tomu je potřeba dostatečně rychlý ADC s dostatečným rozlišením - aby se bez ořezu vešel vysílaný signál (který chceme odečíst) a zároveň aby se přijímaný signál odnaproti, utlumený vedením, svou modulační hloubkou vespod nepotkával s úrovní kvantizačního šumu ADC. Tyhle technologie jsou už hodně staré, plný duplex po dvoudrátu provozovaly už asynchronní telefonní modemy V.všeckomožné. Ale vemte si tehdejší baud rate a modulační schémata (QPSK). Uplynulo hodně vody pod mostem, a dneska totéž dělá VDSL2 a 1/10Gb Ethernet. Stále se to ale dělá, pokud vím, jenom po drátech, nikoli vzduchem. Asi protože útlumový budget pro použitelnou echo cancelation není velký.

Podle mého ty dedicated modemy pro přenos internetu po televizním koaxu jedou full duplex na bázi echo cancelation. Nebo možná frequency-division duplex - nevím.

Citace
Nebo ti jde o to, aby antikolize byla deterministická?

Pokud už half duplex, tak je nejlepší se kolizím vyhnout. Nejsnáz tak, že se nějakým způsobem předem přiděluje vysílací čas - třeba pravidelný timeslot.
Správně zmiňoval @neregistrovany proprietární režimy některých wifin, které jedou TDMA. Např. Mikrotik NV2.

Bohužel ani u TDMA není režie nulová a latence jsou sice deterministické, ale vyšší než u plného duplexu. Protože příchozí paket musí čekat na přidělené vysílací okno.

Každopádně pokud mám na vybranou plný duplex nebo TDMA, beru plný duplex :-)

Citace
Já tomu bohužel nerozumím detailně, ale myslel jsem, že existuje režim, kdy klienty aktivně oslovuje APčko, a když máš klienta jenom jednoho, tak se nemá co pokazit.

Pokud správně chápu CSMA-CA u klasického 802.11 tak to sice není taková hrůza jako CSMA-CD nebo echt Aloha, kde se prostě paket odvysílá celý a až potom se zjišťuje, jestli to prošlo. V režimu CSMA-CA stanice pošle napřed krátký "rezervační" rámec, a když nenastane kolize, odvysílá payload. (A každý paket zvlášť se ACKuje.) Ale pořád je kolizní okno a příležitost v 802.11 CSMA-CA řádově větší, než u TDMA, kde je kolizní jenom kratičký interval, vyhrazený pro tu a tam přihlašování nových stanic.

Striktní řízení, která stanice bude kdy vysílat, je jenom v režimu TDMA, což není 802.11 standard.

802.11 na fyzické vrstvě jede "omezeně kolizní" CSMA-CA, kde jsou si všechny stanice rovny (včetně AP).
O patro výš nad tím je nějaké šifrování (WPA2), ve kterém skutečně se jednotliví klienti "asociují" k AP a pouze s AP si smějí vyměňovat provoz. Podle mého Ad-Hoc režim "každej s každým" fungoval jenom v nešifrovaném WiFi, nebo snad ještě s WEPem (sdílený klíč). Ale jak říkám: to se bavíme o vztahologii vyšších krypto-vrstev, která s řízením přístupu k médiu na fyzické vrstvě nemá nic moc společného.

199
Sítě / Re:Ethernet přes koaxiální kabel
« kdy: 03. 02. 2023, 15:16:31 »
To mě na hrátkách s wifi odrazuje asi nejvíc: že je to pořád half duplex.

k cemu je vam full duplex? Jenom proto ze to je cool?

Přesně tak, half-duplex pro mě není dost sexy :-)

Jsem lenoch a frikulín. Než přemejšlet, jak přesně vypadá aloha v podání 802.11 CSMA-CA, mám radši jistotu, že co se vejde do fronty, to projde skrz.

Jirous umí polarizační duplex.

To umí, ale jenom ve vzduchu. Ne po drátě.
Jestli správně chápu, tak i vzduchem to musí jet po dvou různých frekvenčních kanálech. Protože -50 dB izolace mezi lokálními porty vypadá zajímavě, ale když vysílač pošle +20 dBmW a přijímaná úroveň je někde kolem -60 dBmW, tak bych řekl, že po jednom kanálu by to nešlo.

200
Sítě / Re:Ethernet přes koaxiální kabel
« kdy: 03. 02. 2023, 11:55:20 »
To mě na hrátkách s wifi odrazuje asi nejvíc: že je to pořád half duplex.

201
Sítě / Re:Ethernet přes koaxiální kabel
« kdy: 02. 02. 2023, 17:44:04 »
hezký elaborát, ale už v první větě jste ho (tou bezp. třídou) vymezil na množinu zařízení blízkou nule. EoC krabky co jsem viděl mívají power input via barrel jack. Vestavěný zdroj mají možná multiAVLN master jednotky (což není tento případ), ale i tak na straně Slave bude zas jen barrel jack (Slejva s vestavěným strojem jsem ještě neviděl).

Navíc on má ten coax v rámci jedné budovy, kde rozdíl potenciálů nelze předpokládat.

Dutý napájecí konektor sám o sobě mnoho neříká. Důležitá je informace, zda jeho mínus (obvykle vnější "stínění"/trubička) je připojený na kolík v zásuvce 230V. Tzn. jakou vidlici má zdroj do zásuvky, a pokud včetně PE, tak zda je toto v cihličce zdroje propojeno na mínus výstupu.

Jasně že plastová APčka mají zdroje se dvěma kolíky (opuchlá zástrčka / wall wart).
Ale třeba u notebooků je to fifty-fifty.
A kdyby se jednalo o nějaký ITX počítač, tak čert ví.

Rozdíl potenciálů v rámci budovy být může. Záleží v jak dobrém stavu jsou země po baráku, jaký je odběr v různých větvích relativně k průřezu vedení (hlavně zemí) a kde přesně se rozděluje PE od N. Ale souhlas - skandál není příliš pravděpodobný.

A že notoricky tapetuju, o tom žádná.

202
Server / Re:Proxmox - IOMMU/VT-d přemapování IRQ
« kdy: 02. 02. 2023, 17:32:57 »
Na zacatku vypisu (cca 2. nebo 3.radek) dmesg je Command line.
Vidite v ni ten parametr?
Zmenilo se rozdeleni na IOMMU grupy alespon trosku?

Viz též
Kód: [Vybrat]
cat /proc/cmdline

203
Sítě / Re:Ethernet přes koaxiální kabel
« kdy: 02. 02. 2023, 12:17:28 »
Bál bych se ale toho, co udělá galvanické spojení zemí obou stran - dovedu si představit, že budou-li od sebe počítače vzdálenější, po stínění kabelu poteče nezanedbatelný vyrovnávací proud. Radši bych na druhý konec koaxu dal anténu..

Síříte FUD, nedělejte to. Radši napište že tomu nerozumíte.

1. Coax v tomto pripade primo do pocitace nezapojite. Proste proto ze pocitace nemivaji interface na coax.
2. Prevodnik ma na coax vystupu galvanicke oddeleni (stejne jako snad jakekoliv jine metalicke vedeni)
3. Pocitac ma na ethernetu galvanicke oddeleni v podobe trafa.

galvanicky spojeno tu nic byt nemuze

Naopak bych řekl, že koaxové vstupy mívají stínění spojené s kostrou zařízení (čest výjimkám), a u zařízení bezp.tř. I to skončí až na kolíku v zásuvce. Souhlasím, že toho bych se trochu bál. Tato situace by mohla nastat, pokud by na obou koncích byly počítače s rádiem na USB nebo MiniPCI/M.2, a kostrou uzemněnou na PE v zásuvce.

Pokud bude v datové cestě aspoň jeden spoj metalickým ethernetem (CAT5e) tak máme v sérii dvě signálová trafa, a wifi AP. Pokud AP má oddělený napájecí zdroj, tak je teoreticky po starostech.

I pokud budu uvažovat scénář, kdy na obou koncích koaxu je APčko s lokálním Ethernetem a napájením ve tř.II (bez uzemnění na kolík v zásuvce) tak je mi ještě reziduální otázkou, zda průsak napájecího adaptéru (řekněme max 50 Hz / 1 mA) nebude dost silný na odpálení vstupu na středovém pinu wifi rádia. Nebo statika na 12 metrech koaxu. Spíš si ale myslím, že to zbytečně hrotím. Protože 50 Ohmů jmenovitá impedance. V = I*R, 1 mA * 50 Ohm = 50 mV... tenhle scénář bude nejspíš OK.

Kdybyste někdo někdy narazili na problémy se zbytkovým průsakem 50 Hz skrz Y-cap ve spínaném napájecím zdroji tř.II, může být řešením náhrada modelem určeným pro "medical" použití. Třeba v TME jde podle "použití" filtrovat a najdete přehršel modelů zn. MeanWell, které toto splňují. Mají průsak výrazně menší než konzumní konfekce.

Pokud chcete použít dvojici wifi APček jako "bridge" mezi dvěma sítěmi, hledejte model AP, který umí v nějaké podobě four-address mode. Aby se viděla zařízení na obou sítích navzájem bez omezení počtu MAC adres, oběma směry. Třeba Mikrotik tohle umí.

Dále, wifi rádia (konkrétně pozorováno na Mikrotiku) nemají ráda příliš silný signál. Tuším u Mikrotiku maximum bylo asi -50 dBmW RX level - výš se to chovalo jako při špatném/zarušeném signálu. Stačilo dát dvě větší paraboly na pár desítek metrů a byl problém. Řešením bylo, snížit v konfiguraci vysílanou úroveň - ale je mi otázkou, zda by rozsah nastavení stačil na krátkém kabelu s nevýznamným útlumem. Případně vložit útlumový článek, jak už tu někdo navrhoval.
Z mého pozorování tehdy také vyplynulo, že citlivější na příliš silný signál bylo 802.11n než 802.11a (5 GHz). Po starém koaxu bych každopádně poslal pásmo 2.4 GHz - má lepší šanci prolézt.

Redukci konektorů RSMA na F bych sháněl nejspíš v TME nebo SKT - pokud nebude přímá cesta, tak možná přes dvě redukce. Ony totiž systémy 50 a 75 Ohmů mají své typizované a navzájem nekompatibilní tloušťky kabelů a modely konektorů. Případně se kompatibilitě dá trochu dopomoci cestou mírného bastlu :-)

Pokud je pravda, že se wifiny zamčené v kabelu dá chytit nejdál na pár centimetrů od kabelu, tak bych se nebál, poslat po drátě 802.11ac se šířkou kanálu 80 MHz :-) pokud to v pásmu 2.4 vůbec rádia dovolí nakonfigurovat.

204
Sítě / Re:Ethernet přes koaxiální kabel
« kdy: 01. 02. 2023, 09:57:02 »
Po koaxu funguje dobře Televes CoaxData Modem, v ČR dodává Antech Břeclav.
Zajímavá krabička.

Zaujalo mě, jak v aplikačním examplu posílají datový příspěvek do rozvodu STA skrz výstup splitteru těsně pod domovním zesem :-D
...než jsem si všiml, že to je "diplexer - TV+data" tzn. nikoli nějaký hybridní splitter, ale selektivní slučovač (teoreticky).

Ono to samozřejmě umí pracovat po přímém kabelu = STA není podmínkou nutnou, spíš je to "taky schůdná varianta".

205
Přiřazení skupin na file sharech...
a kolik těch sharů bude? Na kolika fileserverech? Jaký OS na těch file serverech?
Jestli to nakonec neřeší /etc/passwd + /etc/group + /etc/samba/smb.conf .

Mimochodem jabko je sajrajt jak všude cpe ty svoje tečkové soubory.

206
Desktop / Re:Poraďte zajímavé využití RAM disku v Linuxu
« kdy: 29. 01. 2023, 13:08:15 »
Ještě tu nepadla zmínka o overlayfs nad RO-mounted rootem. Počítač pak funguje a OS si myslí, že zapisuje na disk, dokud nedojde RAMka :-) Používám pro "read-only NFS-root" nebo případně nad flashkou.

Jako kompromisní varianta, pokud třeba chcete flashce ulevit od zbytečných zápisů, se nabízí namountovat do tmpfs jenom některé adresáře - už tu někdo zmínil cache browseru, nebo třeba /var/log.

A jak už tu někdo zmínil, Linux by default používá volnu RAMku svobodně pro diskové buffery (cache). Buffery pro čtená data netřeba tunit, stránkovací mechanismus zcela samozřejmě drží v RAMce všechny načtené stránky, dokud nepotřebuje RAMku pro jiné účely (třeba nějaký proces si chce kus alokovat) - v tom případě nastoupí LRU. A pro zápis lze výrazného efektu často dosáhnout úpravou sysctl proměnných /proc/sys/vm/dirty_ratio, /proc/sys/vm/dirty_background_ratio, /proc/sys/vm/dirty_expire_centisecs . Defaulty jsou zbytečně konzervativní: k čemu je mi 8 GB RAM, když pro diskovou WB cache smí kernel využít třeba jenom 5-10%. Pro mě za mě ať si vezme klidně 80-90%. Třeba kompilaci kernelu nebo instalaci většího počtu balíčků na točivém disku to zrychlí dost citelně. Někdy to pošteluju už v instalátoru na jednotlivém stroji, aby instalace běžela rychleji. Pokud zapisující aplikace nedělá příliš často tvrdý blokující "sync", tak běžných frontovatelných bariérových operací zřejmě generuje filesystém relativně málo...

207
Studium a uplatnění / Re:Přiměřeně lehká IT VŠ
« kdy: 27. 01. 2023, 16:01:00 »
Vyhazovaci predmety jde odstudovat na erasmu nebo si je zapsat v anglictine pro erasmaky, kvuli kterym je latka pruchodu nize.
To by mě zajímalo kolik středoškoláků má angličtinu na takové úrovni že pro ně bude snazší učit se obtížný předmět v angličtině než v češtině.
V dobách mého mládí takových ještě mnoho nebylo, ale situace se zrovna lámala - koncem devadesátek.

Dnes bych se nedivil. Není potřeba zrovna cestovat ven, stačí trochu cílevědomosti. Během střední (což je dnes min. do 19 let) už může mít mládě dost rozumu a motivace, aby na cizím jazyku o své vůli pracovalo.

Ale zcela konkrétně... mám na očích děcka, co měla angličtinu na základce jako první jazyk... pokud ne od první třídy, tak od třetí určitě. A na osmiletém gymplu dostávají v cizích jazycích kouř, jaký na gymplu nepamatuju. Mám na očích dva kluky ve věku někde mezi 14-16, kteří mají díky moderním gamesám a YouTube zhruba takovou úroveň pochopení mluveného projevu, jakou já neměl v osmnácti na konci střední. (A ten mladší je na tom líp.) Mám na očích slečnu v šesté třídě ZŠ, které Duolingo AJ/ČJ připadalo pomalé a nudné, tak si zkusila španělskou mutaci (proti angličtině jako "odrazovému" jazyku) a momentálně mastí především tuto.

Fakt bych se nedivil ničemu.

208
Studium a uplatnění / Re:IT na VŠ se sítěmi?
« kdy: 27. 01. 2023, 14:59:23 »
Výhoda je, že ty technologie se můžeš učit hned a nepotřebuješ čekat až to bude ve studijním plánu

To je právě ono. Kurzy z aplikovaného IT, které nejsou úplně začátečnické, bývají až na magisterském stupni - a ani tyto objektivně vzato nejsou nějaký černokněžnický hardcore. Kvůli tomuhle tvrdnout na řádném denním studiu 3 a více let, prokousávat se povinnými předměty na které zajímavé IT věci převážně nijak zvlášť nenavazují...

209
Studium a uplatnění / Re:IT na VŠ se sítěmi?
« kdy: 27. 01. 2023, 11:16:44 »
Jestli správně chápu, ani Silicon Hill už není co bejval...? ;-)

Kdekoli jsem byl ve škole (moc jich nebylo), tak nejlepší síťaři byli lidi, kteří se starali o provoz školní sítě. Pokud někteří z nich byli taky studenti nebo měli akademickou stránku kariéry na škole, tak administrátorský/pracovní aspekt obvykle silně převažoval. Na ekně si pamatuju výborné volitelné cviko z architektury operačních systémů, které přednášel právě někdo z "interního IT" (jméno už si nepamatuju). A další třeba úvod do správy síťových OS.

Jestli se dá ve škole zúčastnit přípravných kurzů na adminování sítí pod vlajkami Cisco, Juniper, MS apod., tak jsou to de facto ušetřené peníze - takové kurzy jinak stojí desítky tisíc Kč, pokud Vás na ně pošle zaměstnavatel (nebo byste si je chtěl platit sám). Zas pokud máte mezitím zaměstnavatele/zaměstnání, které Vám kurzy zaplatí, tak může škola představovat určitou přítěž... čas jsou peníze. Jsou zaměstnavatelé, chtělo by se říci osvícení, kteří vítají, pokud dál studujete.

Pokud budete študovat sítě ve škole a na kursech, převážně "na papíře" či "od stolu", tak se zároveň snažte, hrát si s živým hardwarem. A nemusí to být nutně značkové boxy. V dnešní době je naprosto neuvěřitelné, co všechno se dá poskládat z open-source softu na dostupném hardwaru. Nechci doporučovat PC hardware ze smeťáku, není žádnej med trápit se náhodnými pády a zátuhy namísto toho, aby si člověk trénoval softwarové věci. (Ale taky není špatné, naučit se hardware trochu opravovat / diagnostikovat - pokud je to Vaše gusto.) Ledacos se dá samozřejmě osahat/natrénovat ve virtualizaci = uspoříte hardware.
Všelijaké firemní základní kurzy Vám říkají "takhle se to dělá, takhle je to správně". Ale časem si všimnete, že to třeba spíš znamená "takhle to děláme my, takhle to umíme, takhle to u nás jde nakonfigurovat a reálně nám to funguje". Nevím kolik prostoru dnes zbývá pro selský rozum, myšlení "out of the box". Nakolik se cení, uniknout z pasti "not invented here". Umět vhodně nakombinovat technologie více proprietárních výrobců a třeba to kořenit open-source prvky. Umět si poradit "po svém" znamená, nimrat se v ohavných detailech. Kdopak má na tohle dneska čas... poctivý student řádného denního studia spíš ne.

Pravda taky je, že už mnoho let se čím dál víc věcí stěhuje "do cloudu". Správa on-premises síťovin je krajně nemoderní - šéfové by nejradši offloadnuli do cloudu nejen servery (resp. služby), ale taky datovou strukturku a asi i rozvod 240V... A přesto je dodnes spousta situací, stávajících provozů, zadání apod., kde se adminské řemeslo cení. Občas narazíte na šéfa či zákazníka, který má sklon Vám kázat moderní dobu cloudovou, s jabkem v ruce Vám důrazně vysvětluje, že pokud to nefunguje samo tak je to špatně... a zároveň s určitou mírou zhnusení přiznává, že potřebuje i člověka, který rozumí těm drátům po baráku, umí se postarat aby data byla v bezpečí apod. Aby to "fungovalo samo od sebe", s tím může mít admin i dnes poměrně dost práce :-) A je to taková práce jako úklid: když se udělá správně, tak vlastně není vidět.

Bohužel se obávám, že "všechno as a service" je výsledek, ke kterému odvětví konverguje. Je to v zájmu státu a korporací, a vede k tomu princip z nejohavnějších: úspory z rozsahu. Stejně jako v masové výrobě a distribuci zboží. Tento vývoj je bržděn vlastně jenom "obchodní opatrností" a setrvačností telco odvětví - než kopnou do země, snaží se dojit staré měděné dráty ještě pět minut po dvanácté atd. Až bude kvalitní konektivita dostupná kdekoli, skončí "on premises" servery definitivně jako hračka staromilců a možná relikt/skanzen v organizacích, kde je z nějakých důvodů kladen důraz na soběstačnost. Ta doba možná není daleko.

210
Studium a uplatnění / Re:Přiměřeně lehká IT VŠ
« kdy: 26. 01. 2023, 18:17:49 »
@karel356 no vida, takže základy už máte za sebou :-) Ano ano, kombinovat informace z více zdrojů. BTW examply na C# bych čekal na StackOverflow.com nebo CodeProject.com - ale stejně nakonec nejlepší hledač napříč různými weby je Google :-)

Pokud byste se v programování pohyboval "směrem blíž k operačnímu systému", možná narazíte občas na to, že přímější a čistší cesta k funkcím např. Win32 API (nebo Posixu) je z prostého Céčka :-) a C# API v těchto "systémáckých" oblastech jsou někdy jenom nepříliš povedené wrappery kolem C-level systémových knihoven a syscallů. Ale jedno po druhém, všechno má svůj čas. A v C# se dneska píše velká spusta softwaru.

Stran: 1 ... 12 13 [14] 15 16 ... 84