Příspěvky

1756

Bazar / Re:Prodej: RockPro64 4GB s prislusenstvim

« kdy: 05. 12. 2018, 10:55:55 »

A ty mas zkusenosti s psanim driveru pro kamery na tohle?
Muj zakaznik by me o kamerovy system zajem (kamery mame, je treba je tam naportovat - coz zatim nevim v jake fazi otevrenosti je, alternativa by jeste byla Allwinner V5 od Lindenis)

1757

Hardware / Re:DisplayLink Debian Stretch

« kdy: 04. 12. 2018, 10:16:27 »

Nejspíš jste špatně pochopil o čem vlákno je, shrnu vám to tedy: Tazatel se ptá, zda-li někdo neví, jak rozchodit displaylink u jmenované dokovací stanice na jmenované distribuci.
Na co se tazatel neptá je váš názor na danou technologii. Ten ostatně nezajímá nejspíš nikoho.

Tazatel ma moznost vratit onen smejd a poridit si normalni HW. Nechapu proc kupuje predrazenou usb3 grafiku ktera bude vykonove meh, kdyz by mu postacila pasivni redukce a mohl mit nativni zobrazovadlo.

Protoze i kdyby ten DL rozjel, bude dalsi dotaz ve smyslu:
 - proc se to seka?
 - proc tam nejede video?
 - proc tam nejde audio?
 - proc je to rozmazany?
 - proc to vytezuje procesor?
 - proc nelze nastavit vyssi rozliseni / framerate?

Tyhle snahy vyrobcu prodavat nesmysly je treba zariznout uz v zarodku a poradne jim ty kramy omlatit o hlavu. Protoze jinak hrozi, ze nebude k mani slusny hw ale jen same nefunkcni pitomosti. Se podivejte jak dopadl trh s komercnim sw, nebo nabidka potravin.

1758

Studium a uplatnění / Re:LinkedIn a kontraktor pracující jako OSVČ

« kdy: 03. 12. 2018, 00:13:46 »

To si napiste leda do CV, kdyz s tim bude firma souhlasit a nespada vase najimani mezi neverejne informace.

1759

Hardware / Re:Proč gopro umí e-shutter desítky sekund a opravdové foťáky 1s ; freevideo režimy

« kdy: 02. 12. 2018, 23:48:02 »

1) kazdy slusnejsi fotak umi skoro 30sec, nebo dokonce BULB rezim, kdy mas cas libovolny vyssi (pro priklad nemusim chodit daleko, 550D co mam po ruce umi oboji)

2) problem vezi ve dvou faktorech:

2A) fotoaparaty maji typicky omezene rozhrani z cipu, napr. Canon S120 ma 12MP sony snimac ktery umi 4K60, ale tim ze canon z nej zapojil jen 4 z 10 datovych paru tak holt je omezenej na FHD (asi 60 fps).

2B) cipy jsou optimalizovany, resp rovnou navrzeny na nejaky use case. Protoze MPx roste do aleluja a line skipping je fuj fuj, tak se snazi vyrobci integrovat binning mezi pixely - coz vyzaduje urcite zapojeni tech zkratovacich smycek. Tim, ze nelze kombinovat ty 2, 3, 4 nasobky tak lehce, protoze narusta komplexita aby z toho byl i nejaky zisk (typicky rychlost) nad ramec toho, co by poskytovala sw emulace binningu (rozumej scaling).

Prilis mnoho voleb = nerealny produkt. Nejcasteji je snimac optimalizovan na foto (vysoke rozliseni, 14bit), s moznosti omezeneho videa (10bit, crop, pripadne 2x2 binning). Cokoliv nad to se spis dela v sw domene.

Canon ma v DSLR analogove snimace, tam je 4K temer nemozny skrze ten omezeny pocet kanalu ktere to pouziva, az nedavno presli ze 4 na 8 kanalu (a v 5Ds na 16.. at maji nejaky pouzitelny burst na tech 50MPx).

Na video existuji jine snimace a nejdes je v profi kamerach Typicky se lisi prave vystupnim rozhranim, aby skrz to proslo 4K+ v 60fps pri 14bit+.


Ohledne stabilizace - myslim ze razy zpusobene zrcadlem a zaverkou rusi efekt stabilizaca, takze tu bys vyuzil jen v rezimu elektronicke zaverky a live view ... cimz z toho stroje delas uz bezzrcadlo

1760

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 01. 12. 2018, 18:40:32 »

