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.

Témata - Ħαℓ₸℮ℵ ␏⫢ ⦚

Stran: 1 ... 3 4 [5] 6 7 8

Sítě / Vypnutí WireGuardu v cílové síti

« kdy: 27. 08. 2022, 09:15:28 »

Nazdárek, řeším jeden praktický problémek při používání Wireguard tunelu v režimu road warrior právě na tom "floating" zařízení (připojuje se na globálně veřejného peera a z něj je dostupná cílová sít.naroutovaná přes dalšího peera, kvůli neveřejné IP).

Zařízení je android s "appkou wireguard z f-droidu", což stejně nic neznamená, protože defakto jen ta appkaa je agent s teplou vodou co přenáší příkazy wg set. NE že by to nešlo přes root terminál, Ale zrovna pro přehlednost a zrychlení je boží.

Jde o to, že když jsem v cílové síti (obligátní 192.168.1.0/24) a je zapnutý tunel, tak pakety z smartphonu zbytečně proudí na veřejný peer a zpět, když mohou jít na lokální síti (dokonce on-link) . Ale ještě hůř, když vypadne upstream konektivita, tak se k wireguard veřejnému peeru nedostanu . Interní síť wg je 172.16.1.0/24

Jak tohle elegentně řešit? Je to možná komplexní dotaz, protože se týká konkrétního OS android AOSP, konkrétní appky, jde o spíš soft dotaz, jakým způsobem to řešit nejlépe.

Konkrétní vymyšlený příklad, mám například appku na prohlížení webkamery v lokální síti, jdou tam zadat do seznamu položky webkamer, které budou uložené - stačí název , IP adresa/hostname, port, nějaké heslo... V tomto případě mám 192.168.1.160

Konkrétně způsobů řešení je víc, split-dns, více ip, více připojovacích profilů v aplikaci, používání DNS jmen a v aplikaci, NATování... ale některé jsou vyloženě hnusné

Obviously, jedno řešení je vypínat tunel v cílové síti... Ale zatím jsem nepřišel jak to udělat automatizovaně (hádám, asi by to musela umět appka a nějak sledovat k jaké wifi je spojená a porovnávat čistě podle SSID(

) a nebo podle IP+gateway+masky) . Všechny řešení předpokládám že by byly na vyloženě smartphonu ( až na to NATování).

Nebo je chyba(přičina problému), že telefon (192.168.1.5) se a cílové zařízení v(192.168.1.160) cílové síti má IP ze stejné sítě (192.168.0.1./24) a nějak by se to snad řešilo natováním (třeba symetricky na to 172.16.1.x=192.168.1.x) . ALe chtěl bych zůstat, abych v appkách měl uložený jen jeden profil(jeden záznam)

Hint: šlo by nějak využít fakt, že smartphon je fakticky v dané síti k dané síti připojen on-link? (těmhle věcem v ip addr jsem moc nerozumel)

Hardware / ext4 se přepne do RO, aborted journal a nevalidní inody

« kdy: 17. 08. 2022, 22:01:10 »

Mám velký ext4 partition, kopíruju na něj data, po 3TB se mi objevil a chyba a přepnu do RO. Jakým směrem dál hledat chybu? Dá se zjistit příčina? v složce se mi ukazují 4 soubory

Kód: [Vybrat]

-rwxr-xr-x 1 user grupa 516118971 2021-10-01 16:44 bla S01E06.mp4*
-????????? ? ?     ?                       ?                ? bla S01E07.mp4
-????????? ? ?     ?                       ?                ? bla S01E08.mp4
-????????? ? ?     ?                       ?                ? bla S01E09.mp4
-????????? ? ?     ?                       ?                ? dalsi.iso

Kód: [Vybrat]

