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

[Petr Labaj]

Že vlastní nalogování už má pan Anděl vyřešené a že to nebude dělat na 
PC ale na dedikovaném HW jsem se dozvěděl až později. Proto jsem do 
rozepsaného mailu dopsal to PS.

Původně zazněly návrhy na textovou reprezentaci dat. Pak to asi nebudou 
4 byte na jeden vzorek ale mnohem víc.

I jen 10Gbyte (ze kterého mě budou zajímat jenom zlomky procent) je dle 
mého vidění světa zbytečně moc. Mám rád technicky efektivní řešení, i 
když nemusí být současně i časově/pracností efektivní. Zvlášť v případě, 
kdy to možná není jen jednorázovka, protože pro pana Anděla je myslím 
oblast těchto drenáží výraznou částí jeho byznysu.

Měl jsem vždy pocit, že LabView je SW za docela mastnou cenu. Nebo je k 
tomu nějaká nekomerční licence zdarma? (i když zrovna tento úkol asi 
zrovna nesplňuje charakteristiku "nekomerční", ale nebuďme prudérní)
Nicméně myslím je i nějaká free aplikace podobného zaměření, ale jméno 
si nepamatuju. Kolega to kdysi používal a ukazoval mi to, ale je to už 
dávno.

PL

*****************

Dne 9.12.2024 v 19:16 Jindrich Fucik napsal(a):
> Ahoj,
>
> nic proti, ale Vláďa v tomto mailu píše, že data už jsou na SD kartě:
> https://list.hw.cz/pipermail/hw-list/2024-December/578128.html
>
> Popisuje i jak se tam dostala a tak dále. Takže vstupem je fakt, že 
> máme soubor, který obsahuje dva kanály šestnáctibitových dat. Všechno 
> předtím už se stalo a není potřeba to řešit.
> Teď je na řadě je analyzovat.
>
> Já si myslím, že LabVIEW s tím bude v pohodě a zvládne to. Druhá 
> možnost je ten picoscope.
>
> Tak a ještě bych se rád dopočítal k počtu vzorků.
> Týden má 7 dní, den má 24 hodin, hodina má 7200 sec, sekunda má 2000 
> vzorků. Tedy 2419200000 vzorků ~ 2,5 giga vzorků
> Hrabat se v takovém množství dat mi nepřijde zase tak strašné. Je to 
> jen 10 gigabajtů dat, to se vejde do paměti.
>
>
> Dne 09.12.2024 v 16:45 Petr Labaj napsal(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.
>>
>> ******************
>>
>> Dne 9.12.2024 v 13:55 Jindrich Fucik napsal(a):
>>> Já v tom nevidím žádný problém.
>>> Když se podívám na to co prohazuju skrz USB při každém videocallu, 
>>> tak přenášet a ukládat 4kB za vteřinu je naprosté nic.
>>> Takže jak jsem psal hned na začátku - pro software pro digitální 
>>> osciloskopy je to celkem přijatelná míra informací. Kolik toho 
>>> nasampluje normální osciloskop? 40 mega samplů je spíš základ, 10 
>>> bitů na vzorek je spíš horší osciloskop, dva kanály zase úplně 
>>> běžně. Takže Vláďa se pokouší přenášet 1000x méně informace za vteřinu.
>>>
>>> ---------- Původní e-mail ----------
>>> Od: Petr Labaj <labaj na volny.cz>
>>> Komu: hw-list na list.hw.cz
>>> Datum: 9. 12. 2024 4:45:42
>>> Předmět: Re: vykreslování grafů z velkého množství dat
>>>
>>>      No proč ne. Náš zákazník, náš pán.
>>>
>>>      Já bych to tak ale určitě nedělal.
>>>
>>>      Ukládat místo 10GB dat zbytečně třeba 50GB - děkuji, neprosím si.
>>>
>>>
>>>      PL
>>>
>>>
>>>      *****************
>>>
>>>
>>>      Dne 9.12.2024 v 4:30 Pavel Hudeček
>>>        napsal(a):
>>>
>>>
>>>        Já bych si teda s rychlostí ukládání TXT dat ve windows nedělal
>>>        starosti. Na ukládání dat z detektorů částic máme textové i
>>>        binární, zákazníci slině preferujou textové. A vůbec jim nevadí,
>>>        že je dat tolik, že to vytíží USB 2 na 100 %, nebo jiný zas 
>>> vesele
>>>        ukládaj text z dat co plně vytížily Gb ethernet a ani s USB3 
>>> není
>>>        problém. Až když je těch USB 3 víc ks paralelně, začínaj 
>>> speciální
>>>        přístupy.
>>>
>>>
>>>        PH