V pripade ze se jedna o bug souvisejici s NCQ, tak je vhodne pak otestovat ruzne io-schedulery. U tech se nekdy meni default, neco je lepsi pro ssd, neco je lepsi pro normalni disky, neco spoleha na ncq..

https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

Různé schedulery řeší problémy s výkonem, ne se ztrátou dat.

Ale zde je evidentni ze ztrata dat nastava bud podle zpusobu pouzivani, nebo podle objemu pouzivani. A oboji ti ten scheduler ovlivni (postaci kdyz jeden bude preferovat zapisy a druhy cteni..). Tim, ze na 1.5G to porad blbne, bych se klonil jen k vade pri specifickem zpusobu pouzivani disku.

1761

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 01. 12. 2018, 14:18:33 »

V pripade ze se jedna o bug souvisejici s NCQ, tak je vhodne pak otestovat ruzne io-schedulery. U tech se nekdy meni default, neco je lepsi pro ssd, neco je lepsi pro normalni disky, neco spoleha na ncq..

https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

1762

Software / Re:Hromadné mazání pomocí rm v bash skriptu

« kdy: 29. 11. 2018, 23:48:17 »

Kdyz delas skripty s potencialne nebezpecnyma prikazama, je dobre prikaz pred ostrym pouzitim jenom vypsat.

Tj dej pred rm echo a uvidis jaky jsi idiot - protoze to prvni log smaze z cesty, ale navic to smaze 9 souboru z aktualniho adresare ktere maji jmena jako ty logy.

Prakticke tipy:
ls -1 neni potreba kdyz je tam | (pipe), to se snad detekuje samo
rm -r neni potreba kdyz mazes jen soubory, nebo ti jde i o slozky?
rm -f neni bezne potreba (ty soubory nejsou readonly, ne?)

jestli je grep log na priponu, tak pouzij -Ee '[.]log$', nebo rovnou *.log v ls

Prakticky tam mas jeste jeden bug, ze pocitas soubory ktere jsou i mimo filtr s grep log - takze je mozne ze ti to smaze vsechny logy i kdyz tam bude jen 5 logu a 5 jinych souboru.

1763

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 29. 11. 2018, 19:20:50 »

Jinak až tě to omrzí, tak bych doporučil pořídit normální disky a nahodit třeba FreeBSD a ZFS RAID-Z2.

Chci videt jak spolehlive bude ZFS nad nespolehlivym diskem (vadnym kabelem), obzvlast v pripade, kdy takove zkriplene uloziste bude pouzivano pro slog

1764

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 29. 11. 2018, 19:17:11 »

• 2018 listopad ... 1 ze 7 disků vykopnut z pole, hází chyby čtení, po restartu PC funguje normálně a nevykazuje sebemenší problém, vrátil jsem ho do pole

Najdi si duvod v syslogu - a podivej se, co se delo pred tim nez to mdraid vyhodil. Typicky je tam treba neco se SATA (coz muze byt napr. to chovani od SMR, ze to bude mit silene latence a jednou ten pohar trpelivosti sw raidu pretece).

Opravdu to nemuzes zkusit na jinem HW? To je totiz prvni co by se melo udelat, nez se trapit s potencialne vadnym hw. Ono totiz kdyby byl bug v sw/driveru, tak by se to tykalo vsech, tim ze se problem tyka jen tebe, tak to muze byt hw error.

Napajeni - doufam ze nemas 6 disku na jednom kabelu od zdroje, ale mas to vybalancovany po dvou, max trech. To same mechanicky - neRAID disky nemaji uplne rady vibrace, ktere delaj sousedni disky, takze bys to mel mit idealne rozlozeno od sebe a v ruznych uhlech. Vliv vibraci krasne ilustruje jedno video s nazvem ve stylu "do not shout on your disk array"

Ohledne zmeneneho 160kB bloku - zmena je pak trvala? Jaky je charakter dalsich chyb? (stejne misto, nebo ruzne misto? Lze identifikovat data, ktera tam jsou? (jestli udelas md5 pro kazdy 4kB blok, tak bys dokazal rict, odkud se tyto data vzali), pro rychle overeni staci treba "strings" pokud by to byl blok normalnich dat (coz asi nebude jestli mas ty data od dmcrypt).

1765

Software / Re:Jak je udělán tracking ve videu?

« kdy: 29. 11. 2018, 00:44:49 »

Tento ukol se da rozdelit na dve casti
1) zajisteni polohy letadla v case
2) renderovani

K 1) lze pouzit
a) live broadcast: ADS
b) custom reseni pro tyto soutezny eventy (a la G senzor pro formule)
c) offline zaznam tehoz
d) fotogrametricke rozpoznavani ze zeme

