<d1b2>
<louis> Welcome! Thanks for volunteering to build/test on Windows, that's a big help!
<azonenberg>
@louis: just checking in, what is your current development focus now? anything you need from me?
<azonenberg>
One thing i'd like to request fairly soon is a generic (works for any scope) WFM/s counter in the stats display. We used to have that and it was lost in your stats refactoring
<azonenberg>
we now have display FPS, which gives the *render* rate
<azonenberg>
but for driver optimization and firmware benchmarking the figure of merit is waveforms per second accepted by the driver
<azonenberg>
Another thing that might be useful, i think i have a ticket for it already, is a tool for headless benchmarking of a scope+driver combo
<azonenberg>
basically connect to the scope and AcquireData() as fast as you can
<azonenberg>
and record how many waveforms you get in, say, a minute
<azonenberg>
this cuts GPU/render performance out of the equation and lets us benchmark the driver and scope in isolation
<d1b2>
<louis> I've been occupied with first-order stuff recently, but no, no blockers on your end I think. I've got the dslabs flow control stuff and tek stability stuff I'll PR sooner or later.
<d1b2>
<louis> For received WFM/s, that opens a can of worms I noticed earlier. Which is that the current HzClock in scope driver + set diag params from it's .GetAverageHz() works great.... as long as it is actually being ticked.
<azonenberg>
Yes. Single trigger breaks WFM/s
<azonenberg>
for example
<azonenberg>
that was true before as well
<azonenberg>
But i'm not sure how huge a deal that is given the intended use case is benchmarking for internal dev
<d1b2>
<louis> If waveforms stop abruptly, it just sticks at the last freq forever. So really we want some kind of decay such that after, say, 1/Hz it tends to 0
<d1b2>
<louis> But that means that we can't depend on the osc to call .GetAverageHz() (unless we have some UpdateDiagParams() helper or something, but that's ugly.)
<azonenberg>
how about have PollTrigger() do something
<azonenberg>
since that's normally called in a loop any time the trigger is armed
<azonenberg>
or better yet have ScopeThread call something
<azonenberg>
even if the trigger isn't armed
<azonenberg>
idk. i just think we need to have instrumentation to better understand the dynamic behavior of the system
<d1b2>
<louis> I was thinking about writing a DiagParameter class that was similar to FilterParameter but (1) omits the unneeded conversion logic and (2) has the option for the diag parameter to own/contain the HzClock and expose it's (decaying) state when querying
<azonenberg>
i'm less interested in its behaviors in corner cases as long as we have some notes in the dialog or something so it's clear what is being measured
<azonenberg>
That sounds plausible
<d1b2>
<louis> (This was relevant to me because I was counting the frequency of waveform dropping and UI starving in the dsl flow control code, but it was unhelpful that there being no more drop events leaves it stuck at the (nonzero) previous frequency)
<azonenberg>
yeah
<azonenberg>
Maybe you should look into using sigc timers or something
<azonenberg>
so you have a signal to trigger a timer event every second on the scope
<d1b2>
<louis> I would avoid this if possible, seems to tie scopehal closely to being run in an eventloop-based application, which I think we don't want to be a strict requirement
<azonenberg>
ah true
<azonenberg>
A background method you call in ScopeThread might be the best option then
<azonenberg>
as headless code that doesnt care about this stuff can easily just not call it