As far as I know the LMAX disrupter is a kind of queue/buffer to send data from one thread/task to another.
Typically, some of the tasks run on different cores. The LMAX disruptor is designed such that there is no huge delay due to cache coherency. It is slow to sync the cache of one core to the cache of another core when both cores write to the same address in RAM. The LMAX disruptor is designed that each memory location is (mostly) written to by at most thread/core.
How is the LMAX disrupter relevant for programs with 1 core?
How do you insert into DuckDB fast and what settings ("Indices") do you use? As far as I understand DuckDB builds up statistics for each "block" of data (number of different values, ... ). So I assume inserting is slow. There is a paper [0] and a comment [1] that mentions that DuckDB is 10-500 times slower in a write-heavy workload.
Linear Temporal Logic looks very interesting to specify invariant of a system and monitor them at runtime. I guess this is called monitoring. So you can check if your system behaves as expected and e.g. issue an alert if it fails.
There is also Metric Temporal Logic, a special case of Temporal Logic. It allows statement like "There must be an account login (event) 5 minutes before an account deletion."
There is also the Signal Temporal Logic, a special case of Temporal Logic. It allows statement like "Whenever the temperatue is over 100 degrees it will be lower than 50 degrees within 10 minutes."
Unfortunately, it seems like it allows to formulate invariants that need an unbounded amount of memory if you monitor infinitely long or a huge amount of memory because the implementation essentially computes a window minimum/maximum function over a large window and has to save all the values in this window.
Do you know if there is a restricted subset of temporal logic that can be monitored fast and with a bounded or even small amount (e.g. O(f(lenght of formula)) of memory?
This sounds very cool! How does it work technically? I have checked your website but I am still not sure.
How do I "buy" the instances using usage.ai instead of AWS? Do you need additional tooling or does it work with awscli/terraform? How do you integrate with my account and how do "your instances" appear in my account and how can I sell it back?
As far as I understand, I can buy/sell reserved instances from you in a flexible way, so they can be used like on-demand instances.
it will ask you, e.g. every hour to confirm with YubiKeys and cache the key for one hour. After that the temporary keys expire. Can you also store keys different from AWS?
I'am honest, similar things could happen on my laptop for my personal stuff.
I have some AWS keys in some files that are used by terraform/packer. A hacker could easily get them.
Some other AWS keys are stored in the CI system and provided as env variables. Someone that can merge/push to the specified branches can just change the CI script an exfiltrate them.
How can I fix that?
I would need some MFA for both cases. I would imagine it would be a good idea that I have to confirm each action on MFA device, which will then generate temporary tokens that are invalid after a few minutes. I locked into some solutions like Hashicorp Vault but I was not able to build something in a short time. New features were always more important.
> Long story short if I had money that would be relevant in this context I would invest really hard into Tenstorrent.
I would happily accept a bet (e.g. $100 bucks or a nice bottle of whiskey) from you (or anyone) that atomicsemi is successful. I will just bet against it because I am skeptical that a new company is successful in a capital intensive segment.
It is probably slightly insulting, foolish, and arrogant to bet against the famous Jim Killer on a website dedicated to startups. This should not be a dig against Sam and Jim Killer. I guess that will try something truly innovative. But if I look a the past, the odds seem to be stacked against them.
Very interesting. Thanks for the link to the paper. Isn't the provided paper "just" about the scheduler? Eventually, I would have to output some data, e.g. on the CAN bus with socketcan through the network stack. This is probably a huge amount of code for which worst-case-execution-times are probably hard to get.
Does AGL mean automotive grade linux? What would be other hypervisors?
Yes you are correct. I am currently having a project, making Linux "as real-time as possible": locking memory with mlockall, isolating cores, preempt kernel patch, .... It is still not real-time because you have no guarantees, but you typically get a max jitter of 0.1 ms, which is good enough for my use case.
You could use Linux without a MMU (uClinux), e.g. on a Cortex-M, but is a horribly experience and no standard program works.
I guess it is not a typical OS, but more like a collection of tools that build on already existing OSs. This is comparable to ROS (Robotic Operating System), which are just some programs, middleware, services and conventions to build software for robots on Linux.
It seems like this should integrate and abstract different "OS" (Linux, QNX, AUTOSAR) and run on very different platforms (high power application processor for infotaiment, microcontrollers) (Slide 13). These are widely different systems:
1. Linux needs a Memory Managing Unit (MMU), which only comes with high(ish) powered application processors, e.g. Arm Cortex-A9. These are obviously not hard-realtime because a page fault can occur non-deterministically (except when you can lock everything to RAM). This might be used for infotaiment.
2. (Classic) AUTOSAR is used without a operating system on a microcontroller like the ARM Cortex-M or a automotive MCU like the Infinion TriCore, which can run two cores in lockstep to verify each computation. AUTOSAR is kind of the operating system and you buy an "adaption"/HAL of AUTOSAR to the each MCU from a vendor. This is widely used in many ECUs for hard real-time control, e.g. to control something in the engine, and other stuff like the electric windows. AUTOSAR is a huge pain in the ass to develop for. You usually configure "it", which takes a lot of time. Then a software generates a huge amount of code. The software is from another vendor, e.g. Vector or Elektrobit. The developer fills out the function stubs implementing the actual function. Alternatively, you can generate the code from MATLAB/SIMULINK models with a code generator from yet another vendor (model-based-development). The upside of this, that the HAL and code generators are certified and everything is somehow standardized. The downside is that normal developers want to kill themself, you learn no transferable skills, and the huge amount of generated boilerplate code, that is hard to read.
3. There is also a newer Adaptive AUTOSAR, which can run on Linux or QNX.
I guess (page 8) they want to use it for infotaiment (point 1), interior control (lights, climate control; probably point 2), automated driving and "central driving" (point 1, point 2). I am not sure if this includes typical fast hard-real-time tasks like engine control or chassis control (=vehicle dynamics control).
I am not sure if really want to abstract it all or just extend the "OS" (Linux, QNX, AUTOSAR) with libraries and components, mostly in user space.
If you look at slide 13, you might guess that they will adapt Linux and QNX to run their UI MBUX (in QT). They extend it with services that communicate with ECUs in the car and their servies in the internet. Moreover, they allow to install sandboxed apps from Mercedes, Android Auto (e.g. Spotify) on top of it. They also come with an app store: https://faurecia-aptoide.com/
The real-time ECUs in the car running AUTOSAR will just get additional components to easily communicate with other MB.OS parts and support some newer features like OTA update.
The Tableau algorithm is patented. In particular, the algorithm that chooses the type of the chart depending on the properties of the data. It was developed under the name Polaris at MIT (?).
A few patent applications were accepted in the US and declined in the EU.
This is based on graphic-walker which is based on vega as far as I see. It would be interesting to see if vega is different enough from Polaris/Tableau.
Typically, some of the tasks run on different cores. The LMAX disruptor is designed such that there is no huge delay due to cache coherency. It is slow to sync the cache of one core to the cache of another core when both cores write to the same address in RAM. The LMAX disruptor is designed that each memory location is (mostly) written to by at most thread/core.
How is the LMAX disrupter relevant for programs with 1 core?