dmesg
[186097.898255] EXT4-fs warning (device dm-11): ext4_end_bio:333: I/O error 536870912 writing to inode 109051940 (offset 0 size 0 starting block 447155931)
[186097.912284] Buffer I/O error on device dm-11, logical block 447155931
[186097.949488] JBD2: Detected IO errors while flushing file data on dm-11-8
[186097.956481] Aborting journal on device dm-11-8.
[186098.055815] JBD2: Detected IO errors while flushing file data on dm-11-8
[186098.221674] EXT4-fs error (device dm-11): ext4_journal_check_start:56: Detected aborted journal
[186098.230728] EXT4-fs (dm-11): Remounting filesystem read-only
[187235.996259] EXT4-fs error (device dm-11): ext4_lookup:1769: inode #109051905: comm privRequest.cgi: deleted inode referenced: 109051937....{8,9}

Mám se strachovat, co vlastně chyba znamená a jak je závažná

Software / Jak zjistit přesnou velikost sady souborů a složek

« kdy: 17. 08. 2022, 08:58:54 »

Mám prostou otázku, kterou jsem ale nedokázal vyřešit. Nejsem s to dokopat linux, aby mi vyflusnul přesnou velikost všech souborů v určitém umístění. (tím myslím například/path/na/nějakou/složku)
Pokud se nepletu, tak chci znát přesnou délku souboru (apparent size), ne místo zabrané clustery na FS (což bude asi nejbližší násobek 512/4096/etc).

Jak jsem to zjistil? Kopíroval jsem adresářový strom z jednoho FS( ext4) na jiný (exfat).

Zkoušel jsem pouze utilitu du. A Zkoušel jsem přepínače -S -s -c --aparent-size --block-size v různých kombinacích

Zlobí to, když zkoumaná adresářová struktura má podsložky, což je jaksi samozřejmost.

Například ls uvádí u složek na první partition velikost 131072 a u druhé 4096. Kvůli tomu jsme zkoušel parametr -S.

Příkaz du ukazuje správně na obou místech (umístění na exfat i na ext4), když vyberu nějakou složku, která už nemá podsložky a argument -B1 (zkratka pro --blocksize 1 a --apparent-size)

Jakým způsobem zjistit v linuxu velikost adresáře, který obsahuje další podsložky.. Chci udělat "bitové" srovnání, jestli velikost souborů (o obsahu nic nepíšu) souhlasí na bajt. Logicky složky v tomto srovnání se musí započítávat hodnotou nula.

Software / mount -o offset ale s ntfs-3g

« kdy: 16. 08. 2022, 16:55:31 »

Mám takový problémek: vytvořil jsem image celého (vč.table) externí disku na nějakou partition na hlavním disku.
Postupuji podle tohoto návodu.
První partition se mi daří připojit: mount -o offset=$((512*2048)) /dev/sda3 p1, jelikož je to FAT32.
Jenže další jsou ntfs. a mount se řeší přes `ntfs-3g` A option offset nemá. A tedy nevím , jak ntfs-3g vnutit offset, viděl partition od správné pozice.
Potíž je , že to není klasický linux, ale nějaký embedded bastl.

Existuje nějaká oklika, jak třeba vytvořit přes losetup nová blockdev, která budou "zoffsetěná"? Ale jestli tomu dobře rozumím, losetup nepřijme blockev jako "input", nýbrž jen fajly.
že bych pak zvolal mount /dev/loop3 p2

Například findnt ani lsblk,lsb_release,systemctl,lscpu tu není. losetup nezná argument -P.

Server / ext4 undelete s rozhraním jako recuva

« kdy: 12. 08. 2022, 21:14:24 »

Hledám program uživatelsky přívětivý jako recuva, aby ale uměl zacházet s ext4 filesystemem. což jsem se nedočetl ani na support.piriform.com ani ccleaner.com ,ale až na wikipedii⁹. ale odkaz stejně už obsahuje informační vakuum.

Je jedno jestli na windows nebo hocijaký OS. ale by to mělo 2 možnosti skenu, rychlý i pomalý.
Ale hlavně, aby to umělo připojit ext4 systém skrytý asi 2 úrovních abstrakce ( mdadm a LVM+PV, LVM tier, lvm partition), což netuším jak ve windows by šlo dokázat.

