<d1b2>
<dannas> @azonenberg Ok, I'll dig a little deeper tonight to see what the root cause of my crashes are.
<d1b2>
<dannas> How nice it would be if a small test suite that replayed a pre-recorded stream of SCPI/etcetera messages between each of the supported scopes and glscopeclient. Something to fast detect when you've introduced regressions, instead of having to find someone with each particular scope model. I saw that there was an issue for introducing some semi-automated testsuite that each owner could run, but maybe there's value in my pre-recorded stream idea.
<d1b2>
Oh well, I should probably shout up until I've actually started using and developing glscopeclient for a while. 🙂
<d1b2>
<dannas> makes a mental note to look into the EmptyConstructorWrapper class. I hadn't seen that "pattern" before
<azonenberg>
dannas: yeah i'm not sure if there is a better way to do it
<azonenberg>
the tl;dr is that the default constructor for a primitive datatype initializes it to zero
<azonenberg>
and that wastes time if i'm about to write to it
<azonenberg>
it was either this or writing a custom allocator, the latter is probably a slightly cleaner long term option that i might switch to down the road
<azonenberg>
i.e. making an allocator that deliberately does not call the constructor when creating a new object
<azonenberg>
and that you simply promise never to call except on POD datatypes
<azonenberg>
anyway, re the crashes you found earlier
<azonenberg>
this kind of stability improvement is the main thing i want to address prior to an official v0.1 release
<azonenberg>
I fix crashes as i find and reproduce them but some of them are pretty stubborn and i know are out there
<azonenberg>
but they never happen to die when i have gdb attached, etc
<azonenberg>
or it crashed once and i can't figure out how it got in that state
<azonenberg>
or something
massi has joined #scopehal
<GyrosGeier>
07:37 < azonenberg> the tl;dr is that the default constructor for a primitive datatype initializes it to zero
<GyrosGeier>
that is subject to dead store elimination
<GyrosGeier>
so if the default ctor is inlined it should make no difference
<azonenberg>
GyrosGeier: the issue is if you std::vector::resize() to preallocate memory rather than constantly memcpy'ing by calling push_back 1e6 times
<azonenberg>
you end up writing to a million elements
<azonenberg>
then again when you actually fill the vector
<GyrosGeier>
std::vector::reserve() should do what you want
<azonenberg>
That doesnt actually set the size though right?
<azonenberg>
if i'm doing a raw memcpy or socket read into the space
<azonenberg>
or similar
<GyrosGeier>
indeed
<azonenberg>
And if you call resize it calls the constructor
<azonenberg>
hence the point of my wrapper with a null inline constructor that gets optimized out
<azonenberg>
and thus the allocator only allocates space without actually writing to it
<azonenberg>
basically i want the convenience of a std::vector while being able to explicitly allocate uninitialized memory despite STL being designed to make that hard :p
<GyrosGeier>
do you actually resize the memory?
<GyrosGeier>
because otherwise a std::unique_ptr<unsigned char []> would also work
<GyrosGeier>
but yes, I agree that it's suboptimal
<GyrosGeier>
for memcpy, you can also use v.insert(v.end(), p, p + s);
<GyrosGeier>
to copy s elements starting at p
<GyrosGeier>
that will also adjust the size and directly copy
<azonenberg>
So yes, i often do resize if you change acquisition depth on the scope. and that only works if your input is of class type etc too
<azonenberg>
the code writing to the array is often hand tuned vector intrinsics
<azonenberg>
i need access to the raw memory buffer
<azonenberg>
but then i have to patch the size to make it work
<azonenberg>
This is pushing limits of what people usually use STL for
<azonenberg>
as an example, the code writing to the array is often taking uint8 or uint16 adc samples, applying gain/offset correction factors, then writing float32 to the vector
<azonenberg>
And doing that with carefully optimized AVX code doing like 16 samples per block
someone-else has joined #scopehal
<GyrosGeier>
mh
<GyrosGeier>
we're probably in "custom allocator" territory there anyway
<GyrosGeier>
allocating hugepages would be useful here, for example
<GyrosGeier>
there might even be a nice path to make these available to DMA
<azonenberg>
Yes, that's the kind of thing I'm starting to look into down the road
<azonenberg>
ideally DMA from NIC directly into GPU memory; my endgame is to do as much of the signal processing as possible on the GPU
<GyrosGeier>
one of the things I'm currently looking into is how to talk to an IOMMU from the PCIe bus
<GyrosGeier>
and ask for user pages to be mapped
<azonenberg>
But there's a lot of stuff to do ahead of this still
someone-else has quit [Quit: Connection closed]
balrog has quit [Quit: Bye]
balrog has joined #scopehal
someone-else has joined #scopehal
<d1b2>
<dannas> New day. New attempt at connecting to the Rigol MSO1104. The RigolOscilloscope class does a check for the model number and assumes that models starting with MSO are MSO5000 models. When I commented out that check and set the model to DS_OLD, the program no longer segfaults. Uhm, but it took close to a minute before the waveforms appeared on the screen. I wonder what memory depth it uses.
<d1b2>
<dannas> 4 WFMs, 0.06 WFM/s.
<d1b2>
<dannas> checks the glscopeclient for hints on suggested memory depth for rigol scopes and how to set it up.
<d1b2>
<dannas> It's annoying that the UI hangs while downloading. And it hangs when I tried connecting to the wrong host too before. Maybe it's worth investigating how to avoid such freezes.
<d1b2>
<dannas> Ouch, now glscopeclient died with Gdk-Message: 17:40:23.075: Lost connection to Wayland compositor.
<d1b2>
<dannas> googles that error message
<d1b2>
<dannas> There was no crash. Maybe Wayland shut down the application due to not being responsive?
massi has quit [Remote host closed the connection]
<d1b2>
<dannas> Time to leave the office. So when I set m_protocol = DS, atleast I could display waveforms on the screen, but then the application locked up.
<d1b2>
<dannas> At some point the scope locked up. I had to restart it and reconfigure its LAN settings.
<d1b2>
<dannas> So some progress, yay! Next step is understanding how we setup capture depth.
<miek>
double click on the time axis
<d1b2>
<dannas> miek Thanks.
<d1b2>
<dannas> Tried setting m_protocol=DS_OLD and got a sigsegv inside ReadRawData.
bvernoux has quit [Quit: Leaving]
<azonenberg>
dannas: yeah i didnt realize that anything prior to 5000 series had a MSO name. i'm used to DS1100D model names
<azonenberg>
for their old gen MSOs
<azonenberg>
The MSO1xxx might be a different protocol?
<_whitenotifier-1>
[scopehal] fridtjof synchronize pull request #513: Small Darwin build fixes - https://git.io/JV85B
<Degi>
Hmm, the MSO5000 also has/had the issue of the scope hanging up after a while, but I think it can get close to 1 WFM/s