4 ms·

Nah man python powered ECU is the way it's going to go. The engine stalling whenever the GC runs is a bonus feature.

WJW 6y ago
I know you're joking, but I bet it'd be possible to make a python-powered ECU these days. It's not that hard to make non-allocating code in the first place, but even then the amount of data is so small that a GC cycle could be done in a ms or so at most. An engine running at 3000 RPM is only doing 50 rotations per second, so you have a 20 ms budget to calculate whatever you want, hit whatever spark plug timing you need and then GC.
- jimktrains2 6y ago
  Engines can turn faster than 3000rpm, even in the general case. Car engines are 4 strokes, so you're probably interested in collecting data and issuing control signals through those 4 strokes. I believe my small car redlines at 7,000rpm, so that leaves roughly 2ms per stroke (for all 4 cylinders). Also, the ECU does more than just the cylinder values, it's monitoring other systems as well, such as the transmission, traction control, &c which also have hard deadlines. I don't think there is enough time to garbage collect, and as other gave stated, there should be little to no need to allocate in this type of code anyway.
- ben-schaaf 6y ago
  > It's not that hard to make non-allocating code in the first place It sure is in cpython. `a = 1` may need to allocate/reallocate the dict holding the local/global variables. If an integer exceeds 256 or goes below -5 you're getting an allocation for the object - regardless of whether that number has been seen before or not. Of course you can forget about floating point and function calls - maybe even function calls to C functions.
- rurban 6y ago
  Trivial ECU's run at 500Hz, better ones at 1kHz, the very best (Formula 1) at 10KHz. (fixed typos) There's for sure no dynamic memory, no recursion, only fixed memory slots.
  - matthiasl 6y ago
    Rurban wrote: "the very best (Formula 1) at 10 KHz". how much of the above is a typo and how much is real? I'm pretty sure 'KHz' is a typo which maybe should be kHz as in the start of the sentence. But even then, why are the very best running 50x slower than the trivial ones? Or did you mean MHz? Do you have a link to an example of an F1 ECU with the clock rate specified?
    - rurban 6y ago
      Oops, big typos. Factor 1000 slower, fixed in parent. Thanks Sorry, no links afaik. Internal knowledge.
    - jeffreygoesto 6y ago
      To me it looks like the frequency of the control loop, not the cpu core frequency was meant? 1kHz is typical for i.e. steering or abs control loops.
      - rurban 6y ago
        Sure. The cpu's are normal Intel 4GHz. The control loop is 10Khz. In space the CPU's would be radiation hardened and throttled, somethink like 250Mhz. Still enough. The bottleneck is not the CPU, nor the model running in the loop, but the IO devices and driver's costing latency. In real-time latency kills you. Which turns out to be bended cables, missing resistors, broken filters, or such. A simple cycle-miss in real-time means reboot or worse.
    - foobarian 6y ago
      With a (conservative) 10k RPM limit, you get a 6ms per rotation. But I would imagine the control must run many times per rotation, so it has a chance to do something different depending on the angle, like a physical camshaft would do. Say you have to re-calculate everything at every 1 degree of rotation, that would give you a 60kHz calculation rate or about 16 microseconds per iteration. I guess that's much more than even the best case in OP's example; I wonder what the compromises are then. Surely they don't punt on the granularity and (say) only do something every 10 degrees? Or worse?
- Sebb767 6y ago
  > An engine running at 3000 RPM is only doing 50 rotations per second, so you have a 20 ms budget to calculate whatever you want, hit whatever spark plug timing you need and then GC. The engine should still work at redline, so lets go for a conservative 6000 RPM, or 10ms budget. The spark plugs don't fire at the same time either, but (as far as I know) every second rotation in a staggered manner. So with a 4 piston engine you'd have 5ms (one firing every 180 deg) to do calculations, check for failure conditions and run the gc, with the latter one needing to finish in time. It might be possible to do a proof of concept, but I don't think its that easy.
  - nabilhat 6y ago
    It's even worse considering all of the conditions being controlled for and the precision expected. Spark timing needs to fall within a degree of rotation. Modern cars get direct injection of fuel into the cylinders, which needs to be provided at a precise volume at somewhat less precise timing. Continuously variable valve timing and lift control cylinder conditions for improved burn efficiency while preventing an environment that encourages preignition, at the same time providing as much volumetric flow as possible. All of this needs to account for airflow, altitude, intake air temperature, variations in fuel quality, hiccups in fuel supply, engine temperature, over the entire range of possible engine load and speeds, and transitions throughout all of these states. It's a seriously hard optimization problem, one that's not yet up to the task of providing reliable engine management quickly enough to also provide throttle-by-wire response in general production cars that isn't as spongy as an old Mercedes diesel sedan. I mean, if Mazda could provide throttle response for the new throttle-by-wire Miata that was remotely similar to a 30 year old model, I think they would.
