<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JImG1
<_whitenotifier-f>
[scopehal] bvernoux 6bfbfb4 - Fix Rigol MSO5000 issues/timeout bugs when retrieving :WAV:DATA Fix the issue https://github.com/azonenberg/scopehal/issues/358 glscopeclient hangs on Rigol MSO5000 This fix oscilloscope single trigger synchronization with waveform data by adding "*WAI" command which "Waits for all the pending operations to complete before executing any additional commands." (it is an
<_whitenotifier-f>
IEEE488.2 Common Commands)
<_whitenotifier-f>
[scopehal] azonenberg 7d3f4dc - Merge pull request #359 from bvernoux/patch-1 Fix glscopeclient hangs on Rigol MSO5000
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #358: glscopeclient hangs on Rigol MSO5000 - https://git.io/JImGd
<bvernoux>
miek, on some CPU it avoids to have all optimisations
<azonenberg_work>
to give you an idea of what the actual performance critical stuff looks like
<miek>
the gcc man page kinda says the opposite, it says that you can use -g with -O, but the optimisations might break your ability to debug. nothing about disabling optimisations
<azonenberg_work>
yes, exactly
<bvernoux>
anyway I definitely need a new PC ;)
<bvernoux>
I'm waiting Ryzen5 to have a beast
<bvernoux>
which crush all Intel CPU ;)
<miek>
might be thinking of -Og?
<bvernoux>
will be interesting to see how Ryzen5 work with glscopeclient ;)
<azonenberg_work>
Yeah probably. I do want to have a release no debug option available for reduced size binary releases
<azonenberg_work>
i'd like to ship binaries available with full debug info and stripped
<monochroma>
could do external debug files
<bvernoux>
hehe with Release flag the bin is definitely not the same ;)
<azonenberg_work>
Yeah i havent used that option myself but i think thats how debian does it now
<azonenberg_work>
with separate -dbgsym packages
<bvernoux>
28MB for glscopeclient
<bvernoux>
with Release
<bvernoux>
before it was 22MB I suspect it was debug build by default
<azonenberg_work>
There might be an "unspecified" config that's neither debug nor release
<bvernoux>
as optimisation with unroll/loop increase the bin size ...
<bvernoux>
ha yes ;)
<azonenberg_work>
the 6 MB might be debug info
<azonenberg_work>
if that's not enabled globally
<azonenberg_work>
idk
<bvernoux>
yes I suspect it was a strange build version ;)
<bvernoux>
the release seems quite faster
electronic_eel_ has quit [Ping timeout: 240 seconds]
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JImgi
<_whitenotifier-f>
[scopehal] bvernoux 4392d25 - Optimize Rigol MSO5000 AcquireData Optimize Rigol MSO5000 AcquireData as it does not requires "WAV:STAR" "WAV:STOP" SCPI commands before to call "WAV:DATA?"
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JImgy
<_whitenotifier-f>
[scopehal-apps] azonenberg 6d368af - Updated scopehal with Rigol fixes
<azonenberg>
bvernoux: and yeah in general, any optimizations that result in less commands going to the scope are going to be a significant performance increase
<bvernoux>
yes
<codysseus>
azonenberg: So I have played around with that example you wrote and it is cool! I am now trying to use it to extract the waveforms of each packet, but am struggling a bit. I tried converting from the offset back into rows in the CSV, but am getting odd results (m_offset + m_len > next packet's m_offset) am I going about this the right way?
<_whitenotifier-f>
[scopehal-apps] bvernoux commented on issue #28: Improve state of developer documentation - https://git.io/JImwa
<azonenberg>
codysseus: m_offset should be the number of time ticks since the start of the waveform for that packet
<azonenberg>
with time ticks measured in m_timescale femtoseconds
<azonenberg>
offset+len should always be <= next offset, however it is possible there are bugs causing an incorrect offset
<azonenberg>
When importing a CSV, i believe i always convert the input timestamp to femtosecond resolution since there's no way of knowing what the original scope's sample rate was
<azonenberg>
or if the samples are even at uniform intervals
<codysseus>
I will check with the unmodified values to make sure that is the case. I had tried to do some modification to make them correspond to CSV row numbers but that might have altered the value significantly.
<bvernoux>
very strange this crash with demo
<bvernoux>
with debugger it does not crash ;)
<azonenberg>
bvernoux: try debug build with asan and see if that gives you any info?
<azonenberg>
(just run it, not under debugger)
<bvernoux>
debug build does not crash too
<bvernoux>
only the release
<bvernoux>
when launched without debugger ;)
<azonenberg>
do you get any memory errors in asan that aren't fatal?
<bvernoux>
I does not have the setup for asan
<azonenberg>
debug build should compile with asan by default
<azonenberg>
unless you changed settings
<bvernoux>
but here my issue is with Release
<azonenberg>
Yeah, those are tricky to catch
<azonenberg>
can you enable coredumps and get a core?
<bvernoux>
I'm checking with VIsual Studio ;)
<azonenberg>
codysseus: the best way to trace back to a sample number on the input waveform is probably just to binary search the timestamp
<bvernoux>
it seems related to FFT
<azonenberg>
bvernoux: it's likely related to alignment then
<azonenberg>
possible the aligned memory allocator isn't acting right on windows
<bvernoux>
yes I suspect something like that too
<bvernoux>
which will explain sometimes it works
<bvernoux>
depending on memory ...
<azonenberg>
Yeah
<bvernoux>
Unhandled exception at 0x0000000001F82A56 (libscopehal.dll) in glscopeclient.exe: 0xC0000005: Access violation writing location 0x0000000011FE0000.
<azonenberg>
well that's great. stack trace? anything obvious?
<bvernoux>
0000000001F82A62 75 EC jne 0000000001F82A50
<azonenberg>
assembly without knowing what function it's in etc isn't all that useful :)
<bvernoux>
it is in Visual Studio let me check how to retrieve all the context
<azonenberg>
in any case, file a new bug against libscopehal for it
<bvernoux>
I suspect it cannot parse correctly debug as it is build with mingw64 ...
<azonenberg>
yeah it might have dwarf and not pdb debug info
<azonenberg>
why not use gdb?
<azonenberg>
can you attach gdb once it's started and then make it crash?
<bvernoux>
yes I will try to attach with gdb
<bvernoux>
as natively it is VS which is launched when something crash
<bvernoux>
so far I cannot make it crash when launched from gdb
<bvernoux>
it is the hard part ;)
<azonenberg>
Yay for heisenbugs
<bvernoux>
ha yes catched
<bvernoux>
Thread 17 received signal SIGSEGV, Segmentation fault.
<bvernoux>
[Switching to Thread 4808.0x1e94]
<bvernoux>
0x0000000002132a56 in ffts_generate_table_1d_real_32f ()
<bvernoux>
from C:\msys64\home\Ben\glscopeclient_build_release\libscopehal.dll
<bvernoux>
#0 0x0000000002132a56 in ffts_generate_table_1d_real_32f ()
<bvernoux>
(gdb) bt
<bvernoux>
from C:\msys64\home\Ben\glscopeclient_build_release\libscopehal.dll
<bvernoux>
#1 0xfffd17f9fffd15c8 in ?? ()
<bvernoux>
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
<azonenberg>
interesting
<bvernoux>
yes ;)
<azonenberg>
so ffts itself is crashing
<codysseus>
azonenberg: I did a simple test (p1 offset + len > p2 offset) and there are a lot of packets which overlapped.
<azonenberg>
codysseus: can you send me an input file demonstrating the bug along with any test code needed to reproduce? it's likely a bug in the usb decode
<codysseus>
Sure thing!
<azonenberg>
File a bug against libscopehal for it as well
<azonenberg>
anything you're ok with sharing publicly should go on the tracker
<bvernoux>
haha maybe it is because my CPU does not support SSE3 ;)
<azonenberg>
bvernoux: o_O. i dont know if ffts does any auto detection of that or not