Software / Taky vám nejde Newpipe?

« kdy: 12. 08. 2022, 21:08:01 »

Tak mi přestal jít newpipe, a to ani po updatu z 0.23.0 (2.5.)na 0.23.1 (9.7.). Přičemž stará verze ještě fungovala před týdnem jistě. Nevíte, kdy zase bude fungovat?

/dev/null / ls : drwx------@ co je zač @ na konci nonetu

« kdy: 12. 08. 2022, 18:53:32 »

Co znamená ? ve výpisu ls @ na konci nonetu? (nepočítám desátý decim, to je jen kosmetický indikátor soubor/dev/adresář)
Paradoxně se ve Finderu do složky nedostanu, ale přes terminál ano, soubor je čitelný.
Děje se to jenom na složkách. Vzniklo to při kopírování. Většina se zkopíruje správně. Když takto postiženou složku přejmenuju, je normálně dosupná, ale když ju přemenuje nazad, tak se tam opět objeví problém.

PS: ve Finderu ukazuje u ikonky malá značky zákaz vjezdu.

Hardware / Nefunguje datový přenos s USB-C redukcí (sys/class/usb info included)

« kdy: 01. 08. 2022, 09:52:45 »

Mám problém při připojení telefonu přes USB-C redukci k USB-A hostitelům (takže zapojuju telefon s USB-C do počítačů s USB-A).
Jako early adopter jsem si koupil drahý kvalitní USB-C 3.2 kabel. Nějak nám ta kompatibilita hapruje, kde udělali soudruzi v USBIF chybu?

Jenže paradoxně to blbne s high-tech kabely (Thunderbolt 3 a USB-C 3.2), zatímco paradoxně² USB 2.0 USB-C kabely problém nemají.
A paradoxněsuper³ kabel s konci USB-C a USB-A (tedy redukce není potřeba, kabel má správné koncovky na oba endpointy) to taky funguje.

Projev problému: nefunguje jakýkoli datový přenos. Telefon se pouze nabíjí.

Přikládám výpis(z telefonu) z /sys/class/power_supply/usb/{položka}. Pořadí je :type, typec_orientation, typec_mode, typec_power_role,. U orientace se je vždy 0/1/2, ale zkusím prohodit a když tak spojím |.

Nabíjení vypnutého/zapnutého USB-C guest zařízení telefonem:
USB_PD, 1|2, Powered cable w/ sink, dual power role,

Problematické zapojení(merit dotazu) USB-C high tech kabel s redukcí do USB-A hostitele:
USB, 0, Audio adapter, dual power role,

Jako předchozí, ale s USB 2.0C kabelem (paradox²) - funkční data:
USB, 1|2, Source attached(default current), sink

NIc nezapojeno:
Unknown, 0, Nothing attached, dual power role

Nabíječka USBC s PD:
USB ->USB_PD po chvíli nebo USB_HVDCP -> USB_PD, 1|2, source attached (high current), dual power role

Nabíječka 5V USB-A
USB_DCP, 2|1 source attached(default current). sink

Proč tedy telefon detekuje protipól počítač jako Audio adaptera nejdou data . Proč je tam vyjímka², že USB2.0C² kabel ale funguje (oboje s tou redukcí). A zároveň USB 3.0 kabel³ (bez žádné redukce) taky funguje (na to se neptám, to jen konstantuje, očekává e že věci fungují)

Software / Zjištění URL obrázku v RoundCube

« kdy: 29. 07. 2022, 15:24:37 »

Existuje nějak normální ~BFU způsob, jak v otevřeném příchozím HTML mailu v Roundcube webklientovi zjistit URL adresu obrázku, který je externě linkován

Ukazuje místo to ho růžové čtverečky

