Nisi pokazao kako inicijalizujes len, potom sample count. Ako je to dobro, onda problem moze da bude to sto flushujes svaki
taj write, pa tu moze malo da koci. Inace nw vidim neki problem.

Duzina koja stoji u len je dobra, to je integer i koristi se posle prilikom dekodiranja paketa, to je OK.
U vezi sample_count, isto obican integer, pocetno inicijalizocan na 0, sa tim hvatam prvih X semplova, nista specialno po tom pitanju.

Ali ovo pisanje nesto nije dobro, ne znam sta tacno, mnogo sporo to tako radi.
Na primer kada pokrenem taj program, snimi 125 semplova i zaglavi, sledeci put 132, pa 140 i tako kako mu se cefne, nesto mu je debelo vremenski kriticno ali ne kontam sta i sto je najludje slicno se ponasa na RPi i i7 masini na razlicitim OS, to mi tek nije jasno ...

To parce coda se poziva na svakih 40ms (25fps), recimo da sam potrosio oko 15-ak milisekundi za neko tu potrebno procesiranje, ostalih 25ms bi valjda bilo dovoljno da snimi jedan fajl od 5KB, ako potrosi vise od 25ms e onda moze da bude frka jer ja moram da obradim paket u raspolozivom vremenskom intervalu.

Mislim, mogu da trpam sve u RAM, nije to puno podataka za recimo 1000 semplova (1000 * 5kb = 5MB) i da odvojeno posle samo snimim to u fajlove van ove vremenski kriticne funkcije.

Ali mi nije jasno sto ovako ne radi, gde se potrosi to vreme za pisanje ...

Znas kako nemoj odmah fclose , odlozi fclose naknadno. To ne bi trebalo odmah da glavi nego tek na fclose.

Probao sam bez fclose() (komentarisao celu tu liniju) i isto se ponasa ... :(

Proveri onda da li svaki fopen uvek uspeva, nisam siguran da li fwrite pukne ili nesto drugo kad mu se prosledi null.

Jel se ovaj deo koda poziva sekvencijalno ili je multi thread aplikacija?

I na kom delu tacno zaglavi?

@Doktor Hlad

Ovo parce code se vrdi u main treadu, postoje jos neki treadovi ali oni nisu vezani za ovaj problem, totalno drugo nesto rade.

Probacu da napravim poseban fajl sa simulacijom ovog problema pa mogu da podelim celu skriptu i eventualno ako hoce neko da proba kod sebe ...

A je l' treba "samlpe_count" ili "sample_count"?

Ja probao upise 1000 fajlova bez problema. Znaci da neki thread zeza...

U pravu si, slovna greska u nazivu ali nije to problem, to je to ime variable koje se samo tu koristi ...


Dobijem ja tacno

sample_001.dat
sample_002.dat
sample_003.dat
...

I unutra tacno sta treba zapisano i ispravne duzine fajlovi, ali tamo oko cirka 5. sekunde kada stigne do 125. sempla mu se "prispava", "ne moze da postingne", ne znam kako da objasnim :) i tu se zakoci, ne pukne samo se zakoci i onda se predje predvidjeno vreme za frejm pa mi stize drugi frejm a ja ovaj jos nisam zavrsio i tad zablesavi.

Kao da neki poseban servis na *nix koji se bavi otvaranjem nodova i fajl-pointera se aktivira pri nekom broju fajlova u sekundi (rate) i ulazi u neki drugi mod ili sta vec, uglavnom to pojede vreme i to me muci ...

A da se tebi ne zaglavi to citanje frejmova? Ovaj kod sto si poslao nema nikakvih problema ;)

Pa kad izbacim to parce coda za pisanje fajlova sve odlicno radi, veruj mi da sam testirao na 1 milion procesiranih frejmova na RPi i radilo je bez greske, kako sam ovo dodao tako je otislo sve u 3 lepe ...

