Příspěvky

1501

Desktop / Re:Notifikátor docházející paměti

« kdy: 25. 01. 2020, 00:16:14 »

Neni to vtip.

1) to, ze dochazi pamet nepoznas. Staci proces, ktery udela malloc(1G) a bude se snazit zaplnit kazdou stranku daty (vyzada si alokaci), v pripade ze nemas swap, zafunguje OOM

2) jestli mas swap, tak takovyto proces Ti zpusobi odmigrovani jine pameti do swapu, tj. poznas to hned jak udelas ALT+TAB do jine okna

Jsou totiz ruzne urovne nepouzitelnosti - swap ti zaruci, ze se system spomali a muzes sam reagovat. Bez swapu jsi plne rukojmym sveho systemu.

K cemu ti je meric vyuziti pameti, kdyz ta hodnota muze vyrust tak rychle, ze se jednak nestihne ani zobrazit a druhak ze nestihnes vubec zareagovat? Natoz se rozhodnout ze jak budes reagovat. Pocitac je holt rychlejsi nez clovek.

SWAP ti da vic nez merak.

1502

Desktop / Re:Notifikátor docházející paměti

« kdy: 24. 01. 2020, 21:00:10 »

Porid si swap device.

Vzhledem k rychlosti jakehokoliv media pripojitelneho k RPi rychle poznas, ze uz je system nepouzitelny, takze te to donuti prestat delat neco, na co to RPi stavene neni.

1503

Hardware / Re:Problémy s Lenovo T490 s kernelem > 4.19.93

« kdy: 21. 01. 2020, 18:40:40 »

Ty verze nejsou tak vzdalene.. tak bys mohl zkusit bisect a najit patch po kterem ti to prestane fungovat.

1504

Vývoj / Re:Interpolace bez lineární funkce

« kdy: 20. 01. 2020, 23:40:00 »

Otazka je, zda i tyto dnesni, jiz omnoho komplexnejsi ukoly, by se meli resit technologii ktera neni pro ne vhodna. Operaci nasobeni ma dnes kazdy normalni mcu.

Podle casovani potrebujes 1M lookupu, takze to nepobezi na zadnem ATtiny s par MHz a par bajty pameti.
Takze co s ~100MHz a 32K+ pameti nema MUL?

1505

Software / Re:Část skriptu je ignorována

« kdy: 19. 01. 2020, 12:08:21 »

Nastav si v cronu mail pro reportovani chyb.

A nejspis to skonci na tom, ze neni nastaveny DISPLAY env. variable, ktery je nutny pro praci s necim pod X. Zkus se prihlasit z jineho pc skrze SSH a pusti si ten skript, uvidis co to dela, kdyz se to pousti.

A co ma byt to done na konci? Prijde mi ze ti chybi i zacatek skriptu.

1506

Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2

« kdy: 18. 01. 2020, 20:46:13 »

Ta FPGA deska je jiz spis stary kram. Jako muzes mi napsat mail, poslu NDA a pak ti reknu jak moc realny je s tim neco udelat v rozumnem case, nebo se proste stav na pokec :-) U FPGA nejsou genericke navody - protoze ten "kod" resi vzdy nejakou specifickou ulohu a vse potrebuje jiny a individualni pristup.

1507

Hardware / Re:Čidlo BME280 (3.3 nebo 5V) na vzdalenost cca 50m

« kdy: 16. 01. 2020, 12:01:27 »

Jestli nepotrebujes velikou rychlost, tak muzes resit napajeni i komunikaci pres jeden par dratu - zpetna komunikace je jednodussi - na zakladni stanici budes merit proud a na vzdalenem vysilaci pripinat pres fet paralelni zatez. Dopredna komunikace by byla obdobna, jen s merenim napeti a spinanim serioveho odporu (zde pak zalezi i na odberu cidla).

1508

Hardware / Re:Raspberry Pi: vystříhání se podpětí je celkem náročné

« kdy: 16. 01. 2020, 00:02:56 »

A chladic jako mas?

1509

Hardware / Re:DVB-T2 T settopbox pouze ve fullHD, nároky české televize

« kdy: 15. 01. 2020, 02:32:28 »

Nesoudělná prokládaná "rolling scan" rozlišení a nakonec to skončí na placce, která zobrazí celý snímek naráz :-O

Vsechny zobrazovadla roluji (LCD typicky v 60p/120p, u nas nejspis u novych veci bude 100p), nejbliz ke globalnimu zobrazovadlu ma DLP projektor - ten ma sice jen binarni zrcadla, ale updatuji se radove v 10k fps aby mohli delat pwm a vytvorit iluzi toho, co vnimas jako odstiny jasu.

jejich kamer s pidi cipy - vzali za vdek tomu, co jsem mel ja.

Z jakého roku? Není to nějaký překlep? Jakože oni měli třeba 1/2.3" a ty fullframe?

