Re: vykreslování grafů z velkého množství dat

[Jan Waclawek]

[preposielam]

Dobry vecer,

p.Labaj vystihol ste to velmi dobre, ze problem ma dve roviny. Hardware a software. Pricom hardware ma tie problemy dva. Prvy je pravidelne vzorkovanie co 500us nove data, a druhy je zapis bloku dat do nejakeho pomaleho zariadenia s dlhou odozvou. Ono aj SD-karta ma nejake ms na zapis bloku. Takze je tu problem vzorkovanie 500us a zapis dat v milisekundach. To sa riesi pohodlne tou dual-port RAM, co som ju spominal rano v mojom emaily, ktory uz davno zapadol prachom.

A teraz este ku tej softwarovej casti. Budete potrebovat nejaky editor, ktory Vam umozni rozsekat povedzme 1GByte file na mensie subory. To tiez nie je trivialny task a rozne textove editory to riesia inak. S niektorymi sa pri takto velkom file neda vobec pracovat.  Berte to prosim p.Andel s rezervou, je to moja skusenost spred cca. 15rokov. Mozno to Vase audacity to vie bez problemov urobit. To neviem zase ja. Ale rozhodne budete tie velke logy spracovavat v mensich suboroch, mozno po dnoch a po hodinach. Tu si myslim, ze p.Labaj ma dobry napad, ze predspracovanie by mohol urobit ten procesor alebo mikrokontroler, ktory sa bude starat o zapis dat do pomalych pamati a komunikovat s PC, tie data budete musiet totiz nejako dostat aj do PC. 

A.
>>>
Ten úkol má 2 roviny.
Jeden je rychlost sběru dat, které to musí bez zakoktání ukládat.
A druhá je pak výsledný objem dat a práce s ním.

Osciloskop určitě dokáže sejmout rychle nějaké vzorky, je to jeho práce.
Ale zase většinou není dělaný ta to, aby to kontinuálně snímal několik dní.
A má na to snímání a bufferování dat příslušný HW.

On to podobně v jenom z předchozích mailů pojal pan Hudeček. Kde spočítal,
že je to za sekundu nějaký objem dat, a že to tedy nic není.

Ale to nejsou data za sekundu. To by byly po nějakém bufferování nějakým
HW. Třeba to ESP32, od Číňana za 45 Kč holý modul nebo za 100 Kč i s deskou.
Pak už to samozřejmě pro PC není řádný problém.
Ale problém může nastat, pokud ta data chodí pravidelně každých 500us.
A pokud se na chvíli PC zaobírá něčím jiným, tak mu nebufferovaný vzorek
může utéct.

Je to problém, který se řeší třeba při SW ovládání CNC. Tam těch dat, které
PC pošle driveru krokáčů nebo serv, není moc. Kdyby se to spočítalo jako
kB za sekundu, tak je to sranda.
Ale jde tam o přesné načasování toho odesílání. A často to třeba ani moderní
nabušené PC se spoustou GHz nezvládá, ale nějaký starý střep s pomalým
Atomem klidně ano. Jen proto, že má líp vyřešené latence, resp. jitter 
té latence.

Prostě podle mě PC s Windows není pro real-time aplikace vhodná platforma.
A stejně tak podle mě u velkých dat stojí zato se zamyslet jak s nimi 
nakládat.
A ne je jenom zednicky hrnout na velkou hromadu s tím, že "výkonný stroj
to zvládne". A když něco nestíhá, tak přidáme GHz a GByte, místo abychom
se zamysleli.

Ze školy (asi ze základky) si to pamatuju jako rozdíl mezi intenzívním a 
extenzivním
rozvojem zemědělství. U intenzivního se snažíme mít vysoké výnosy a malé 
ztráty.
U extenzivního prostě osázíme větší plochu a kašleme na efektivitu.

PL

PS. Nicméně mezitím se vysvětlilo, že to pan Anděl bude mít bufferované 
nějakým
svým oblíbeným Silabsem a ukládat dedikovaným HW.
Takže už zbývá jen druhá rovina problému - práce s obrovskou spoustou 
dat, ze
kterých zřejmě 99.95% bude k ničemu.
Takže kdyby to ukládání řešil něčím inteligentním (třeba tím BluePill 
nebo ESP32),
tak by mohl předzpracování řešit hned na něm a ukládat jen zajímavé sekce.
A mít tak možnost s rozumným množstvím dat udělal záznam třeba celý rok,
případně furt.