True. But what if there are more people competent to set up & maintain secure tunnels through the internet than there are people competent to set up & maintain dedicated fiber links?
But what if the actual bottleneck isn't the size of the various cohorts of people, but a bureaucracy that inflicts some irrational set of conditions that impedes competent operation? If so, then changing media won't help; whatever scheme you envision will fail.
I'm rather certain the FAA does indeed either employ or contract people that are capable of providing the solution. I'm also quite certain those people live in a perpetual blizzard of responsibility diffusion bullshit: the FAA is a venerable and highly risk-adverse operation. If someone told me it takes months of meetings and sign-offs to so much as log into a router and perform a benign check of some setting, I wouldn't blink.
Yes, but low-functioning bureaucracies are also the most prone to outsourcing. They can't manage to get anything done internally, so they hire outside orgs (hopefully higher functioning) to perform necessary basic services. Often late in the game, when (figuratively) a VIP visit could reveal that their bureaucracy is too broken to keep its office bathrooms clean.
In this case, that outsourcing could easily look like "call local ISP's, get connections, set up tunnel".
GE9X aircraft engines have 3D printed low pressure turbine blades, so I think the view that jets are somehow exceptional is already disproven. There are real benefits to using additive processes for turbojet/fan applications: many jet components have intricate passages and bizarre shapes to conduct gasses, and they are hideously expensive to manufacture with conventional tools.
Yes, that's the usual way. With SpaceX, however, Raptor engines are gimbled with electric actuators.
And yes, the TVC adds very little to the complexity of Raptor 3's appearance: it still looks like science fiction, even when operating in Starship. Had TVC been present in the original SP1 image that had Tory accusing SpaceX of misleading everyone, it would have made no difference.
> TLDW
That video has beautiful shots of Raptor 3 firing and gimbling. It's worth watching.
MCUs are getting crazy. ESP32-S31 running Linux. 40MSPS/12b ADC+DSP on dsPIC33A. New Renesas parts running a 1GHz. RP2350 roflstomping things with PIO. The Cortex M7 in this story is actually pretty old now: circa 2019.
It depends. This product is pretty niche, and when a ~$3 MCU gives you the headroom you need without a team of career engineers on the payroll, it can make sense. Also, it's running USB power as opposed to batteries.
The distinction of first (known) deployments of orbital kinetic weapons belongs to the Soviet Union. In 1968, they tested an anti-satellite system by intercepting a target satellite with a interceptor satellite and detonating it (Kosmos-249/Kosmos-252).
Later, in the 1970's, the Soviets deployed and test fired Rikhter R-23 23mm revolver cannons from Salyut military space stations.
> except the high priests of the LLMs / nascent Cthulhoid godlings
Let's not be this flippant about where the real pressure for this is coming from. Presidents and their appointees come and go. The people pushing the regulators[1] are not subject to US election cycles. It's important to know who they are when we aim our finely honed fingers, even if we find that these folks were formerly virtuous and mighty green energy advocates, because if your solution is merely different figureheads, all that will really change is the scale of the bribes.
>Presidents and their appointees come and go. The people pushing the regulators[1] are not subject to US election cycles.
While true, it’s also true that presidents and their appointees can vary wildly in their susceptibility to those “people pushing”. Both sides might be bad, but one’s very obviously worse.
> except the high priests of the LLMs / nascent Cthulhu-oid godlings...
I did not say that, but is so obvious, like looking through a plate glass window. There is no pressure, its just a natural transition to the end of bipedal life.
mmap(2) in Unix predates Linux itself by several years (1988 Sun, 1990 BSD). mmap(2) was present in Linux well before any of the high performance databases, file systems and other applications that use(d) O_DIRECT appeared on Linux.
O_DIRECT was resisted by Torvalds and others, but it's there today, and used by supposedly important platforms. Nvidia even has an API to DMA data to and from GPUs that uses O_DIRECT. There are folks working on new async WAL O_DIRECT for PostgreSQL as well.
So what can be said? mmap(2) isn't sufficient for certain cases. Torvalds has faced and successfully navigated difficult design choices in a pragmatic manner. What else?
The lesson I take is this: there are levels to implementation complexity and value. The wisdom to decide the appropriate abstraction level is crucial. You are unlikely to be equipped well enough to beneficially utilize O_DIRECT, but it's not impossible and some, in fact, are so equipped.
SpaceX has >11,000 satellites whipping around the planet. They increased the number of LEO sats by nearly one order of magnitude in bit more than 5 years.
So apparently, in the US, the culture, expertise and infrastructure do exist to do these things.
> The best case latency is higher than doing the work at interrupt level
One approach is to do everything in ISRs, a la RTIC. That requires efficient, vectored, nested, tail-chained, base priority-ed interrupt silicon, and a lot of it, but it is feasible and elegant where this exists, such as Cortex NVIC. Emerging RISC-V devices with xCLIC (ch32v, gd32v, newer ESP32 and others) are potentially even better.
I really appreciate that the author took the time to add the Embassy vs RTIC addendum.
FWIW, just having a mask in the interrupt controller is normally enough to give you the same thing at the cost of a dozen or so cycles in the critical path. Basically you just keep a mask per priority that can be built up cheaply at init time (or even compile time if you're cute about it), you apply the appropriate mask in the interrupt prologues and epilogues, and pretty much as soon as you apply the new mask in the prologue you go ahead and acknowledge the interrupt.
You can do this on x86 as well at a cost a merely tens to hundreds (possibly lots of hundreds) of thousands of cycles. This is part of why x86 is so popular in the embedded space.
(I’m being sarcastic, obviously. x86 interrupts and interrupt returns are hilariously slow. FRED may improve this by quite a bit.)
Mostly tons of speculative state that needs to be unwound, combined with spectre mitigations, plus tons of committed state that the interrupt prologue needs to save, plus a huge song and dance to do that correctly (that FRED should help with).
All combined with the fact that there's a good chance the memory the interrupt handler is going to touch isn't in the cached working set anymore, both in the actual L* caches and in subtler places like the branch predictors and TLBs.
You’re missing the big ones: both the interrupt delivery and the IRET (interrupt return) mechanisms use incredibly complicated data structures to determine what the new state should be. They need to dig around in the IDT, the GDT, the TSS and possibly the LDT to find all the register values they need to set, and they need to handle all kinds of backwards compatibility. And they “serialize”, which is an extra heavyweight fence, although that only likely accounts for a few hundred cycles in each direction.
Check out the pseudocode in the SDM — there are pages of it, and the pseudocode isn’t even complete.
FRED simplifies the state transitions such that the new state is mostly a foregone conclusion based on MSR contents.
A 1GHz superscalar Cortex-M7 can still hit a 12 cycle interrupt latency if the system stack is kept in the 2x32 bit wide zero cycle dTCM, and the VTOR and handler are in the iTCM thanks to lots of bandwidth and a reasonably short pipeline. The NVIC is truly the underappreciated superpower of the Cortex-M family. You can implement a full RTOS or complex bare metal application without ever having to disable interrupts. On other MCU architectures (most RISC-V, PIC32, even older crap refusing to die) you'll easily end up with closer to 100 then 10 cycles of jitter from critical sections having to run with disabled interrupts e.g. context switching code.
That’s fair. I’m not saying x86 is a pig for interrupt latency. But M still isn’t a fair comparison. X86 runs general purpose OSes which like to do things like load balance interrupts (not that I’m convinced this is actually a good design) which NVIC doesn’t have a full solution to especially for multicore (A series also uses a GIC).
The other problem is that A series and x86 runs out of DRAM typically whereas M is generally set up to run its ISRs out of SRAM so it can actually realistically hit its low latencies. But even though A also has significantly better nominal interrupt latency (competitive with M actually), in practice it’s similar to x86 because DRAM dominates anyway. Also of course best case latencies are when you don’t use the FPU which is more common on M series than it would be on A or x86 (and x86 also has generally more SIMD stuff to handle)
The gap is a low narrower than those exaggerated numbers. Cortex-M goes to 1 GHz and beyond with MIMXRT117x, while loads of x86 chips down-clocked to the couple GHz or are capped lower, like laptop CPUs
I am aware. That "dozen or so" is a problem: when everything is an interrupt, there are no interrupts: it's just scheduling, and things that must be scheduled frequently can't suffer "a dozen or so" overhead. For the SRP model to really hum, you need the silicon that solves this.
I've found that it doesn't matter except for something that you want at the absolute highest priority anyway, which then by definition doesn't need to jump through the same hoops because nothing can preempt it anyway.
It's more about frequency than priority. When something has to be serviced tens of thousands of times a second, "a dozen or so" becomes a problem. If you have the silicon that solves this, you can retain the model. If you don't then you have to resort to workarounds.
Fortunately we typically have more efficient means to deal with such hardware, but not always, and it would be a shame to break the intended model when this is the case.
Whatever OS/applications you have run in low priority ISR contexts, taking however much time they wish. When a high priority interrupt happens, the lower priority ISR contexts are preempted and then resumed after the high priority ISR is complete. Go have a look at the design and the SRP model behind it; your questions are directly addressed there.
> One approach is to do everything in ISRs, a la RTIC.
That only works for really simple systems. On more complex systems there is a pretty good chance you will end up with locked up hardware if your ISR is long enough. Interrupts need servicing to keep the data flowing, prioritization is a job for the OS, not the hardware.
> On more complex systems there is a pretty good chance you will end up with locked up hardware if your ISR is long enough.
That is true of all such systems, from MCUs to the greatest CPUs ever made, and all prevailing software stacks running on them. Nothing about RTIC precludes servicing interrupts in a timely manner. It is based on a mathematical model of concurrency called Stack Resource Policy (SRP) and is entirely capable of reliably implementing whatever interrupt regime you imagine your "complex" system requires, with zero risk of priority inversion.
> prioritization is a job for the OS, not the hardware
So say you. The long and storied history of fragility and failure related to scheduling and interrupt handling suggests there is opportunity for greater rigor than the conventional muddle you assert as best.
The model works pretty well up to much larger systems than you'd expect.
If a particular interrupt has a hard real time constraint, it sounds like a great candidate for a higher priority interrupt which will let it meet that requirement.
The biggest constraint is that this is really a single core model. You need something different if you go to SMP. Though there, AMP where the main core runs this 'interrrupt controller is your scheduler' scheme, and the other cores run against a work stealing scheduler for compute bound work items still is a very nice system to program against.
The ARM v7M architecture helps a lot here because the NVIC supports priority inheritance without disabling interrupts. Yes you have to assign your priorities correctly and yield CPU time for anything compute bound, but again the architecture helps you in the form of the SVCall+PendSV exception pair. The PendSV handler can easily be multiplexed on the Cortex-M3/M4 using atomic operations on bit-banded memory. I've needed only a few dozen lines of Forth to set this up on bare metal without an RTOS to split peripheral drivers in a short interrupt handler saving the required state and delegating protocol handling to a lower priority callback.
reply