<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jfg2o
<_whitenotifier-c>
[scopehal-apps] azonenberg 1546623 - OscilloscopeWindow: add channels to menu when reconnecting to saved scope. Fixes #98.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #98: When reconnecting to a scope via a save file, channels are not added to the "add channel" menu - https://git.io/JfROv
<_whitenotifier-c>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jfgap
<_whitenotifier-c>
[scopehal] azonenberg dd47991 - Oscilloscope: load nickname from save files
<_whitenotifier-c>
[scopehal] azonenberg b4766b8 - Oscilloscope: Added APIs for querying sample rate and memory depth (cannot set yet)
<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+2/-0/±5] https://git.io/Jfgoe
<_whitenotifier-c>
[scopehal-apps] azonenberg f36e9bc - Double clicking timeline now brings up "timebase properties" dialog with configuration for memory depth and sample rate. Displays legal settings and highlights current config, but can't change yet.
<azonenberg>
Well that was long overdue
<azonenberg>
now to add config
futarisIRCcloud has joined #scopehal
juli964 has joined #scopehal
<_whitenotifier-c>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±15] https://git.io/JfgXZ
<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JfgyI
<_whitenotifier-c>
[scopehal-apps] azonenberg 42ce800 - Stats now follow waveforms when moving between groups. Fixes #5.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #5: When a channel is moved between viewports, statistics should follow - https://git.io/JfWrm
<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfgyO
<_whitenotifier-c>
[scopehal-apps] azonenberg c4f8708 - Stats now follow waveforms being copied between groups, not just moved
<lain>
iirc it's a way for a usb device to indicate some human-readable stuff if it fails to enter alternate mode, or its alt mode is not supported
<azonenberg>
so we could print an error if someone plugs our probe into a PC
<azonenberg>
sounds handy
<lain>
so you can maybe use that to pop up a message like "oi, this is an oscilloscope probe ya dummy"
<azonenberg>
"why the heck did you just plug a scope probe into your laptop? WTF were you expecting to happen?"
<sorear>
"if you are attempting to debug your laptop, the probe is connected backward"
<azonenberg>
lol
<lain>
haha
zkms has quit [Quit: uguu]
zkms has joined #scopehal
<azonenberg>
also, new rev probe shells are on the way
<azonenberg>
with the cutout for the sma bottom side
<azonenberg>
(although i did machine one of the current rev for testing)
zkms has quit [Client Quit]
smkz has joined #scopehal
<electronic_eel>
azonenberg: so the probe pcbs came in? did you already build one for testing?
<Degi>
Lol I just randomly stumbled on that chip and didn't bother to read beyond "USB PD" and "I2C" but nice that it can do so much
<Degi>
Huh cool this super thin tesla coil I made a long time ago actually works, neat. Measured 4-5 MHz resonance with my scope depending on position... AWG feature is useful!
<sorear>
it's difficult for me to believe you have NOT destroyed a significant amount of test equipment with the coil
<Degi>
Oh I'm powering it with a 1 turn loop with the scopes AWG
<Degi>
Well I have another tesla coil that when you place a CFL on it it just makes a hole in the glass
<azonenberg>
electronic_eel: Yes it came in, i built one, and i machined the enclosure to fit the SMA
<Degi>
Heh apparently theres an overtone at 12.5 MHz
<azonenberg>
i need to spend more time characterizing it
<azonenberg>
initial vna measurements yesterday had a high degree of variability
<azonenberg>
and were also affected by the lack of a proper test fixture with a well matched connector transition
<Degi>
Tesla nunchucks
<electronic_eel>
hmm, you already wrote last time that you had high variability in the results and some wobbling in the connectors in the probe
<electronic_eel>
did you think about any options to improve the retention of the probe pin in the mill max connector?
<electronic_eel>
how about a small fr4 strip, glued to the back of the probe, which has some plastic cylinder or blob on top
<electronic_eel>
the fr4 strip acts as a spring and presses the plastic cylinder onto the probe pin, pushing it upwards a bit
<azonenberg>
my plan was and continues to be a tiny dot of adhesive
<azonenberg>
probably purple, i think is the weakest, loctite? on the front side, not the electrically mating surface
<azonenberg>
that is not the cause of this variability though
<electronic_eel>
ah, what do you think causes the variability?
<azonenberg>
i basically just need to sit down and collect more data
<azonenberg>
probably tonight
<electronic_eel>
ok, cause yet unknown
<azonenberg>
in particular i want measuremetns across a termination
<azonenberg>
not open circuit like i have been doing
<azonenberg>
i didnt get just a vertical shift
<azonenberg>
it actually substantially changed flatness
<azonenberg>
(with all of these designs)
<azonenberg>
so i need to understand that too
<azonenberg>
electronic_eel: did you see all of the ui and performance work i've been doing on glscopeclient the last few days?
<electronic_eel>
I saw it but I must admit I didn't set up scopehal yet for use with my scope. I also didn't dive into the code yet,
<azonenberg>
ah ok
<azonenberg>
suffice it to say there's been major ui updates. timebase config finally works for example
<azonenberg>
at least on lecroy scopes, the APIs are there for the other drivers but the functions are all stubs
<azonenberg>
electronic_eel: also i got about 1.6 GHz -3dB bw on the last test of the current rev probe
<azonenberg>
vs 1.77 for the old rev
<azonenberg>
the old rev seemed to be flatter probing across a 50 ohm load so i'll be doing the same with this probe tonight
<electronic_eel>
these were both models with 3 resistors?
<azonenberg>
this is comparing the current rev with the 6 resistors and final probe shape
<azonenberg>
vs the old version reworked to have a 6 resistor footprint and a closer ground location
<azonenberg>
i expected slightly higher L from the further ground on the new probe
<azonenberg>
the new probe was flatter though
<azonenberg>
+/- 1 dB to 1.26 GHz
<azonenberg>
vs the old one peaked at +1 dB at 500 Mhz under the same conditions
<azonenberg>
like i said, less flat into the coupler vs across a terminator
<electronic_eel>
but if you say that the results were very variable and you don't know the reason for this, there might be some measurement error
<azonenberg>
no the results were fairly consistent for one exact setup
<azonenberg>
i just noticed large variations among apparently similar setups
<azonenberg>
e.g. if the ground lead was on the inside or outside of the sma barrel
<azonenberg>
i need to find a more stable fixture to probe on because i dont trust the original fixture i built for this purpose
<electronic_eel>
ah, this was the problem were you said that soldering the connector to the back substantially changed things
<azonenberg>
yeah. among other things
<azonenberg>
i'm very much looking forward to the new oshpark'd probe rev
<azonenberg>
i expect high loss from the enig but good, flat performance
<electronic_eel>
hmm, is there something like your probe characterization board commercially available?
<electronic_eel>
or something that can be repurposed?
<electronic_eel>
something with known s parameters and stuff
<electronic_eel>
so that you don't have to redo your board without exactly knowing where the fault ist
<azonenberg>
Well i've been building test fixtures for the new SMA connectors i can probably use
<azonenberg>
and going back and forth w/ sonnet support to get my field solver models to more closely match the real world measurement data
<azonenberg>
there's a lot going on here and lots of things are changing, i have two boards already in the pipeline with improved configs
<azonenberg>
Also (fyi lain) i just got off the phone w/ lecroy service
<azonenberg>
remember we were talking the other day about cpu upgrades for the scopes etc?
<azonenberg>
turns out there *currently* is not a mobo upgrade option available
<azonenberg>
however one is in the pipeline
<azonenberg>
i talked to carrie at service and she's gonna give me a call back in a few days with the part number and anticipated pricing, as well as some idea of when it will be available
<azonenberg>
as hilarious as it sounds this would be a great excuse to get glscopeclient running on windows
<azonenberg>
electronic_eel: did you hear my crazy idea?
<Degi>
Because the scopes run windows?
<azonenberg>
i want to run glscopeclient *on the scope* connected to localhost
<azonenberg>
and outperform MAUI
<electronic_eel>
hehe
<azonenberg>
i can't do it on my current scopes because they're ivy bridge CPUs from 2012 that predate GL 4.x so no compute shader support
<electronic_eel>
how would you get the raw data?
<azonenberg>
electronic_eel: i'd use VICP to 127.0.0.1
<azonenberg>
lol
<electronic_eel>
hmm, didn't you say that the network wasn't the limiting factor?
<electronic_eel>
so it wouldn't be faster than running it remotely
<azonenberg>
Correct
<azonenberg>
but it doesnt matter
<azonenberg>
the point would be for the luulz
<azonenberg>
i did a test a while ago using my 2014 era desktop running 10/100 protocol decodes, two eye patterns, two bathtub curves, etc at 100 updates/minute on 5M point waveforms
<azonenberg>
on two channels of 10/100 ethernet
<electronic_eel>
for real lulz: hack the interface to get the raw data
<azonenberg>
by comparison, MAUI ran at 160 updates/min just displaying waveforms with no processing, and 18 updates/min with a single eye pattern
<azonenberg>
so if i can get better than 18 updates/min running on the actual scope displaying a single eye, i will be faster than lecroy's firmware on the same hardware
<azonenberg>
that, and seeing glscopeclient on the actual scope would just be cool
<electronic_eel>
if everything in the lecroy sw is built using dlls, com and similar, isn't there some interface you could hack in?
<azonenberg>
Yes there is almost certainly a COM and/or DCOM interface i could hook into that might be faster than SCPI. but that's something for much later
<azonenberg>
even if i was just using scpi, if i can run faster than their firmware on the same hardware it would be cool :p
<Degi>
Hmm what is the thing with eye patterns that they are apparently hard to compute?
<azonenberg>
probably the CDR PLL
<azonenberg>
but could be just their software being slow and unoptimized :p
<Degi>
Hmm did you use GPU computing when you got 100 updates per minute with 5 MSamples?
<azonenberg>
only for rendering, which wasnt a big portion of the overall time
<azonenberg>
all of the PLL and eye integration was done in software
<Degi>
Ah
<Degi>
Hm yes, eye integration on the GPU should be much faster.
<azonenberg>
it's not very parallel actually
<Degi>
Qh<
<Degi>
*Why
<Degi>
Because of the CDR pll?
<azonenberg>
because the CDR frequency can shift if you track low frequency noise in the signal etc
<azonenberg>
so you cant trivially data parallelize it
<azonenberg>
while you could divide the data up into chunks, the act of doing so would require a mostly linear traverse over the waveform
<azonenberg>
the actual integration costs almost nothing
<azonenberg>
I would love to do this, it's a huge portion of my cpu when doing this benchmark
<azonenberg>
but so far i havent even found a good way to multithread it
<azonenberg>
much less gpu
<Degi>
Oh well
<bvernoux>
azonenberg, next step is to push scopehal... to Qt ;)
<bvernoux>
Will be really an amazing step
<bvernoux>
to avoid such X11 stuff not portable
<bvernoux>
Qt is clearly the solution for all platforms
<bvernoux>
and I'm pretty sure your opengl stuff does not requires any change as Qt support OpenGL natively
<azonenberg>
i'm not doing any native x11 stuff, i'm using gtkmm
<azonenberg>
i'm not porting everything to a new ui toolkit, and from what i hear qt has some nasty licensing issues lately
<azonenberg>
the issue i'm having is related to how x11 window managers handle "fullscreen" windows and the choice of widget toolkit is irrelevant
<azonenberg>
i know how to do what i want on windows, all i need is WS_EX_POPUP and maybe WS_EX_ALWAYSONTOP and i should be OK
<azonenberg>
i just don't know the relevant style bits for x11 and how to set things up
<azonenberg>
actually i think it's WS_POPUP not extended? it's been a few years
<azonenberg>
WS_POPUP | WS_EX_ALWAYSONTOP should do what i want
<bvernoux>
I have no idea how work X11 so I cannot help on that
<azonenberg>
basically the problem is that the window manager sees the app as being "on top of everything else"
<azonenberg>
which is what i want
<azonenberg>
but it needs to know that the protocol decode and history windows are part of the app, and not other background windows
<azonenberg>
set_transient_for should do that
<azonenberg>
and it works fine when focus is on the app
<azonenberg>
but when focus is on one of those windows the others show up behind the app
<bvernoux>
maybe you could ask that on some ML with linux guru
<bvernoux>
what is the way to do it
<sorear>
if you're truly memory bandwidth limited multithreading won't help
<azonenberg>
sorear: let me rephrase
<azonenberg>
i think i'm currently memory latency limited
<azonenberg>
and so if i multithreaded i might be able to block on multiple fetches at once
<azonenberg>
and get higher throughput
<azonenberg>
the challenge is that the integration of the pixel data has to be atomic and atomic increments tend to be expensive because they force serializaiton
<bvernoux>
azonenberg, good news is soon I will reinstall a clean XUbuntu 18.04LTS on my main PC ;)
<azonenberg>
one possibility is to have a separate copy of the eye for each thread then stack them in post
<sorear>
ah yes
<azonenberg>
which i tried and got worse performance, but i didn't optimize it too much
<azonenberg>
as performance was within acceptable limits at that point
<bvernoux>
azonenberg, as I will receive next week a new 1TB SSD and so my current one will be dedicated to native Linux ;)
<azonenberg>
So i reverted those changes
<azonenberg>
actually sorry it wasnt worse performance, it gave incorrect output
<azonenberg>
and i didnt feel like debugging
<sorear>
I mean, if you're reading data 64 bytes at a time and reading it exactly once there's not much to be gained
<sorear>
maybe be clever and combine multiple postprocesses into one pass over the data
<azonenberg>
the other problem is theres not much you can do wrt vectorization
<azonenberg>
because the access patterns are so random
<azonenberg>
there's also lots of interpolation and other stuff going on
<azonenberg>
if you have ideas on how to tune it have a look at lib/scopeprotocols/EyeDecoder2.cpp in the Refresh() function
<azonenberg>
The loop on lines 377 - 436 is ~all of the run time according to vtune
<sorear>
roughly what is the throughput currently, and where do you want it to be
<sorear>
what's the typical range of m_width and m_height
<sorear>
offsets and durations, which are always 1 for analog data: 16 bytes per sample
<sorear>
analog capture data: 4 bytes per sample
<sorear>
is this a "someone help me budget" situation or have I missed something important
<sorear>
getting rid off the offsets might also make that loop much more optimizer friendly, most of the variables in the body become effectively induction variables
<azonenberg>
durations are 1, offsets are index of the data for analog data
<azonenberg>
for the clock, that's not necessarily true
<azonenberg>
the clock also normally has a different time scale than the waveform because the clock is interpolated to sub-sample precision
<azonenberg>
It's currently fast enough to keep up with the scope, this is more "faster is always better but i've run out of easy optimizations"
<azonenberg>
making it faster isn't a priority right now
<sorear>
i'm not suggesting to get rid of the offsets and durations on the clock (a digital signal)
<azonenberg>
There is a general plan at some point to special case "dense packed" waveforms
<azonenberg>
in which offsets are 0...N and durations are always 1
<azonenberg>
and allow some filters to skip certain processing
<azonenberg>
this may be able to benefit from that
<azonenberg>
but i need to keep the generality because i cant assume sampling rates are uniform on everything
<azonenberg>
width and height is the size of the eye pattern
<azonenberg>
so on the order of a few hundred to low thousands of pixels each
<sorear>
low thousands * low thousands * sizeof(int64_t) runs a good risk of blowing cache
<azonenberg>
even the waveform wont fit in cache
<sorear>
waveform doesn't need to fit in cache since you're accessing it in a single sequential pass
<azonenberg>
5M points * 32 bit float = 20 MB for a single eye pattern's input
<azonenberg>
oh you mean the buffer being accumulated
<azonenberg>
yes
<sorear>
and that should be >> 10 GB/s on server hardware
<azonenberg>
memory performance was actually really low during these tests. like i said i need to do more profiling and analysis to see where my bottlenecks are
<azonenberg>
but i think i was latency bound because of lots of small fetches
<azonenberg>
and not making good use of bandwidth
<azonenberg>
if there's a way to coalesce several fetches i think it could be improved a lot
<sorear>
well as I was saying you also have 5M points * 2 * 64-bit int for the offsets/durations
<azonenberg>
Yes. There's definitely room to add optimizations for dense packed inputs
<azonenberg>
this all the way back to the start because of things like the differencing filter etc
smkz has quit [Quit: smkz]
smkz has joined #scopehal
<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/Jf2m6
<_whitenotifier-c>
[scopehal-apps] azonenberg 802ce42 - WaveformArea: can now drag channels between waveform areas. Fixes #6.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #6: Allow drag-and-drop for reordering channels within a viewport / between viewports - https://git.io/Jf2mi
<_whitenotifier-c>
[scopehal-apps] azonenberg opened issue #102: Dragging a channel to the right/bottom of the current waveform area should create a split - https://git.io/Jf2mP
<_whitenotifier-c>
[scopehal-apps] azonenberg labeled issue #102: Dragging a channel to the right/bottom of the current waveform area should create a split - https://git.io/Jf2mP