Zasto glavi fwrite() pri 25 zapisa/fajlova u sekundi?

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 ...

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

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.

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 ...

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

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 :)

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

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 ...

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

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 ... :(

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

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.

Potpis

gorankg

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 ...

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

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 ... :(

Potpis

Site about Software Defined Radio – SDR
http://yu3ma.net/
https://github.com/yu3ma
On-line LM317 kalkulator

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

Potpis

gorankg