Jde o standardní funkci napříč mailovými klienty, že blokují v těle mailu externě načítané zdroje. Pokud ale dám povolit, obrázky se rovnou načtou, já jen chci vidět URL

(Testováno v dotykovém UI.)
(Vím, mohu si v uBlocku origin dát blokaci 3rd party na, ale to je shození *ovna o patro níž, ani tak na první dobrou to nezjistím ,prostě se neukážou a musím otvírat logger, a vidět které jsou zablokovaná)
(Do třetice, vím, že si mohu dát Zobrazit zdrojový kód CTR+F, src=, ale já hledám uživatelsky přívětivé řešení, jako třeba, že se ukáže jako tooltip... ale to asi chci moc)

Vývoj / Skript pro paralelizovanou tvorbu md5 bloků disku

« kdy: 29. 07. 2022, 13:04:34 »

Mám něco jako

Kód: [Vybrat]

ptr=0; while  [[  $ptr -lt 500000 ]] ; do dd if=/dev/sda bs=1M  count=10 skip=$ptr conv=fullblock  | md5sum  -b > blok$ptr.bin ; ptr=$((ptr+10));  done

Cílem je udělat (z 5TB) jakýsi zhuštěný "hash". Například každý 1MB dat do 2bajt bloku .
Abych poznal na první pohled, která pole jsou plná nul, která plná FF, a pak(volitelně) nevím něco mezi tím (něco jako entropie), ale aby to nebylo moc výpočetně náročné. Logicky aby stejný blok měl stejný výstup.

A taky tam jsou dvě vady:
Prostřední "výkonný" blok md5sum -b má pevnou délku 160b, md5sum je pomalé,nechci md5sum, ale nějaké CRC, které mi třeba jen řekne počet nul a počet jedniček modulo 255.

Zadruhé je o procesor to v jednom sekvenčním zpracování brzdí. buď se čte a nebo vypočítává hash.

Zatřetí procesor by to ani nestíhal, kdyby jednovlákno neustále počítalo hash. Je třeba zaměstnat víc vláken

4. Opustit md5sum, sloužilo to jen jako příklad. Musí to být rychlé a zároveň nějak matematicky založené (že třeba první bajtu dává počet nul v bloku%1024) adruhý počet nul v lichých bitech. A srozumitelné, když koukn že tam je 0x80CC, tak že tam je půl napůl nuly a CC nějaká hodnota entropie. Hodně zjednodušeně

Disk má 240 MB /s, ale zpracování md5 asi 50 MB/s. Potřeboval bych to paralalizovat (i kdyby tam md5 nezůstalo).

Jak tu paralalizaci řešit? Dá se to nějak v bashi elegantně řešit nebo na to je lepší si napsat skript v rustu, perle, ruby, pythnu?

Aby disk jel maximum nonstop, nečekal na dkonočení výpočetní části, aby se nezastavoval ani neseekoval zběsile. a data předával nějakým threadům (4-8), která sama zpracují a zapíšou na příslušnou pozici.

Nechci zapisovat do 5000000 souborů *.bin, ale do jednoho 5MB/10MB souboru. Technicky i do nějaké paměťové struktury, které se občas syncne na disk.

Další nápad, vytvořím si soubor předvyplněný hodnotami třeba 0xEE. A budu vědět v případě ukončení, kde se (kdzž to bude lineární) nebo které bloky jsou "neposkvrněné čtením"

Poradíte, nakopnete, jak začít, jaké klíčové konstrukce programátorské použít?

A hlavně , jaký algoritmu výpočtu otisku bloku zvolit, ideálně nějaké funkce z knihovny jazyka, ale nic jako CRC jsem v bashi nenašel. A zda zůstatu u bashe.

Sítě / Více bran při víc IP, ale jedna MAC

« kdy: 18. 07. 2022, 08:12:35 »

