<azonenberg>
@louis: so @MP is saying you were going to be fixing some stuff around blocking calls?
<azonenberg>
Let's discuss the specific pain points in detail
<azonenberg>
so you don't duplicate effort
<d1b2>
<louis> Yeah, just that at some point we'll want to work on the UI-lockup inducing stuff referenced in (b) above
<azonenberg>
So the first step is going to be making sure that all calls to the transport use the write queueing layer in the transport
<azonenberg>
(see the siglent driver for an example of this)
<azonenberg>
and you should not lock the main mutex for these as writing to the queue locks the queue mutex momentarily, pushes the command, then releases it
<azonenberg>
Basically, there's fundamentally two kinds of blocking going on in the UI thread
<azonenberg>
the first is unnecessary blocking, such as blocking on a mutex for the socket when you try to change volts/div during a waveform download
<azonenberg>
the queueing layer will help reduce or eliminate this
<azonenberg>
the second is unavoidable blocking, where some UI event relies on the result of a query
<azonenberg>
When the result in question cannot be cached, or the cache is not hot, there's no way to avoid waiting for the result
<azonenberg>
so the next best option is to use async callbacks of some sort, for example popping up the dialog immediately but not populating the entry in a list box for a second or two
<azonenberg>
Making this easy to avoid is one of the goals of the twinlan protocol
<azonenberg>
you can be calling methods against the scpi endpoint while the waveform endpoint is busy
<d1b2>
<MP> Async callback please
<d1b2>
<MP> 😂
<azonenberg>
But that's a lot more work for less return IMO. Write queueing needs to happen first
<azonenberg>
and be deployed across as many drivers as possible
<azonenberg>
when we did it on siglent the benefits were immense
<d1b2>
<MP> Also true
<d1b2>
<MP> Let’s see how it goes
<d1b2>
<MP> @louis also you may want to go to USB3 Instead if lab
<d1b2>
<MP> Few more gigabits to be had
<d1b2>
<louis> Yes, that'd be good to try
<d1b2>
<louis> Also on my todo list is to break up large CURV? downloads into a number of smaller downloads of segments of the curve,
<d1b2>
<louis> mostly to allow more granular hang-recovery, but you could also release the transport lock to allow UI threads to sneak in
<azonenberg>
@MP i do not think that will help with the mso
<d1b2>
<louis> though that is probably just a worse solution than pre-populating all the cache fields
<azonenberg>
firmware is the limiting factor not transfer rate
<azonenberg>
yeah the UI thread should avoid blocking on the transport lock as much as possible
<azonenberg>
hence write queueing
<azonenberg>
and caching
<azonenberg>
you hit the cache or transport lock momentarily then release it
<azonenberg>
and the main waveform thread doesnt hold it
<d1b2>
<louis> at the cost of overhead from chunking
<azonenberg>
Awesome
<azonenberg>
noticing any render lag when panning around etc on the big captures?
<azonenberg>
if you zoom in it's not a big deal, if the entire waveform is on screen 100+ megapoints is going to give your GPU a workout
<d1b2>
<louis> will investigate further later; i think it is a question of the scope blocking at the CURV? query for longer than the socket timeout. so may be possible to avoid chunking or have much larger chunks if i fix that
<d1b2>
<louis> yeah; something's screwed up and it won't let me zoom out past like 1ms
<azonenberg>
yeah makes sense. and i think there is some numerical precision issues in rendering with like e8 and larger sample waveforms
<azonenberg>
I need to investigate that
<azonenberg>
i've noticed some weirdness in the display
<azonenberg>
the samples are fine, the DSP works fine
<azonenberg>
but i think somewhere i convert X axis positions from int64 to float32 too early or something
<azonenberg>
and end up getting rounding error
<azonenberg>
Interesting observation: per docs, the integrated func gen on the Siglent oscilloscopes is the same, or almost the same, SCPI API as the SDG series AWGs
<azonenberg>
(just with one channel instead of two, and less BW etc)
<azonenberg>
when i'm done with this scope i might ask jason to send me a SDG so i can add support for that
<azonenberg>
(I'm writing the func gen driver now, should be done later tonight)
<azonenberg>
Well, i got distracted from the siglent func gen code by looking at performance counters for the DDR interface on the sniffer board
<azonenberg>
it's not good
<azonenberg>
with my current test waveforms etc i'm pushing 12.6 Gbps of data to the DRAM
<azonenberg>
I have about 9 Gbps of available capacity
<azonenberg>
and the remaining ~23 Gbps of bandwidth is unusable due to overhead
<azonenberg>
right now i am using 4 bank machines in the controller, i'm going to experimnet with what happens when i change that
<azonenberg>
and compare performance/area tradeoffs
<azonenberg>
but i may also have to explore changing access patterns etc
<Degi>
72 % of the bandwidth is overhead?
<azonenberg>
Degi: no, about half. theoretical peak is i think 41.6
<azonenberg>
64 bit bus @ 650 MT/s
<azonenberg>
I define "overhead" as any cycles in which the controller indicates it's not ready to accept a command
<azonenberg>
and i subtract 256 bits of BW (the controller bus width) from the theoretically usable BW
bvernoux has quit [Quit: Leaving]
<d1b2>
<mubes> I totally messed up my config so built a new scopehal from the repository, and now I get this error; glscopeclient: symbol lookup error: /lib/x86_64-linux-gnu/libscopeexports.so: undefined symbol: _ZTI12ExportWizard
<d1b2>
<mubes> ...did I do somrthing dumb?
<azonenberg>
@mubes: let me see...
<d1b2>
<mubes> Hmm. When I cmake with cmake ../ -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=/usr then I get the above problem
<d1b2>
<mubes> cmake on its own with no params and I dod't
<azonenberg>
yeah gimme a minute
<azonenberg>
At the end of the root CMakeLists.txt
<azonenberg>
try adding the POSITION_INDEPENDENT_CODE property to scopeexports
<d1b2>
<mubes> ok
<azonenberg>
also make sure you don't have bits of partially installed stuff in either /usr/lib or /usr/local/lib
<d1b2>
<mubes> Yeah, already checked that one
<azonenberg>
left over from old builds
<d1b2>
<mubes> So, like this; set_property(TARGET scopeexports PROPERTY POSITION_INDEPENDENT_CODE ON)
<d1b2>
<mubes> ?
<azonenberg>
yeah
<azonenberg>
that shouldn't be the cause, but it's something we should have enabled anyway
<azonenberg>
ExportWizard is defined in libscopehal, to which both libscopeexports and glscopeclient link
<d1b2>
<mubes> That does seem to fix it, with the previously problematic cmake line
<azonenberg>
ah perfect. send a PR then
<azonenberg>
i dont understand how it caused that
<azonenberg>
but it needed to happen anyway :p
<d1b2>
<mubes> another one whacked. Haven't been able to look at anything for a few weeks.
<azonenberg>
also do you have the function generator option on your SDS?
<d1b2>
<mubes> yes
<d1b2>
<mubes> never used it 🙂
<azonenberg>
ok great, i'll want you to try out my driver for it when i'm done
<azonenberg>
i need a bit more time to finish
<d1b2>
<mubes> no prob. At the moment I don't seem to be able to connect to my scope...
<d1b2>
<mubes> ah, thats cos I'm stupid
<d1b2>
<mubes> Still geting a few warnings; Warning: ReadDataFile: Could not open file "kernels/WaveformRendering.cl" ERROR: OpenCL error: clCreateKernel (-46) Warning: ReadDataFile: Could not open file "kernels/WaveformRendering.cl" ERROR: OpenCL error: clCreateKernel (-46) Warning: ReadDataFile: Could not open file "kernels/WaveformRendering.cl" ERROR: OpenCL error: clCreateKernel (-46) Warning: ReadDataFile: Could not open file