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] 2 3 ... 106
1
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ě na LinuxuAndroidu 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.

2
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...

3
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?

4
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.

5
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):

1. Overte, či používate `amd-pstate` namiesto starého `acpi-cpufreq`:

```bash
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
```
...
Ano, na tom se shodneme...

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.

6
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

7
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).

8
Sítě / Re:Jak na upgrade domácí Wi-Fi
« kdy: 07. 05. 2025, 09:04:42 »
Děkuji za zpětnou vazbu a držím palce, ať to jede.

Do záznamu třeba pro ostatní ohledně Inssideru: pro Linux existuje něco podobného, jmenuje se to LinSSID, a protože to usnulo v roce 2018, jsou už mezitím nějaké forky na Githubu...
https://sourceforge.net/projects/linssid/files/
https://github.com/chunmeng/linssid-ex
https://github.com/jm2/linssid-ex


9
Sítě / Re:Jak na upgrade domácí Wi-Fi
« kdy: 06. 05. 2025, 19:06:28 »
V nějakém kvoku na Redditu jsem postřehl zmínku, že "only the enterprise Pico 4 supports WiFi 6E, not the consumer version. " Je řeč o podpoře pro 6GHz pásmo = takový je pravý význam zkratky 6E.

Takže se asi držte aspoň 5 GHz. Je fajn že to pásmo máte pro sebe.

Takže výpadek nastává při retrainu? V tom případě máte kliku že máte Mikrotik, protože si můžete omezit množinu povolených HT rychlostí - doporučuji zakázat ty nejrychlejší (největší hloubka modulace, nejvyšší nároky na odstup signál/šum). Snižujte rychlost, dokud APčko vůči headsetu nepřestane retrainovat.

A ještě jedna věc:

Rx Signal RSSI je -38 až -45 mezi MikroTikem a Headsetem

