<_whitenotifier>
[scopehal-apps] azonenberg ee88704 - A few fixes around creation of BERTs, added dual 2.92mm connector icon
<_whitenotifier>
[scopehal-apps] azonenberg 798d00d - Transmit side of BERT driver GUI is now basically done. Still have to work on timebase and receiver
<d1b2>
<azonenberg> Good progress on the BERT driver
<azonenberg>
the inaugural device for driver support is the MultiLANE ML4039 and it could probably be easily extended to support most other ML BERTs
<azonenberg>
So far i have the transmit side basically done but havent done much on the receiver yet
bvernoux has joined #scopehal
<d1b2>
<fox.sabrina> testing out latest rigol fw with lan transport and it's night and day speed improvement
<d1b2>
<fox.sabrina> arguably unusable without a firmware post v00.01.03.02.02
<d1b2>
<david.rysk> @azonenberg yeah separate channels for in/out sounds like the way to go
<d1b2>
<azonenberg> Can you share some hard performance numbers for my spreadsheet? using ngscopeclient, the performance dialog should show acquisition rate in waveforms per second
<d1b2>
<azonenberg> Data I need is scope model, firmware rev, scopehal git revision, number of channels enabled, memory depth, and WFM/s
<d1b2>
<azonenberg> several data points at different channel/configs would be useful
<d1b2>
<azonenberg> (I can also add a note to documentation saying that you should use this firmware rev or newer for best results)
<d1b2>
<fox.sabrina> will do, had to fix a small issue with the driver so let me get that PR'd and i'll get those for you
<juh>
noob question, what constitutes "1 waveform"? if we said "samples per second" or "bits per second" i'd get that, but how much data is a single waveform/how is it defined/why is that our unit of measure for performance (rather than samples or bits)?
<azonenberg>
juh: That's why knowing the size of the waveform is important
<azonenberg>
basically, some scopes have very long processing times internally that are constant per trigger even for only a few points
<azonenberg>
so a 50-point waveform might still max out at 1 Hz update rate while a 50K would only be a tiny bit slower
<azonenberg>
Others have lower latency and are primarily dominated by memory depth
<azonenberg>
The spreadsheet I have for performance tracking has all of the variables: a full acquisition is (number of active channels) * (bits per sample padded up to integer number of bytes) * (number of points per channel) bits of data
<azonenberg>
For UI responsiveness etc WFM/s is the important metric, as it basically defines how laggy things feel when you touch a probe to the DUT until you see the display change
<juh>
Aaahhh, this makes much more sense, thanks!
<azonenberg>
But the spreadsheet also calculates throughput in Msps and Mbps which is the dominant factor for deep-memory captures where you get bottlenecked on transfer rate
<azonenberg>
you can see how the pico and lecroy scopes have relatively constant throughput (WFM/s scales mostly linear with memory depth)
<azonenberg>
while a lot of the low-end scopes like siglent and rigol are dominated by the O(1) trigger processing time
<azonenberg>
and reducing memory depth doesn't buy you a whole lot of performance
<d1b2>
<fox.sabrina> huh, i've managed to lock out the fw over lan twice
<d1b2>
<azonenberg> like hang it?
<d1b2>
<azonenberg> So the new firmware is faster but less stable?
<d1b2>
<fox.sabrina> i made it hang once, and another time the fw was stuck trying to "complete" a waveform transmission, so i had to connect with nc and let it dump what it wanted before being able to reconnect
<d1b2>
<fox.sabrina> also starting to suspect it's not much faster, 4ch@1M is now at 0.80wfm/s vs 0.59wfm/s before
<d1b2>
<fox.sabrina> it seemed perceptively on first blush, but while getting the hard numbers it quickly drops off
<d1b2>
<fox.sabrina> current data, also trying to look at a few other things such as a lot of tcp window updates on macos that were randomly tossing a few ~50-100ms delays in the waveform download
<d1b2>
<azonenberg> What scope is this?
<d1b2>
<fox.sabrina> rigol MSO5074
<d1b2>
<azonenberg> this is with ngscopeclient i assume not glscopeclient? what commit?
<d1b2>
<azonenberg> (starting to log this so we can track changes in performance w/ scopehal side optimizations
<d1b2>
<fox.sabrina> poking into it a bit more, tcp window updates are significantly affecting macos buffer download times, but unfortunately don't seem to speed things up too much as most of the time is waiting for :trig:stat? default recvspace buffer (131072) 1M wfm download time: 1.11s max recvspace buffer (7100000) 1M wfm download time: 0.15s
<d1b2>
<azonenberg> interesting. and yeah the trig:stat poll delay is the scope fw being slow
vup2 has joined #scopehal
vup has quit [*.net *.split]
josuah has quit [*.net *.split]
<d1b2>
<fox.sabrina> yep, this version still has the ~0.57ms delay of combined trigger poll, preamble query, and initial data send
<d1b2>
<fox.sabrina> actually wfm transmission is faster is seems, but you're ultimately capped at ~1.6wfm/s by the trigger system still
<d1b2>
<azonenberg> Yep the processor and/or firmware is just really slow on the rigols
<azonenberg>
That's why I'm so excited about the thunderscope and company
<azonenberg>
actually having an affordable scope that has good PC performance
<azonenberg>
because right now you have to go to one of the big names and pay up the nose
<d1b2>
<david.rysk> Has there been any more progress with Siglent?
<d1b2>
<david.rysk> I need to dig out my scope
<azonenberg>
hansemro has a bunch of pending PRs that arent merged yet as he's still working on them
<azonenberg>
he seems to be taking over as the new maintainer since mubes hasn't had time
<azonenberg>
as far as an official relationship with the company, that kinda stalled when jason chonko left to work somewhere else
<azonenberg>
he was our big advocate within the company
<azonenberg>
and we havent yet established a new relationship
<azonenberg>
We still have email addresses of some of the dev team in China but from what i can tell of the company culture if nobody is leaning on them, our requests are low priority
<d1b2>
<david.rysk> Was someone going to reach out to vendor contacts? I can’t remember
<azonenberg>
We have ongoing discussions with some vendors
<azonenberg>
off the top of my head Pico, R&S, and Tek have had contacts with us fairly recently and Digilent was helpful in the past but i havent talked to them super recently once i got the preliminary analog discovery driver working
<azonenberg>
We dont have a formal relationship with lecroy but i did have a productive meeting with them a year and change ago
<azonenberg>
the driver is mature enough i havent really needed much from them but they're responsive to support queries if i have issues with a specific corner case or something
<azonenberg>
Copper mountain sent me a demo to try out, but that was in anticipation of a future purchase and not specifically to support driver dev