<xzcvczx>
azonenberg: btw re the commit for UART.cpp i could have (like darius) split it into 5 or so #ifdefs but i find those to be quite unreadable, and there isn't that much common
<d1b2>
<Darius> silly linux makes it hard 😉
<xzcvczx>
ikr down with linux
<xzcvczx>
i am surprised more great things from bsd aren't ported over to linux due to the liberal licensing
<d1b2>
<Darius> ho ho ho
<d1b2>
<Darius> they would need to be relicensed
<d1b2>
<Darius> which wouldn't be a deal breaker if anyone really wanted to in all lieklyhood
<d1b2>
<Darius> I think NIH is a strong reason 😕
<xzcvczx>
well 2&3 clause BSDs are apparently compatible with gpl
<xzcvczx>
(not the opposite of course)
<d1b2>
<Darius> I didn't think linux shipped non GPLd code though
<xzcvczx>
termios MIGHT be userspace
<xzcvczx>
but always possible
<sorear>
lots of linux kernel code is BSD dual licensed
<xzcvczx>
hmmm you are mostly right, they seem to allow mit/isc but not bsd single licenced
<xzcvczx>
@darius
<xzcvczx>
and i only added that last bit after you commented sorear
<xzcvczx>
i hadn't seen that
<d1b2>
<Darius> dual licensed would be fine
<d1b2>
<Darius> but I believe you couldn't take some code only BSD licensed and put it in the Linux kernel
<xzcvczx>
well termios mainly seems to be done in glibc
<xzcvczx>
but gnu doesn't like the "say you are using it" clause either
<sorear>
"individual source files can have a different license which is required to be compatible with the GPL-2.0:"
<d1b2>
<Darius> fair enough
<xzcvczx>
sorear: is that for glibc?\
<sorear>
clearly not, glibc is GPL3
<sorear>
quote from Documentation/process/license-rules.rst
<xzcvczx>
oh my bad
<xzcvczx>
glibc is lgpl2 iirc
<xzcvczx>
or maybe lgpl3
<xzcvczx>
oh lgpl2.1
<sorear>
indeed mine is
<xzcvczx>
Aside from that, individual files can be provided under a dual license, e.g. one of the compatible GPL variants and alternatively under a permissive license like BSD, MIT etc. <--- is what i read so would need to be dual regardless (for kernel)
<xzcvczx>
well dual if bsd
<d1b2>
<mubes> Didn't the whole networking stack that Alan Cox ported come from bsd originally?
<azonenberg>
mubes: awesome, glad to hear
<_whitenotifier-1>
[scopehal-apps] azonenberg opened issue #348: Create Windows install packaging - https://git.io/JsOwO
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JsO1c
<_whitenotifier-1>
[scopehal-apps] azonenberg 89a486b - Don't allow zooming out further than the longest waveform in a group
<xzcvczx>
ooo i so have to try that
<xzcvczx>
have you actually followed up on the attribute target avx thing on clang or have you stopped? i might try and follow it up if yo uwont'?
<azonenberg>
I havent touched it. I believe the problem is that the immintrin.h functions aren't marked as attribute target
<azonenberg>
so it gets confused about the ABI
<azonenberg>
it doesnt realize that they're a) inlined and b) only ever called from functions with target avx2
<azonenberg>
gcc figures it out, clang doesn't
<xzcvczx>
i dont remember, did you test clang on linux?
<azonenberg>
No
<xzcvczx>
is immintrin provided by os or compiler?
<azonenberg>
That's a good question and i dont know
<xzcvczx>
ok i will look at that
<xzcvczx>
i should probably also look at building with gcc on bsd and make sure there are no issues there
<d1b2>
<mubes> Huge improvement. Helps avoid zoomout-hell, especially when you've got a lot of samples and a not-so-fast graphics card
<azonenberg>
Yep, that's exactly why I did it
<azonenberg>
I might also make it center/clamp when you zoom out all the way rather than letting you zoom to one end and see empty space
<azonenberg>
that will come later
<d1b2>
<mubes> Sometimes it's useful to move the start of a waveform onto the screen, otherwise it's a bit tricky to zoom at the beginning.
<azonenberg>
Also you may have seen i made some improvements to the protocol analyzer mode
<azonenberg>
When you click on a packet it will center if it fits entirely on screen
<azonenberg>
if it doesn't fit at the current zoom level, it will move the start of the packet to about the left 10% of the view
<azonenberg>
Also the cursors are synced to the protocol analyzer
<azonenberg>
If you move a cursor onto a packet, the protocol analyzer will select that row
<azonenberg>
and if you click a row with a cursor active the cursor moves to the start of the packet
<d1b2>
<mubes> Didn't notice that one at the moment, but I'm in day-job mode at the moment pushing paper around so will look this evening.
<xzcvczx>
azonenberg: dumb fix but i wonder if it might work, as the avx/2 function should never be called by an unsupported cpu could we put in a "default" (FMV) function that just returns which clang might not cough on?
<d1b2>
<mubes> The only real major bugbears I have with the display now are down to the scales.
<xzcvczx>
or does it just not build on windows?
<xzcvczx>
well non-elf
<xzcvczx>
and would be a dirty hack
<azonenberg>
FMV will not compile on non-elf
<xzcvczx>
ok nvm then
<sorear>
not even elf, it's a glibc only feature
<azonenberg>
well gcc can only use it on elf targets
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JsOAQ
<_whitenotifier-1>
[scopehal-apps] azonenberg d74ac30 - Fixed incorrect comment in shader
bvernoux has joined #scopehal
<bvernoux>
azonenberg, When I test latest glscopeclient I see a regression with EyeDiagram or something related
<bvernoux>
to reproduce it I just load 64b66b.scopesession
<azonenberg>
I haven't touched any of that code in quite some time
<azonenberg>
It looks like a bug but i don't think it's a regression
<azonenberg>
and it might be windows specific? 64b66b.scopesession loads fine for me
<bvernoux>
it seems like m_accumdata pointer is invalid
<bvernoux>
also the gtk assertion about length
<azonenberg>
That's unrelated
<bvernoux>
ha ok
<azonenberg>
it's in the protocol analyzer window and i havent found the root cause but it appears harmless
<bvernoux>
I need to check with debug version
<bvernoux>
as with release it is impossible to have more details with full stack frames linked to code ...
<azonenberg>
Yeah, and also see if you can log what's going on in the EyeWaveform object as far as when stuff is created and destroyed
<azonenberg>
this smells like it might be a race condition triggered by events happning in a different order on windows from linux?
<bvernoux>
few days ago (let say 1 week) I didn't have such crash when loading 64b66 example
<azonenberg>
Very possible some of the unrelated tweaks I made to optimizing file load caused events to happen in a different order or something
<azonenberg>
I dont think i've made any changes to the eye pattern code in quite some time
<azonenberg>
So if the bug is truly there, it's a latent bug that has been there for a long while and was only unearthed when something else happened
<bvernoux>
yes I'm not sure the root cause is EyePattern
<azonenberg>
The other possibility is that it's something related to the optimized file loading code i wrote and the crash being in the eye is just a side effect or symptom
<azonenberg>
Let me know what you figure out
<bvernoux>
something seems corrupted or failed before ...
<bvernoux>
I'm trying to hack the scopesession ;)
<bvernoux>
to remove the Eye pattern
<bvernoux>
if I remove it I suspect I will have issue with id ;)
<azonenberg>
yeah you have to delete the waveformarea that references it too
<azonenberg>
and the references to that area in the splitters
<azonenberg>
The file format was not really meant to be hand edited, although it can be done with some effort
<bvernoux>
yes it is what i'm trying to figure out
<bvernoux>
to confirm if that load fine without Eye Pattern displayed/used
<bvernoux>
yes it crash also in debug ;)
<bvernoux>
it is a good point
<bvernoux>
I confirm it crash on => m_accumdata = NULL;
<bvernoux>
I have removed the Eye Pattern stuff and no crash
<bvernoux>
just edited the file by hand ;)
<azonenberg>
That sounds like there's a double free somewhere
<azonenberg>
because we set m_accumdata to NULL in the destructor and nowhere else
<azonenberg>
So there's only three possible ways this could happen
<azonenberg>
a) double free
<azonenberg>
b) casting a garbage pointer to an EyeWaveform
<azonenberg>
c) memory corruption somewhere else that takes out m_accumdata in the process
<azonenberg>
Try adding a debug log to the destructor and constructor
<azonenberg>
and record "this"
<azonenberg>
if you see the same pointer destroyed more than once you've got the smoking gun
<azonenberg>
at which point the question is why it doesnt happen on linux
<bvernoux>
yes strange
<bvernoux>
it is fun but if I do the Eye Pattern manually it works
<bvernoux>
so it seems the issue appears when it is auto loaded with session
<azonenberg>
Yeah, so something in the loading code triggers a double free but only on windows
<azonenberg>
Looking at your backtrace it was handling a resize event
<azonenberg>
that might have something to do with it
<bvernoux>
hmm it seems scopesession file have changed ;)
<azonenberg>
since the eye reallocates when you resize
<bvernoux>
I have saved it to compare
<bvernoux>
there is some new parameters and others have changed a bit
<bvernoux>
like the inputs
<bvernoux>
before 3
<bvernoux>
after
<bvernoux>
3/0
<bvernoux>
overlays have stream too now
<bvernoux>
maybe old format are not supported correctly ?
<bvernoux>
are you sure you are using same 64b66b.scopesession than mine (it was old test you provided)
<bvernoux>
also metadata are different now
<bvernoux>
with time in fsec before it was psec
<bvernoux>
I really suspect a bug to read old scopesession
<azonenberg>
No, because i created my current test file by reading the same one you did
<bvernoux>
hmm ok
<azonenberg>
i generally don't re-save test files
<azonenberg>
so a lot of them are still using fairly old file formats
<azonenberg>
yeah there's no stream indexes in my 64b66b.scopesession
<bvernoux>
if i reload the session I have saved all work fine
<bvernoux>
I have the issue only with old session
<bvernoux>
maybe the resize too
<bvernoux>
I see in call stack there was a resize before the crash
<azonenberg>
Let me upload my current test file i'm using
<bvernoux>
also new scope data are "compressed" now so new format is more interesting
<bvernoux>
so maybe it is not mandatory to support older format if it is the root cause
<bvernoux>
so far I cannot debug correctly with mingw64 & python3 something is broken :(
<bvernoux>
but I can add some traces ...
<azonenberg>
There's no compression
<bvernoux>
it is why I attache VS2019 to debug when it is crashed (too late)
<azonenberg>
I'm just not saving data I can regenerate on demand
<bvernoux>
azonenberg, I see data are smaller strange
<azonenberg>
The old sparse file format still exists
<bvernoux>
ha ok
<azonenberg>
and is used for irregularly sampled dat
<azonenberg>
If you look at the waveform metadata file
<azonenberg>
missing is synonymous with "sparsev1"
<azonenberg>
"densev1" is the newer compact format
<azonenberg>
"sparsev2" is planned but not implemented, and will be the same size as sparsev1 but in struct-of-arrays format instead of array-of-structs so faster to load (direct serialization of the in memory representation)
<bvernoux>
hmm your sessions file are identical to what I test
<bvernoux>
so it seems to be a bug related to MSYS2 mingw64 build....
<azonenberg>
Yeah like i thought
<azonenberg>
I deliberately keep the old test files around to make sure things stay compatible
<azonenberg>
I've added new features and new storage formats and new fields
<azonenberg>
but i always had default values and such so that loading old files works. I don't want data to ever bitrot
<azonenberg>
Any lack of upward compatibility is a bug and should be reported as such
<bvernoux>
yes
<azonenberg>
But since the linux build loads it fine, i dont think it's related to the file format
<azonenberg>
I think it's events firing in a different order on windows than linux during file load
<azonenberg>
causing some kind of race
<bvernoux>
yes really possible
<bvernoux>
it can be related to msys2 mingw64 updates too who know
<bvernoux>
as it is up to date here
<bvernoux>
using latest official version
<bvernoux>
gcc ...
<bvernoux>
ok I have repaired python 3.8 ;)
<bvernoux>
ok I have
<bvernoux>
warning: HEAP[glscopeclient.exe]:
<bvernoux>
Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
<bvernoux>
--Type <RET> for more, q to quit, c to continue without paging--
<bvernoux>
warning: Invalid address specified to RtlFreeHeap( 0000000000570000, 000000000CFD5D30 )
<bvernoux>
0x0000000076e592d2 in ntdll!EtwEventProviderEnabled () from C:\Windows\SYSTEM32\ntdll.dll
<bvernoux>
it seems there is 2 free called
<bvernoux>
#0 0x0000000076e592d2 in ntdll!EtwEventProviderEnabled () from C:\Windows\SYSTEM32\ntdll.dll
<bvernoux>
#1 0x0000000076e3028a in ntdll!longjmp () from C:\Windows\SYSTEM32\ntdll.dll
<bvernoux>
#4 0x000007fefec110c8 in msvcrt!free () from C:\Windows\system32\msvcrt.dll
<bvernoux>
#3 0x0000000076e358f2 in ntdll!longjmp () from C:\Windows\SYSTEM32\ntdll.dll
<bvernoux>
#2 0x0000000076e747c9 in ntdll!RtlLogStackBackTrace () from C:\Windows\SYSTEM32\ntdll.dll
<bvernoux>
#5 0x000007fed4678699 in EyeWaveform::~EyeWaveform (this=0xcfd5c60, __in_chrg=<optimized out>)
<bvernoux>
at C:\msys64\home\Ben\scopehal-apps\lib\scopeprotocols\EyePattern.cpp:61
<bvernoux>
#6 0x000007fed46786f9 in EyeWaveform::~EyeWaveform (this=0xcfd5c60, __in_chrg=<optimized out>)
<bvernoux>
at C:\msys64\home\Ben\scopehal-apps\lib\scopeprotocols\EyePattern.cpp:65
<bvernoux>
#7 0x000007fed753bb66 in OscilloscopeChannel::SetData (this=0x5ec0d70, pNew=0x0, stream=0)
<bvernoux>
at C:\msys64\home\Ben\scopehal-apps\lib\scopehal\OscilloscopeChannel.cpp:351
<bvernoux>
#8 0x000000013f29e116 in EyePattern::SetWidth (this=0x5ec0d70, width=746)
<bvernoux>
at C:/msys64/home/Ben/scopehal-apps/lib/scopeprotocols/EyePattern.h:126
<bvernoux>
#9 0x000000013f2523f6 in WaveformArea::on_resize (this=0x5ff9870, width=746, height=347)
<bvernoux>
at C:\msys64\home\Ben\scopehal-apps\src\glscopeclient\WaveformArea_events.cpp:96
<bvernoux>
in the call stack
<bvernoux>
5 & 6
<bvernoux>
hmm this => #7 0x000007fed753bb66 in OscilloscopeChannel::SetData (this=0x5ec0d70, pNew=0x0, stream=0)
<bvernoux>
is suspicious with pNew=0x0
<azonenberg>
SetData(NULL) is a well defined, legal operation for when there's no data or a filter failed to run for some reason
<azonenberg>
If anything doesn't handle that, that's a bug
<azonenberg>
When it SetData(NULL)'s it frees the old EyeWaveform
<azonenberg>
The stack trace of EyeWaveform::~EyeWaveform() showing up twice looks funny
<azonenberg>
I don't know if that's related or not
<azonenberg>
might be an artifact of the gdb logs
<azonenberg>
you'd have to add a log call to ~EyeWaveform() or look at the disassembly to see what is actually going on there
<azonenberg>
Ultimately what's happening is that when the waveform view is resized, it resizes the eye pattern
<azonenberg>
Which results in clearing out the old eye data as it's the wrong size now
<azonenberg>
That destructor call is crashing when it should be cleanly freeing memory
<azonenberg>
I suspect the true problem is further up the chain causing the data to be bogus or something
<azonenberg>
or maybe the same data is freed more than once
<azonenberg>
or something
<bvernoux>
I'm adding a bp in C:\msys64\home\Ben\scopehal-apps\lib\scopeprotocols\EyePattern.cpp:61
<bvernoux>
to check that ;)
<azonenberg>
bvernoux: also before i forget
<azonenberg>
what is the status of the mso5000 x/y axis incorrect bug you reported a while ago?
<azonenberg>
#381
<azonenberg>
is that still a thing or is it fixed now?
<bvernoux>
azonenberg, it is not fixed as IIRC there was no any change on Rigol driver
<azonenberg>
Ok
<bvernoux>
it is just the scale is wrong
<azonenberg>
Any interested in working on that once you figure out what's up with this eye issue?
<bvernoux>
zoom out to full scale
<bvernoux>
like it is not computed correctly the min/max for X & Y
<bvernoux>
or not computed at all maybe
<azonenberg>
What do you mean min and max?
<azonenberg>
the displayed time scale in the view has nothing to do with what's on the scope screen
<azonenberg>
that's what timebase settings are for
<bvernoux>
in fact to change the scale for waveform min/max is computed for the full waveform IIRC
<bvernoux>
I suspect it is not done on Rigol
<bvernoux>
to be checked
<azonenberg>
For Y axis, the view should always map 1:1 to the full scale ADC range
<bvernoux>
Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
<bvernoux>
then single step => Single stepping until exit from function ntdll!RtlUnhandledExceptionFilter,
<bvernoux>
all is dead ;)
<azonenberg>
So m_outdata is what dies?
<azonenberg>
hMMM
<azonenberg>
bvernoux: Do you still have the gdb session active?
<azonenberg>
are there any other threads running?
<azonenberg>
I have a guess as to what might be going on
<bvernoux>
no i have closed it
<Degi>
uhh yes
<bvernoux>
azonenberg, ok let's go back to the crash
<bvernoux>
I was starting Rigol
<Degi>
I kinda have a bunch to do in the next weeks but ill see if I can take a look at 381... Its kinda frustrating since the scope occasionally crashes...
<azonenberg>
Degi: it's currently a release blocker for v0.1 so please do look at it if time permits
<azonenberg>
If not, i'll have to find somebody else with a rigol and time to work on it
<azonenberg>
it's not like the last ticket we're waiting on or anything
<Degi>
Okay
<Degi>
Maybe in a few hours I can take a look
<azonenberg>
but i'm trying to go through the list of blockers for v0.1 and make sure we have a plan to get each one done
<bvernoux>
I confirm on Rigol MSO5k
<bvernoux>
the X scale is wrong
<azonenberg>
Screenshot?
<bvernoux>
from 0 fs to 25ns
<azonenberg>
What's the correct time scale for that test?
<azonenberg>
and is Y correct?
<bvernoux>
0 to 4.02ms
<Degi>
Hmm, vertical scale is wrong too? Did Rihol change their drivers?
<bvernoux>
Y seems correct
<bvernoux>
I have 0 to 380mV on the screen
<Degi>
Hmh yes, I should test for non-default X scales too...
<bvernoux>
-380mV to + 380mV which seems correct
<bvernoux>
on glscopeclient
<azonenberg>
bvernoux: -380 to +380 or 0 to 380? big difference
<Degi>
Also how do we solve the bandwidth thing... Upgraded rigol models say they're still the MSO5074... Is it an option to send a request to set BW to x on startup and see if that succeeds?
<Degi>
And do network devices need some kind of Gateway or something? I put my printer and scope into a VLAN and now they disconnect after a few mins (or take a while to connect, not sure if that was different before)
<bvernoux>
Y is broken like you see I cannot change the range ...
<bvernoux>
which shall be -200mV/+200mV
<Degi>
azonenberg, how is X scaling handled? Is it possible to call some function to set it to max range or so?
<bvernoux>
it is 10x set to 1x in fact in reality it shall corresponds to -2V/+2V
<bvernoux>
i have just done a new test
<bvernoux>
I quit glscopeclient and restart
<bvernoux>
Y axis is correct +3V/-3V now like on Rigol
<bvernoux>
but X axis is always 0 to 25ns which is wrong
<azonenberg>
degi: If it's on a different subnet yes, it needs to know the IP of your router so it can route to the other subnet
<azonenberg>
degi: just the time scale in the waveform
<azonenberg>
The driver has no control over zoom of the displayed viewport
<azonenberg>
I will probably add a zoom-to-fit function eventually
<azonenberg>
But what's important at this point is that if you feed a 1 MHz squarewave into the scope it shows up as 1 MHz in glscopeclient
<azonenberg>
as far as bandwidth goes, that's going to happen later
<azonenberg>
i'm not worrying about it for v0.1
<Degi>
Hmh, now my PC refuses to connect to my rigol (sometimes it works, I think it might have to do with rigol having 192.168.1.1 as gateway and being on subnet 192.168.2.x, maybe that is confusing its NIC)
<azonenberg>
Yeah that's wrong
<azonenberg>
the gateway needs to be in its subnet
<azonenberg>
so if it's in 192.168.2 the gateway has to be there
<Degi>
Hmh but does it need a gateway? Should I specify the managed switch as Gateway?
<azonenberg>
How are you routing between the subnets?
<Degi>
Oh now the ping works
<azonenberg>
You're going to get all kinds of problems if you just magically throw subnetting around without understanding what your network topology actually is
<Degi>
So I have Rigol and Printer on 192.168.2.x and every other device on .1.x and I have a managed switch which tags the packets from rigol and printer as VLAN 2 and my PC has a VLAN 2 configured too, so that only my PC can access them
<bvernoux>
Degi, me too it took some time to negotiate the IP very strange ....
<azonenberg>
Is the link to your PC a trunk?
<azonenberg>
or do you have two separate physical interfaces on vlan 1 and 2?
<azonenberg>
you'd need to packet sniff and see what's going on but a gateway of 192.168.1.1 is not right unless you're in 192.168.1.x
<Degi>
Yes trunk
<Degi>
Maybe I can just set the switch or the device itself as gateway
<azonenberg>
you could try setting gateway to self but that will only matter for out-of-subnet destinations
<Degi>
Anyways now it seems to work magically, I think the NIC drivers on the scope and printer handle that case badly
<azonenberg>
the bigger question i think is what IP the PC is coming from
<Degi>
Yes, I think it might be coming from 192.168.1.6 and not using the .2.x, maybe I should configure a second address on my PC
<Degi>
Or somehow manage the VLAN differently, now its configured that all .2.x addresses land on the VLAN. Maybe I can put all devices on .1.x and enter IP address for VLAN routing for each device manually... On the scope the subnet mask is /16
<azonenberg>
What i do in my setup here is i have one vlan for trusted stuff like my desktop, one for test equipment, one for untrusted stuff like my wife's chromebook
<azonenberg>
then they all go through a linux router with shorewall to configure what can talk to what
<Degi>
Argh, now the rigol stopped wanting to talk again...
<Degi>
Hmm yes that sounds like a good idea
<Degi>
Ahh, the scope wants DNS and Gateway... Now I set the address to the scope itself to see if that fixes the issue
<azonenberg>
So the downside to the way I have it is that the router is a bottleneck for performance. in particular right now I use a "router on a stick" topology
<Degi>
Hm, now the scope seems to work
<azonenberg>
It has a single 10G pipe right now which means a max of 10 Gbps aggregate traffic through the router between vlans
<Degi>
How do I change the X scale on the scope in glscopeclient?
<azonenberg>
Double click the timeline
<azonenberg>
you should see a dialog with settings for memory depth and sample rate
<azonenberg>
If you never implemented those APIs, there's your problem :p
<Degi>
Oh no, socket read failed (resource unavailable) and glscopeclient crashed
<Degi>
terminate called after throwing an instance of 'std::bad_alloc'" What options can I use to debug this?
<Degi>
Nvm the NIC of the rigol stopped working apparently
<azonenberg>
Fix your network first
<Degi>
yes
<Degi>
Hm, I configured that my PC accesses it over 192.168.2.1 IP, now it seems to be fine
<Degi>
Oh no
<Degi>
Weird, somehow networkmanager didn't configure the vlan in the first place. I wonder if my PC is actually at fault.
<azonenberg>
>networkmanager
<azonenberg>
well there's your problem
<azonenberg>
:p
<azonenberg>
i have yet to see it do the right thing in any nontrivial network setup
<Degi>
I wonder if something is initialized in the wrong order or so, after reloading it works fine
<Degi>
bvernoux: Scrolling the Y axis works fine for me, its just extremely slow. Maybe the write command should refresh the cache
<Degi>
Horrendously slow. Will fix, its slower than a few acquisitions I think
<Degi>
Hm, I wonder if subscaling should be done on scopehal side, the rigol seems to do weird stuff / doesnt actually scale the ADC but in software and just scales ADC to 5/2/1 steps
<Degi>
But for now it "works"
<Degi>
Ugh, when I change the sample rate the rigol rescales the sample depth and the rate stays the same
<Degi>
And then it crashes because of "Warning: Socket read failed (errno=11, Resource temporarily unavailable)
<Degi>
zsh: abort (core dumped) ./glscopeclient" though pingd still works fine
<Degi>
double free or corruption (out)
Tost has quit [Ping timeout: 240 seconds]
<bvernoux>
Degi, I suspect the read timeout comes from the fact of data frame bugs which sometime does not returns any data
<bvernoux>
I can reproduce that sometimes especially on > 1MS
<Degi>
Ooh good to know
<Degi>
Yes it happened when I increased sample rate then Rigol set to 4 MS and after a few frames it crashed
<bvernoux>
but it is hard to apply it on glscopeclient as we do not have direct access to socket with recv() to read as much as possible without waiting timeout (it returns nb data)
<bvernoux>
Degi, I have provided that code to Rigol guys to fix the ultra slow SCPI and fix bugs which they have reproduced with this tool
<bvernoux>
Degi, a workaround is to display FFT on Rigol side that help to synchronize stuff (SCPI+screen/data) and avoid that error ;)
<bvernoux>
anyway >1MS is unusable with SCPI as it is so slow ....
<Degi>
Hm, just enabling FFT fixes it?
<azonenberg>
meanwhile pico will do 10+ wfm/s at 1MS lol
<bvernoux>
yes it is crazy but for me it totally fixed it
<Degi>
lmao
<bvernoux>
and that does not slow it more ;)
<bvernoux>
anyway it is never more than 2WFM/s ...
<bvernoux>
we gain so small speed as it avoid a retry in fact even with my c code and it avoid crash as it is desynchronized with glscopeclient
<bvernoux>
azonenberg, I really doubt we would be close to 10 wfm/s at 1MS with MSO5k even with future FW update but if they can improve robustness and speed it will be a win-win ;)
<bvernoux>
and as user/customers we can push them to improve things too
<bvernoux>
I see Siglent are also as slow as Rigol MSO5k and anyway they are limited to 100Mb Eth or USB 2.0 HS (probably limited to 100Mb ...)
<azonenberg>
Yeah. I'm not sure if siglent has gig-e on any higher end models
* azonenberg
checks specs
<bvernoux>
yes with gig-e it will definitely help to reach decent speed in streaming
<azonenberg>
yeah i cant find the ethernet speed easily published
<bvernoux>
which is clearly a dead end with 100mb ETH
<bvernoux>
SFP+ interface => 1 on the rear panel, 10 Gbps
<bvernoux>
It is strange as their MSO8000 have a very old FW (even older than MSO5K) => 2020/02/25
<bvernoux>
Without any update
<bvernoux>
I doubt they have sold lot of MSO8000 ...
<azonenberg>
I may have to start making friends with rigol apps engineers. They were next on my list of vendors to try and get a good relationship with
<azonenberg>
bvernoux: BTW what is the status of your contacts w/ rigol right now? just going through normal support channels or what?
<bvernoux>
azonenberg, I will contact them on monday
<bvernoux>
azonenberg, I have 2 contact one from Rigol Europe and one directly from R&D now
<azonenberg>
Ok great, I'm working on trying to get some contacts with the USA team as well
<bvernoux>
azonenberg, yes will be great last time I contacted them they never replied but maybe you will be more lucky
<azonenberg>
bvernoux: But it's performing well for you using the picoscope?
<azonenberg>
Did my recent shader tweaks provide a noticeable boost?
<azonenberg>
i forget if it was you or mubes i was talking to about them the other day
<bvernoux>
yes
<bvernoux>
I was checking theoretical max speed
<bvernoux>
my Pico3000 support 125MS/s continuous realtime stream mode over USB3.0
<azonenberg>
Rendering wise, I can get quite a few FPS - fairly smooth scrolling - on my 2080 Ti with 128M points on screen at once
<bvernoux>
ha nice
<azonenberg>
And I have pushed 151 Msps over USB3 from my 6824E
<bvernoux>
if you zoom in does it speedup ?
<azonenberg>
that's 2.42 Gbps of waveform data
<azonenberg>
yes. That's with the entire 128M points on screen
<azonenberg>
my profiling shows about 53 ms for the actual shader
<bvernoux>
interesting so you have same effect as me with my old GFX card
<azonenberg>
It's a fundamental issue of the way the renderer works
<bvernoux>
anyway now it is very less visible
<azonenberg>
More stuff on screen = more work to do
<azonenberg>
Shader run time is always going to be O(n) in the number of onscreen samples
<bvernoux>
what is more annoying is the speed of context menu
<azonenberg>
I've just greatly shrunk the constant factor
<bvernoux>
it is quite slow on my computer
<azonenberg>
The context menu should not be hitting the scope every time
<azonenberg>
it should only do it the first right click after you connect
<azonenberg>
If it's hitting the scope every time something is missing a cache, try logging scpi traffic to see
<bvernoux>
I have seen some improvements also on my Rigol MSO5K even at 1 or 2WFM/s the menu is a bit better than before it seems you have decoupled things
<azonenberg>
And if it's slow despite not hitting the scope maybe you have something waiting on a mutex it shouldn't be holding that long
<azonenberg>
Try running under a profiler to find bottlenecks
<azonenberg>
I make heavy use of intel vtune for tuning the general UI, protocol decodes, and the lecroy/pico drivers
<bvernoux>
yes it will be interesting to check
<azonenberg>
and nvidia nsight
<bvernoux>
I could check USB 3.0 speed bottlneck
<bvernoux>
just to check the delay between packet over USB3.0 with USB3.0 analyzer
<azonenberg>
I dont think i've maxed out USB3 yet. But i've made a lot of optimizations in general over the past few weeks
<bvernoux>
as the framerate is not smooth it jump +/-7WFMs
<azonenberg>
between that and switching all of the drivers i can, pico included, to AVX accelerated sample processing
<azonenberg>
That might be host side
<bvernoux>
yes it could be clearly a limitation of my PC ;)
<azonenberg>
When in doubt, profile
<noopwafel>
what do you get, bvernoux?
<azonenberg>
I suspect there's more i can optimize on the PCIe/cache side of things in rendering (not mapping buffers I don't need, it probably triggers expensive TLB operations
<azonenberg>
and then the Cairo rendering code can probably be tweaked too
<bvernoux>
noopwafel, on Pico3000 ?
<noopwafel>
the bridge currently doesn't re-arm the scope immediately so you can't saturate the pico
<noopwafel>
but you should get reasonably close
<azonenberg>
e.g. right now i regenerate those textures every frame even if they havent changed
<bvernoux>
noopwafel, he's working on adding MSO stuff ...
<azonenberg>
Yeah I'm going to try to find time this weekend to implement the MSO stuff
<bvernoux>
noopwafel, if you wait too much the repo will be hard to merge ...
<azonenberg>
And i want to get both that and the 3000 series initial support merged in time for xzcvczx to get his 5000D series
<azonenberg>
Because once he starts working on that i expect we'll be getting another pile of patches coming in
<bvernoux>
yes it is great
<bvernoux>
with refactor on the common driver
<bvernoux>
with some sort of abstract API for common Pico call maybe ?
<azonenberg>
What i want is lecroy's frontend and ADC bolted onto pico's streaming infrastructure
<azonenberg>
That would be my dream scope
<azonenberg>
But as far as i can tell it doesnt exist
<bvernoux>
azonenberg, maybe that can push big actors to think about it ;)
<bvernoux>
as so far there was nothing usable in remote
<noopwafel>
I would liek to look at it tomorrow, but it won't hapen today
<bvernoux>
azonenberg, maybe tek as one of the most advanced remote UI for scope with their new Tek 6B MSO but like you said the Ethernet have some bugs ...
<bvernoux>
noopwafel, ok great do you plan to do lot of modifications ?
<noopwafel>
well, I can just PR it as-is :P
<bvernoux>
yes i think too
<noopwafel>
it's not nice but that can be tidied after
<bvernoux>
it is clearly already a very good beta version
<noopwafel>
let me do this to at least get it rolling
<bvernoux>
thanks to your work and azonenberg work it is first time I can use glscopeclient correctly ;)
<_whitenotifier-1>
[scopehal-pico-bridge] noopwafel opened pull request #11: add 3000-series support - https://git.io/Jsszd
<noopwafel>
but now I have to run again :p sorry!
<bvernoux>
great PR !!
<azonenberg>
Great I'll review the PR this evening
<azonenberg>
bvernoux: also speaking of the Tek MSO6 I just got off the phone with Alan Wolke, east coast US FAE for Tek
<bvernoux>
ha great and what are the news ?
<azonenberg>
He's gonna be putting me in touch with somebody from the west coast to discuss in more detail but apparently they're still working on that new firmware they hinted about before but it's hopefully coming out in june
<bvernoux>
(because I clearly plan to buy one of those MSO64B ;)
<azonenberg>
Some time in the near future they're going to try and get me a loaner to test on and see how performance has improved
<bvernoux>
ha great news
<bvernoux>
I hope they will provide latest version MSO64B or MSO68B
<azonenberg>
We'll see
<bvernoux>
the MSO68B is interesting only in case to use lot of MSO with it else that will sacrifice too much Analog chan ;)
<bvernoux>
As I have never seen use case which required 8 analog chan at time ;)
<bvernoux>
but more is always better ;)
<azonenberg>
Indeed, lol
<bvernoux>
hmm there is still room for improvements on MSO6
<bvernoux>
I like the Known Issues at least they are transparent
<bvernoux>
I love that one => - Memory leak can cause scope to stop acquiring data after 1.5M acquisitions
<bvernoux>
oups ;)
<bvernoux>
workaround reboot the scope after 1.5millions acq ;)
<azonenberg>
This is for a new firmware coming
<azonenberg>
which presumably fixes that among other issues
<bvernoux>
yes
<bvernoux>
this release not was for Firmware from Jan 2021
<bvernoux>
so they have probably fixed those issues and maybe also ethernet "slowness" things you have found before but they are not in the Known issues...
<bvernoux>
What is nice is the same firmware is for lot of different scopes => MSO44, MSO46, MSO54, MSO56, MSO58, MSO58LP, LPD64, MSO64, MSO64B, MSO66B and MSO68B
<bvernoux>
all serie4, 5 & 6 have the same FW woo
<bvernoux>
I love the "This software may contain one or more programs licensed under the GPL or LGPL."
<bvernoux>
if it contains GPL so all shall be open sourced ;)
<bvernoux>
like on Rigol scope ...
<azonenberg>
only the GPL binaries
<azonenberg>
so the linux kernel and such are GPL but not their userland apps
<bvernoux>
yes
<bvernoux>
but in theory they shall provide blob and source linked to GPL in order we rebuild the full FW ;)
juli9611 has joined #scopehal
bvernoux has quit [Quit: Leaving]
<_whitenotifier-1>
[scopehal] mubes opened pull request #479: Fix digital levels and waveform offset - https://git.io/JsGYY
<_whitenotifier-1>
[scopehal-apps] mubes opened issue #349: Vertical cursor over extends past right hand end of waveform display window - https://git.io/JsGOj