Je to taková rada ze záhrobí... zažil jsem situaci, před mnoha lety, kde mikrotik s rádiem Atheros na 802.11n měl problémy udržet stabilní kanál, když jsem použil od oka hodně směrové antény na zřejmě dost krátkou vzdálenost... měl jsem RSSI kolem -40 dB. Jednalo se o point-to-point spoj, dva mikrotiky proti sobě. Když jsem ubral vysílaný výkon, takže RSSI kleslo někam k -55 dB, spoj se jako zázrakem stabilizoval. Druhá věc, která zlepšovala stabilitu, bylo vykašlat se na 802.11n a slézt na 802.11a :-( což by Vám nejspíš kapacitně už nevyhovělo (54 Mbps modulační rychlost).

Jinak bezdrátové klávesnice a myši jedou buď modrozub (v pásmu 2.4 GHz, a tuším se s WiFi snaží nějak ohleduplně navzájem vyhýbat) nebo proprietární rádiový protokol, který se s wifinou v pásmu 2.4 GHz na férovku ruší. Toto je případ těch miniaturních donglů/základnových rádií do USB, které se vůči počítači tváří jako HID device. Tzn. o důvod víc, jet kritický provoz na 5 GHz.

10
Sítě / Re:Jak na upgrade domácí Wi-Fi
« kdy: 06. 05. 2025, 12:02:48 »
Wifi éter v okolí vypadá jak? Kolik je tam rušení? MetaGeek Inssider v2 byl docela dobrý SW skener zadarmo pro Windows...

Pokud by nebylo rušení od sousedů, a chcete co nejkratší odezvy pro VR headset, přimlouval bych se, pořídit pro VR zvlášť APčko, dát mu dedicated frekvenční kanál a samozřejmě ESSID. Vybodněte se na 2.4 GHz, na 5 GHz je lepší šance na "relativní ticho v éteru", protože to hůř prolézá zdmi (a kanálů je k dispozici větší počet). A je otázka, jak pro tyhle potřeby přistupovat k šířce frekvenčního kanálu. Kapacitu lze nahnat buď odstupem signál/šum uvnitř kanálu, nebo šířkou kanálu. Opět: zkuste se rozhlédnout v éteru...

Mimochodem, pokud WiFi7, umí ten headest i pásmo 6 GHz? Přiznám se, že jsem nezkoumal, jak je to s úrovní rušení v legální spodní půlce 6GHz pásma v dnešním obytném prostředí...

11
(Co přidřenej větrák? Kdyby EC hlídal otáčky, a zjistil zaseklej větrák, že by preventivně přiškrtil CPU...)

12
Ještě bych dodal, že kromě hardwarového signálu PROCHOT EXT může být škrcení zařízeno jistě i "čistě softwarově". Intel hardware to umí pomocí IA32_CLOCK_MODULATION MSR, předpokládám že AMD má něco podobného. A v tom případě by to mohl dělat BIOS, např. s využitím SMI. A pokud řízení "performance" v Linuxu je řízeno obecným ovladačem ACPI (nikoli HW-specifickým amd_pstate) tak může mít Lenovo nějaké svoje chytré věci i pod kapotou té ACPI codepath.

Pokud se týče měření teploty - pokud je původ údaje dohledatelný k on-die čidlu CPU, tak se tomu dá docela věřit. (coretemp / k10temp)

13
Zaměřte se na klíčové slovo PROCHOT (Intel: BD PROCHOT, AMD: PROCHOT EXT) = signál, který má prsty v nouzovém škrcení výkonu CPU. Např. utilitu turbostat znám jenom z Intelu - co Vám ukáže na AMD? Zná tyhle AMD-specific věci? Nebo nekvákne něco takového RyzenADJ ?

Signál PROCHOT je generován jednak interně, když se přehřívá procesor - druhak ale může být generován taky externě, motherboardem, z jakýchkoli příčin, mezi těmi legitimními klasicky např. při nějakém problému s napájením (baterka, externí adaptér, třeba zlomené komunikační linky v jeho kabelu) nebo obecně v důsledku designových bugů (HW na motherboardu, firmware EC). U Intelu existovaly historicky v některých modelech CPU bugy, kdy procesor škrtil i v nepřítomnosti nominálního PROCHOT signálu... neznám tyhle zákulisní historky u AMD.

Každopádně především hledejte příznak PROCHOT - bohužel jeho přítomnost neznamená, že se přehřívá procesor, možnosti jsou širší, a nemusí mít máslo na hlavě AMD, ale klidně Lenovo.

14
Sítě / Re:LTE - Internet v odlehlé končině
« kdy: 01. 05. 2025, 18:06:13 »
LTE pásma jsou plná, a postupně ubývají transpondéry ve prospěch 5G (NR). Tvrdí mi lidi, že jim v krajině vysloveně "mizí vysílací věže". Nemohu bohužel ve všech případech říct, že je dotyčný schopen odfiltrovat případy, kdy BTSka surově odmítá účastníky v bandu 20 (800 MHz) a odkazuje na nějaké nechytatelné vyšší pásmo. (Bezelstný uživatel to pak vnímá jako "horší signál, zmizela věž".)

V krajině ve smyslu nejlepšího dosahu dává smysl pásmo 800 MHz (které taky relativně dobře proleze koaxem na pár metrů) ale přesně tohle pásmo bývá brutálně přetížené na počet účastníků. Protože to je jediná věc, co tam kolem funguje :-( Vyšší pásma jsou hlavně ve městě, neprojdou skrz les, neohnou se přes kopec...

V pásmu 700 MHz se začíná slušně rozjíždět 5G - ale taky je v něm už poměrně plno, protože se podpora posunuje v matlafounech do postupně nižších cenových hladin.

Teltonika obecně palec nahoru za to, že podporuje omezení podporovaných pásem. A že uvnitř používá moduly Quectel, aspoň to platilo svého času. Podobně jako Conel/Advantech - taky vynikající otevřený firmware, taky Quectel, bohužel cenovka je "průmyslová", není to úplně na takové to domácí žvýkání. Modemy Quectel znám holýma rukama v USB redukci s použitím AT příkazů - dá se proskenovat pásmo a nechat si vypsat viditelné BTSky i se sílou signálu... (což bohužel na hotových routerech prakticky nemáte šanci)

Správně píšete, že levné modemy a routery umí pouze LTE/4G. Zatímco v telefonech 5G začíná být i v modelech pro normální lidi, 5G modemy do počítačů a routerů jsou pořád ještě s krutou vysokohorskou přirážkou. Nejlevnější jsem viděl kolem 4-5 kKč bez DPH (u součástkových distributorů) ale modemy vyšší než low-endové jsou spíš v rozpětí mezi 5-10 (i výš) za samotný modem. Tak se potom divte, že kompletní 5G router od Teltoniky stojí na krámě 12 nebo víc kKč vč. DPH.
Mimochodem zatímco několik předchozích generací WWAN modemů mělo původně RS232 a pak USB 2.0, 5G modemy už mají USB 3.0 nebo PCI-e (v některých případech je tuším přítomen taky lane USB 2.0 pro zpětnou kompatibilitu).
Schválně se mrkněte, co má zalistováno a případně skladem takový SOS Electronic (slovenský distributor).
Najdete pár modulů ve formátu nejspíš M.2 B-key. Koukám je tam ve výprodeji Quectel RM500 series, za ceny už pod 100 EURO bez DPH... to je Quectelova první generace, které se asi mnoho neprodalo, právě s ohledem na nesmyslnou cenu.

Jakou anténu... pro základní orientaci mám nutkání navrhnout klidně pasivní logáro pro televizní použití. Pozor, televizní antény mívají nějakou aspoň pasivní zádrž proti blízkým LTE pásmům (třeba nějaký napohled nenápadný parazitní odlaďovací prvek = laděnou tyčku). Superlevná TV anténa nebude obsahovat solidní keramický odlaďovací filtr. Třeba taková EMOS EM-2845 (bez G na konci) má tahat až k 800 MHz.

A úplně bych se nestyděl, připojit pasivní anténu k LTE/5G rádiu televizním 75-Ohmovým koaxem :-) Mimochodem takový CB113 má dost slušné VF vlastnosti za tu cenu. O dost lepší než prašivý RG174, který bývá přibalený k anténám v délce třeba 5m.  CB113 má útlum -20 dB/100m@1GHz (-30dB/100m@2GHz). RG174 má něco jako 90 dB/100m@1GHz, čert ví kolik na 2 GHz. Jistě existují správně přizpůsobené 50-Ohmové kabely, low-lossové a kvalitní... ale taky poměrně drahé. Zmíním RF240 (Belden 7808A) nebo RF400, H1000.

LTE/5G antény mají v některých pásmech *mnohem horší* nepřizpůsobení, než je přechod 50/75 Ohmů... (mnohem horší SWR). Hehe když máte anténu třeba s třímetrovým nebo pětimetrovým kabelem, a máte to štěstí, že výrobce antény v datasheetu ukázal skutečně změřený průběh SWR, tak ten delší kabel se obvykle projeví ohavným "hřebenem" napříč pásmem (což je známka nepřizpůsobení antény ke jmenovité impedanci kabelu). Měřeno přímo na napájecím portu antény to nevypadá zdaleka tak chlupatě.

Čili CB113 na 50 m by sebral třeba jenom 10 dB signálu. To není tragédie. A šla by použít "televizní" koaxiální bleskojistka, třeba Brokova SPKO-F75, pokud je na místě ochrana před bleskem.
Mimochodem koaxové konektorové redukce prakticky "všeho na všechno" vede buď v Praze Rasel (převzal sortiment dřívejšího SKT) nebo ve Varšavě TME. Třeba F na SMA by neměl být problém. Pozor neplést LTE/GSM prosté SMA vs. wifinářské reverzní SMA (kolík uvnitř má opačnou pohlavní orientaci).

Pravda taky je, že líp bude hrát rádio umístěné poblíž antény (třeba 1 metr kabelu), případně integrované v anténě.

Pokud jde o "průmyslové" vlastnosti některých routerů ve smyslu odolnosti vůči prostředí: asi se nesnažte, shánět router, který bude mít IP67. Kdyžtak mrkněte na rozsah provozních teplot - ten se může hodit. Běžných kancelářských 0-60 je do venkovního prostředí trochu slabota, ale zkusit to můžete - pokud modem zavřete do přiměřeně velké (radši trochu větší) elektro-krabice s příslušným krytím proti vodě (dešti) a nejlíp krabici ochráníte nějakou stříškou proti přímému oslunění, aby se zbytečně nehřála.
Dodělat napájení po CAT5 pro venku umístěný router s dutým jackem není velký problém... i4wifi a podobní prodávají pasivní výhybky použitelné jako splitter či injektor (levné jsou zejména ty co propustí pouze 100Mb) které nemají zabudovaný konvertor napájení. Pokud se nebojíte páječky, lze přidat externí snižující měnič na požadovaných třeba 5V (nevím kolik bere např. Teltonika).
https://dratek.cz/arduino/1738-step-down-modul-napajeni-mini-buck-nastavitelny.html
https://dratek.cz/arduino/1740-step-down-synchronni-napajeci-zdroj-dc-dc-buck-9-35v-na-5v-5a.html

Ohledně parabol... proč ne, jenom si uvědomte, že na spodním konci LTE/5G pásma (700-800 MHz) je délka vlny něco jako 30-40 cm, tak si vemte, jak velká by musela být parabola, aby se tvar jejího reflektoru nějak smysluplně projevil, když od kruhového obvodu parabolického zrcadla směrem do středu musíte odečíst asi půlvlnu, abyste získali efektivní plochu... Jako vzít starý ofsetový 90cm nebo 120cm talíř, a jako ozařovač použít "cantennu" z pozinkového kýblu... to by mohlo fungovat :-D

Když přestanu šaškovat, tak Mikrotik má ty svoje integrované jednotky zmáknuté dost dobře, a na spodním konci pásma naopak mají lepší zisk a SNR všechny aktivní zesilovače v rádiu, takže nemám strach, že by anténa byla nějak citelně horší - důležité je, aby přístroj pásma 700 a 800 MHz jmenovitě podporoval.

Pokud by byl zájem na špičkové odolnosti proti blesku, tak koupit hotový optický patchcord a dát ven do krabice k routeru ještě taky mediakonvertor na optiku (a druhý dovnitř). A napájení si pak vyřešte jak je libo. Třeba samostatným metalickým vedením, bezpečným malým stejnosměrem, který se relativně snadno ochrání proti přepětí... nebo tam dát malý solár s baterkou...

Mimochodem pro rychlý přehled "co odkud svítí" ve frekvenčním pásmu, lze použít RTL-SDR. Pásmo 700-800 MHz je rozhodně v jeho schopnostech, ohledně horního konce kolem 1800 MHz si nejsem úplně jistej :-) Před pár lety jsem si na to napsal svůj vlastní band-scanner, protože mě štval předchozí RTLSDR-Scanner. Popravdě jeho schopnosti končí někde u -120 dBmW, což je ale taky už nepoužitelný signál pro WWAN data...

