azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/glscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
<azonenberg> @louis: holy moley
<azonenberg> i've never seen anyone do that well
<azonenberg> in particular this is a big issue for combo scopes that have like a scope and an AWG
<azonenberg> being able to control them on separate sockets is super handy
<d1b2> <louis> currently hacking around to try using it in the driver... we'll see if it stands up to automated use
<azonenberg> You shouldnt need to use it in the driver, right?
<azonenberg> what's the use case, minimizing sync points between data and control planes?
<azonenberg> start by using the nonblocking queued command API
<azonenberg> which i dont think the legacy R&S driver used
<azonenberg> if that's done right, there should not be much if any blocking in the gui thread
<d1b2> <louis> yes
<d1b2> <louis> i mean have one thread doing all the interaction, and the other blocking-waiting on data
<d1b2> <louis> to avoid polling for if data is ready
<azonenberg> yeah makes sense. i mean thats kinda what we do already with the queued command API except we have the other thread polling the scope
<azonenberg> but same idea. Start with the queued API imo
<azonenberg> and then worry about multi socket after you get that implemented and working
<azonenberg> iff you see room for more performanec
<d1b2> <louis> yeah im using the queued api
<d1b2> <louis> but you still need to poll to see if there is a waveform to be grabbed
<azonenberg> Correct. but that's in ScopeThread
<azonenberg> is there any way around that?
<azonenberg> in most scpi apis the scope will just return old data if you send a read command before it triggers
<azonenberg> it won't block until trigger
<d1b2> <louis> on this scope SINGLE; *WAI blocks until the capture is done
<azonenberg> interesting
<azonenberg> I'm curious how you end up implementing this
<azonenberg> would there be two SCPISocketTransport's?
<d1b2> <louis> yes
<d1b2> <louis> same idea as the twinlan transport
<azonenberg> well the diff is twinlan separates "raw" data from commands
<d1b2> <louis> just instead of server push for waveform data, you send SINGLE; *WAI and wait for it
<azonenberg> you'd basically need two separate streams that can each do both
<d1b2> <louis> yes they are both capable of both
<azonenberg> well only one NEEDS both
<azonenberg> there should be no need to do raw binary on the control plane socket
<d1b2> <louis> but as i'm playing with it rn all one ever does is SINGLE; *WAI; CHANx:DATA:HEAD? and blocks
<azonenberg> yeah maeks sense
<azonenberg> i mean you can theoretically use twinlan
<azonenberg> and just send that using the raw data calls
<azonenberg> and it will work out of th ebox today
<d1b2> <louis> i think that would break the locking discipline for queued commands, though
<d1b2> <louis> but conceptually yes
<azonenberg> you might need to make a fork of twinlan with different mutexing or something
<azonenberg> but yeah
<d1b2> <louis> not sure it actually helps performance
<d1b2> <louis> but it is very cool that it works
<d1b2> <louis> i think the main overhead now is marshalling the data to the network
<d1b2> <louis> may see what i can get if i use the raw adc sample format for waveform
<azonenberg> nice
<azonenberg> yeah we can AVX and/or GPU that conversion ourselves
<d1b2> <louis> unfortunatley dosen't seem to be any faster in INT,8 or INT,16 raw modes 😦
<azonenberg> in that case fp32 is probably the best since it saves us a conversion step
<d1b2> <louis> yeah
<azonenberg> or... hmm
<azonenberg> maybe int16 since it uses less network bandwidth?
<d1b2> <louis> well; depends on how fat your pipe is
<azonenberg> exactly
<d1b2> <louis> I'm succeeding in getting 670Mbps off this RTO6 sustained
<azonenberg> Nice
<d1b2> <louis> (albiet that is 20MS fp32 @ 1.05Hz to get that number, but it's nonetheless quite impressive)
<azonenberg> Yeah
<azonenberg> that's more than the 512 Mbps i got off my HDO9204 which is my record with lecroy
<d1b2> <louis> of course nothing compared to a DSCope in terms of WFM/s, but a DSCope won't do 20Ga/s
<azonenberg> but that was more samples/sec because it was int16 samples
<d1b2> <MP> this is a decidedly midrange 4GHz class instrument
<d1b2> <louis> I don't know how much a higher-end R&S would get you in terms of WFM/s, at least right now. I think it must be software overhead on their side. Since the hardware in that thing should be quite capable
<d1b2> <MP> @louis what exact CPU is in it
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<d1b2> <MP> not socketed
<d1b2> <MP> pity
octorian has quit [Quit: ZNC - http://znc.sourceforge.net]
octorian has joined #scopehal
massi has joined #scopehal
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 252 seconds]
massi has quit [Remote host closed the connection]
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]