Nije problem u pisanju fajlova sigurno nego u kombinaciji sa ostatkom koda. Mislim da ako taj kod ne radi, onda bi zaista bilo mnogo alarma po svetu :P

Prevideh ovu poruku ...

Probaj molimte samo da to radis u tacnom ritmu od 40ms, dakle svakih 40ms nov fajl i ako mozes nekako da pratis vreme izvrsavanja tog pisanja, cela je poenta da se ne iskoci iz tog vremenskog okvira jer tada kada se iskoci nastaje problem ...

Cuj, kod mene upise 1000 fajlova za 38ms i to bez optimizacije. Totalno je nebitno dal ces da spavas ili ne izmedju pisanja. Tvoj deo za citanje frejmova najverovatnije zaglavi.

Probao sam ponovo ali nemam taj tamo senzon koji pljuje pakete nego ono malo paketa sto je snimio sam iscitao i to vrtim u krug + snimam u nove fajlove semplove i to kao radi ... e to je situacija :) ... a senzor nemam ovde, on je na 150km drugoj lokaciji na masini niti imam duplikat senzora ... "Bolesni" je u pitanju ... :)

_{[Ovu poruku je menjao mikikg dana 24.09.2020. u 00:32 GMT+1]}

Miki, možeš da simuliraš taj senzor nekim tvojim hadrverom. Kako se vezuje na RPi?

Senzor je povezan preko LAN sa TCP soketom, to radi sve lepo i sa tim nemam probleme.

Problem je nastao kada sam bas tamo gde procesiram TCP paket uzeo da petljam sa fajlovima, tu mi bilo zgodno da snimam i posle reprodukujem ponasanje i da mi ostane sve u programu manje vise na svom mestu.

Mozda bi pre zavrsio posao WireShark nego ja da petljam i snimam taj TCP saobracaj koji je uglavnom u jednom smeru i ne kriptovan? :)

Miki, ja bih na tvom mestu dodao malo printf da vidim šta se događa.

Prva, glupa, glupa ideja koja mi pada na pamet je da probaš da otvoriš fajl sa "w", a ne sa "w+".
Druga glupa ideja je da se to tvoje zaglavljivanje dešava posle 512kB pročitanih frejmova. Da nisi negde zaboravio da dealociraš prostor?
Treća glupa ideja je da len predstavlja kumulativnu dužinu pročitanih paketa, pa oda pišeš 5kB, pa 10kB ... i onda ti se fajl toliko poveća da len bude duži od bafera.

Što odmah potežeš tešku artiljeriju? netcat može sasvim lepo da ti završi posao...

Ajmo ovako posaljes minimalni kod koji reprodukuje problem. Probaj bar to. Mislim siguran sam da zaglavi negde kod citanja. Znaci posalji taj kod koji cita + to sa fajlom.

Ne mogu da reprodukujem problem u lokalu bez tog senzora ... :(

Ovo je konkretno parce code-a koje koristim (dobudzeno malo za moje potrebe) i tu na 225. liniji sam umetnuo ovo za pisanje u fajlove:
https://github.com/konradb3/li...346b6d74d989ae/LMS1xx.cpp#L225

Dakle bez tog dodatka za pisanje u fajlove mi sve lepo radi ...

Ja i dalje ne videh odgovor na moje pitanje: na kojoj tacno liniji "zaglavi"?

Cenim da ce odgovor na to pitanje mnogo da nam kaze :)

Znas kako ovaj kod nije bas industry strength, tj imas posla sa soketima a ne proveravas da li iskace greska na bogus input
i uopste svaki od tih read/write callova ka soketima moze beskonacno da blokira.
recimo ovo:

Ne sme nikako da prodje bez provere, jer moze da zaglavi.

Ovo isto moze vrlo lako da zvekne:

Znaci len se konstantno uvecava pa moze i da pukne ili da beskonacno blokira. Znaci ovde treba uslov za izlazak da bude
i kad se dotigne procitanih 20000. Ali ovo podrazumeva savrsen drugi kraj.

