<azonenberg>
woop, flex probe prototype sent to oshpark
<azonenberg>
Bird|otherbox: how goes it?
balrog has joined #scopehal
_whitelogger has joined #scopehal
Kenley has quit [Read error: Connection reset by peer]
_whitelogger has joined #scopehal
deltab has quit [Ping timeout: 240 seconds]
deltab has joined #scopehal
_whitelogger has joined #scopehal
<_whitenotifier-f>
[scopehal] bluecmd opened issue #296: Demo oscilloscope - https://git.io/JUF1l
<_whitenotifier-f>
[scopehal-apps] bluecmd opened issue #210: Example scope session files - https://git.io/JUF15
bluecmd[m]1 has joined #scopehal
juli965 has joined #scopehal
<Bird|otherbox>
azonenberg: still need to sort out the submodules stuff, will work on that tonight I think
<Degi>
azonenberg: I mean that you press a button in glscopeclient to do a single trigger. Currently it does the loop of single acquisitions which crashes after approx 100. With a single trig button that wont be as much of a problem
<_whitenotifier-f>
[scopehal-apps] bluecmd opened issue #211: Black screen when starting glscopeclient - https://git.io/JUbna
<bluecmd[m]1>
azonenberg: I am here in the channel if you want to bounce any debug stuff for that latest #211 issue.
<bluecmd[m]1>
whichever is most convenient :)
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #211: Black screen when starting glscopeclient - https://git.io/JUbcY
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #211: Black screen when starting glscopeclient - https://git.io/JUbna
<azonenberg>
o/ bluecmd[m]1
<azonenberg>
So yeah, WSL is completely untested at this point. If you can make it work good for you, but nobody's tried
<azonenberg>
The lack of menus and toolbars (drawn by GTK) suggests either a catastrophic failure of the graphics subsystem early on in startup (your WSL X server is just totally borked) or an early stage hang
<bluecmd[m]1>
Tbh, I would have been more surprised if it did work :)
<azonenberg>
Even the Windows build in general is relatively young and unreliable, but bvernoux and katharina (both AFK at the moment) have done a lot of good work and it should at least compile and sorta run
<azonenberg>
afaik those are the only two folks who have used it on windows at all
<bluecmd[m]1>
The problem with running as a Windows build is that I would not be able to access e.g. my spice simulations
<bluecmd[m]1>
WSL can access Linux and Windows files, but Windows cannot access the Linux files
<bluecmd[m]1>
And of course, I was curious to integrate glscopeclient with xschem to render ngspice simulation data, which ideally would be done by having a shared socket/FD between the two processes to send the nets to visualize
<azonenberg>
If nothing else, it would help rule out potential problems with your platform
<azonenberg>
If you want to debug the WSL build, i'd start by checking if it's hanging with 100% CPU or not
<azonenberg>
then set that env var mentioned in the warning
<azonenberg>
(If we can make it work under WSL then great)
<azonenberg>
what does glxinfo in the WSL system output?
<azonenberg>
if you don't have OpenGL 4.3 then it's not going to work
<bluecmd[m]1>
It is currently running at 440% CPU according to top
<bluecmd[m]1>
and been running for ~15 min now
<bluecmd[m]1>
(I am running with `OMP_WAIT_POLICY=PASSIVE`)
<azonenberg>
Attach gdb and see where it's hanging?
<_whitenotifier-f>
[scopehal-apps] bluecmd edited issue #211: Black screen when starting glscopeclient - https://git.io/JUbna
<azonenberg>
Interesting. So you have OpenGL 3.3, and we nominally require 4.3. But you also have GL_ARB_compute_shader (which is *standard* in 4.3 but apparently your much older vmware driver supports it)
<azonenberg>
We've never tested on such a system and i would expect rendering to fail currently, but i think we could make it work
<bluecmd[m]1>
The strange thing is I have nothing related to VMware in this box :)
<bluecmd[m]1>
So I think this is just something strange the X410 X server reports, or glxinfo is picking something odd from somewhere
<azonenberg>
WSL or something might be using the llvmpipe driver? not sure
<azonenberg>
anyway, the point being that right now the best case scenario is that OpenGL rendering of the waveforms fails but everything else works and you see GTK chrome around a nonfunctional UI
<azonenberg>
But i think that can be improved
<bluecmd[m]1>
Yeah, getting the UI to show seems like a good start :)
<azonenberg>
bluecmd[m]1: Can you link a full backtrace from every thread?
<azonenberg>
You're in an OpenMP parallel region
<azonenberg>
that thread looks to just be waiting for it to finish
<bluecmd[m]1>
Do you know the gdb command for bt on all threads on the top of your head?
<azonenberg>
i've always done "info threads" then "bt" in each separately
<bluecmd[m]1>
thread apply all bt it see
<bluecmd[m]1>
* `thread apply all bt` it seems
<azonenberg>
although... looking at the line that thread is stuck on i have a pretty good idea of the problem
<azonenberg>
but that will confirm
<azonenberg>
OscilloscopeWindow::OnAllWaveformsUpdated() is trying to call WaveformArea::PrepareGeometry() on a waveform area without a valid GL context. So something is probably dying there
<bluecmd[m]1>
updated the gist with bt all on all threads
<azonenberg>
hmm, lots of addresses and not much useful info
<azonenberg>
can you install the debug symbol package for libgomp and libglib, then try again?
<azonenberg>
It's not failing where i would expect
<bluecmd[m]1>
yep yep, I'm going to try to run som 3D benchmark also to verify some basic 3D functionallity. glxgears works but I doubt says much :)
<azonenberg>
Yeah so right now i think you've got at least two separate issues
<azonenberg>
first, if opengl init fails in a particular way the app hangs
<azonenberg>
rather than having sane output
<azonenberg>
second, i strictly require gl 4.3 rather than gl 3.x plus a bunch of extensions
<azonenberg>
which i think is probably workable as compute shaders are really the only 4.x feature i use
<azonenberg>
that i know of
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #212: glscopeclient requires GL 4.3 even though we don't need most 4.3 features - https://git.io/JUb8i
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #212: glscopeclient requires GL 4.3 even though we don't need most 4.3 features - https://git.io/JUb8i
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #213: Allow glscopeclient to run on pre-4.3 OpenGL if we have the necessary extensions. - https://git.io/JUb89
<bluecmd[m]1>
getting the debugging symbols for libgomp1 seems to be harder than ideal. there is some version mismatch for ubuntu 20.04 it seems
<bluecmd[m]1>
for groovy it seems to match again, but that's a full gcc-10 cherrypick
<azonenberg>
Weird
<azonenberg>
ok yeah dont worry about it just yet
<azonenberg>
I'm gonna work on a few things here, i think fundamentally the problem is that PrepareGeometry() shouldnt be called unless i'm sure the GL context is OK etc
<azonenberg>
We *should* abort cleanly if GL init fails but clearly that doesnt work
<azonenberg>
i'm also spinning up a vmware instance on my lab PC to see how we handle lower GL versions
bvernoux has joined #scopehal
<bluecmd[m]1>
The phoronix-test-suite for graphics (unigine-heaven) ended up with 1 FPS and bad performance, so my guess is that everything OpenGL-wise is being emulated
<bluecmd[m]1>
Right now xschem + gaw uses a fixed port (2020) which has a lot of limitations which I'd like to avoid. Ideally the flow would be a bit more robust and life cycles would be a bit more tied. RIght now you can easily start another xschem and it would talk to the GAW belonging to the first xschem, which definitely makes everything super broken
<azonenberg_work>
Yeah looks like some work is needed on both sides
<azonenberg_work>
my dream is to be able to use glscopeclient to do things like plotting eye patterns of a spice sim of an io cell
<azonenberg_work>
or even an open SERDES IP on sky130
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #213: Allow glscopeclient to run on pre-4.3 OpenGL if we have the necessary extensions. - https://git.io/JUbRp
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #213: Allow glscopeclient to run on pre-4.3 OpenGL if we have the necessary extensions. - https://git.io/JUb89
<azonenberg>
also i just checked, there is no GL_ARB_compute_shader on my (older) vmware
<electronic_eel>
hmm, why do you want to send the spice sim data over tcp? wouldn't it be easier to write them into a file and load them from there?
<electronic_eel>
for accessing WSL files, isn't there \\wsl$ now?
<azonenberg>
electronic_eel: the use case would be realtime streaming as the sim runs i think
<azonenberg>
among other things
<electronic_eel>
but you could just write the data into a file and load while it is being written? if one program just writes and the other just reads I don't see an issue
<azonenberg>
also it looks like vmware workstation 15, which i have, tops out at opengl 3.3 but 16 has gl 4 support
<azonenberg>
so we might actually be able to run in a vm eventually
<electronic_eel>
loading the sim data from a file would allow to use the same code as for importing waveforms from files and you just need to add the live-read part
<azonenberg>
Yeah we'll have to think about how to do file import in general soon
<electronic_eel>
also you wouldn't need special support for it in the simulator, as writing to a file is something every simulator should already support
<azonenberg>
(as in non-native file format)
<electronic_eel>
I'd would like to be able to import vcd files, to compare data from a ila to data from the scope
<azonenberg>
Yes. That's an open ticket but i havent touched it yet
<azonenberg>
Longer term i want native realtime ILA support including control and trigger
<azonenberg>
as well as the ability to do synchronized triggering via a GPIO between an ILA and an analog scope
<azonenberg>
(I've POC'd this already but nothing release ready, it used an internal ILA core i need to debug more)
<electronic_eel>
yeah, that would be nice
<bluecmd[m]1>
electronic_eal: I guess you could send the spice data, but the thing I was thinking was more remote control
<bluecmd[m]1>
you click on a wire in xschem, press Alt+G and it shows up in glscopeclient
<bluecmd[m]1>
that's how the GAW integration works now
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUbu0
<_whitenotifier-f>
[scopehal-apps] azonenberg da8600b - Reduced required OpenGL version from 4.3 to 4.2 plus a bunch of extensions. Improved GL version checking.
<azonenberg>
bluecmd[m]1: Try the latest commit. It probably still won't work, but does it detect a graphics problem and abort rather than hanging?
<bluecmd[m]1>
sure thing
<azonenberg>
if so we can call #211 fixed
<bluecmd[m]1>
no difference
<azonenberg>
So that's interesting. It seems like we're loading the file before the window is realized and that is failing. gimme a bit...
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUbzE
<_whitenotifier-f>
[scopehal-apps] azonenberg 09d8497 - OscilloscopeWindow: Don't update waveform areas before GL init has completed
<azonenberg>
bluecmd[m]1: and what about this?
<bluecmd[m]1>
Same
<azonenberg>
attach gdb and pull a trace
<azonenberg>
it should be impossible to hang in the same spot
<azonenberg>
because the offending function isnt called before GL init has happened
<azonenberg>
printing an error dialog about being unable to open a file
<azonenberg>
the event loop for the dialog is busy-polling a nonexistent oscilloscope
<azonenberg>
rather than rendering it
<azonenberg>
I can actually reproduce this locally by opening a nonexistent file, so what's probably happening is that you typoed the file path or it's in the wrong directory or something
<bluecmd[m]1>
let's see!
<azonenberg>
During startup glscopeclient chdir's to the binary directory in order to find all of the resources it uses
<azonenberg>
so you have to open files by absolute path
<azonenberg>
if you pass them on the command line
<bluecmd[m]1>
no, the file exists
<azonenberg>
It pops up an "unable to open file" dialog but that dialog is hanging rather than displaying in this case
<bluecmd[m]1>
oh
<bluecmd[m]1>
absolute
<azonenberg>
The backtrace shows you in the Yaml::BadFile exception handler
<bluecmd[m]1>
yep that worked!
<azonenberg>
Define "worked"
<bluecmd[m]1>
I got a bunch of OpenGL errors and a UI
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #214: glscopeclient hangs during startup when opening nonexistent file - https://git.io/JUbgx
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #214: glscopeclient hangs during startup when opening nonexistent file - https://git.io/JUbgx
<bluecmd[m]1>
So the windows that opened are: 1) The "Oscilloscope: myscope (LECROY ...)" window, 2) Protocol Analyzer: 10GBase, 3) 2x dialog windows with "Your graphics card or driver does not appear to support OpenGL 4.2"
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #214: glscopeclient hangs during startup when opening nonexistent file - https://git.io/JUbgx
<azonenberg>
Great. What's the stdout log say? and does the protocol analyzer display some valid looking ethernet frames?
<bluecmd[m]1>
Probably pasting it in this IRC bridge thing is not a great idea
<bluecmd[m]1>
(I was one enter away from pasting i here, but no idea how that would show up on the IRC end)
<_whitenotifier-f>
[scopehal-apps] azonenberg edited issue #212: glscopeclient requires GL 4.2 even though we don't need most 4.2 features - https://git.io/JUb8i
<bluecmd[m]1>
As for the protocol analyzer it is empty
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #212: glscopeclient requires GL 4.2 even though we don't need most 4.2 features - https://git.io/JUb2n
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #211: Black screen when starting glscopeclient - https://git.io/JUb2W
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #211: Black screen when starting glscopeclient - https://git.io/JUbna
<azonenberg>
Ok so your WSL platform is only giving you GL 3.1
<azonenberg>
I'll add some clarifications to the error message
<azonenberg>
the first step is to make the error render :p
<azonenberg>
anyway so the GL version issue is a WSL graphics limitation that we can't do anything about
<_whitenotifier-f>
[scopehal-apps] nshcat commented on issue #212: glscopeclient requires GL 4.2 even though we don't need most 4.2 features - https://git.io/JUb2z
<azonenberg>
so for the time being glscopeclient on WSL isn't going to happen
<_whitenotifier-f>
[scopehal-apps] nshcat edited a comment on issue #212: glscopeclient requires GL 4.2 even though we don't need most 4.2 features - https://git.io/JUb2z
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #212: glscopeclient requires GL 4.2 even though we don't need most 4.2 features - https://git.io/JUb2D
<azonenberg>
bluecmd[m]1: I'll work on the #214 hang, but in the meantime do you want to try building under mingw/msys2 and we'll see how well we can make that work for you?
<bluecmd[m]1>
Yeah, let's try that I guess
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #212: glscopeclient requires GL 4.2 even though we don't need most 4.2 features - https://git.io/JUb2N
<bluecmd[m]1>
I think I'd prefer to cross-compile it from Linux if that's possible rather than install mingw
<azonenberg>
There is currently no cross compilation support for building Windows binaries on Linux. I'm willing to explore that in the future
<azonenberg>
but nobody's attempted it and it likely won't work :p
<azonenberg>
If you want to try building and running on native linux to start, feel free
<azonenberg>
that will give you a chance to play around with the app if nothing else
<bluecmd[m]1>
Right, probably will do that on the laptop then
<azonenberg>
Basically all but two of the known users/devs on the project right now are linux users
<azonenberg>
so anything but building on linux to run on linux is a lot less well tested :)
<bluecmd[m]1>
Sorry to be a PITA, but compiling stuff and doing any development work is what I use Linux for, I'm really quite unproductive trying to figure out how to even get started with mingw
<bluecmd[m]1>
So that's why I have this WSL frankenstein setup :)
<azonenberg>
Yeah lol
<azonenberg>
why are you trying to run on windows at all?
<electronic_eel>
bluecmd[m]1: why do you use windows as your primary os then? and not linux with windows in a vm?
<bluecmd[m]1>
electronic_eel: Windows is much more stable as a desktop OS I find (snappier UI, better "just works" when it comes to e.g. Chrome, richer audio system), and of course the occasional Steam gaming
<bluecmd[m]1>
Really, having Linux as a well-integrated VM in Windows is perfect for me - in theory
<electronic_eel>
hmm, linux is much more customizable to the way I want to work. also I don't have any issues with "snappiness". re auido I think pulse works nice for me, and if I'd need more, jack would offer it. gaming is not a requirement for me.
<electronic_eel>
if gaming were a requirement, I'd probably set up dualboot
<bluecmd[m]1>
Pros/cons on everything. If you have dualboot you can't have a large download or simulation running in the background when you play.
<electronic_eel>
if offload long downloads to my server, that could also be done with sims
<bluecmd[m]1>
and I could have two computers, it's all solvable problems. again, pros/cons - down to personal taste. right now WSL is the best solution that I know of for me so..
<bluecmd[m]1>
seems llvmpipe, which I read is a full CPU renderer is getting 4.5 OpenGL support. So I guess I would be able to use glscopeclient using software rendering for now if I get those patches
<bluecmd[m]1>
Scrolling in and out is snappy and nice, 0% CPU usage right now
<azonenberg>
Ok. There's a 502 error GL_INVALID_OPERATION iirc, but i often get those during startup for reasons i havent figured out. if you don't get it every frame it's nothing to worry about and not the root cause for the problem
<bluecmd[m]1>
Ah
<bluecmd[m]1>
Didn't see that one
<azonenberg>
what i find interesting is that one of the two digital traces (clock recovery) does not show up
<azonenberg>
but the other (threshold) does
<azonenberg>
they're the exact same rendering code path
<azonenberg>
same as C2-C3 vs C2
<azonenberg>
also interesting is the UI chrome not showing up for menus and most of the toolbar
<azonenberg>
conjecture: i'm doing something slightly wrong and the "real" gpu drivers are more forgiving than mesa
<azonenberg>
If you right click anywhere in the plot area does a context menu show up?
<azonenberg>
also if you double click a channel name box or the timeline does a properties dialog appear?
<azonenberg>
Make a new issue against scopehal-apps for this, include the screenshot. We'll probably find multiple problems and make new tickets for each as we go
<bluecmd[m]1>
The menu shows up when I mouse-over on it
<bluecmd[m]1>
and the menus as well
<azonenberg>
Innnteresting
<bluecmd[m]1>
they stay rendered once a mouse-over pass has been done
<azonenberg>
Note all of this in the issue log
<bluecmd[m]1>
Context-menu works, it has some pixel errors but looks fine
<azonenberg>
So i guess the big blocker at this point is some of the traces not showing up
<bluecmd[m]1>
properties works
<bluecmd[m]1>
Could it be a save-file issue?
<azonenberg>
Doubtful. The protocol decodes are all derived from that data
<azonenberg>
Decodes are evaluated lazily, the decode output isn't serialized
<azonenberg>
only the config
<azonenberg>
So if you are pulling valid ethernet frames out and have a nice eye pattern, the data is fine
<azonenberg>
oh also there should be visible splitter bars between the waveform areas you can drag to resize them
<azonenberg>
Those arent showing up either
<azonenberg>
anyway i'm about to finish lunch and have to get back to $dayjob but keep us posted and see how much you can figure out on your end. My top priority after work is going to be the hang on bad save file since it's probably an easy fix
<bluecmd[m]1>
And the function is called ClockRec still?
<azonenberg>
yeah i mean if the 64/66b decode and eye pattern work
<azonenberg>
you obviously had a clock for it to sample the data
<azonenberg>
so the CDR filter is doing its thing, the output just isn't rendered
<bluecmd[m]1>
Right
<bluecmd[m]1>
Anyway, thanks for your help!
<bluecmd[m]1>
At least we know that Mesa 20.2 works fine with WSL
<azonenberg>
When you zoom in/out (scroll wheel) does anything change in terms of traces appearing/disappearing?
<bluecmd[m]1>
Well, not more than I would expect
<bluecmd[m]1>
If I zoom out super long everything becomes dark
<azonenberg>
yeah it's doing zoom to center, the overlays probably get too small to see after a while
<azonenberg>
i have some optimization that culls stuff <1 pixel wide etc
<azonenberg>
FYI if you do more digging, i'm using a bit of a complicated multistep render architecture
<azonenberg>
Each plot (WaveformArea) is its own GTKGLArea and thus GL context
<azonenberg>
Within each WaveformArea, rendering is multiple passes
<bluecmd[m]1>
The eye diagram seems very very static
<bluecmd[m]1>
I can't really interact with it at all
<azonenberg>
The first step, which seems to be universally failing, is to use Cairo to draw a gradient and grid in the background to a texture
<azonenberg>
Second step is to use one compute shader invocation per signal to render analog and digital waveforms (not protocol data) to another texture
<azonenberg>
There is no GL triangle geometry in the signals, they're effectively software rendered on the GPU
<azonenberg>
Then the third step goes back to Cairo and draws the Y axis, cursors, channel label button, and decode boxes/text to yet another texture
<azonenberg>
Eye patterns are generated as a bitmap in software then written to a texture
<azonenberg>
once all of this is done, i then do the only actual GL triangle rendering pass to composite all of these textures on a pair of triangles filling the whole viewport
<azonenberg>
During this final pass the under/overlays are just copied and alpha blended
<azonenberg>
waveforms and eye patterns are 32-bit floating point density maps internally, so the fragment shaders for those apply tone mapping to RGB
<azonenberg>
the eye pattern shader actually uses each floating point pixel value as an index into a 1D texture with the gradient
<azonenberg>
The waveform shader just tone maps the floats to RGB from a static color and scales it. (They're floating point because once i fix the broken code from the new rendering engine, waveform persistence will integrate multiple waveform passes with decay)
<bluecmd[m]1>
it was more annoying to record a full desktop than I thought so I ended up running the X server in virtual desktop mode, which is locked to a pretty low resolution - so it's quite cramped.
<bluecmd[m]1>
however, it looks and behaves exactly how it does in Windows (except that windows are easier to move around)
<bluecmd[m]1>
easier in windows that is, fluxbox apparently didn't like being draged around in the title bar
<azonenberg>
no close button on the protocol analyzer window?
<azonenberg>
somebody else here had that issue on linux with a certain window manager too
<azonenberg>
Guess we need to investigate
<azonenberg>
also of note is that the channel 2 waveform in this video looks correct while it looked almost flatlined in the last screenshot you linked
<azonenberg>
But the ClockRec and C2-C3 traces are still missing
<azonenberg>
Eye patterns aren't supposed to share groups with normal signals, i haven't yet added logic to disallow that
<azonenberg>
but they force the time scale to be two UIs wide and i think disallow panning horizontally
<azonenberg>
persistence is known broken, there's an open issue for it
<azonenberg>
(not that it will do anything in offline mode anyway)
<bluecmd[m]1>
Maybe there is, i didn't want to close it because I wanted to show that I could jump around
<bluecmd[m]1>
and show how the latency is
<bluecmd[m]1>
I have no complaints on the speed, it feels very snappy
<azonenberg>
Yeah although it might slow down once everything is rendered :p
<bluecmd[m]1>
true :D
<azonenberg>
Also those are comparatively short waveforms
<azonenberg>
the real test is how it handles 128M points per waveform or something
<bluecmd[m]1>
well, you know where I am if you want to give it a try :)
<azonenberg>
but when you add 32-bit floats per sample and then overhead for timestamps etc the capture would be gigabytes in size
<azonenberg>
So its not something to casually email around
<azonenberg>
I have one waveform capture that's 80 GB
<azonenberg>
It's 64M points on 7 channels and there's i think 11 historical waveforms in the dump? in total it was around 5 billion data points, ~700M per channel
<azonenberg>
glscopeclient needs about 110 GB of RAM to open it
<azonenberg>
now THAT is a good test of performance :p
<bluecmd[m]1>
Yeah that's maybe a bit heffy for my poor workstation
<azonenberg>
Although i've got better lately at de-duplicating digital waveforms with periods of no toggling so that would probably fit in ~30 GB of RAM now if not less
<bvernoux>
It will be really interesting to have a bench
<azonenberg>
The other planned optimization is to figure out how to swap out some historical waveforms to disk
<bvernoux>
especially to check how the latest Ryzen work vs Intel
<azonenberg>
so if you have hundreds of waveforms in a dump, only keep a few in memory and swap out the rest to disk
<bvernoux>
as Ryzen are faster than Intel now especially for heavy load with multicore
<azonenberg>
Right now the entire history has to fit in ram
<bvernoux>
It would be nice to have a ThreadRipper with glscopeclient ;)
<bvernoux>
or just a Ryzen9 ;)
<electronic_eel>
a colleague of mine has a first-gen threadripper. for compiling, the current ryzen 9 of another colleague rips the threadripper apart
<electronic_eel>
so amd really improved their designs
<electronic_eel>
and the next gen ryzen will be announced this week
<bvernoux>
ha yes
<bvernoux>
I'm really interested by next gen Ryzen ;)
<azonenberg>
Yeah i've been all intel for years but i might want to look at AMD's low end server offerings when i build the new storage cluster
<bvernoux>
as Intel is far behind now
<bvernoux>
also Intel have so bad integrated GPU vs AMD ;)
<azonenberg>
since i dont need ultra high CPU performance. what i need is moderate performance, a lot of pcie lanes for nvme and 10GbE, low idle power, and ECC RAM
<electronic_eel>
intel is just stagnating. it's just another *lake refresh every year, without any substantial improvements
<bvernoux>
ok NVIDIA is number one for GPU ;)
<bvernoux>
yes intel is stagnating with expensive stuff since too much years now
<bvernoux>
azonenberg, I search also native 10GbE ;)
<electronic_eel>
and you can use ECC ram on the ryzens, while intel requires $$$ systems for that
<bvernoux>
a workstation ;)
<bvernoux>
with 128GB RAM ;)
<bvernoux>
it is for OpenEMS too ;)
<azonenberg>
i have yet to see a reasonably priced motherboard with SFP+ interfaces
<azonenberg>
10Gbase-T doesn't count
<bvernoux>
azonenberg, I'm seraching that too ;)
<bvernoux>
for SM200C ;)
<bvernoux>
a refurbished SM200C ;)
<electronic_eel>
seems like fibre to the desk isn't a thing for the mass market
<azonenberg>
electronic_eel: yeah apparently. but i'd expect to see it on server mobos
<bvernoux>
yes it is clearly not ;)
<azonenberg>
I'm not even seeing many xeon boards with it
<bvernoux>
yes it is clearly not standard
<electronic_eel>
on server boards it should be common. unfortunately many people seem to think 10gbase-t is reasonable there. or they get confused by having 1gbase-t and sfp+ on one board or something
<electronic_eel>
hpe has some boards where you can plug in a sfp+ cage without losing a pcie-slot or lanes
<azonenberg>
yes i see a lot of 10gbase-T on server mobos
<azonenberg>
less SFPs
<bvernoux>
azonenberg, when do you plan to rent the Tek Serie5 ?
<azonenberg>
Which is odd as a SFP is much less hardware than a baseT PHY
<bvernoux>
azonenberg, maybe they can provide you a Tek Serie6 for the same price ;)
<azonenberg>
you need the mac regardless, and a 10gbase-R PCS is barely any gates, then a standard serdes ip
<bvernoux>
I do not remember the advantage of SFP+ vs 10gbase-T
<bvernoux>
less power consumption ?
<azonenberg>
bvernoux: lots of them. baseT is very picky on cable quality so lots of gigabit-grade cat5 wont work reliably
<azonenberg>
it uses much more power, the PHY chips are almost impossible to find without NDAs and such from broadcom et al
<electronic_eel>
much less power consumption / cooling, 10gbase-T adds latency
<azonenberg>
it requires FEC and very complex line coding so the latency is higher
<azonenberg>
meanwhile a 10Gbase-R SFP+ just needs one bidirectional SERDES to drive and a cheap connector (like $3 for connector+cage, maybe less)
<bvernoux>
yes very nice
<bvernoux>
it is strange why it is not more popular
<azonenberg>
so you can just stick it on an fpga with no external parts
<azonenberg>
bvernoux: as far as a mso6, TRS-RenTelCo has a MSO64 but it's the 8 GHz version
<azonenberg>
and i imagine that's a lot more expensive per month to rent
<azonenberg>
the 5 series is 2 GHz and has relatively few options on it so it's cheap
<bvernoux>
azonenberg, yes it shall be crazy more expensive to rent it ;)
<bvernoux>
azonenberg, maybe you can have a deal with them
<bvernoux>
to do a video of the Tek6 and they provide you a very nice price
<azonenberg>
interestingly they are also willing to sell it for $60K
<azonenberg>
(base model, 8 GHz with no options)
<bvernoux>
with 8GHz Probes ;)?
<bvernoux>
I really doubt
<bvernoux>
they provide only 1GHz passive probes IIRC
<azonenberg>
oh of course there's no 8 GHz probes for that price
<azonenberg>
lol
<bvernoux>
1x 8GHz Probes is probably 20KUSD ;)
<azonenberg>
Lol, very possible
<azonenberg>
Considering the 4 GHz active diff probe i'm looking at from lecroy is $3.5K... as a refurb
<azonenberg>
assuming the same ~50% discount vs new that they usually do, it probably sells new for around $7K
<bvernoux>
yes ;)
<bvernoux>
so 8GHz is clearly >2x 7KUSD ;)
<bvernoux>
especially they shall not sell such probe every day ;)
<bvernoux>
it is not even enough for USB 4.0 ;)
<electronic_eel>
or for doing pcie 3.0 si work
<azonenberg>
I think if i had a scope that could do 10GbE SI work i'd be set for a long time
<bvernoux>
USB 4.0 = PCI Express on USB-C connector ;)
<azonenberg>
But that will require quite a bit more bandwidth than i have now
<azonenberg>
bvernoux: also the rule of thumb i've seen for active probes is on the order of $1K + $1K/GHz
<bvernoux>
ha ok
<azonenberg>
with MSRP probably a fair bit higher than that
<azonenberg>
So as a rough guess i'd expect an 8 GHz probe to be somewhere a little over $10K
<azonenberg>
(that rule is also from a few years ago and inflation has probably bumped that up a bit)
<miek>
another problem is an 8GHz scope and an 8GHz probe does not equal an 8GHz system :)
<azonenberg>
Yeah
<azonenberg>
oh, random note i found reading the pico probe datasheet
<azonenberg>
it says they use MELF resistors
<miek>
do they say why?
<azonenberg>
No
<azonenberg>
it was just mentioned in passing "MELF resistor technology"
<electronic_eel>
strange. usually bigger physical size is associated with less usable for high freq
<Degi>
Maybe they're more stable or so?
<Degi>
Are devices usually specified at -3 dB? So probe + scope = -6 dB?
<azonenberg>
That would be my assumption, yes
bvernoux has quit [Quit: Leaving]
<_whitenotifier-f>
[scopehal-apps] electroniceel opened issue #215: Window title of protocol analyzer windows not shown or imcomplete - https://git.io/JUbF2
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #215: Window title of protocol analyzer windows not shown or imcomplete - https://git.io/JUbF2
<_whitenotifier-f>
[scopehal-apps] nshcat commented on issue #215: Window title of protocol analyzer windows not shown or imcomplete - https://git.io/JUbbU