Neni to preklep. Rok 2014, TV pouziva 1/2"~2/3", ja mel APS-C (S35), takze prakticky 10~7 nasobny rozdil v plose, samozrejme roli pak hraje i svetelnost skla a to, ze nemam DSLR, takze vyuzit je cely cip bez line-skippingu. Jo.. na detailech zalezi :) S externim rekorderem lze na ni mit i 12bit v 4:4:4 (snimac ma adekvatne vice pixelu).

1510

Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2

« kdy: 15. 01. 2020, 01:38:58 »

Tak ja si napsal taky jednoduchy test (1h, neco pres 100 radku), testovano na zcela nahodnych datech (z urandom, jak pro data tak pro slovnik s 10M polozkami). #nocheat really.

Ze vstupnich 64-byte se pocita 32bit hash (xor, podminen nahodnymi daty v objektech) ktery je pak index do LUT pole (slovniku) o 4G polozkach, tim ze je tam obsazeno jen 10M zaznamu, tento vstupni filtr redukuje nutnost plneho porovnani cca 1:400. Ze neni match trva vzdy 1 nahodne cteni z pameti, kdyz je, je to o neco vice (kontrola celeho retezce, ze seznamu linkovaneho z LUT (zde se vyuzije cache, ze 64B se nacte jednou pametovou transakci), adresaci seznamu resim proprietarne at se me LUT vejde do mene nez 16G ram a vyzaduje se, aby hash distribuoval hodnoty rovnomerne).

Z 10M * 64B zajmovych polozek ve slovniku pri zhasovani na 32bit zatim taky nemam kolize - takze efektivita vylouceni bude narustem polozek casem klesat - nastesti to znamena zachovani max 1 polozky v seznamu pro plne overeni. Prumerne se dela tedy 399*1 nahodne + 1*3 souvisle pametove operace pro 400 testu.

Staci vysoke frekvence cpu (hash se spocte z L1, ma minimalni dopad na vykon) a hlavne rychle pameti s nizkou latenci - tohle reseni je vlastne limitovano pameti.

Bez specialni mmx/sse/avx onanie, bez prefetchu, jen primitivni C kod, jde zpracovani z prednacteneho pole z pameti takto:

X3430 4C/4T @ 2.40GHz  (2ch DDR3-1333 ecc reg), zde kompilovano s gcc9.2 -O4:

Kód: [Vybrat]

# 4 * 26.4 = 105.6 MT/s
# 8 * 14.8 = 118.4 MT/s

Phi7250 68C/288T @ 1.4G (58c/58t pouzitelnych ze starsiho gentoo livecd), stejna binarka tudiz neoptimalni -march, bez DDR4, jen onchip 16G MCDRAM:

Kód: [Vybrat]

#  8 * 14.7 = 117.6 MT/s
# 16 * 15.1 = 241.6 MT/s
# 32 * 14.5 = 464.0 MT/s
# 64 * 12.5 = 800.0 MT/s

Vypusteni vypoctu hashe pridava na vykonu cca 50% - takze v pripade paralelizace cekani na lookup (pres prefetch) a vypoctu dalsiho hashe tohle opravdu lze ziskat.

Prinos rychle pameti je evidentni :-) Myslim ze dosazeni 2GT/s po optimalizacich a s jadrem co umi SMT2/SMT4 je na Phi i realny, ale 128GB/s dat - vstupniho streamu pro tuhle kadenci tam ale nikdy nedostanete. (36L pcie gen3 da cca 32GB/s, a dve 100G rozhrani (eth/OPI/IB) po x16 pak prinejlepsim 25GB/s dohromady).

K testovani 25Gb/s streamu (vase pripojeni) postaci cokoliv co zvladne overovani rychlosti 50MT/s.

pozn. 1T = 1 transakce (test) s 512bit daty.

Rekl bych zaverem.. uzke hrdlo bude jinde, nez v cache :-)

1511

Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2

« kdy: 14. 01. 2020, 00:26:49 »

Az budete chtit na to dedikovany hw, treba s FPGA, tak se ozvete :) Zrovna hashe se tam pocitaji s nulovou cenou vuci propustnosti, pridana je jenom latence. Ale ty dva ruzne hashe by mela upocitat i grafika - navic je tam vyhoda velike propustnosti pameti. By me zajimalo jak moc ten slovnik lze zkomprimovat - a jaky je ocekavany narust poctu polozek, nebo trafficu.

Alternativne, co to zkusit na necem divocejsim - treba Phi 7250 (co tu mam), coz ma 16G rychle pameti na cipu (400GB/s+), takze cache miss (z 34MB) by nemusel tolik bolet. Plus to jde rozdelit na vice numa clusteru - nektera cast jader muze delat jen rychly filtr ze sve L1/2, a jine jadra pak full lookup z ram toho, co zbyde. U bezneho cpu jste precejen vice omezen dvojkanalovou pameti.