Je možné na linuxu v roli routeru na jednom rozhraní mít více bran( ne ve smyslu výstupních v ip+route, ale "vstupních" tedy) —přidat více ip adres na rozhraní jde, ale sdílí jednu MAC a komunikující zařízení tedy můžou mít nastaveny odlišné brány(t.j. odlißné ip), ale díky arp se resolvují na stejnou MAC a router informaci, na jakou ip brány paket šel, neuvidí (jelikož ip paket se nemění kromě ttl a hashe)

Mám podezření že jde o podivný nápad(vymyšlení hranatého kolo), problém jde řešit lépe, oradite jak "po správnu"? Je nutné použít VLANy, nebo bohatě stačí segmentace přiřazenych IP a následně ip yource routing

Myšlenka:
Například když si určitý komp nakliká ve Windows jinou bránu za účelem aby provoz teéto stanice šel jinou routovací trasou (pres vpn, nebo jinym rozhranim , ale na routeru až))Měnit IP by bylo fuj, jde furt o jeden stejny komp

A:
Je možné vlinuxu síťové kartě nastavit vícero MAC? Dá se to usělat víc způsoby(vlan-s/bez) pres nejaky virtualni switch?

Sítě / Wi-Fi ma zpoždění paketů 10 sekund

« kdy: 15. 07. 2022, 22:46:22 »

Pozoroval jsem nějakou slabou chvilku wifi nadřazeném routeru.... šlo o dočasný stav pár hodin
Ping kamkoli 10 sekund
Traceroute nabírá těch 10 sekund hned na prvním hopu(tedy na tom nadřazeném hopu)
ping přes wireguard tunel funguje ale s proměnnou latencí (2-10 sekund)
nemožnost se kamkoli připojit přes TLS(asi vyhnije spojení kvůli víc roundtripům ) , tedy ani DnsOverTLS , DNS-53 netestováno
úspěšnost na http asi 50%
4 stávající probíhající tcp spojení jedou původní rychlostí, jako by se jich to netýkalo To je fakt zajímavé: Může fungovat TCP přenos s takovouhle latencí ? Přizpůsobí se tomu nějak paramtery window size? Zřejmě ztrátovost nevzrostla.

Co by tohle mohlo znamenat?

Pro jistotu - aktuální router (ne ten nadřazený) je v pořádku, iperf, ping, curl plný výkon, normální latence milisekund. Logicky ale testuji druhé rozhraní(vnitřní sítě) a nadřazený router je na jiném rozhraní(wifi wlan0)

Sítě / Podivné DHCP dotazy

« kdy: 15. 07. 2022, 11:37:59 »

Nazdarek, v logu jsem zaznamenal neočekávané DHCP komunikaci. Co by to mohlo být? Tipuji že MAC adres jsou náhodné (alá android randomizace). A taky je mi divné, že sekvence DHCP končí vždy OFFER (nenásleduje Request&Ack)

adresy MAC mám v souboru dané direktivou dhcp-hostsfile=/...conf pro přehlednost, a toto jsou neznámé.

Poznáte (spíš podle charakteristiky), co by to mohlo být nebo jaký OS /stack se takhle chová? Třeba nějaká feature na detekci konektivity nějakého zařízení? Vtipné je, že 129.168.1/24 je skutečný rozsah sítě.

Víc jsem nedohledal v logzích.

Kód: [Vybrat]

23:50:17  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) 03:d7:75:fd:53:35
23:50:17  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.113 03:d7:75:fd:53:35
23:50:20  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) 4a:72:e0:b9:91:1b
23:50:20  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.87 4a:72:e0:b9:91:1b

00:13:19  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) d2:cb:bc:20:9c:03
00:13:19  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.81 d2:cb:bc:20:9c:03
00:13:22  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) ad:15:86:9b:20:fc
00:13:22  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.65 ad:15:86:9b:20:fc
00:13:25  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) 2b:f5:0f:66:45:75
00:13:25  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.12 2b:f5:0f:66:45:75
00:13:28  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) ca:46:15:53:28:54
00:13:28  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.96 ca:46:15:53:28:54