edit:
i da uslov za izlazak je besmislen jer se ovo moze desiti samo kad se iz cuga sve procita pa ceo marifetluk sa parcijalnim
citanjem prakticno znaci da ce uci u beskonacnu petlju.

_{[Ovu poruku je menjao Branimir Maksimovic dana 24.09.2020. u 10:27 GMT+1]}

Nemam senzor kod sebe i ne mogu da reprodukujem problem, trenutno samo znam da se "tu negde" u tih 10-ak linija koje se bave pisanjem u fajlove zaglavi.
Sta je konkretno uzrok stvarno ne znam, kada bih znao mozda bih i resio ...

Detaljno testiranje oko toga mogu da nastavim tek kada ponovo odem na teren kod te masine, poveca djunta od 10-ak tona, 30+kW u servo drajvu, senzor je uvezan u vrlo slozen custom PID algoritam ...

Znas kako gde zaglavi mozes ili poor man debuggingom uz pomoc printf ili da pokrenes debuger pa vidis gde zaglavi. U fwrite/fopen/fclose ne moze da zaglavi beskonacno sigurno.
Moze malo da laguje, ali da zaglavi jok.

Mnogo mi je kritican taj deo coda-a koji se bakce dekodiranjem podataka, ne smem to da cackam tek tako niti bilo sta da menjam jer ne mogu lako da testiram ...
Bez ovih zadnjih izmena oko fajlova spomenuh da sam testirao na 1+ milion frejmova i radilo je bez greske.

Najverovatnije cu onda da batalim da to snimanje radim na tom mestu gde sad radim, prebacicu cu to u neki drugi proces ili jednostavno da snifujem (netcat-ujem) TCP saobracaj pa posle u nekom post-procesiranju da izvucem/snimim lepo fajlove ...

Cela ova zaludjica mi treba da bih snimio nekoliko sekvenci iz realnog ponasanja masine pa posle sa tim da radim offline na nekim specificnim algoritmima za prepoznavanje oblika ... ma ludnica :)

BTW:

Kada se prebacim u "read from files" mode, na istom mestu gde sam radio write samo se prebacim na read to radi bez greske, evo imam ovde neki RPi koji vrti to vec 10-ak dana neprekidno, sve radi odlicno ...

U tom slucaju mozemo samo da nagadjamo. Probaj da izmenis kod tako da snima u RAM umesto u fajl i onda kada dodje do 1000 snimi sve u fajl. U tom slucaju ces imati upis samo jednom. I sto rece neko fopen/fwrite/fclose mogu samo malo da koce ali nikako da zaglave skroz.

Znas kako mogu da se kladim da zaglavi u tom readu od 20000 bajtova. Sa obzirom da tu ne znas ni pocetak ni kraj, tj kraj je da procitano 0x3 u zanjem procitanom bajtu,
ako se paket polomi na vise delova sigurno si u problemu. To se verovatno ne desava kad ne upisujes u fajl ali taj delic sekunde dok se upisuje
u fajl izaziva delay, koji ispoljava problem.

To je vrlo moguc scenario, u sustini to se tacno i desava, nesto se zabrlja sa duzinom paketa i oko detekcije kraja paketa sa 0x3.

Ovu konstataciju potvrdjuje situacija da zadnjih par fajlova koje snimi (kada zabaguje) iz nekog razloga u sebi ima snimljeno 2 ili 3 paketa!!?

