1
Distribuce / Re:Debian 11 mi nevidí žádné USB
« kdy: 28. 07. 2025, 14:52:21 »
Zkusil bych novější kernel. Comet Lake je poměrně mladý hardware.
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.
2
Hardware / Re:Doporučte značku notebooku pro práci
« kdy: 26. 06. 2025, 15:20:32 »
Někdo mi tu při COVIDu poradil HP ProBook, tehdy byl cca v 8. generaci... následně jsem koupil 10.gen a 11.gen a v pohodě. Devátá generace ProBooku neměla podsvícení klávesnice. Každopádně AMD a osobně volím úhlopříčku 15-16 palců. Tzn. ProBook 455 nebo 465, co zrovna v té které generaci vypustí. ProBook 465 gen.11 má displej 1920x1200 (tzn. nikoli x1080). Má to dva SODIMM sloty a docela snadno se dá dostat břichem dovnitř kvůli servisu. Taky šasi letmo potkalo hliník, není to celé jenom plasťák. Klávesnice jsou co jsou, obecně u notebooků, líp už bylo.
3
Software / Re:Algoritmus pro doporučování zboží v e-shopu
« kdy: 17. 06. 2025, 22:23:41 »
Za mě... užitečný je algoritmus, který přiřazuje věcně související položky.
A vnímám to jako součást správy produktových karet v e-shopu.
Kam řadím i údržbu selekčních filtrů.
"Algoritmus pro související položky" je další v řadě z této oblasti.
Správa produktových karet se dá buď flákat: že máte popis nulový, nebo minimální, nebo oprásknutý nastojato z datashitu výrobce, nebo si pomocí AI vygenerujete trochu nastavované kaše / omajdy okolo.
Nebo do svého popisu produktu vmasírujete kus svého praktického know-how. Znalost produktu z vlastní zkušenosti. Stačí v kostce bodově důležité vlastnosti - a už se odlišíte. Zamyslíte se nad podstatnými filtrovatelnými atributy...
Pokud odkazy na související produkty nepřidáváte ručně do popisu produktů, dal by se na to použít nějaký engine, který by jel nad nějakými metadaty. Třeba minimální vztahovou mapou.
Například e-shop TME má související produkty často dost užitečné. Sháním konektor, pracně najdu to správné tělo, a TME mi k němu doporučí kompatibilní piny (i více druhů).
Nebo zabrousím v počítačovém e-shopu na motherboard, a e-shop mi k němu nabídne kompatibilní procesory a RAMky (což není úplně triviální úloha, na prostou kompatibilitu patice / technologie / taktu se nedá vždy spolehnout). A třeba taky chladiče.
Nebo například údržbuju několik starších MTB s trojtácem, cca od 3x7 do 2x11. Bohužel e-shopy s komponenty zápasí i se základním explicitním filtrem :-( Velice by se mi líbilo, když už si vyberu třeba trojtác, aby mi e-shop k němu začal poňoukat kompatibilní přesmyk, řetěz, přehazku a kazetu. Byl by docela masakr, extrahovat do počítačové vztahové mapy pravidelně aktualizovaný dokument "Shimano compatibility information" :-) Bohužel je reálně problém spíš ten, že Shimano starší varianty roztečí řetězu, starší varianty trojtáců apod. postupně z nabídky kostí, aby bylo naschvál složité, sehnat náhradní díl na starší kolo, abyste nesehnal náhradní díl za původní dražší sadu (a musel sáhnout po levnější byť snad kompatibilní náhradě) atd. Takže vzato do důsledku, pokud by ta doporučení skutečně technicky seděla, vycházela by z toho často téměř prázdná množina... Což není problém počítačově-algoritmický, ale marketingový v cílové doméně.
A vnímám to jako součást správy produktových karet v e-shopu.
Kam řadím i údržbu selekčních filtrů.
"Algoritmus pro související položky" je další v řadě z této oblasti.
Správa produktových karet se dá buď flákat: že máte popis nulový, nebo minimální, nebo oprásknutý nastojato z datashitu výrobce, nebo si pomocí AI vygenerujete trochu nastavované kaše / omajdy okolo.
Nebo do svého popisu produktu vmasírujete kus svého praktického know-how. Znalost produktu z vlastní zkušenosti. Stačí v kostce bodově důležité vlastnosti - a už se odlišíte. Zamyslíte se nad podstatnými filtrovatelnými atributy...
Pokud odkazy na související produkty nepřidáváte ručně do popisu produktů, dal by se na to použít nějaký engine, který by jel nad nějakými metadaty. Třeba minimální vztahovou mapou.
Například e-shop TME má související produkty často dost užitečné. Sháním konektor, pracně najdu to správné tělo, a TME mi k němu doporučí kompatibilní piny (i více druhů).
Nebo zabrousím v počítačovém e-shopu na motherboard, a e-shop mi k němu nabídne kompatibilní procesory a RAMky (což není úplně triviální úloha, na prostou kompatibilitu patice / technologie / taktu se nedá vždy spolehnout). A třeba taky chladiče.
Nebo například údržbuju několik starších MTB s trojtácem, cca od 3x7 do 2x11. Bohužel e-shopy s komponenty zápasí i se základním explicitním filtrem :-( Velice by se mi líbilo, když už si vyberu třeba trojtác, aby mi e-shop k němu začal poňoukat kompatibilní přesmyk, řetěz, přehazku a kazetu. Byl by docela masakr, extrahovat do počítačové vztahové mapy pravidelně aktualizovaný dokument "Shimano compatibility information" :-) Bohužel je reálně problém spíš ten, že Shimano starší varianty roztečí řetězu, starší varianty trojtáců apod. postupně z nabídky kostí, aby bylo naschvál složité, sehnat náhradní díl na starší kolo, abyste nesehnal náhradní díl za původní dražší sadu (a musel sáhnout po levnější byť snad kompatibilní náhradě) atd. Takže vzato do důsledku, pokud by ta doporučení skutečně technicky seděla, vycházela by z toho často téměř prázdná množina... Což není problém počítačově-algoritmický, ale marketingový v cílové doméně.
4
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 06. 06. 2025, 14:35:19 »
Já bych možná jen zmínil, že přestože jsem tu a tam historicky něco malého napsal, zhusta v céčku, tak shift na signed integer jsem co pamatuju nikdy nepotřeboval :-) takže ponaučení původnímu tazateli: jestli chcete tak se céčka bojte, ale ne kvůli shiftu se znaménkem :-)
5
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 03. 06. 2025, 01:04:11 »
Na nějaké halucinace v chování shiftu jsem narazil v implementaci CRC v modbusové knihovně (mé vlastní). To CRC jsem si někde "půjčil" - a přestože GCC na x86 mi to dlouhá léta chroupalo správně, tak GCC na ARMu dávalo nesprávný součet. Přisuzoval jsem to nějakému rozdílu v inicializaci defaultních hodnot bitů v registrech mezi platformami nebo co... v zásadě mi stačilo ty operace pečlivěji (explicitněji) uzávorkovat a otypovat, a začalo se to chovat na obou platformách stejně...
Jojo, printf... různé verze a varianty format stringu se navzájem liší v drobných nuancích...
Na druhou stranu jsem zaznamenal, že jak C++ zamlada prudilo "všichni musí používat iostream a jeho C++ manipulátory, na printf() zapomeňte", tak později tenhle fundamentalismus trochu vyvanul a printf() se dále používá jako legitimní funkce pro vkládání proměnných do textového řetězce...
Jojo, printf... různé verze a varianty format stringu se navzájem liší v drobných nuancích...
Na druhou stranu jsem zaznamenal, že jak C++ zamlada prudilo "všichni musí používat iostream a jeho C++ manipulátory, na printf() zapomeňte", tak později tenhle fundamentalismus trochu vyvanul a printf() se dále používá jako legitimní funkce pro vkládání proměnných do textového řetězce...
6
Vývoj / Re:Je jazyk C skutočne ťažký?
« kdy: 02. 06. 2025, 11:52:58 »... má jen minimum datových typů ...
Pokud se týče základních datových typů, tak bych naopak řekl, že jako snad jediný jazyk (kromě assembleru) poskytuje kompletní množinu různě dlouhých integerů se znaménkem nebo bez (a floaty a pointery). Sice se integer typy divně jmenují (char, short, long, long long) takže si je lidi někdy pro lepší přehlednost přejmenovávají na něco jako u16, nebo s32... ale těch pár jiných jazyků, které, jsem potkal, mě většinou tlačilo nějak do kouta stylem "tumáš nějaký integer a neotravuj s detailismem". Na to navazují bit-banging operace AND, OR, XOR, NOT.
Žádné rozmazlování garbage collectorem - máte lokální proměnné na stacku a globální tuším na heapu, a na případnou dynamickou alokaci z heapu máte v případě zájmu explicitní malloc() a free().
Jazyk je to závorkovatý, takže se nemusíte bát, že se Vám program rozbije změnou odsazení řádku.
Zároveň není tak ukecaný jako někteří jeho vrstevnící, kteří uzavírají blok mezi slůvka BEGIN a END :-)
Ten jazyk má přímý přístup k systémovým standardním knihovnám a syscallům. Vyšší jazyky toto C-level API musí nějak "balit" pro své potřeby, mohou být pozadu / nabízet jenom podmnožinu, nabalit další vrstvu abstrakce která může věci zjednodušovat a ve složitějších případech překáží apod.
Jsou situace / zadání, kde je zcela legitimní a vhodné, použít něco jiného než právě C :-)
Je to osobní volba. Mě v hadích letech vždycky zajímalo, jak věci fungují "pod kapotou", a když jsem po setkání s Basicem a Pascalem potkal vlastním přičiněním nakonec i Céčko, byla to pro mě veliká úleva. Že nemusím prosté věci řešit divnými oklikami, zároveň ale nemusím zabředat do detailů instrukční sady procesoru.
7
Hardware / Re:Mobil/SBC pro Debian s funkční Wi-Fi
« kdy: 26. 05. 2025, 23:04:02 »Apropo, kde se tyhle prumyslovy veci kupuji? Vsude vidim akorat "cena na dotaz", patrne zamysleny opravdu jen pro prumysl s odberem poctu v radu stovek kusu minimalne?
O počty kusů ani tolik nejde. Aspoň tady náš tuzemský trh průmyslových PC je maličký, takže objednávky prakticky od jednoho kusu. Samozřejmě když se povedou větší počty, tak jedině dobře - na druhou stranu, čím víc kusů se toho prodá, tím větší potenciálně průser, když se v tom hardwaru najde nějaká hnida... ;-)
Do tohoto segmentu dodávají většinou Taiwanci. Protože jsou ochotni osadit a poslat od jednoho kusu. Kontinentální číňan se začne bavit tak od stovky kusů, míň většinou ne - a taky u těchhle exotičtějších věcí z kontinentální Číny není takový spoleh na jakousi minimální úroveň kvality. Větší taiwanští výrobci mají mezisklad v Evropě, ti menší expedují přímo z Taiwanu (a doprava zabolí).
Napadá mě jeden výrobce embedded PC desek, který se tváří že sídlí v Německu, ale výrobu má stejně na Taiwanu.
Tady u nás je několik firem, které fungují jako dovozci (já pracuju pro jednu z nich). Ale těch cest kde koupit je víc, zeměkoule je čím dál menší - bohužel pro nás dovozce ;-) Výrobci většinou nedodávají drobným zákazníkům napřímo, odkazují je na dovozce/distributory...
Na "průmyslovém hardwaru" je úžasné, že se dá koupit konkrétní model desky několik let. Když skousnete občas novou revizi čipů, tak třeba 10 let. Objednávka od jednoho kusu. Výrobce na Taiwanu drží skladem plošáky a zásobu součástek, a osadí pár kusů na míru. Když nechcete zakázkové opšny, mívá pár kusů základního provedení motherboardu skladem. Pravda je, že tahle pružnost není úplně pravidlem. Takhle fungují ti nejlepší - malí a pružní, specialisti na konkrétní sortiment. Pak jsou relativně velké firmy s mnoha divizemi, které mají procesy podstatně zkostnatělejší... vyrábějí ve větších sériích podle toho, jak si centrálně předem naplánují poptávku apod.
Taky úroveň a ochota techsupportu se mezi výrobci dost liší - a opět je často příjemnější práce s malou speciálkou, než se silnou a známou značkou.
Cenově pro hobbíka to obecně moc není - ale za optání nic nedáte.
Že třeba nejsou ceny veřejně v e-shopu je dáno několika faktory:
- od zahraničních dodavatelů v tomhle segmentu obecně moc nefunguje strojový import ceníků z nějakého strojově čitelného formátu. Čest výjimkám. Ceníky posílají v čem je napadne, klidně v PDF apod.
- sortiment (seznam položek) je velice široký v porovnání s realizovanými objednávkami. V zásadě se prodá sem tam kus od jednotlivé položky, třeba 90% ceníku se tady u nás nikdy neprodá. A údržba cen v e-shopu stojí čas a úsilí. Kdybyste vystavil ceny a nechal je pár let bez aktualizace, tak stejně nemůžete zákazníky nechat, aby si za ty neaktuální ceny sami objednávali.
Takže je jednodušší, když už vůbec konkrétní položku veřejně zalistujete, nechat cenu schovanou, a v případě zájmu reagovat na poptávku - buď máte aktuální ceník, nebo poptáte u výrobce apod.
Taky se nenechte odradit, pokud u tuzemského dovozce nenajdete konkrétní model, který jste si vyhlédl u výrobce - pokud dovozce zastupuje kýženého výrobce, nebojte se zeptat.
Zrovna s ARMovými deskami a paneláky mám bohužel zkušenost, že se jich tu moc neprodává, demovzorky končí zaprášené v odepsaném šrotu apod. Podle mého je to tím, že tu není moc lidí, ochotných poprat se s bootstrapem rozumného linuxového distra na ARM, a WinCE poněkud usnuly. Trochu se prodávají konkrétní ARMové modely s aspoň trochu rozumným Linuxem od výrobce počítače, pro nějaké nenáročné použití typu "kiosek s browserem", nebo v roli protokolové gatewaye, kde místní zákazník nepíše do toho boxu žádný nativní software, spíš jenom pokonfiguruje hotový software co byl přibalený.
8
Hardware / Re:Mobil/SBC pro Debian s funkční Wi-Fi
« kdy: 25. 05. 2025, 10:40:11 »
Opožděně zareaguji na původní dotaz: co tak pozoruji, hodilo by se něco třeba se 2 CPU jádry na co nejjemnější litografii, plus požadovaná bezdrátová výbava, optimalizováno na co nejnižší příkon, zároveň co nejvíc otevřené, s dostupnými ovladači...
Nemám :-)
Jemná litografie, důraz na spotřebu a úsporná rádia - toto vše se vyskytuje v telefonním světě, který ale není svobodný. Navíc i ten důraz na spotřebu kulminoval někdy začátkem století ještě před nástupem matlání (výdrž na baterku měsíc apod.) - Androidové founy nikdy tak důsledné se spotřebou nebyly, designové kritérium zdá se být spíš "stačí když to vydrží na jedno nabití asi den, hlavně ať to má aspoň 8 CPU jader a OpenGL".
Takže zatímco mobilní matlafouny míří někam ke 5 ... 4 ... 3 nm (údajným nanometrům), na průmyslových boardech jako nejskromnější vidím několik posledních generací DMP Vortex86 (už nevím jestli končí na 40 nm, nebo třeba 28 nm, tuším UMC) a z holdingu DMP výrobce desek ICOP si přilepšuje i.MX8 od NXP. Pokud se týče spotřeby, tak úspornější varianty Vortex86 boardů berou něco jako 3W (bez wifi, bez LTE a bez displeje), i.MX8 je tuším zhruba o 1 Watt níž a možná se do toho vešla i wifi... Boardy a počítače s i.MX8 vidím v "průmyslu" i u dalších výrobců - spotřeba bude podle mého podobná. Není to určeno na micropower přežívání někde z baterky, jsou to spíš "relativně levné" a příkonově úsporné počítače na nějaké to nenáročné HMI, s trvalým napájením ze sítě.
Mrkněte třeba na tenhle board:
https://www.icop.com.tw/datas/upload/files/Product/SBC/NX8MM-35/NX8MM-D168%20carrier%20boardBLOCK%20DIAGRAM2024.jpg
https://www.icop.com.tw/product/NX8MM-35#!
Má to onboard jakousi wifinu (model jsem nezkoumal) a do MiniPCI-e slotu se SIM paticí by se dal strčit LTE modem. Viděl jsem tuším modely LTE kartiček prodávané jmenovitě pro "IoT" nasazení = relativně pomalé a snad i optimalizované na příkon.
Ve světě x86 je jako nejúspornější od DMP určen patrně Vortex86EX, případně EX2. Viz třeba tenhle board:
https://www.icop.com.tw/product/VEX-6225
Onboard žádné rádio, spotřeba něco jako 3W. Dva sloty MiniPCI.e, asi by se dala osadit požadovaná rádia. Problém je, že každé rádio si za jízdy vezme hravě 1W, pokud ne víc.
Požadované 2-3W mají být průměrná spotřeba, nebo nepřekročitelná obálka? Wifi rádio musí být neustále ready, nebo by se dalo nějak utlumovat/vypínat? Pokud neustále ready, třeba by se dal omezit na tu krátkou vzdálenost vysílaný výkon a taky rychlost.
Intelův ATOM je dodnes úsporný spíš naoko. Takový Alder Lake N, v "booksize" počítači s pasivním chlazením, umí topit tak, že na žebrech sotva udržíte ruku. Pokud mohu soudit, úspornější bratranec Quark je prakticky mrtev - vypadá to na experiment, který skončil jako slepá vývojová větev.
Nemám :-)
Jemná litografie, důraz na spotřebu a úsporná rádia - toto vše se vyskytuje v telefonním světě, který ale není svobodný. Navíc i ten důraz na spotřebu kulminoval někdy začátkem století ještě před nástupem matlání (výdrž na baterku měsíc apod.) - Androidové founy nikdy tak důsledné se spotřebou nebyly, designové kritérium zdá se být spíš "stačí když to vydrží na jedno nabití asi den, hlavně ať to má aspoň 8 CPU jader a OpenGL".
Takže zatímco mobilní matlafouny míří někam ke 5 ... 4 ... 3 nm (údajným nanometrům), na průmyslových boardech jako nejskromnější vidím několik posledních generací DMP Vortex86 (už nevím jestli končí na 40 nm, nebo třeba 28 nm, tuším UMC) a z holdingu DMP výrobce desek ICOP si přilepšuje i.MX8 od NXP. Pokud se týče spotřeby, tak úspornější varianty Vortex86 boardů berou něco jako 3W (bez wifi, bez LTE a bez displeje), i.MX8 je tuším zhruba o 1 Watt níž a možná se do toho vešla i wifi... Boardy a počítače s i.MX8 vidím v "průmyslu" i u dalších výrobců - spotřeba bude podle mého podobná. Není to určeno na micropower přežívání někde z baterky, jsou to spíš "relativně levné" a příkonově úsporné počítače na nějaké to nenáročné HMI, s trvalým napájením ze sítě.
Mrkněte třeba na tenhle board:
https://www.icop.com.tw/datas/upload/files/Product/SBC/NX8MM-35/NX8MM-D168%20carrier%20boardBLOCK%20DIAGRAM2024.jpg
https://www.icop.com.tw/product/NX8MM-35#!
Má to onboard jakousi wifinu (model jsem nezkoumal) a do MiniPCI-e slotu se SIM paticí by se dal strčit LTE modem. Viděl jsem tuším modely LTE kartiček prodávané jmenovitě pro "IoT" nasazení = relativně pomalé a snad i optimalizované na příkon.
Ve světě x86 je jako nejúspornější od DMP určen patrně Vortex86EX, případně EX2. Viz třeba tenhle board:
https://www.icop.com.tw/product/VEX-6225
Onboard žádné rádio, spotřeba něco jako 3W. Dva sloty MiniPCI.e, asi by se dala osadit požadovaná rádia. Problém je, že každé rádio si za jízdy vezme hravě 1W, pokud ne víc.
Požadované 2-3W mají být průměrná spotřeba, nebo nepřekročitelná obálka? Wifi rádio musí být neustále ready, nebo by se dalo nějak utlumovat/vypínat? Pokud neustále ready, třeba by se dal omezit na tu krátkou vzdálenost vysílaný výkon a taky rychlost.
Intelův ATOM je dodnes úsporný spíš naoko. Takový Alder Lake N, v "booksize" počítači s pasivním chlazením, umí topit tak, že na žebrech sotva udržíte ruku. Pokud mohu soudit, úspornější bratranec Quark je prakticky mrtev - vypadá to na experiment, který skončil jako slepá vývojová větev.
9
Hardware / Re:Konvertor z RJ11 (RS232/C) na Ethernet
« kdy: 23. 05. 2025, 11:06:03 »
To zařízení se historicky původně jmenovalo "terminal server", přestože je to v dnešní době většinou malá až miniaturní krabička. Má to nějaký firmware způsobilý k TCP/IP, Ethernet (nebo wifi) a sériový port. V základní variantě je to TCP server = otevřete TCP spojení na konkrétní TCP port, a krabka spustí obousměrný relay TCP relace na svůj sériový port.
Sériový port má nějaké konfigurovatelné vlastnosti navíc, které TCP spojení postrádá.
Konfiguraci sériového portu je obvykle možno zařídit nějak "out of band", anebo taky in-band.
Jednak existuje RFC-2217, které káže několik dodatečných Telnet Options = v kontextu mechanismu escape sekvencí protokolu Telnet přidává pár kódů speciálně pro konfiguraci sériového portu (baud rate, formát znaku).
Kromě toho se někteří výrobci "terminálových miniserverů" uchylují k proprietární enkapsulaci transportu sériové komunikace nad TCP/IP - kde mají toto ovládání také pořešeno. Klientem je v tom případě obvykle proprietary "virtual COM port driver" do Windows (a k němu doprovodná konfigurační utilita).
Transport sériových dat nad TCP/IP není úplně transparentní v rovině časování. Pokud používáte virtuální sériák pod Windows a snažíte se, aby aplikace nepoznala, že nemá fyzický lokální COM port, může Vaše partyzánská činnost narazit na principielní vlastnost, že paketizace způsobuje nerovnoměrné rozestupy mezi znaky přijímanými v čase a prodloužení transportních latencí. Ovladač virtuálního COMu se obvykle nesnaží ve směru "příjem" reprodukovat rovnoměrné časování okamžiku příchodu jednotlivých znaků. Prostě přijme TCP paket a payload obsahující kdoví kolik znaků předá jedním vrzem čekající funkci recv() nebo read() nebo jak se to v klientském OS jmenuje. Pravidla pro paketizaci ze sériové linky do TCP mívají terminálové servery do jisté míry konfigurovatelná: po jak dlouhé pauze od posledního znaku ukrojit a odeslat paket, resp. po kolika znacích/bajtech (maximem je zřejmě MTU nebo MSS nebo jak se tomu).
Skrz generickou paketizaci nemusí projít nastojato některé protokoly, které nad fyzickou sériovou linkou dbají na striktní časování. Třeba Modbus/RTU má prohlásit "konec rámce" po ekvivalentu 3.5 znaku od posledního přijatého znaku. Takovéhle protokoly mívají bratříčka, který s TCP enkapsulací nativně počítá - a potřebujete "o něco chytřejší" gateway, která mezi oběma enkapsulacemi bude provádět relay v souladu s normou pro daný protokol. Třeba Modbus/RTU vs. Modbus/TCP, IEC-101 vs. IEC-104 apod.
Inteligentní relay konkrétních fieldbusů tradiční terminálové servery neuměly - ale už dávno existují varianty firmwaru, které takové věci umí buď jako svou pevnou náplň práce, nebo jako konfiguračně volitelnou vlastnost...
Pokud potřebujete od "terminálového serveru" obecně "něco svého", řešíte spíš možnost, dopsat si do takové krabičky svůj vlastní software. Tzn. ke krabičce přistupujete spíš jako k obecnému počítači, ve kterém uvítáte otevřený Linux (nebo tak něco) do kterého si dopíšete co je potřeba. Někteří výrobci tomuto využití jdou naproti (tradičně Lantronix, zřejmě taky ATOP a u některých modelů Advantech), u ostatních nevím.
Případně, pokud Vaše koncové zařízení na sériové lince má nějaký opravdu primitivní protokol, možná byste sehnal "průmyslovou krabičku se sériovým portem", která by to dokázala nějak pozřít a podat dál skrz jednoduché HTTP GUI nebo třeba MQTT apod. Třeba váha pošle řetězec zakončený konkrétním znakem, buď v pravidelném časovém intervalu, nebo v reakci na událost, nebo v opravdu krajním případě na nějakou výzvu po sériové lince... Jako že by to šlo naklikat bez programátorské práce.
Terminálové servery velké jako krabičku sirek či cigaret dělá v dnešní době spousta výrobců. Lantronix je zřejmě pradědeček, tuzemského Papoucha už tu taky někdo zmínil, osobně znám pár dalších značek (Advantech, ATOP, Moxa, Korenix, Westermo) ... prakticky kdokoli v Číně kdo má nos mezi očima to vyrábí v garáži (a jeho babička). Samozřejmě je možné to postavit zcela po svém na dnešních otevřených platformách typu RPi nebo ESP32.
Není pravda, že "většina sériových donglů na USB má RS232 výstup na elektrických úrovních TTL". Pokud Vám to tak připadá, doporučuji Vám udělat si podrobnější průzkum trhu a pořádek ve zbožíznalství :-)
Sériový port se skládá obecně ze dvou čipů: UART (= posuvný registr) a "level shifter" = analogový opakovač, budič linky. Ideové blokové schéma s polaritami signálů najdete třeba tady (disclaimer: samožer).
UART je součástka společná pro RS232/422/485. UART s level shifterem se baví na elektrických úrovních TTL. Teprve level shifter vyrábí kýžené napěťové úrovně pro RS232 nebo 422/485 (nebo třeba M-bus, ten má taky zcela svoji fyzickou vrstvu). Kolmá poznámka: budu dále abstrahovat od detailu, že pro half-duplexní varianty sériové linky (RS485 a snad i M-bus) je vhodné mít z UARTu vyvedený signál TSRE aka TEMT, což třeba klasický TI 16C550A UART nemá.
Konkrétně RS232 má platné logické úrovně 3 až 15 Voltů od společné referenční země, bipolárně plus a mínus. Samotná zem (nula voltů) je zakázaný stav, zavřený ve Schmittově hysterzi. Existuje mnoho level shifterů, které si "divné" napěťové hladiny pro RS232 vyrábí z jediné vstupní napájecí větve (3.3V nebo 5V) on-chip RC nábojovou pumpou, a na výstupech pak vidíte třeba něco jako +/-6 nebo +/- 10 V. Nebo třeba jenom +/- 5V u některých USB donglů. Ale nenechte se zmást, těch "asi 5 Voltů" bývá bipolárně kolem nuly. Taky si všimněte, že polarita logických úrovní je na RS232 lince opačná (invertovaná), oproti interní TTL komunikaci mezi UARTem a level shifterem. Pokud tedy narazíte na dongle, který produkuje TTL (cca 5V / 0V), tzn. nedává zápornou úroveň, a přitom používá "polaritu jako RS232", tak se jedná o paskvil / zmetek / čínskou inovaci - osobně takových mnoho nevídám.
Ano, jsou k nalezení levné USB/serial dongly s výstupními úrovněmi TTL - protože postrádají level shifter. Třeba známá firma FTDI takové varianty nabízí, vedle bratříčků s level shifterem pro RS232 nebo RS485. Dongle bez level shifteru je v tomto případě řádně označen. Bavíte se v tomto případě navenek přímo s UARTem.
K čemu to?
Mnoho malých krabiček (levné routery) mají vyvedenu sériovou konzolu právě na úrovních TTL rovnou z UARTu. Proč: protože použitý SoC/CPU/MCU obsahuje UART nebo dva on chip, a servisní konzola je typickým účelem takové sériové linky. Ovšem ta linka zůstává za normálních okolností schovaná pod kapotou, a použije ji jenom znalý servisák, pokud za vzácných okolností není zbytí - možná ji použije fabrika pro upload firmwaru (pokud toto nemají ošetřeno jinak, třeba přes JTAG nebo SPI). Jedná se o využití na kratičkou vzdálenost, v kontrolovaných laboratorních podmínkách. Poškození "divočejším počasím" nebo nešikovností uživatele až tolik nehrozí. Pro tyto potřeby je škoda utratit dolar nebo dva navíc za level shifter.
USB/serial dongly jsou založeny na čipech několika populárních výrobců: FTDI, Prolific, Silicon Labs, WinChipHead, Moschip, teoreticky taky Exar něco má, možná někdo další by se našel...
USB/serial nemá svou vlastní třídu USB zařízení. Asi nejblíž je CDC-ACM, což je ale třída specificky pro USB modemy. Možná proto výrobci USB/UART čipů CDC-ACM obecně ignorují a používají každý své rozhraní na USB. Proto taky do Windows potřebujete pro USB/serial dongly vždy specifický driver od výrobce UART čipu - protože Windows neobsahují class-based driver, protože neexistuje jednotná třída rozhraní.
Kupodivu Linux obsahuje ovladač usbserial.ko. Tento ovladač sdružuje HW-specifické open-source drivery pro větší počet výrobců čipů :-) Je možné, že tam je nějaká synergie (sdílení kódu) v transportu dat mezi TTY subsystémem a USB endpointem... navenek se to chová úplně jako class-based ovladač :-) Prostě v Linuxu drivery pro USB/serial dongly naprosto neřešíte. Píchnete do počítače anonymní dongle co jste našli válet zaprášený v racku, a ejhle, kernel našel /dev/ttyUSB0, minicom funguje...
No a pokud se týče Androidu: ten má přece uvnitř linuxový kernel, žeano. Takže by snad měl automaticky obsahovat ovladače pro USB UARTy výše zmíněných "obvyklých podezřelých" výrobců...
Omyl vážení! Pardon - tahle zkušenost je už třeba 5 let stará, doufám že nekecám. Osobně do mobilních OS nefušuju - ale bavil jsem se chvíli s hobbíkem, který si pro Android programoval nějakou odposlechovou appku se sériovou komunikací. Android rozhodně vanilkový usbserial driver v kernelu neobsahoval. Naopak existovala/existuje na githubu open-source knihovna pro Javu, která s využitím tuším libusb obsluhuje USB UARTy několika značek. Původně třeba dvou, ale na Githubu projekt dosáhl už v té době několika forků, z nichž ty poslední podporovaly už asi 5 výrobců. Momentálně mi Google ukázal zřejmě "mateční rostlinu", které se evidentně dobře daří a má na okraji repa zmíněno 1600 forků...
= potřebujete v Javě naLinuxuAndroidu sáhnout na USB port? Zkompilujte si ze zdrojáků knihovničku, která ty čipy bude obsluhovat z user space... Sodoma a Gomorra. Naštěstí tyhle USB UARTy mívají docela dlouhé FIFO.
Sériový port má nějaké konfigurovatelné vlastnosti navíc, které TCP spojení postrádá.
Konfiguraci sériového portu je obvykle možno zařídit nějak "out of band", anebo taky in-band.
Jednak existuje RFC-2217, které káže několik dodatečných Telnet Options = v kontextu mechanismu escape sekvencí protokolu Telnet přidává pár kódů speciálně pro konfiguraci sériového portu (baud rate, formát znaku).
Kromě toho se někteří výrobci "terminálových miniserverů" uchylují k proprietární enkapsulaci transportu sériové komunikace nad TCP/IP - kde mají toto ovládání také pořešeno. Klientem je v tom případě obvykle proprietary "virtual COM port driver" do Windows (a k němu doprovodná konfigurační utilita).
Transport sériových dat nad TCP/IP není úplně transparentní v rovině časování. Pokud používáte virtuální sériák pod Windows a snažíte se, aby aplikace nepoznala, že nemá fyzický lokální COM port, může Vaše partyzánská činnost narazit na principielní vlastnost, že paketizace způsobuje nerovnoměrné rozestupy mezi znaky přijímanými v čase a prodloužení transportních latencí. Ovladač virtuálního COMu se obvykle nesnaží ve směru "příjem" reprodukovat rovnoměrné časování okamžiku příchodu jednotlivých znaků. Prostě přijme TCP paket a payload obsahující kdoví kolik znaků předá jedním vrzem čekající funkci recv() nebo read() nebo jak se to v klientském OS jmenuje. Pravidla pro paketizaci ze sériové linky do TCP mívají terminálové servery do jisté míry konfigurovatelná: po jak dlouhé pauze od posledního znaku ukrojit a odeslat paket, resp. po kolika znacích/bajtech (maximem je zřejmě MTU nebo MSS nebo jak se tomu).
Skrz generickou paketizaci nemusí projít nastojato některé protokoly, které nad fyzickou sériovou linkou dbají na striktní časování. Třeba Modbus/RTU má prohlásit "konec rámce" po ekvivalentu 3.5 znaku od posledního přijatého znaku. Takovéhle protokoly mívají bratříčka, který s TCP enkapsulací nativně počítá - a potřebujete "o něco chytřejší" gateway, která mezi oběma enkapsulacemi bude provádět relay v souladu s normou pro daný protokol. Třeba Modbus/RTU vs. Modbus/TCP, IEC-101 vs. IEC-104 apod.
Inteligentní relay konkrétních fieldbusů tradiční terminálové servery neuměly - ale už dávno existují varianty firmwaru, které takové věci umí buď jako svou pevnou náplň práce, nebo jako konfiguračně volitelnou vlastnost...
Pokud potřebujete od "terminálového serveru" obecně "něco svého", řešíte spíš možnost, dopsat si do takové krabičky svůj vlastní software. Tzn. ke krabičce přistupujete spíš jako k obecnému počítači, ve kterém uvítáte otevřený Linux (nebo tak něco) do kterého si dopíšete co je potřeba. Někteří výrobci tomuto využití jdou naproti (tradičně Lantronix, zřejmě taky ATOP a u některých modelů Advantech), u ostatních nevím.
Případně, pokud Vaše koncové zařízení na sériové lince má nějaký opravdu primitivní protokol, možná byste sehnal "průmyslovou krabičku se sériovým portem", která by to dokázala nějak pozřít a podat dál skrz jednoduché HTTP GUI nebo třeba MQTT apod. Třeba váha pošle řetězec zakončený konkrétním znakem, buď v pravidelném časovém intervalu, nebo v reakci na událost, nebo v opravdu krajním případě na nějakou výzvu po sériové lince... Jako že by to šlo naklikat bez programátorské práce.
Terminálové servery velké jako krabičku sirek či cigaret dělá v dnešní době spousta výrobců. Lantronix je zřejmě pradědeček, tuzemského Papoucha už tu taky někdo zmínil, osobně znám pár dalších značek (Advantech, ATOP, Moxa, Korenix, Westermo) ... prakticky kdokoli v Číně kdo má nos mezi očima to vyrábí v garáži (a jeho babička). Samozřejmě je možné to postavit zcela po svém na dnešních otevřených platformách typu RPi nebo ESP32.
Není pravda, že "většina sériových donglů na USB má RS232 výstup na elektrických úrovních TTL". Pokud Vám to tak připadá, doporučuji Vám udělat si podrobnější průzkum trhu a pořádek ve zbožíznalství :-)
Sériový port se skládá obecně ze dvou čipů: UART (= posuvný registr) a "level shifter" = analogový opakovač, budič linky. Ideové blokové schéma s polaritami signálů najdete třeba tady (disclaimer: samožer).
UART je součástka společná pro RS232/422/485. UART s level shifterem se baví na elektrických úrovních TTL. Teprve level shifter vyrábí kýžené napěťové úrovně pro RS232 nebo 422/485 (nebo třeba M-bus, ten má taky zcela svoji fyzickou vrstvu). Kolmá poznámka: budu dále abstrahovat od detailu, že pro half-duplexní varianty sériové linky (RS485 a snad i M-bus) je vhodné mít z UARTu vyvedený signál TSRE aka TEMT, což třeba klasický TI 16C550A UART nemá.
Konkrétně RS232 má platné logické úrovně 3 až 15 Voltů od společné referenční země, bipolárně plus a mínus. Samotná zem (nula voltů) je zakázaný stav, zavřený ve Schmittově hysterzi. Existuje mnoho level shifterů, které si "divné" napěťové hladiny pro RS232 vyrábí z jediné vstupní napájecí větve (3.3V nebo 5V) on-chip RC nábojovou pumpou, a na výstupech pak vidíte třeba něco jako +/-6 nebo +/- 10 V. Nebo třeba jenom +/- 5V u některých USB donglů. Ale nenechte se zmást, těch "asi 5 Voltů" bývá bipolárně kolem nuly. Taky si všimněte, že polarita logických úrovní je na RS232 lince opačná (invertovaná), oproti interní TTL komunikaci mezi UARTem a level shifterem. Pokud tedy narazíte na dongle, který produkuje TTL (cca 5V / 0V), tzn. nedává zápornou úroveň, a přitom používá "polaritu jako RS232", tak se jedná o paskvil / zmetek / čínskou inovaci - osobně takových mnoho nevídám.
Ano, jsou k nalezení levné USB/serial dongly s výstupními úrovněmi TTL - protože postrádají level shifter. Třeba známá firma FTDI takové varianty nabízí, vedle bratříčků s level shifterem pro RS232 nebo RS485. Dongle bez level shifteru je v tomto případě řádně označen. Bavíte se v tomto případě navenek přímo s UARTem.
K čemu to?
Mnoho malých krabiček (levné routery) mají vyvedenu sériovou konzolu právě na úrovních TTL rovnou z UARTu. Proč: protože použitý SoC/CPU/MCU obsahuje UART nebo dva on chip, a servisní konzola je typickým účelem takové sériové linky. Ovšem ta linka zůstává za normálních okolností schovaná pod kapotou, a použije ji jenom znalý servisák, pokud za vzácných okolností není zbytí - možná ji použije fabrika pro upload firmwaru (pokud toto nemají ošetřeno jinak, třeba přes JTAG nebo SPI). Jedná se o využití na kratičkou vzdálenost, v kontrolovaných laboratorních podmínkách. Poškození "divočejším počasím" nebo nešikovností uživatele až tolik nehrozí. Pro tyto potřeby je škoda utratit dolar nebo dva navíc za level shifter.
USB/serial dongly jsou založeny na čipech několika populárních výrobců: FTDI, Prolific, Silicon Labs, WinChipHead, Moschip, teoreticky taky Exar něco má, možná někdo další by se našel...
USB/serial nemá svou vlastní třídu USB zařízení. Asi nejblíž je CDC-ACM, což je ale třída specificky pro USB modemy. Možná proto výrobci USB/UART čipů CDC-ACM obecně ignorují a používají každý své rozhraní na USB. Proto taky do Windows potřebujete pro USB/serial dongly vždy specifický driver od výrobce UART čipu - protože Windows neobsahují class-based driver, protože neexistuje jednotná třída rozhraní.
Kupodivu Linux obsahuje ovladač usbserial.ko. Tento ovladač sdružuje HW-specifické open-source drivery pro větší počet výrobců čipů :-) Je možné, že tam je nějaká synergie (sdílení kódu) v transportu dat mezi TTY subsystémem a USB endpointem... navenek se to chová úplně jako class-based ovladač :-) Prostě v Linuxu drivery pro USB/serial dongly naprosto neřešíte. Píchnete do počítače anonymní dongle co jste našli válet zaprášený v racku, a ejhle, kernel našel /dev/ttyUSB0, minicom funguje...
No a pokud se týče Androidu: ten má přece uvnitř linuxový kernel, žeano. Takže by snad měl automaticky obsahovat ovladače pro USB UARTy výše zmíněných "obvyklých podezřelých" výrobců...
Omyl vážení! Pardon - tahle zkušenost je už třeba 5 let stará, doufám že nekecám. Osobně do mobilních OS nefušuju - ale bavil jsem se chvíli s hobbíkem, který si pro Android programoval nějakou odposlechovou appku se sériovou komunikací. Android rozhodně vanilkový usbserial driver v kernelu neobsahoval. Naopak existovala/existuje na githubu open-source knihovna pro Javu, která s využitím tuším libusb obsluhuje USB UARTy několika značek. Původně třeba dvou, ale na Githubu projekt dosáhl už v té době několika forků, z nichž ty poslední podporovaly už asi 5 výrobců. Momentálně mi Google ukázal zřejmě "mateční rostlinu", které se evidentně dobře daří a má na okraji repa zmíněno 1600 forků...
= potřebujete v Javě na
10
Server / Re:Hardwarový RAID nebo ZFS?
« kdy: 21. 05. 2025, 07:50:42 »
To vypadá, že by se mohlo jednat skutečně o MegaRAID.
Našel jsem návod na cross-flash IT firmwaru pro celou rodinu a k tomu vlákno na fóru, které obsahuje zajímavé komentáře na okraj, "když se nedaří" apod. Jenom jsem letmo líznul první asi dvě strany, a byl tam tip např. po/při cross-flashi odpojit baterku, jinak zůstanou v cache stará data RAIDového firmwaru což při bootu mate IT firmware...
Našel jsem návod na cross-flash IT firmwaru pro celou rodinu a k tomu vlákno na fóru, které obsahuje zajímavé komentáře na okraj, "když se nedaří" apod. Jenom jsem letmo líznul první asi dvě strany, a byl tam tip např. po/při cross-flashi odpojit baterku, jinak zůstanou v cache stará data RAIDového firmwaru což při bootu mate IT firmware...
11
Server / Re:Geograficky redundantní NAS
« kdy: 15. 05. 2025, 10:55:36 »Neriešil by Váš problém lsyncd alebo glusterfs?
Přimlouvám se za keep it simple. Třeba rsync v cronu udělá taky spoustu práce, ale lsyncd je o krok dál. Glusterfs by tomu dal křídla, jenom už to souvrství začíná být maličko složitější :-)
Nezapomeň, že tohle děláš, abys zvýšil spolehlivost, jakákoliv komplexnost ti naopak tu spolehlivost zase posouvá dolů. Testovat stabilitu musíš v nejhorším scénáři a ne v tom nejlepším a pak tvrdit, že synology je vlastně super, není. Oni i ty enterprise systémy trvá dlouho vyladit a náklady na pravidelné testy jdou také do dost vysokých čísel. Někdy je prostě lepší se znovu snést na zem.
Taky mám radši věci, do kterých je vidět dovnitř. Snáz se v tom dá vyznat v případě nějakého katastrofického kolapsu (disaster recovery). Věci automagické, složité a uzavřené jsou mi spíše z principu podezřelé :-(
Jakýkoli systém na bázi geografického clusteru, kde se na každé lokalitě do té věci konkurenčně zapisuje, smrdí problémem pokud nastane split-brain. Jak se z něho vrátit do spojitého stavu. Principielně je potřeba se snažit, aby lokality nemusely "sdílet stav s právem zápisu". Každá lokalita ať si zapisuje do svého lokálního písečku, a na jiné lokality se jenom "letmo zálohuje" s možností "lokálního read-only přístupu k datům vzniklým v jiné lokalitě". Na jaké vrstvě se povedou hranice mezi "parcelami lokalit" je vcelku na uvážení integrátora. Může se jednat o oddělené foldery ve filesystémech, nebo o atribut "location of origin" v SQL databázi (nebo mě napadá, přidělit každé lokalitě její vlastní řadu generovaných unikátních klíčů v rámci sdíleného sloupce, ale to je moje lidová tvořivost :-) Což samozřejmě komplikuje vývoj aplikace, pokud má být "jenom jedna, společná, homogenní napříč lokalitami", datový model má hodně entit apod.
Hmm šimrá mě správně v šedé hmotě keyword Mumps ?
Tuším jsem taky zaslechl termín "eventual consistency", jako že "časem se to rozkopíruje a začne to v globále dávat smysl". Vývojově to tuším pochází z modernější doby, no-SQL v masivních cloudových systémech, microservices apod., než klasické poučky o distribuovaných systémech z minulého století...
Distribuovaný systém se simultánním RW provozem bez explicitního rozparcelování lokalit lze postavit, ale pak řešíte vzájemnou synchronizaci, zamykání, konkrétně two-phase commit (2PC) a podobné radosti, což je právě závislé na přenosových latencích (jak už psali ostatní). Co máte v rámci jednoho stroje (hypervizoru) v desítkách nanosekund, na LANce je v řádu desítek mikrosekund, napříč městem či krajinou jdou další řády nahoru... Čím větší ethernetový switch nebo router, tím větší hrubá průchodnost, ale obecně taky store-and-forward latence jdou nahoru... a pak je problémem potenciální split-brain. Jak se při něm chovat (zastavit provoz? zastavit zápisy?) a jak se případně zotavit, pokud provoz nezastavíte... mít jednu "centrální" lokalitu, jejíž "spojitý přeživší shluk" může zapisovat dál, a kdo se odpojí od centrálního shluku, smí lokálně pouze číst?
12
Hardware / Re:Nový notebook hučí jako vysavač
« kdy: 08. 05. 2025, 20:07:58 »
On sensors-detect (a zřejmě i drivery v kernelu) obecně ignorujou noťasové čipy EC (což je vlastně SuperIO obohacené o MCU jádro, typicky 80C51 nebo malý ARM) protože v nich běhá proprietární firmware, který může dělat ledacos. Přitom tihle EC švábi mívají podobný health monitoring subsystém, jako klasický SuperIO šváb bez MCU. SuperIO bez MCU jsou ovšem běžné spíš na desktopových a serverových motherboardech.
Kromě toho sensors-detect je skript z původních lm_sensors, a nedivil bych se, pokud maličko zatuchnul (poté co se drivery z projektu lm_sensors přestěhovaly do upstreamu na kernel.org. Takže třeba nemusí znát IDčka novějších čipů, které v driverech v kernelu de facto mohou mít podporu...
Třetí relevantní kousek softwaru je superiotool (původně z projektu coreboot). Ani on nezná nejnovější výdobytky a zřejmě moc neřeší EC (kvůli proprietárnímu FW, na noťasy podle mého coreboot tak snadno nacpat nejde). Zná ale jednotná "multiplexní vrátka ke konfiguračním registrům" a jejich odemykací sekvence u několika běžných výrobců SuperIO, a když mu dáte parametr -V, tak Vám i řekne, že tam nějakého švába našel, ale nezná jeho chip ID, takže ho ignoroval. No ale když víte vendora a chip ID, tak se dá ještě pohledat, jestli by se na to nechytil některý driver v kernelu. Bohužel tyhle HWMON drivery pro SuperIO šváby nepodléhají PnP. Asi protože nejsou na žádné PnP sběrnici. A nikoho kolem kernelu to netrápí natolik, aby tahle SuperIO konfigurační vrátka do nějakého PnP zapřáhnul.
Popravdě je to ještě trochu složitější... jedna multiplexní vrátka má SuperIO šváb pro svou vlastní konfiguraci (Configuration Registers, zkratka CR) - po těch jde superiotool. Jiná, svoje vlastní multiplexní vrátka (na jiné IO adrese) má samotný health monitor - po těch jde sensors-detect (kromě toho, že hledá na I2C, protože tam jsou health monitory tradičně taky vidět).
A ještě další multiplexní vrátka (i několikery) mívají EC švábi pro své další funkce. Ne všechny vnitřní periferní registry EC švába jsou přístupné z hostitelského CPU, a možná ne všechny (ale velká většina) jsou dostupné z interního MCU jádra EC. Některé registry mohou fungovat jako dual-ported "mailbox" pro komunikaci mezi EC MCU a hostitelským CPU = jejich význam pro hostitelský CPU je definován firmwarem EC MCU... Takže proprietární firmware na zapečeném MCU jádře, a pro jistotu datasheety pod NDA.
BTW že se ten ventilátor umoudřil je poměrně záhada :-) Možná se EC "učí" :-) Nebo se nově nainstalované Bubuntu potřebovalo zabydlet, postahovat aktualizace apod - a reálně Vám dneska žere míň procesoru než včera :-) Hypotézu že došlo k automatické aktualizaci BIOSu zamítám - tohle občas dělá aktualizátor výrobce pod Windows (nebo snad i Windows Update), ale pochybuju, že by Ubuntu konkrétně toto nějak řešilo.
Kromě toho sensors-detect je skript z původních lm_sensors, a nedivil bych se, pokud maličko zatuchnul (poté co se drivery z projektu lm_sensors přestěhovaly do upstreamu na kernel.org. Takže třeba nemusí znát IDčka novějších čipů, které v driverech v kernelu de facto mohou mít podporu...
Třetí relevantní kousek softwaru je superiotool (původně z projektu coreboot). Ani on nezná nejnovější výdobytky a zřejmě moc neřeší EC (kvůli proprietárnímu FW, na noťasy podle mého coreboot tak snadno nacpat nejde). Zná ale jednotná "multiplexní vrátka ke konfiguračním registrům" a jejich odemykací sekvence u několika běžných výrobců SuperIO, a když mu dáte parametr -V, tak Vám i řekne, že tam nějakého švába našel, ale nezná jeho chip ID, takže ho ignoroval. No ale když víte vendora a chip ID, tak se dá ještě pohledat, jestli by se na to nechytil některý driver v kernelu. Bohužel tyhle HWMON drivery pro SuperIO šváby nepodléhají PnP. Asi protože nejsou na žádné PnP sběrnici. A nikoho kolem kernelu to netrápí natolik, aby tahle SuperIO konfigurační vrátka do nějakého PnP zapřáhnul.
Popravdě je to ještě trochu složitější... jedna multiplexní vrátka má SuperIO šváb pro svou vlastní konfiguraci (Configuration Registers, zkratka CR) - po těch jde superiotool. Jiná, svoje vlastní multiplexní vrátka (na jiné IO adrese) má samotný health monitor - po těch jde sensors-detect (kromě toho, že hledá na I2C, protože tam jsou health monitory tradičně taky vidět).
A ještě další multiplexní vrátka (i několikery) mívají EC švábi pro své další funkce. Ne všechny vnitřní periferní registry EC švába jsou přístupné z hostitelského CPU, a možná ne všechny (ale velká většina) jsou dostupné z interního MCU jádra EC. Některé registry mohou fungovat jako dual-ported "mailbox" pro komunikaci mezi EC MCU a hostitelským CPU = jejich význam pro hostitelský CPU je definován firmwarem EC MCU... Takže proprietární firmware na zapečeném MCU jádře, a pro jistotu datasheety pod NDA.
BTW že se ten ventilátor umoudřil je poměrně záhada :-) Možná se EC "učí" :-) Nebo se nově nainstalované Bubuntu potřebovalo zabydlet, postahovat aktualizace apod - a reálně Vám dneska žere míň procesoru než včera :-) Hypotézu že došlo k automatické aktualizaci BIOSu zamítám - tohle občas dělá aktualizátor výrobce pod Windows (nebo snad i Windows Update), ale pochybuju, že by Ubuntu konkrétně toto nějak řešilo.
13
Hardware / Re:Nový notebook hučí jako vysavač
« kdy: 08. 05. 2025, 17:51:53 »Jeste chatgtp
...
v tomto prípade zrejme ide o procesor z rady Ryzen 7000 (alebo 8000) s hybridnou architektúrou (kombinácia výkonných a úsporných jadier)
AMD má big.LITTLE ? A odkdy? Právěže tuhle ... vymoženost má konkrétně Intel :-)
Aha... AMD s tím vystrčilo tykadla ve dvou modelech z rodiny "Phoenix 7040 series" (Zen4).
https://en.wikipedia.org/wiki/List_of_AMD_mobile_processors#Phoenix_(7040_series,_Zen4/RDNA3_based)
Ale zmíněný noťas ThinkBook 16 G7 ARP má mít některý z procesorů 7035 series (Zen3+), které mají všechna jádra rovnocenná.
Citace
Linux na takomto hardvéri ešte často nemá doladenú podporu, hlavne ak používate novšie jadro a úplne čerstvé Ubuntu 24.04.Toto tvrzení nemá hlavu ani patu. Pro nový hardware právě obvykle potřebujete čerstvé distro a kernel.
Ubuntu 24.04 není čerstvé. Právěže bohužel už je nejmíň rok staré. Proto má smysl, zkusit novější - pokud máte čerstvý hardware.
Citace
* *SATA/ACPI Settings* – ponechať na "AHCI" alebo zapnuté ACPI, podľa možností.hodinky a holínky... nesmyslná žvatlanice.
Citace
#### `amd-pstate` (nový ovládač správcu výkonu pre AMD):Ano, na tom se shodneme...
1. Overte, či používate `amd-pstate` namiesto starého `acpi-cpufreq`:
```bash
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
```
...
Citace
sudo sensors-detect
Toto chválím, je to směrem k jádru podla... akorát to nejspíš na notebooku nenajde žádný podporovaný čip :-(
Citace
### **Ak nič nepomôže – skúste staršiu verziu Ubuntu alebo iné distro**Starší? Asi ne...
Jinak... nevím jak moderní UEFI firmwary, ale klasický BIOS běžel na jediném CPU jádře a vytěžoval ho na 100%, protože nepoužíval HLT/MWAIT když neměl co dělat. Takže ano, v BIOSu může procesor žrát víc, než v naběhnutém střídmém plnohodnotném OS, který správně používá C-stavy.
14
Hardware / Re:Nový notebook hučí jako vysavač
« kdy: 08. 05. 2025, 07:58:32 »
Jo a to zadrhávání audia v úsporném režimu může být projevem povolení C-states (idle states) na max.
Že je to v kombinaci s procesorem na co nejnižších hodinách je druhá věc :-)
Osobně jsem C-states zatím řešil jenom na intelu, kde nejhlubší C-state je něco jako C7 nebo C9. Přitom vhodný kompromis z hlediska latencí je povolit nehlubší C1 nebo C1e. A pokud C-stavy úplně zakážete (resp. ponecháte povolený jenom C0 = "běžím furt, neklimbám u toho") tak možná oproti C1 naměříte mírné zkrácení latencí odezvy systému.
Čtu zmínky, že procesory AMD mají C-stavy pouze 0, 1 a 2 (a neznám jejich chování = latence).
Pro procesory AMD lze C-stavy ovládat pomocí driveru acpi_idle .
Procento času CPU strávené v C-stavech ukazuje powertop. Seznam podporovaných C-stavů ukáže taky cpupower idle-info.
Nastavit nejhlubší povolený C-stav na C1 na procesoru AMD lze údajně příkazem na kernel command line (= v bootloaderu):
processor.max_cstate=0
Ano čtete správně, nastavením =0 povolíte C-stav C1 :-)
https://lenovopress.lenovo.com/lp1945-using-processor-idle-c-states-with-linux-on-thinksystem-servers
https://support.lenovo.com/cz/en/solutions/tt1668-linux-and-c-state-settings-on-amd-thinksystem-servers-lenovo-thinksystem
Že je to v kombinaci s procesorem na co nejnižších hodinách je druhá věc :-)
Osobně jsem C-states zatím řešil jenom na intelu, kde nejhlubší C-state je něco jako C7 nebo C9. Přitom vhodný kompromis z hlediska latencí je povolit nehlubší C1 nebo C1e. A pokud C-stavy úplně zakážete (resp. ponecháte povolený jenom C0 = "běžím furt, neklimbám u toho") tak možná oproti C1 naměříte mírné zkrácení latencí odezvy systému.
Čtu zmínky, že procesory AMD mají C-stavy pouze 0, 1 a 2 (a neznám jejich chování = latence).
Pro procesory AMD lze C-stavy ovládat pomocí driveru acpi_idle .
Procento času CPU strávené v C-stavech ukazuje powertop. Seznam podporovaných C-stavů ukáže taky cpupower idle-info.
Nastavit nejhlubší povolený C-stav na C1 na procesoru AMD lze údajně příkazem na kernel command line (= v bootloaderu):
processor.max_cstate=0
Ano čtete správně, nastavením =0 povolíte C-stav C1 :-)
https://lenovopress.lenovo.com/lp1945-using-processor-idle-c-states-with-linux-on-thinksystem-servers
https://support.lenovo.com/cz/en/solutions/tt1668-linux-and-c-state-settings-on-amd-thinksystem-servers-lenovo-thinksystem
15
Hardware / Re:Nový notebook hučí jako vysavač
« kdy: 08. 05. 2025, 07:19:57 »
Myslím si správně, že to má AMD (Ryzen) ?
Dotazy v technické rovině, pokud to ještě chcete zkoumat:
- pod widlema se to chová líp?
- nastavení "výkonnostního režimu" provádíte kde/jak? V BIOSu? V Linuxu? V linuxu čím?
- jakým ovladačem v Linuxu řídíte spotřebu? acpi_cpufreq, nebo amd_pstate?
Zmiňujete Ubuntu 24.04 LTS s kernelem 6.11. Chvályhodná konzervativní volba.
Nicméně Váš problém trochu zavání kompatibilitou OS nebo kernelu s hardwarem nebo s BIOSem.
Doporučil bych zkusit něco víc bleeding edge, např. 25.04 s kernelem 6.14.
A není řečeno předem, zda bude správně ovladač ACPI nebo amd_pstate.
Pokud je na tom noťasu co konfigurovat ohledně performance režimů v BIOSu, můžete zkusit nakombinovat různé varianty nastavení v BIOSu vs. v OS (v Linuxu). Např. amd_pstate odhadem bude fidlat s frekvencemi (napájecí napětí CPU jader je dnes ovládáno spíš nepřímo v režii samotného CPU) ale otáčky ventilátoru pojedou patrně nějak autonomně podle teploty, měřené kdoví kde. Na notebooku se do toho pravděpodobně bude míchat nějaká regulační smyčka implementovaná v Embedded Controlleru. Je otázkou, zda do této smyčky zasahuje BIOS pokud řídíte P-stavy skrz ACPI, vs. jak se to bude chovat při přímém štelování procesoru (amd_pstate). Neznám bohužel podrobnosti, na co všechno sahá amd_pstate.
Obecně bych za ideální považoval uspořádání, které vídám na "desktopovějších" motherboardech, kde otáčky ventilátorů
řídí hardware SuperIO švába, a na boardu není EC s neprůhledným firmwarem. Obecně máte na výběr ze dvou variant:
A) v BIOSu nastavíte režim řízení otáček ventilátorů = v SuperIO health monitoru se nastaví pár parametrů jak se má chovat regulační křivka, SuperIO šváb jakýmsi komunikačním kanálkem dostává informaci z čidla na procesoru (coretemp/k10_temp), a ventilátor nějakým způsobem reaguje na rostoucí teplotu zvyšováním otáček.
B) v Linuxu najdete driver pro SuperIO švába, a převezmete řízení PWM. SuperIO švábi ve svém hardwaru toto obvykle umožňují, a ovladače v Linuxu pro to mají také podporu. Dá se to otestovat ručně zásahem do rozhraní hw monitoru v sysfs, následně na to navázat servosmyčku patrně pomocí službičky "fancontrol".
Každopádně amd_pstate by se měl starat hlavně o procesor. Otáčky ventilátoru mu můžou být ukradené / "to řeší někdo jiný" (hardware SuperIO/EC nebo fancontrol).
Dotazy v technické rovině, pokud to ještě chcete zkoumat:
- pod widlema se to chová líp?
- nastavení "výkonnostního režimu" provádíte kde/jak? V BIOSu? V Linuxu? V linuxu čím?
- jakým ovladačem v Linuxu řídíte spotřebu? acpi_cpufreq, nebo amd_pstate?
Zmiňujete Ubuntu 24.04 LTS s kernelem 6.11. Chvályhodná konzervativní volba.
Nicméně Váš problém trochu zavání kompatibilitou OS nebo kernelu s hardwarem nebo s BIOSem.
Doporučil bych zkusit něco víc bleeding edge, např. 25.04 s kernelem 6.14.
A není řečeno předem, zda bude správně ovladač ACPI nebo amd_pstate.
Pokud je na tom noťasu co konfigurovat ohledně performance režimů v BIOSu, můžete zkusit nakombinovat různé varianty nastavení v BIOSu vs. v OS (v Linuxu). Např. amd_pstate odhadem bude fidlat s frekvencemi (napájecí napětí CPU jader je dnes ovládáno spíš nepřímo v režii samotného CPU) ale otáčky ventilátoru pojedou patrně nějak autonomně podle teploty, měřené kdoví kde. Na notebooku se do toho pravděpodobně bude míchat nějaká regulační smyčka implementovaná v Embedded Controlleru. Je otázkou, zda do této smyčky zasahuje BIOS pokud řídíte P-stavy skrz ACPI, vs. jak se to bude chovat při přímém štelování procesoru (amd_pstate). Neznám bohužel podrobnosti, na co všechno sahá amd_pstate.
Obecně bych za ideální považoval uspořádání, které vídám na "desktopovějších" motherboardech, kde otáčky ventilátorů
řídí hardware SuperIO švába, a na boardu není EC s neprůhledným firmwarem. Obecně máte na výběr ze dvou variant:
A) v BIOSu nastavíte režim řízení otáček ventilátorů = v SuperIO health monitoru se nastaví pár parametrů jak se má chovat regulační křivka, SuperIO šváb jakýmsi komunikačním kanálkem dostává informaci z čidla na procesoru (coretemp/k10_temp), a ventilátor nějakým způsobem reaguje na rostoucí teplotu zvyšováním otáček.
B) v Linuxu najdete driver pro SuperIO švába, a převezmete řízení PWM. SuperIO švábi ve svém hardwaru toto obvykle umožňují, a ovladače v Linuxu pro to mají také podporu. Dá se to otestovat ručně zásahem do rozhraní hw monitoru v sysfs, následně na to navázat servosmyčku patrně pomocí službičky "fancontrol".
Každopádně amd_pstate by se měl starat hlavně o procesor. Otáčky ventilátoru mu můžou být ukradené / "to řeší někdo jiný" (hardware SuperIO/EC nebo fancontrol).