Software / pidof vrací neúplný počet výsledků

« kdy: 13. 07. 2022, 13:29:13 »

proč když v linuxu (debian, 5.10) zadám (opakovaně za sebou) pidof wget, tak mi to vrátí neúplný počet výsledků?

Kód: [Vybrat]

0 6 9 9 9 0 11 12 12 12 0 12 12 12 12 12 12 12 12 12 12 11 11 5 1 0 0 4 8 12 12 9 0

(výstup jsem předžvýkal originál pidů uplně dole)

Bude to trošku delší post s výstupy utilit, snad se vtom odhalí zakopaný pes

Nějak na to musí mít vliv fronta zápisu na disk a čekání procesů, které se vytratí, když zthrottluji rychlost stahování a když ji navrátím, po nějaké době se nastolí čekání.... Avšak bcmstat hlásí konstantně 4-5 MB/s. Mimochodem, proč iftop hlásí polovinu? (99% trafficu se neforwarduje)

v htopu stále jsou, některé mají stav D(isk sleep), S(leep)
Jde o stahování na RPI 3 a z nějakého důvodu
Mimochodem flashka má seq. zápis 110MB/s, čtení 210 MB/s. benchmark lehce: sekvenční zápis přes DD na sda i přímo
do mountpointu (přes exfat) dává 33MB/s

iostat hlásí write size 64kB blocksize. exfat driver je tam rychlý(kernelový)

htop:
wgety v htop dávají po 2%(10x http) a po 8%(2x https)
htop K H:
15% kworker/0:2-events
40% kworker/us:5-brcm_wg/mmc - patrně wifina-, když přes ni jde 40 Mbps (15000 irq/s)- viz dole

Děje se tam něco nepěkného.... ohledně přerušení/ fronty disku/

Swap není, využití ram 280/900

bcmstat

Kód: [Vybrat]

Time         ARM    Core    H264 Core Temp (Max)  IRQ/s      RX B/s      TX B/s   cpu0   cpu1   cpu2   cpu3
12:54:37  600Mhz  250Mhz  250Mhz 45.62C (47.24C)  4,585     175,964       5,911 100.00 100.00 100.00 100.00
12:54:39  600Mhz  250Mhz  250Mhz 45.62C (47.24C)  8,468   2,516,984     164,778 100.00 100.00 100.00 100.00
12:54:41  600Mhz  250Mhz  250Mhz 45.62C (47.24C) 15,418   3,468,569     151,227 100.00 100.00 100.00 100.00
12:54:43  600Mhz  250Mhz  250Mhz 45.62C (47.24C) 13,627   3,924,711     118,448 100.00 100.00 100.00 100.00
12:54:45  600Mhz  250Mhz  250Mhz 45.62C (47.24C)  8,493   3,543,318      66,350  64.19  70.97 100.00 100.00
12:54:47  600Mhz  250Mhz  250Mhz 45.62C (47.24C) 17,527   3,718,094      60,898  81.63 100.00 100.00 100.00
12:54:49  600Mhz  250Mhz  250Mhz 45.62C (47.24C)  8,330   3,384,918     140,940  95.66 100.00 100.00 100.00
12:54:51  600Mhz  250Mhz  250Mhz 46.16C (47.24C)  7,952   3,846,413      34,260 100.00 100.00 100.00 100.00
12:54:53  600Mhz  250Mhz  250Mhz 46.16C (47.24C)  7,676   3,355,452      66,200 100.00 100.00 100.00 100.00
12:54:55 1200Mhz  400Mhz  300Mhz 46.16C (47.24C) 11,820   5,020,296      37,388 100.00 100.00 100.00 100.00
12:54:57  600Mhz  250Mhz  250Mhz 45.08C (47.24C)  2,434     658,430       1,419  60.28 100.00 100.00 100.00
12:54:59 1200Mhz  400Mhz  300Mhz 45.62C (47.24C)    778      19,182         595   1.58  51.52 100.00 100.00
12:55:01  600Mhz  250Mhz  250Mhz 45.08C (47.24C)  1,868       4,794         162  87.42  46.31 100.00 100.00
12:55:03  600Mhz  250Mhz  250Mhz 45.08C (47.24C)  3,520     140,598       4,432 100.00 100.00 100.00 100.00
12:55:05  600Mhz  250Mhz  250Mhz 45.08C (47.24C)  6,674   1,889,065     110,850 100.00 100.00 100.00 100.00