Evo konkretni primeri, to je zadnjih 5 paketa koje je snimio. Semplovi 150 i 151 su ok kao i svi predhodni pre toga, e onda se pojavi 152 koji ima dva paketa, pa se posle pojavi 153 i 154 koji imaju 3 paketa i posle toga zaglavio ... :(

Pazi, ako se paket pocepa na vise delova sigurno ce izaci iz petlje pre nego sto procitas kraj.
Znaci algo treba da ide ovako:
citas, potrazis 0x2 to je pocetak i citas sve dok ne naletis na 0x3 kao oznaju za kraj.
Da se ne bi zezao sa pretrazivanjem bafera, najbolje ti je da citas bajt po bajt.
ne treba ti ni select takodje koliko vidim.
Posto se tcp baferise to usporenje u n pozivu f-ja neces ni osetiti na nivou milisekundi.

I za neki sledeći problem, ne daj bože :) treba da imaš "senzor" kod sebe. Zato sam ti preporučio da ga simuliraš na nekom hardveru. Jedan STM32 Nucleo sa Ethernet-om i gruvaj pakete na prekid tajmera. AKo nemaš kod sebe ja ću da izbunarim Nucleo, treba da imam neki ovde.

Posto ne mogu to procesiranje paketa da menjam/testiram bez senzora, hajde onda makar da izmestim problem na drugo mesto, tj da smislim nesto sto ce sigurno da mi zavrsi posao za snimanje semplova kada odem na teren kod masine.

Taj senzor ima u sebi TCP server i dozvoljava vise klient konekcija.
Jednom kada mu se posalje komanda za startovanje on posle sam izbacuje pakete, dakle odatle nadalje je sve u jednom smeru, svakih 40ms pljune jedan paket.

Predlozite mi neko *nix resenje/komandu koja se okaci na taj soket i sve sto primi da snima u jedan fajl? Posle cu ja taj fajl da obradujem i vadim pakete ...

Znam sta mi pricas ali mi je prilicna komplikacija da napravim simulator tog senzora. To je "bolesni" Lidar sa cenom izrazenom u 5 cifri USD, zato i nemamo drugi senzor ... :(

Ja bih to definitivno sa dva threada. Jedan thread slusa i salje drugom na upisivanje a drugi na svojoj strani ima implementiran thread-safe queue. Izgleda da ti imas situaciju da tvoj senzor salje u momentu dok ti vrsis upisivanje i ne slusas sta salje pa se onda mozda prepuni bafer pa ne pokupis sve i onda cekas nesto sto je on vec poslao... uglavnom to ne izadje na dobro.

Meni to mirise da moze sa NodeRED brzo da se resi. Otvoris TCP, posaljes komandu i onda slusas i guras u neki queue koji ce da cita drugi proces i da upisuje.

Probaj sa netcat

Pošto moraš da znaš protokol ne vidim problem da implementiraš server koji će da glumi senzor... please

edit:
ovo please je sam ubacio telefon ;)

Da tebi ne fali "b" za binary mode?
Jer ovako ti fwrite procesira input buffer kao da je tekst.

Koristi Linux, nema tu binary mode.

Heh, pa ne moram bas toliko detaljno da poznajem protokol, nije jednostavan ima tu dosta stvari:
https://www.sick.com/media/pdf/7/27/927/IM0045927.PDF

A i kada bi napravio protokol opet imam problem sa fundamntalnim stvarima koje se ticu tog senzora a to su izmerene vrednosti tacaka, kojim trikovima da simuliram na primer ovakav rezultat, "fleka od tacaka" koja menja oblik i seta se po ekranu, + jitter + false-detection + + + ...
Ovo je kao jedan objekat koji pratim, tek trebam da se bakcem sa algoritmima koji nekako/nesto prepoznaju u toj gomili tacaka ... Zato mi treba snimak, ne mogu to da simuliram ...

Ma sadrzaj paketa je totalno nebitan. bitno da izsimuliras slanje tih paketa na 40ms. Mogu biti potpuno prazni. Cilj je da popravis onaj read tj prepoznas 0x2 kao pocetak 0x3 kao kraj i odvojis paket, mozes onako kako sam rekao.