15
Vývoj / Re:Jak napsat objekt N to N
« kdy: 01. 05. 2025, 16:01:57 »
Ahoj,

potřebuji napsat objekt, který se bude chovat takhle:

Mějme 2D pole objektů:
Řekněme matice 3x3 pro jednoduchost, ve skutečnosti pole 65 535 * 65 535.

Citace
A1__B1__C1
A2__B2__C2
A3__B3__C3

Objekt A může posílat jen do B, B může posílat jen do C.
Objekt A nemůže posílat do jiného A, B do jiného B, C do jiného C.
Data jdou z vrstvy do vrstvy, nikdy jinak.
...

Spíš na okraj: v jakém jazyce to chcete psát? V jakém umíte?

Obecně:

Máte-li "matici" nějakých prvků, a potřebujete držet data o každém z nich, nebo o většině z nich, může být základem "2D pole o statických rozměrech" = alokovat jedním vrzem úplné pole objektů.
Sáhnout na objekt na konkrétních souřadnicích v matici pak víceméně znamená, vynásobit číslo sloupce délkou sloupce, připočíst adresu ve sloupci, to celé třeba ještě vynásobit alokační velikostí pointeru (64b systém = 8 bajtů) a připočíst bázovou adresu celého pole. Je to poměrně jednoduchá adresní aritmetika s pevným počtem kroků na tuto operaci.