iostat (v době ,kdy je "zahlceno")

Kód: [Vybrat]

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,12    0,03     14,5k      0,7k     0,07     0,04  35,6%  58,3%   14,19  158,11   0,01   119,4k    21,7k   8,00   0,1% mmcblk0
    0,02    0,75      2,1k     55,7k     0,00     0,07  11,8%   8,5%   24,36   27,90   0,02    91,6k    74,7k  14,78   1,1% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    2,00      0,0k    128,0k     0,00     0,00   0,0%   0,0%    0,00 1031,17   2,06     0,0k    64,0k 486,67  97,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   71,33      0,0k      4,5M     0,00     2,33   0,0%   3,2%    0,00   36,32   2,59     0,0k    65,0k  18,18 129,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33  110,67      0,2k      6,9M     0,00     0,00   0,0%   0,0%   34,00   17,81   1,98     0,5k    63,9k   8,98  99,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   62,00      0,2k      3,9M     0,00     7,00   0,0%  10,1%   26,00   25,06   1,56     0,5k    63,9k  12,73  79,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   13,33      0,0k    834,7k     0,00     0,00   0,0%   0,0%    0,00  161,95   2,16     0,0k    62,6k  81,25 108,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   22,33      0,2k      1,4M     0,00     2,33   0,0%   9,5%    5,00   82,75   1,85     0,5k    62,9k  40,88  92,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   19,67      0,0k      1,3M     0,00     0,00   0,0%   0,0%    0,00  106,81   2,10     0,0k    65,6k  53,73 105,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    2,67      0,0k    170,7k     0,00     0,00   0,0%   0,0%    0,00  624,38   1,66     0,0k    64,0k 358,75  95,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    1,33      0,0k     85,3k     0,00     0,00   0,0%   0,0%    0,00  725,75   0,97     0,0k    64,0k 537,50  71,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   40,33      0,2k      2,5M     0,00     4,67   0,0%  10,4%    8,00   72,62   2,93     0,5k    62,7k  36,15 147,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   77,33      0,0k      4,8M     0,00     4,00   0,0%   4,9%    0,00   21,55   1,67     0,0k    63,0k  12,93 100,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   36,33      0,0k      2,3M     0,00     2,33   0,0%   6,0%    0,00   43,27   1,57     0,0k    64,3k  21,74  79,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   91,67      0,2k      5,8M     0,00     4,67   0,0%   4,8%   37,00   26,20   2,41     0,5k    64,3k  13,19 121,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   50,67      0,2k      3,1M     0,00     4,67   0,0%   8,4%   31,00   38,80   1,98     0,5k    63,0k  19,41  99,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    1,33      0,0k     85,3k     0,00     0,00   0,0%   0,0%    0,00  930,25   1,24     0,0k    64,0k 572,50  76,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    0,67      0,0k     42,7k     0,00     0,00   0,0%   0,0%    0,00 1439,00   0,96     0,0k    64,0k 720,00  48,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33    0,67      0,2k     41,3k     0,00     2,33   0,0%  77,8%    3,00 1638,00   1,09     0,5k    62,0k 1090,00 109,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    0,33      0,0k      2,7k     0,00     0,00   0,0%   0,0%    0,00 3104,00   1,03     0,0k     8,0k 3100,00 103,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    0,67      0,0k     42,7k     0,00    31,33   0,0%  97,9%    0,00 4386,50   2,92     0,0k    64,0k 1420,00  94,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33  162,00      0,2k     10,1M     0,00     0,00   0,0%   0,0%   16,00   20,70   3,36     0,5k    63,9k  10,41 169,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   50,00      0,0k      3,1M     0,00     4,67   0,0%   8,5%    0,00   39,85   1,99     0,0k    63,5k  20,07 100,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   90,67      0,2k      5,6M     0,00     8,33   0,0%   8,4%   35,00   17,15   1,57     0,5k    62,8k   8,68  79,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   12,00      0,2k    766,7k     0,00     0,00   0,0%   0,0%   23,00  177,75   2,14     0,5k    63,9k  87,03 107,3% sda