Razumem sta pricas, ja tu imam vise problema, ja sam po default u problemu jer vidi sta mi stize od podataka, to mi je najveca zaludjica tu celoj prici, "hteo sam samo" da snimim seplove i lupio glavom o zid iz taka kada sam probao to tamo da uradim u delu code-a koji obraduje prijem sa soketa, necu to da diram vise, prebacicu se ko covek lepo na drugi soket kanal i asinhrono da hvatam to, ne smem da pipam klasu za to procesiranje, samo mogu da je menjam pod striktno kontrolisanim uslovima i da se testira.
U tom parcetu mi je i neka bitna logika za konverziju sfernih u planarne koordinate, pa hvata neke minimume/maksimume po grupama, kritican mi je taj code, to ce na kraju da bude najverovatnije uvezano ili pripremljeno za ML/AI.

Pazi kod je neispravan, to ce praviti probleme dalje ako to ne resis. Cela fora je da paket mora da bude iz jednog "dela" (tcp ima maks duzinu, mislim na jedan poziv read) primljen da bi radilo, a tcp to ne garantuje.

Socket select su stavili da bi mogli da setuju timeout, tu je 50ms, cudna vrednost ali to radi, to je kontinualni sistem i jednostavno mora da tera dalje sta god da mu se desi.



Sto se tice bogus inputa i 0x2 0x3, to si u pravu, provericu to ...

Ehhh ... :)

Samo jos onaj tab "EMULATORS" da proradi i pobedili su :D

Kakvu svrhu ima timeout kad je petlja? Pazi ulece u beskonacnu petlju na kraju.... to da li ce zauzimati cpu 100% u toj petlji nema nikakve veze.

Elem da se vratimo na kod:


Dakle, ovo je petlja. Tu select nema nikakvu svrhu. select ima svrhu samo onda kada osim citanja radis jos nesto dok cekas na input. Dakle ovde select moze da se izbaci.
Drugo da ti ne bih komplikovao da obrazlozim sta je ovde propust.
Pitanje buf[0] != 0x2. To. Dakle ako je buf[0] == 2 izlazi iz petlje i tu nastaje karambol. Zato sto nema garancije da je paket ceo procitan. Ako izbacis
to pitanje i ostavis samo buf[len-1] != 0x3 nece upadati u mrtvu petlju zato sto pretpostavimo da svaki kraj paketa zavrsava sa 0x3. Nema garancije
da neces procitati vise paketa, ali bar nece da uleti u mrtvu petlju.
E sad evo kako sam ja (netestirano) odradio, pa vidi, probaj, ne skodi ;)


Dakle citas karakter po karakter sve dok ne naletis na 0x3. Ono sto je interesantno je da hvatas pocetak, tj 0x2 znaci skipujes
ako si promasio pocetak.
string sam uzeo jer je tako jednostavnije nego sam da upucavas u neki bafer i bavis se time.

Mali update na temu, posto sam na srecu lepo organizovao memoriju i sve ovo sto se gore radi se smesta u moju /dev/shm, celu stvar oko snimanja a i tamo neke druge komunikacije sam resio preko NGINX :)

Konkretno nisam dirao ovaj code koji se bavi skumpljanjem podataka, tek cu time da se bavim nakanadno ali sam celu stvar externe I/O komunikacije resio sa jednom C skriptom (NGINX modul) koja pravi most izmedju moje SHM i HTTP (nema nikakav file I/O, sve iz memorije) i to radi mnogo lepo i to moram da napomenem na ARM RPi 2 koji gura i GUI pored svega, NGINX to servira u pozadini bez problema i moze da servira do punih 100Mbit/s na jednom RPi za zauzecem jednog core-a oko 50-55%, sjajno radi.
NGINX radi tako da koliki je PING u mrezi toliko mu treba vremena da vrati odgovor :)

Za klienta sa druge strane konekcije sam iskoristio libCurl koji se pokazao isto odlicno tako da sam na kraju mogao da izvucem cak 450req/s sa paketima od 20kB sto meni ihaaahaaa kako zavrsava posao jer mi je trebalo 25req/s :)