encom 6y ago
Don't give Hacker News any ideas, or we'll end up with an Electron-based ECU (as-a-service).

WJW 6y ago

I know you're joking, but I bet it'd be possible to make a python-powered ECU these days. It's not that hard to make non-allocating code in the first place, but even then the amount of data is so small that a GC cycle could be done in a ms or so at most. An engine running at 3000 RPM is only doing 50 rotations per second, so you have a 20 ms budget to calculate whatever you want, hit whatever spark plug timing you need and then GC.

jimktrains2 6y ago
Engines can turn faster than 3000rpm, even in the general case. Car engines are 4 strokes, so you're probably interested in collecting data and issuing control signals through those 4 strokes. I believe my small car redlines at 7,000rpm, so that leaves roughly 2ms per stroke (for all 4 cylinders). Also, the ECU does more than just the cylinder values, it's monitoring other systems as well, such as the transmission, traction control, &c which also have hard deadlines. I don't think there is enough time to garbage collect, and as other gave stated, there should be little to no need to allocate in this type of code anyway.
ben-schaaf 6y ago
> It's not that hard to make non-allocating code in the first place It sure is in cpython. `a = 1` may need to allocate/reallocate the dict holding the local/global variables. If an integer exceeds 256 or goes below -5 you're getting an allocation for the object - regardless of whether that number has been seen before or not. Of course you can forget about floating point and function calls - maybe even function calls to C functions.
rurban 6y ago
Trivial ECU's run at 500Hz, better ones at 1kHz, the very best (Formula 1) at 10KHz. (fixed typos) There's for sure no dynamic memory, no recursion, only fixed memory slots.
- matthiasl 6y ago
  Rurban wrote: "the very best (Formula 1) at 10 KHz". how much of the above is a typo and how much is real? I'm pretty sure 'KHz' is a typo which maybe should be kHz as in the start of the sentence. But even then, why are the very best running 50x slower than the trivial ones? Or did you mean MHz? Do you have a link to an example of an F1 ECU with the clock rate specified?
  - rurban 6y ago
    Oops, big typos. Factor 1000 slower, fixed in parent. Thanks Sorry, no links afaik. Internal knowledge.
  - jeffreygoesto 6y ago
    To me it looks like the frequency of the control loop, not the cpu core frequency was meant? 1kHz is typical for i.e. steering or abs control loops.
    - rurban 6y ago
      Sure. The cpu's are normal Intel 4GHz. The control loop is 10Khz. In space the CPU's would be radiation hardened and throttled, somethink like 250Mhz. Still enough. The bottleneck is not the CPU, nor the model running in the loop, but the IO devices and driver's costing latency. In real-time latency kills you. Which turns out to be bended cables, missing resistors, broken filters, or such. A simple cycle-miss in real-time means reboot or worse.
  - foobarian 6y ago
    With a (conservative) 10k RPM limit, you get a 6ms per rotation. But I would imagine the control must run many times per rotation, so it has a chance to do something different depending on the angle, like a physical camshaft would do. Say you have to re-calculate everything at every 1 degree of rotation, that would give you a 60kHz calculation rate or about 16 microseconds per iteration. I guess that's much more than even the best case in OP's example; I wonder what the compromises are then. Surely they don't punt on the granularity and (say) only do something every 10 degrees? Or worse?
Sebb767 6y ago
> An engine running at 3000 RPM is only doing 50 rotations per second, so you have a 20 ms budget to calculate whatever you want, hit whatever spark plug timing you need and then GC. The engine should still work at redline, so lets go for a conservative 6000 RPM, or 10ms budget. The spark plugs don't fire at the same time either, but (as far as I know) every second rotation in a staggered manner. So with a 4 piston engine you'd have 5ms (one firing every 180 deg) to do calculations, check for failure conditions and run the gc, with the latter one needing to finish in time. It might be possible to do a proof of concept, but I don't think its that easy.
- nabilhat 6y ago
  It's even worse considering all of the conditions being controlled for and the precision expected. Spark timing needs to fall within a degree of rotation. Modern cars get direct injection of fuel into the cylinders, which needs to be provided at a precise volume at somewhat less precise timing. Continuously variable valve timing and lift control cylinder conditions for improved burn efficiency while preventing an environment that encourages preignition, at the same time providing as much volumetric flow as possible. All of this needs to account for airflow, altitude, intake air temperature, variations in fuel quality, hiccups in fuel supply, engine temperature, over the entire range of possible engine load and speeds, and transitions throughout all of these states. It's a seriously hard optimization problem, one that's not yet up to the task of providing reliable engine management quickly enough to also provide throttle-by-wire response in general production cars that isn't as spongy as an old Mercedes diesel sedan. I mean, if Mazda could provide throttle response for the new throttle-by-wire Miata that was remotely similar to a 30 year old model, I think they would.

encom 6y ago

Don't give Hacker News any ideas, or we'll end up with an Electron-based ECU (as-a-service).