watch -d -n4 "cat /proc/interrupts" (ručně jsem vybral řádky které mají víc než 100/sec zhruba

Kód: [Vybrat]

 75:   12310667          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ
 75:   12315233          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ

 89:   89839051          0          0          0  ARMCTRL-level  64 Edge      dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
 89:   89842337          0          0          0  ARMCTRL-level  64 Edge      dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1

105:   14910325          0          0          0  ARMCTRL-level  80 Edge      vc4 firmware kms
105:   14910569          0          0          0  ARMCTRL-level  80 Edge      vc4 firmware kms

119:  124949997          0          0          0  ARMCTRL-level  94 Edge      mmc1
119:  124972375          0          0          0  ARMCTRL-level  94 Edge      mmc1

free

Kód: [Vybrat]

 free -m
              total        used        free      shared  buff/cache   available
Mem:            871         262          75          74         533         471
Swap:             0           0           0

PIDY: originál před zkrácením while read e; do echo $e | wc -w; done <textovy_vystup_pidy| tr "\n" " "

Kód: [Vybrat]

24449 23863 23778 23774 23726 23464
24449 23863 23788 23778 23774 23726 23491 23464 23195
24449 23868 23863 23788 23778 23774 23726 23464 23195
24449 23868 23863 23788 23778 23774 23726 23464 23195

24449 23868 23863 23788 23785 23778 23774 23733 23726 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195

24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23726 23491 23464 23195
23863 23733 23726 23491 23464
23788


23788 23491 23464 23195
23863 23788 23785 23778 23774 23733 23491 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23863 23788 23785 23778 23774 23726 23464 23195

Windows a jiné systémy / Nehezký přechod bílá–černá na externím LCD na Macbooku

« kdy: 11. 07. 2022, 15:29:58 »

Když si zobrazím nějaký plynulý přechod barev (bílá,černá, červená, zelená, modrá atd, nejmarkantněji bílá–černá)
, tak je mi divné, při jaké kombinaci mi se to ukazuje krásně plynule a kdy to dělá celkem nepěkné skoky.

Na Macbooku na interním LCD nádhera. Na jiném externím monitoru (2013) taky pěkné (nejlepší je nechat defaultní prostor, kontrast, křivky, gammu , pak se to horší)

Na testovaném LCD (2018) , z výroby kalibrovaném, dle recenzí DeltaE <1.9. začne přihořívat Když je to na jiném PC než Macbooku, tak je to tam taky hezké, bez pruhů. Ale jakmile připojím macbook na tento monitor, po celé siločáře přechodu se ukážou skoky . Čím to je ? Taky jsem hned zkoušel to hasit různým defaultním nastavením monitoru(gamma, režim, kontrast, HDMI,MiniDisplayPort) a nic.

Paradoxní je, že OS X sám o sobě nabídne asi 3 různé barevné profily ("po filtru" ✅ Pro tento monitor), ani jeden z nich to nespravil. Zkoušel jsem neškálované zobrazení, nativní i škálované (nativní,ale větší písma,ikony atd).

Nevíte, kde by mohl být problém, když jiné počítače (pravda, zkoušeny windowsy pokaždé) s tím nemají problém?

Stran: 1 ... 3 4 [5] 6 7 8