<_whitenotifier-9>
[scopehal-apps] azonenberg b8cf80e - Updated submodules with more siglent fixes
<d1b2>
<dannas> The responsiveness of horizontal and vertical zoom is greatly improved.
<azonenberg>
and yeah i was confused as to why people were saying that the gui was locked to the waveform rate because it should not be, they're architecturally decoupled
<azonenberg>
i figured it was a driver bug and managed to get siglent to send me a dev unit to tinker with
<azonenberg>
and sure enough yeah, there were mutex sync points that were unnecessary or covering more code than they had to
<azonenberg>
and it wasn't taking advantage of the write queueing layer
<azonenberg>
I think this is most of the speedup i can get without help on the instrument firmware side, but there's still room to do more WRT feature set
<d1b2>
<dannas> So... the horizontal zoom on the scope now seems to be fixed at a 100ms resolution... Is that intended?
<d1b2>
<dannas> I was expecting the horizontal zoom to stay in sync with the zoom settings of the glscopeclient gui.
<azonenberg>
dannas: that was never the case
<azonenberg>
the gui zoom is purely for display since you can zoom into and pan around a large dataset
<azonenberg>
you have to open timebase properties (double click the timeline) and select memory depth and sample rate explicitly
<azonenberg>
Vertical zoom is synced to the scope since it's rare that you would want to zoom into a portion of a waveform
<d1b2>
<dannas> @azonenberg Ah, ok. That was a misconception I had then. And using sample rate/mem depth for controlling the scope makes sense - it's what my logic analyzer gui uses for controlling the LA device.
<azonenberg>
Yeah
<azonenberg>
Fundamentally, glscopeclient differs from classical DSO GUIs by treating the scope as a data acquisition device
<azonenberg>
and giving up any pretense of it being an analog scope
<azonenberg>
so there's no concept of measuring things in divisions etc
<d1b2>
<dannas> As for controlling the vertical zoom. I notice that if I change the resolution fast, there seems to be quite a few commands that queue up.
<azonenberg>
Yes. So that is an optimization that is still pending
<azonenberg>
the scope is slow and we actually have a forced 50ms delay between commands to work around scope firmware bugs
<d1b2>
<dannas> It can take 10s of seconds before the scope has finished modiying it's settings. So I shouldn't do that I guess. 🙂
<azonenberg>
if you change the same setting more than once per 50ms it is in principle possible to delete the redundant commands from the queue before they are submitted
<d1b2>
<dannas> Once again, thank you for the changes. It really makes a huge difference to the usability for controlling my scope.
<azonenberg>
i'm curious if the rigol driver has similar issues
<azonenberg>
but i dont currently have any rigol dev units
<azonenberg>
(And i also dont know how long siglent will let me keep this one for)
<d1b2>
<dannas> 0.18 WFM/s for 7MS sample rate. So the responsiveness of the commands are improved but the throughput of the data transfer is still low.
<d1b2>
<dannas> When I was hacking on the scope driver i had several WFM/s. I wonder if I did something silly with changing the timebase then.
<d1b2>
<dannas> goes to check the changes done to the Siglent driver
<azonenberg>
My changes do not improve WFM/s rate but they did not seem to make it worse either (if there are regressions we need to address that)
<azonenberg>
I'm testing on a 2104X+
<azonenberg>
The main point of my changes was to remove unnecessary locking and make it so that write-only calls would return immediately rather than blocking until the 50ms delay for the network rate limiting had passed
<azonenberg>
(and also blocking during waveform download)
<azonenberg>
and making it so that Get() calls would return immediately if they hit in cache rather than blocking on a mutex that they didnt actually need to access
<azonenberg>
So basically waveform download should be the same as before, but doing things during a waveform download should now be much faster
<d1b2>
<dannas> 0.65 WFM/s for 7KS sample rate. I'm not sure whether it really was several WFM/s or not. Maybe I'm just misremembering. So don't take my observerations as truth here.
<d1b2>
<dannas> I'll try building glscopeclient with an older version of the code (but won't have time today) and see if it makes a difference.
<azonenberg>
Ok yeah. If you can bisect to a specific version of the code then that will definitely help narrow things down
<azonenberg>
just keep in mind that the scopehal and glscopeclient sides need to be relatively synced
<azonenberg>
in the past few months there have been several refactorings that made breaking changes to APIs
<azonenberg>
so if you revert one half and not the other things might not compiile
<d1b2>
<mubes> The 50mS was hopefully a little bit more subtle than just a straight delay. It should have taken a record of the time at which the message was sent, and then on the next transmission only delay if 50mS hasn't passed yet....but sorting out the locking has got to be a big step forward. I'll try and check for regressions soon. It might be this evening (since I'm using scopehal for JTAG analysis at the moment), tomorrow evening otherwise.
<azonenberg>
@mubes yes i ported over your code to the SCPITransport class basically as is
<azonenberg>
but now it works on the command queue
<d1b2>
<mubes> Excellent. If we can get multi-command on the same line then that can become switchable depending on version. They have reproduced the bug so I'm hopeful it'll be addressed in upcoming builds.
<azonenberg>
Great
<azonenberg>
Multi command is a much lower priority than the sleeps though
<azonenberg>
we're literally throwing performance away there
<d1b2>
<mubes> My intention was to add 'opc?' to the end of sequences and just wait for the 0 back...that way we never have to wait for longer than a command actually takes. Trouble is, at the moment, tagging that onto a line borks command execution.
<d1b2>
<mubes> Then the sleeps can go completely, and the Comms thread only has to block if it's not received the command completion 0 back yet.
<azonenberg>
Yeah
<azonenberg>
That will, however, hurt the command queueing
<azonenberg>
because it means we cannot queue up a bunch of writes and then have them execute whenever
<azonenberg>
the *proper* option is to have the instment actually use the tcp window correctly
<azonenberg>
and read(2) commands when it's ready to execute them and no sooner
<d1b2>
<mubes> Well, we can worry about that when we've got the capability. Trouble is scpi can be carried over different bearers so relying on something from the transport might be problematic.
<azonenberg>
True
<azonenberg>
anyway, queueing is still critical at the upper layer
<azonenberg>
even if we have to OPC on each command in the transport
<azonenberg>
because this decouples the gui thread from the network io
<d1b2>
<mubes> Yes, how it's delivered to the scope is really a separate issue.
lain has quit [Quit: kthxbai]
lain has joined #scopehal
<azonenberg>
@mubes, @dannas, any other things in particular i should be looking at while i have the siglent dev unit?
<azonenberg>
i dont know how long i will get to keep it
<azonenberg>
so i want to bang out high priority TODOs asap
<azonenberg>
the 10 bit mode is on hold until i hear back from their firmware team
<azonenberg>
the redundant scale optimizations are on my list for the next day or two
<azonenberg>
then i was thinking maybe i could focus on adding more trigger types
<d1b2>
<mubes> For rounding things out that would be handy. Digital channels aren't (properly) in there at the moment either and there might be issues hidden in there somewhere.
<d1b2>
<mubes> Apart from that I think it's reasonably functional. Finding the redundant locking is really helpful though....that would have lurked in there for a very long time.
<azonenberg>
They did not send me a MSO probe though
<azonenberg>
so i cannot do that
<azonenberg>
i think you have one now? or is that still pending?