Security and open source at the hardware/software interface. Embedded sec @ IOActive. Lead dev of ngscopeclient/libscopehal. GHz probe designer. Open source networking hardware. "So others may live"
Toots searchable on tootfinder.
| ngscopeclient | https://www.ngscopeclient.org/ |
| Blog | https://serd.es |
| Location | Seattle area |
| GitHub | https://github.com/azonenberg |
Still as cis as ever, but I thought I'd show my support by posting an interesting transition metal compound from my lab inventory.
Here's a solution of tantalum chloride in ethanol/methanol, intended for sol-gel deposition of tantalum pentoxide thin films. You spin coat it on a substrate then heat in air; the chlorine swaps with an oxygen in atmospheric water vapor and you get HCl gas evaporating and Ta2O5 on the surface.
Looking at a pollen sample from outside (just a piece of double sided tape pressed against the roof of the car to see what had stuck).
This isn't necessarily a representative sample of what's in the air, I could do a more scientific test by leaving a piece of tape out for a while to see what settles out, but I just wanted something to show my daughter what pollen looked like.
Can anybody ID any of these? We have alder, willow, maple, poplar, and various evergreens in close proximity among others.
Most of the published pollen images I see are made with biological (transmitted light) microscopy or SEM and this is semi-darkfield metallurgical reflected/scattered light (some epi-illumination combined with low angle lighting to show off the surface particles rather than the tape surface) so they look a lot different than reference images I can find online.
SEM would definitely be better, you can really see the limited DOF here.
Sorry for no scale bar, having software issues. These images are all 238 nm/pixel so the big greenish spherical thingies are roughly 70 um in diameter.
Sadly couldn't join myself (wife wasn't feeling good and wanted me to stay home and help parent while she napped) but my SAR team participated in a great inter-agency training this past weekend.
It's always nice to practice alongside volunteers from other teams that we work with on real incidents and get to know each other without the pressure of a real emergency.
One note: I half feel like there should be a CW on this post for mentioning law enforcement in a positive light lol. But the sheriff is responsible, per state law, for all missing persons in their jurisdiction so any search-and-rescue mission must have them involved at some level.
SAR duty is an extra responsibility that deputies can sign up for and while it may not apply to the rest of the department I have nothing but good things to say about someone who takes time out of their day "so others may live" regardless of what uniform they may wear while doing so. The kind of person who would rather be saving lives - sometimes homeless or undocumented immigrants - instead of arresting people is the exact kind of person we *want* wearing a badge.
Original post from FB:
"What a beautiful day for our final training of the year! We had a great time during today's countywide mock search hosted by the Kitsap County Sheriff's Office and also attended by Olympic Mountain Rescue and Kitsap County Search Dogs. We're super fortunate here in Kitsap County to not only have SAR units who work well together but also to have a Sheriff's Office that is so supportive of the work we do. And with that, that's another great training session in the bag!!"
And it only took an hour or so to get working. Need to test more and make sure I'm not thrashing on live streaming input (I haven't unpacked the ThunderScope after coming home from HARRIS yet) but 4.9 -> 3.4 GB of total VRAM usage from optimizing one filter block is a pretty decent shrinkage.
Scratch pool usage went from just over 1GB to 613 MB.
Updated the color coding to not highlight overhead on scratch buffers, since these get shared by multiple shaders and so the amount of overhead in the most recently executed shader does not necessarily mean space is being wasted.
The biggest offender by *far* in this demo is the CDR PLL. Between the recovered clock and sampled data sparse outputs we have north of a gigabyte of wasted VRAM (allocation larger than the actual used space).
So that's going to be the next target for optimization.
As part of the ongoing effort to reduce VRAM bloat in ngscopeclient I've added some nice debug tools (currently accessible by Window | Memory Analysis but that will probably get moved to the debug menu at some point) to show you the full list of AcceleratorBuffer objects along with a bunch of metadata.
Haven't figured out how to right align the column titles but this is a debug visualization so not a huge priority.
Rows with more than 10% overhead (capacity > 1.1*size) are color coded yellow, and more than 100% red. This lets you quickly zero in on buffers that are much larger than the data they're holding.
You can see the CDR PLL buffers have huge overhead, with ~40 MB of used data in a 305 MB allocation. One of the scratch buffers is 305 MB and only using 160 kB.
This is an unfortunate necessity of parallel filters, you have to allocate a buffer big enough for the largest possible output since you don't know the actual number of packets/clock edges until the shader runs.
One thing I'm considering for the worst offenders is to switch to an iterative algorithm: allocate say 1/16 of the theoretical maximum output size to start, and have the shader return an error if the buffer is too small. Then iteratively double the output buffer allocation until there's enough space.
This will result in an extra O(log N) allocations and shader executions the first time the shader runs but assuming the data is pretty consistent, should be O(1) after startup and save a lot of VRAM.