Pokud ve skutečnosti potřebujete držet data jenom o nějaké podmnožině té "matice", tzn. matice je "řídká", dává smysl kvůli úspoře RAM (popř. také místa na disku) postavit tu matici pomocí "dynamických datových struktur" z prvků jako je pointer, seznam, seznam pointerů, kombinovaná obousměrná uspořádání typu "A ukazuje na právě jeden B, ale B potřebuje držet seznam pointerů na několik A", setříděný seznam, key->value asociativní pole, strom, partial mesh s jednosměrnými nebo obousměrnými vazbami...

Třeba řídké pole X*Y by se dalo postavit jako asociativní pole vnořené do asociativního pole, a konečným prvkem by mohly být objekty (held by value) nebo pointery/reference na ně...
Nebo dva vnořené spojové seznamy :-)
Spojový seznam má tu potenciální nevýhodu, že je třeba ho procházet stylem "předchozí/následující" (sledovat pointery). Takže operace "nalézt prvek číslo 2307" je otrava. Operaci vyhledání mají naopak rychlou asociativní kontejnery (indexy) založené na binárních stromech nebo hash tabulkách.

Můžeme mluvit o pointerech v low-level smyslu = adresa v paměťovém prostoru procesoru. Vzhledem k rozměru dat a vzhledem k letopočtu ty adresy budou 64bitové. Každý pointer uložený v paměti zabere 64 bitů = 8 bajtů.