Podle me je to B - kdyz na ty letadla uz dali ten HD prenos z kokpitu, tak nejake metadata z GPS a gyra tam soupnete take.

Pak nastava bod 2 - rendering. Na to muzou mit specialni sw, obdoba zas toho co kresli ilustrace nad hrace fotbalu. Zde je potreba znat smer kterym se kamera kouka a jak moc ma nazoomovano Pak se tam narenderuje 3D scena s urcitou pruhlednosti. Ten viewport muze byt urcen rozpoznavamim featur v obraze (v podstate ty branky), nebo prostym meridlem na kamere.

Apropo Google is your friend:
https://www.redbull.com/int-en/tv/video/AP-1V2N93BY11W11/behind-the-air-race-the-ghost-plane

1766

Odkladiště / Re:telecentrický objektiv a makro objektiv, jak to jde dohromady.

« kdy: 28. 11. 2018, 22:35:49 »

Makro neznamena telecentricky.

1767

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 28. 11. 2018, 15:08:37 »

a ponechat jen disky

Ano, ponechat disky, které jsou v RAIDu naprosto neprovozovatelné a vyhodit vše ostatní, to dává skutečně smysl. 

Pokud ma vadnej kabel, zdroj, pameti, cpu, tak mu sebelepsi disk nepomuze. Pokud sis nevsim, porad se hleda zavada. Vypnuti cache na disku jenom snizi pocet operaci a pravdepodobnost chyby klesne, ale neni to reseni ani duvod chyby. To by taky rovnou mohl zkusit jet na 1.5G - SATA gen I, nebo zkrouhnout traffic, aby se to "ustihalo". Taky to ale neni reseni!

1768

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 28. 11. 2018, 14:39:23 »

Kluci, ale zadny drive-managed SMR disk uz z principu nemuze produkovat nekonzistentni data, cache, ne-cache!
Kde mate dukaz ze tyhle disky nectou to, co jste do nich zapsali??

To, jak se tyto SMR interne chovaji odpovida modernim SSD se SLC cache (zapis jede do docasneho uloziste, po jehoz zaplneni rychlost znatelne poklesne - coz muze disk vyhodit z raid-pole u hw radice z duvodu ze nereaguje). Na pozadi se to pak vklada do bloku ktere lze prepisovat jen jednim smerem.

Ten 160 KiB blok je podle me spis jen v ramci jednoho stripe (podle presneho offsetu to muzes rict zda jo nebo ne). Delit poctem disku to nema tady smysl. Kdyby to nebyly dulezite data, tak bych rad videl co se to tam zmenilo a jak (klidne PM).

Pokud chces dal experimentovat, tak cti jak /dev/mdX tak /dev/sdX ze stejnych mist (resp. mel bys byt schopen spocitat kde se onen 160kB blok nachazi). V pripade, ze se zmeni data na 3 discich zaroven, tak to je regulerni zapis (coz spis neni, kdyz kontrola konzistence pole ti vraci errory). Takze to spis muze byt vadnej port/kabel na jednom disku (pokud ten offset bude pri dalsich chybach indikovat ze to je puvodem z jednoho disku). Nez experiment s jinou verzi kernelu bych zvazil experiment se znatelne jinym hw (intel^amd) a ponechat jen disky, vymenit i kabely.

1769

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 27. 11. 2018, 04:31:51 »

Jako chova se ti to hodne divne.

Zkus namisto cteni pouzit kopirovani (do RAM - /dev/shm) a nad tim md5, pokud je stejny jako predesla kopie tak se udela cteni znova. Jen musis mit v ram dve kopie stejneho regionu. Az ti to zahlasi ze md5 nesouhlasi, tak ty dva soubory porovnas.. a zjistis co se s tim vlastne stalo - bud se zmeni 1 bit, nejaky sektor, nebo cely raid stripe.

Tip pro porovnani dvou X GB souboru: udelej si skript co projede pres 1M bloky md5 a pak diff tech dvou seznamu md5. Vadnej chunk pak extrahuj, hexdump -Cv a pak diff 1.hex 2.hex (takto jsem nasel 1 flipnuty bit v 18G instalacce).

1770

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 27. 11. 2018, 00:17:01 »

Cteni 10GB z /dev/sdX+1GB neodpovida lokaci ktera je z tech sestavenych disku do /dev/mdX+1GB

A pokud pises "provadi se zapis na jine misto", tak v pripade ze mas nad tim LVM, je zcela mozne ze ty bloky se ti prekryvaj a meni se ti /dev/mdX prave tam kde to necekas.