<joshua_>
hm, we could add the OscilloscopeChannel API, also, GetDownloadStartTime, so the UI could choose to display it only if it has been 100ms
<joshua_>
I have a "slow SCPI simulation mode" on my desk, all you have to do is power on the DHO4000
<d1b2>
<chille0417> I would suggest trying a bit more. I think the average human reaction time is something like 270 ms.
<joshua_>
mostly I think it is just to keep flicker down for "immediate" things
<joshua_>
it can be messed with
<d1b2>
<azonenberg> So the idea here isn't that it pops up every download after 100ms
<d1b2>
<azonenberg> it'd be a sticky flag
<d1b2>
<azonenberg> as soon as a download takes 100ms it stays on
<d1b2>
<azonenberg> either for the duration of the session or maybe until you change memory depth
<d1b2>
<azonenberg> but yes. the idea is to not have fast scopes / shallow memory be flashing at you when the scope is running at tens of WFM/s
<d1b2>
<azonenberg> We can play with the exact thresholds and algorithms for when to show the progress
<joshua_>
yeah I trust whoever plays with this to get a good result
<d1b2>
<azonenberg> Yeah i'll have a look hopefully tomorrow. I have a bunch of unmerged code on two different computers that i'm still working on related to handling of memory pressure and bad font paths (among other things)
<d1b2>
<azonenberg> I was planning to be working on the "recover better from OOM" code all night
<d1b2>
<azonenberg> Ended up spending most of the evening hauling somebody ouf of the woods instead lol
<joshua_>
only processes die from OOM, people die of exposure, and the latter is much more important
<d1b2>
<azonenberg> Yep
<d1b2>
<azonenberg> It was a warm night, happy ending all around
<d1b2>
<azonenberg> (in case i havent mentioned before I volunteer with the local SAR team)
<joshua_>
are you SAR-related? if so, do you want... a free idea? I want someone to commercialize this and sell it. I want someone to put, on a light weight drone, four quadrant directional antennas aimed down, each with the biggest LNA you can meaningfully put on it, each one connected to three BLE demodulators listening to each of the advertisiing frequencies, and if you hear a preamble (who cares about decrypting the packet), yell
<d1b2>
<azonenberg> So every so often i end up going hiking with zero notice in new and exciting places like swamps and blackberry thickets :p
<d1b2>
<azonenberg> Interesting idea and i actually saw some work doing similar with LTE (you could even target a specific IMEI)
<joshua_>
or on a heavy weight drone for that matter. automatically gridding a high-angle region to pick up fitbits, airtags, iPhones that are in battery-save mode, Garmins, etc
<joshua_>
yeah, though LTE means that the UE's battery still has to be very alive and it has to not be in airplane mode
<d1b2>
<azonenberg> The big problem in these parts is the tall trees. Drones are difficult to use below the tree canopy because of the constant collision hazards
<d1b2>
<azonenberg> and above treetop height you're so high up it's difficult to fly from the ground (FPV might help to some extent) but you also need really good optics to see anything on the ground through the gaps in the tree cover
<d1b2>
<azonenberg> A few other agencies have drones but i dont think we've ever had a successful drone find on any call i've run
<joshua_>
yeah, the idea in this case is that you can get deep into the noise by just listening for a preamble, and so, ok, you lose a lot of link margin to the tall trees, but you get a lot back by having good directional gain and coding gain and a good LNA
<d1b2>
<azonenberg> Manned aircraft are a different story - coast guard, navy, and several local sheriffs depts have helos with full 1080p FLIR pods with crazy zoom lenses that probably cost as much as my house
<d1b2>
<azonenberg> (just the lens)
<d1b2>
<azonenberg> They find people for us fairly often. Some of those folks do have various radio receive capabilities, i dont know about LTE or BT specifically
<joshua_>
and that you do not even need to 'see' anything on the ground optically, at least for high sierra rescue on high angle terrain then I am told that even knowing roughly where the victim is would save a lot of time searching
<d1b2>
<azonenberg> Yeah, around here getting to them can be half the battle
<d1b2>
<azonenberg> We had voice contact with our guy today like 30 seconds after leaving the road
<d1b2>
<azonenberg> still took a while to make our way through the brush :p
<joshua_>
there is RECCO also but hilariously you're not allowed to use it other than at a ski resort
<joshua_>
(900MHz frequency doubling passive reflector)
<d1b2>
<azonenberg> Anyway, back to on topic... I have a "memory leaker" dialog in my local copy that lets you leak a configurable amount of memory
<d1b2>
<azonenberg> well ok, not leak per se... it allocates an AcceleratorBuffer and holds onto it, then frees when you close the dialog
<d1b2>
<azonenberg> But it lets you create a desired level of memory pressure
<d1b2>
<azonenberg> We have two levels of memory pressure: "soft" (at start of frame, VK_EXT_memory_budget reported less than X free memory, for configurable X - not yet implemented but in the API, and requires that extension on your Vulkan implementation)
<d1b2>
<azonenberg> and "hard" which means an allocation has failed
<d1b2>
<azonenberg> (this is what currently triggers an abort with an unhandled exception in mainline scopehal)
<d1b2>
<azonenberg> and you can get both of these failure conditions with both host and device memory
<d1b2>
<azonenberg> In my WIP, whenever memory pressure is detected (so far only hard pressure on a failed GPU allocation) it calls the global OnMemoryPressure() function which iterates over a list of callbacks registered by various subsystems, taking arguments for the type of memory (host or device), the level of pressure (soft or hard), and in the case of hard pressure, the size of the failing allocation
<d1b2>
<azonenberg> And i'm now working on the code that actually responds to memory pressure by trying to free stuff
<d1b2>
<azonenberg> Long term, if attempts to free space fail, device memory allocations should fall back to pinned host local / device readable memory
<d1b2>
<azonenberg> That's a ways down the list but on the roadmap
<_whitenotifier>
[scopehal-apps] azonenberg f3a9e6f - Intial work on memory pressure handling. So far just a skeleton, doesn't actually free memory when pressure is detected
<d1b2>
<azonenberg> But this should be a good improvement to stability once i get it done since i suspect a lot of our "crashes" are actually just OOMs
<d1b2>
<fredzo_72653> I'm in charge of the local HAM radio SAR team myself (hence the question about decoding COSPAS/SARSAT beacon frame earlier ;-)) ! We're not engaged that often luckily, it's not everyday that an aircraft crashes nearby, event though I'm near the Pyrénées mountains 😂
<d1b2>
<azonenberg> Yeah we've never run a plane crash, mountain rescue i think has done a handful. A sizeable fraction of our local calls (vs mutual aid to other jurisdictions which tend to be more hikers/backpackers) are old folks who went for a walk and forgot where they lived
<d1b2>
<azonenberg> So we get the call whe nthey don't find their way home
<d1b2>
<fredzo_72653> We do embed SARSAT beacon receivers into drones to help detecting signals when the beacon is at the bottom of a deep valley
<d1b2>
<azonenberg> yeah what i've seen is that the utility of drones is extremely terrain dependent
<d1b2>
<azonenberg> in avalanche conditions when you want to be able to scout unstable snow without putting teams in danger, and you have a clear line of sight to ground level everywhere, they excel
<d1b2>
<azonenberg> heavy tree cover, less so
<d1b2>
<azonenberg> Anyway it's 1 in the morning so i should get some sleep. I'll try and find time to look at some of the pending PRs and finish the eye mask unit test tomorrow