Nebo vzhledem k tomu, že máte tabulku těsně pod 4 Giga objektů, můžete se odkazovat na pořadové číslo objektu, které bude 32bitové, nebo na dvě souřadnice každou 16b, nebo pokud víte, že odkazy jsou vždy zásadně do dalšího sloupce, tak vlastně stačí "svislá souřadnice" = 16b číslo (a který sloupec je následující může být dáno implicitně)...

Mimochodem pokud tu matici uděláte 65536 x 65536, můžete v části adresní aritmetiky pro rozklad na řádek/sloupec používat operace maskování a posuvu (bit-banging) namísto násobení a dělení... tedy pokud pro takovou operaci najdete ve svých algoritmech uplatnění...

Vlastně jsem ale mířil k ponaučení, že i "dynamické datové struktury" mají svou režii, a tedy se vyplatí až od určité "míry prořídnutí matice".

Jestli jsem trochu pochopil zadání, možná budete potřebovat nějaký hybridní přístup: pole o pevných rozměrech [X;Y] a možná nikoli řídké, kde v každé "buňce" bude nějaký "objekt" (C struct, C++ instance třídy apod.) který bude držet hrst proměnných, odkazů a může z něj rašit nějaký dynamický seznam nebo stromek apod.

A dále jak psal @speculatius... pokud algoritmus běží mezi dvěma-třemi řádky po sobě jdoucími, a nemáte dost RAM na celou datovou sadu, možná by se dal úplný soubor dat držet na disku a natáhnout do RAM vždycky jenom nějakou "podmnožinu", potřebnou ke zpracování... (několik sloupců po sobě jdoucích)

Ta data natékají do matice kontinuálně / iterativně do levého sloupce, a postupně probublávají doprava?
A je to tak, že dodáte vstup do levého sloupce, pak se spočítá celá matice, zahodí se mezivýsledky a všechno znova?

A říkáte, že v každé buňce potřebujete kompletní cestu přes všechny předchozí sloupce?
Podle "algoritmu agregace" se může jednat o seznam (délka = číslo sloupce), nebo strom (hloubka = číslo sloupce).
V každé "iteraci zpracování" se "dosavadní cesta" v aktuální buňce matice odhákne, a "předá se příslušné buňce o sloupec vpravo, ke vhodnému zaagregování do výsledné cesty pro tuto iteraci" (seznam/strom o patro naroste).
Mimochodem taková úplná "cesta" bude žrát dost paměti i pokud se bude jednat o prostou sekvenci (seznam), nedejbože strom. Předpokládám, že si v tomto bodě vysvětluji zadání špatně, protože to začíná připomínat ten vtipný čínský příběh se šachovnicí a zrnky rýže...

Potřebujete tu cestu uchovávat během výpočtu pro všechna políčka v tabulce, nebo jenom pro políčka v aktuálně počítaném sloupci?

Potřebujete během výpočtu uchovávat (alokovat) základní hodnoty pro celou matici, nebo vlastně stačí jenom pro aktuální sloupec? (nebo dva nebo tři)

Poslední dva dotazy míří na paměťovou náročnost.

Stran: [1] 2 3 ... 106