Pripadne se pohrat s tim, ze eliminacni cast stromu bude upocitatelna z cache (je treba dat pozor na to, co tvori klic do cache pro vas konkretni cpu a kolik podobnych zaznamu to dokaze ulozit - takze ta forma ulozeni stromu v pameti bude hodne specificka), Koncove seznamy pak mit v pameti ktera se necachuje - tim zarucite to, ze tyto nahodne pristupy do ram nebudou penalizovat vzdy potrebnej rychly rozhodovaci strom.

Predpokladat, ze v cache je poslednich XY MB pouzitych dat je naivni a ve skutecnosti to tak opravdu nefunguje - klicem byva hash z adresy a pro stejny hash si to pamatuje treba 8 hodnot :)

1512

Hardware / Re:DVB-T2 T settopbox pouze ve fullHD

« kdy: 13. 01. 2020, 22:10:53 »

... viz. technické podmínky pro výrobu pořadů.

Pokročilejší režimy pracují s interpolací pohybu... sice úplně nechápu, co tam chtějí interpolovat oproti prostému kopírování prokládaných řádků na střídačku, ale asi proč ne... Hmm když o tom tak přemejšlím, jsou v analogovém PALu jednotlivé řádky "exponovány v tomtéž okamžiku" (tzn. snímek nastojato), nebo se počítá s nějakým pohybem scény v průběhu řádkování snímku na stínítko, tzn. řádky v čase navzájem mírně posunuté?

Prokladane snimkovani si predstav jako filmovani v 50 Hz rolling shutter, ale pak kazdy druhy radek se zahodi, jednou liche, jednou sude. Samozrejme, ze podstatou prokladani je to, ze ty pulsnimky jsou exponovany casove posunute - o 1/50 vteriny. A samotny rolling scan znamena, ze vrsek obrazu je casove posunut take o 1/50 vteriny vuci tomu, co vidis na spodni strane.

V dobe synchronniho skenovani v CRT kamere + CRT prijimaci to byl nejidealnejsi retezec. Dnesni CMOS kamery dokazi replikovat rolling scan alespon tak, ze cely radek je vycten v jednu dobu (crt snimac cetl bod po bodu), ale zobrazovadla (lcd/plazma/oled) jiz bohuzel synchronni nebyvaj a uz vubec ne prokladana.

Interpolace pohybu v lepsim deinterlace je mezi snimky. Na dopocteni bud chybejiciho pulsnimku (do 50p), nebo k dalsimu vyhlazeni pohybu (na 100p), ktere nektere televize tlaci aby mohli rict jake mega framerate maji, ale vypada to jenom hnusne a je to prvni co znaly clovek vypina

1513

Hardware / Re:DVB-T2 T settopbox pouze ve fullHD, nároky české televize

« kdy: 13. 01. 2020, 13:22:31 »

Obrazový signál nesmí obsahovat subjektivně pozorovatelné vady, jako jsou např. šum, neostrost, neklid,
digitální artefakty, geometrické zkreslení, zkreslení barevného podání,

A ještě si v podmínkách píšou že musí kamery mít nějaký Tier 2L podle nějakých norem. A  to jsem tohle v reportáži viděl chromatickou aberaci.

Tier 2L jsou obycejne 8-bit kamery, bez nutnosti dodatecnych barevnych korekci, coz s typickou 10-bit televizni technikou znamena "profesionalni" kram. T2L jsou pouzivany v internich produkcich, ktere nejsou prodavany/licencovanym externim subjektum.

Vyjimky jsou z duvodu toho, ze muze existovat neopakovatelny zaznam o ktery CT ma zajem. Sam jsem jim takovy daval - v 8bit/25p/420, coz porusuje veskere akvizicni standardy. Protoze svetelne podminky neumoznovali pouziti jejich kamer s pidi cipy, nasvitit jim to nedovolili a porad se musel vyrobit - vzali za vdek tomu, co jsem mel ja.

1514

Hardware / Re:Poweredge r620 10-bay

« kdy: 13. 01. 2020, 13:07:19 »

Deska s konektory je HDD backplane: https://www.ebay.com/p/1537667503

Ale tam nebudou ty spravne suplicky, takze te mozna ceka vymena celeho case za jiny model:
https://www.ebay.com/itm/Dell-Poweredge-R620-1U-10HDD-Bays-Chassis-Assy-5H52N/332702176203

Jinak zkus najit manual k tomu serveru, dily byvaj vypsany, tak mozna najdes kody i pro ty kovove casti, ktere ti pak hledani ulehci.

1515

Vývoj / Re:C, zápis do pole čísel a zápis mimo cache L1/L2

« kdy: 12. 01. 2020, 22:43:02 »

A jeste mi chybi pocet matchu se slovnikem, ze vstupniho streamu. Jestli je to 1 z 1000, tak to snese hodne dlouhou latenci.