(no subject)
I've been annoyed at work, as usual. Right now it's because in the last ten days, I've had four separate "this is your highest priority: drop everything else including your last priority and focus on this and get me a presentation of your findings in two days" discussions with my manager, and none of the presentations has actually happened because of the next crisis. I've been spending a ton of time doing research and analysis to produce a big pile of well-ordered bits that are going to sit on a hard drive unused forever.
However, crisis #4 was interesting. There is an area of operation for our integrated circuit where it realizes it's about to get itself in trouble, so it reacts appropriately to avoid that happening. In doing so, it adjusts the frequency it operates, and because of some internal details, what it does is start clocking itself with two closely spaced pulses, then a pause out to what would have been its normal next pulse, then another two. It goes from tick tock tick tock to lubdub-lubdub-lubdub.
For some reason this totally freaks out one of the companies working with the chip. We've tried explaining this is expected functionality and they are having none of it.
Well, as it so happens, I'd run across this quite a while ago and thought it was weird, so I wrote some stuff to characterize it. Likewise, my coworker who handles system designs based on the chip thought it was weird, so he did a bit of work, and we talked about it and came up with some other things to check.
This directly contradicted my manager's instructions on what I was supposed to be doing, so I added it as an extension on some other testing, because I figured getting double the information for only about 10% more time spent could be worthwhile.
It was. When this issue reared its ugly head, my manager was all "do you have any information or data on this at all?" and I'm all "about 20 megabytes" and five minutes later had graphs and circles and arrows and all sorts of groovy stuff. So that was nice, and for once, actually got some attention.
Now I'm back to rerunning some of the test over a large area. I'm characterizing operation over a five-dimensional space, which is going to be fun to try to visualize.
The fun part of this was I got to load in a bunch of experimental software, piggybacked on the side of the (itself originally piggybacked) software I already had.
To geek out a bit: I've written something that assigns one execution thread to each interface, and on one, to each slow instrument running on that interface, so they're all operating in parallel, which massively reduces the test time, and massively increases the operation space I can reasonably expect to characterize. I have a primitive thread handler running, that figures out the thread execution speed and uses that to organize how the logfile is written, so that it starts writing the logfile before all the data is in but still manages to guarantee the order in which it is written. (This used to be critical. I just found a way to run my analysis software so it is no longer critical, but that's my next sneaky experiment.)
The system texted me a little while ago to tell me it hasn't blown up yet, which is nice, since it's running overnight. My coworkers were dumbfounded when I set them up with a snippet that emailed or texted them if a disaster happened: they had no idea that was possible. (And it's particularly nice because when I say "blown up" I mean enough fire we have to hit the emergency button to shut down all the power to the lab and then abandon it until the air system has cleaned it, but not enough to set off the sprinkler system.)
That was actually fun, particularly when the thread handler correctly started allocating resources to the different threads. I had no idea if that would work.
This entry was originally posted at https://randomdreams.dreamwidth.org/63007.html. Please comment there using OpenID.
However, crisis #4 was interesting. There is an area of operation for our integrated circuit where it realizes it's about to get itself in trouble, so it reacts appropriately to avoid that happening. In doing so, it adjusts the frequency it operates, and because of some internal details, what it does is start clocking itself with two closely spaced pulses, then a pause out to what would have been its normal next pulse, then another two. It goes from tick tock tick tock to lubdub-lubdub-lubdub.
For some reason this totally freaks out one of the companies working with the chip. We've tried explaining this is expected functionality and they are having none of it.
Well, as it so happens, I'd run across this quite a while ago and thought it was weird, so I wrote some stuff to characterize it. Likewise, my coworker who handles system designs based on the chip thought it was weird, so he did a bit of work, and we talked about it and came up with some other things to check.
This directly contradicted my manager's instructions on what I was supposed to be doing, so I added it as an extension on some other testing, because I figured getting double the information for only about 10% more time spent could be worthwhile.
It was. When this issue reared its ugly head, my manager was all "do you have any information or data on this at all?" and I'm all "about 20 megabytes" and five minutes later had graphs and circles and arrows and all sorts of groovy stuff. So that was nice, and for once, actually got some attention.
Now I'm back to rerunning some of the test over a large area. I'm characterizing operation over a five-dimensional space, which is going to be fun to try to visualize.
The fun part of this was I got to load in a bunch of experimental software, piggybacked on the side of the (itself originally piggybacked) software I already had.
To geek out a bit: I've written something that assigns one execution thread to each interface, and on one, to each slow instrument running on that interface, so they're all operating in parallel, which massively reduces the test time, and massively increases the operation space I can reasonably expect to characterize. I have a primitive thread handler running, that figures out the thread execution speed and uses that to organize how the logfile is written, so that it starts writing the logfile before all the data is in but still manages to guarantee the order in which it is written. (This used to be critical. I just found a way to run my analysis software so it is no longer critical, but that's my next sneaky experiment.)
The system texted me a little while ago to tell me it hasn't blown up yet, which is nice, since it's running overnight. My coworkers were dumbfounded when I set them up with a snippet that emailed or texted them if a disaster happened: they had no idea that was possible. (And it's particularly nice because when I say "blown up" I mean enough fire we have to hit the emergency button to shut down all the power to the lab and then abandon it until the air system has cleaned it, but not enough to set off the sprinkler system.)
That was actually fun, particularly when the thread handler correctly started allocating resources to the different threads. I had no idea if that would work.
This entry was originally posted at https://randomdreams.dreamwidth.org/63007.html. Please comment there using OpenID.