5 ms·

Yeah, downvoted for honest and informed opinion. Unfortunately this is quite common in HN.

viraptor 10y ago
I downvoted you for random assumptions and insulting people you never talked to. > a modern automatic transmission is controlled by firmware, a unikernel Have you seen the source? If not, how do you know it's a unikernel? > The shift points and the shifting logic are based on the developers' very dim understanding of economy and of performance driving "dim understanding"? Do you have a reference for any of that? Why do you think it's developers, not mechanical engineers or engine testing that resulted in the shift threshold? > there is often a significant latency involved - by the time the unikernel has managed to process all the inputs from all the sensors Again, that's a heavy assumption unless you have a source for it. Also, from own experience in actually writing control software like that, real world sensors can be read tens/hundreds+ of times per second. But even with tiny 8K microprocessors you can process it more quickly. Mostly you sit in a tight loop and wait for new data. Processing it takes tiny fraction of the wait time. > On top of that, the developers' opinions of what's acceptable and what makes sense are truly dim and utterly infuriating Yeah... you're just throwing ad-hominem around. Please come post some sources which support your opinions.
- Annatar 10y ago
  I have noticed systemic abuse of ad hominem labeling anyone who doesn't lavish high praise and criticizes instead. Please show some emapthy and think about how the code could be improved instead, so these criticisms can be addressed with a practical solution. In this particular case, all my criticisms can be addressed by offering a manual transmission option with a dry clutch, not even code optimization is required. Also, as a firmware writer, you know that all such source code is under strict non-disclosure agreements, and whatever I know or have seen, I wouldn't be at liberty to discuss or cite, or else I risk legal penalties. We're neither anonymous nor protected here. As for unikernel, any firmware or subsystem concerned with one task - such as running a vehicle - is by definition a unikernel - all firmware is, as its running one single monolithic application image. Developers versus mechanical engineers - in this context a mechanical engineer is also a developer, just of the transmission, and they often write the software themselves, too. Finally, as a firmware writer, please explain to me why there is a lag between depressing an accelerator pedal in a 2011 Volkswagen Golf, why the engine will often konk out unless the accelerator pedal is pressed fully when starting on a hill, and why a 2012 Buick LaCrosse will display "shift denied" on the dashboard when I try to upshift from 5th to 6th going at 1,400 RPM, which would put me at 1,200 RPM, well within the engine's ability to continue running efficiently?
  - striking 10y ago
    > lag between depressing an accelerator pedal Well, doesn't fuel flow need to be increased before acceleration can begin? That causes latency, much more than software would. Perhaps the software is causing a little bit of that, perhaps there's a simple delay loop instead of a sensor there and it's a little too long. We'll never know, but there are plenty of guesses you could make. > why the engine will often konk out unless the accelerator pedal is pressed fully when starting on a hill That doesn't at all sound like a software problem. It sounds like you're conflating "I don't like my car" with "my car software sucks". > upshift from 5th to 6th [...] 1,400 RPM [...] 1,200 RPM Are you certain that upshifting like that would only drop you 200 RPM? Not at least 1000? I'm fairly certain that's not correct. > [...] all my criticisms can be addressed by offering a manual transmission option with a dry clutch [...] Just buy a manual car if you care so much. Or buy a journal and vent into that rather than the HN comment section. Goodness gracious.
    - Annatar 10y ago
      Well, doesn't fuel flow need to be increased before acceleration can begin? That causes latency, much more than software would. No, because the engine in question is a common rail diesel engine, which means that the fuel is kept under a constant pressure of 2,200 atmospheres, ready to be injected into the cylinders. The only thing that has to happen is for the piezoelectric injectors to open. On a vehicle with a common rail diesel engine without firmware, where the logic is hardwired electronics in the ECU, and the throttle is connected with a cable as opposed to drive-by-wire, such a thing does not occur: zero latency, instant response. As I owned both types of vehicles, I was in the unique position to observe and experiment. These are vehicles from completely different manufacturers, one German, one Japanese. The Japanese diesel has no issues or problems whatsoever. That's the one I kept. Not a single stall since going back to a mechanical throttle. And also, I've learned on a manual and have been driving them daily for decades. And for the record, I had two firmware updates on the drive-by-wire model, and they only helped marginally with throttle response, but never fixed the issue.
  - viraptor 10y ago
    > I have noticed systemic abuse of ad hominem labeling You literally said it's due to developers' dim opinions. Lots of people don't like auto transmissions, and that's fine. Just chill about it. > you know that all such source code is under strict non-disclosure agreements Nope. Are you saying that all such code is under strict NDA? Likely, you can still say you signed one and cannot talk about it if that's the case. > I wouldn't be at liberty to discuss or cite As in, you cannot link to an existing, public article that supports what you're talking about? I call BS. > any firmware or subsystem concerned with one task - such as running a vehicle - is by definition a unikernel That's not a definition of a unikernel. You can easily have embedded systems with no kernel to speak of. It may be a unikernel, but since you're possibly under NDA you're not saying that, are you? > Finally, as a firmware writer, please explain to me... I'm not a the author of those systems, therefore I will not make assumptions about them. And I recommend the same to you. What you're describing is behaviour and sure - they may behave like this for some reason. Blaming that on a specific part of the system, or technology, or developers that are dim and do stuff without a reason, without a good proof is neither useful nor helpful.
- striking 10y ago
  >> sensors More to the point, the sensors are either wired directly to the controller or data is retrieved over CAN. And there may not even be a spin-lock waiting for that data, data acquisition could very well be interrupt-driven. The latency claim is totally unfounded, and anyone who has made use of an embedded platform (even as weak as PIC or Arduino) to collect data can see it as totally and utterly wrong.
  - Annatar 10y ago
    The latency claim is totally unfounded, and anyone who has made use of an embedded platform (even as weak as PIC or Arduino) to collect data can see it as totally and utterly wrong. Where is the latency coming from, then? Other than disputing what I wrote, no explanation of where the latency is coming from has so far been offered. I will gladly accept an explanation where the latency is coming from, and have even listed concrete models, years, and scenarios to facilitate a concrete explanation. Please, have at it.

I downvoted you for random assumptions and insulting people you never talked to. > a modern automatic transmission is controlled by firmware, a unikernel Have you seen the source? If not, how do you know it's a unikernel? > The shift points and the shifting logic are based on the developers' very dim understanding of economy and of performance driving "dim understanding"? Do you have a reference for any of that? Why do you think it's developers, not mechanical engineers or engine testing that resulted in the shift threshold? > there is often a significant latency involved - by the time the unikernel has managed to process all the inputs from all the sensors Again, that's a heavy assumption unless you have a source for it. Also, from own experience in actually writing control software like that, real world sensors can be read tens/hundreds+ of times per second. But even with tiny 8K microprocessors you can process it more quickly. Mostly you sit in a tight loop and wait for new data. Processing it takes tiny fraction of the wait time. > On top of that, the developers' opinions of what's acceptable and what makes sense are truly dim and utterly infuriating Yeah... you're just throwing ad-hominem around. Please come post some sources which support your opinions.

Annatar 10y ago
I have noticed systemic abuse of ad hominem labeling anyone who doesn't lavish high praise and criticizes instead. Please show some emapthy and think about how the code could be improved instead, so these criticisms can be addressed with a practical solution. In this particular case, all my criticisms can be addressed by offering a manual transmission option with a dry clutch, not even code optimization is required. Also, as a firmware writer, you know that all such source code is under strict non-disclosure agreements, and whatever I know or have seen, I wouldn't be at liberty to discuss or cite, or else I risk legal penalties. We're neither anonymous nor protected here. As for unikernel, any firmware or subsystem concerned with one task - such as running a vehicle - is by definition a unikernel - all firmware is, as its running one single monolithic application image. Developers versus mechanical engineers - in this context a mechanical engineer is also a developer, just of the transmission, and they often write the software themselves, too. Finally, as a firmware writer, please explain to me why there is a lag between depressing an accelerator pedal in a 2011 Volkswagen Golf, why the engine will often konk out unless the accelerator pedal is pressed fully when starting on a hill, and why a 2012 Buick LaCrosse will display "shift denied" on the dashboard when I try to upshift from 5th to 6th going at 1,400 RPM, which would put me at 1,200 RPM, well within the engine's ability to continue running efficiently?
- striking 10y ago
  > lag between depressing an accelerator pedal Well, doesn't fuel flow need to be increased before acceleration can begin? That causes latency, much more than software would. Perhaps the software is causing a little bit of that, perhaps there's a simple delay loop instead of a sensor there and it's a little too long. We'll never know, but there are plenty of guesses you could make. > why the engine will often konk out unless the accelerator pedal is pressed fully when starting on a hill That doesn't at all sound like a software problem. It sounds like you're conflating "I don't like my car" with "my car software sucks". > upshift from 5th to 6th [...] 1,400 RPM [...] 1,200 RPM Are you certain that upshifting like that would only drop you 200 RPM? Not at least 1000? I'm fairly certain that's not correct. > [...] all my criticisms can be addressed by offering a manual transmission option with a dry clutch [...] Just buy a manual car if you care so much. Or buy a journal and vent into that rather than the HN comment section. Goodness gracious.
  - Annatar 10y ago
    Well, doesn't fuel flow need to be increased before acceleration can begin? That causes latency, much more than software would. No, because the engine in question is a common rail diesel engine, which means that the fuel is kept under a constant pressure of 2,200 atmospheres, ready to be injected into the cylinders. The only thing that has to happen is for the piezoelectric injectors to open. On a vehicle with a common rail diesel engine without firmware, where the logic is hardwired electronics in the ECU, and the throttle is connected with a cable as opposed to drive-by-wire, such a thing does not occur: zero latency, instant response. As I owned both types of vehicles, I was in the unique position to observe and experiment. These are vehicles from completely different manufacturers, one German, one Japanese. The Japanese diesel has no issues or problems whatsoever. That's the one I kept. Not a single stall since going back to a mechanical throttle. And also, I've learned on a manual and have been driving them daily for decades. And for the record, I had two firmware updates on the drive-by-wire model, and they only helped marginally with throttle response, but never fixed the issue.
- viraptor 10y ago
  > I have noticed systemic abuse of ad hominem labeling You literally said it's due to developers' dim opinions. Lots of people don't like auto transmissions, and that's fine. Just chill about it. > you know that all such source code is under strict non-disclosure agreements Nope. Are you saying that all such code is under strict NDA? Likely, you can still say you signed one and cannot talk about it if that's the case. > I wouldn't be at liberty to discuss or cite As in, you cannot link to an existing, public article that supports what you're talking about? I call BS. > any firmware or subsystem concerned with one task - such as running a vehicle - is by definition a unikernel That's not a definition of a unikernel. You can easily have embedded systems with no kernel to speak of. It may be a unikernel, but since you're possibly under NDA you're not saying that, are you? > Finally, as a firmware writer, please explain to me... I'm not a the author of those systems, therefore I will not make assumptions about them. And I recommend the same to you. What you're describing is behaviour and sure - they may behave like this for some reason. Blaming that on a specific part of the system, or technology, or developers that are dim and do stuff without a reason, without a good proof is neither useful nor helpful.
striking 10y ago
>> sensors More to the point, the sensors are either wired directly to the controller or data is retrieved over CAN. And there may not even be a spin-lock waiting for that data, data acquisition could very well be interrupt-driven. The latency claim is totally unfounded, and anyone who has made use of an embedded platform (even as weak as PIC or Arduino) to collect data can see it as totally and utterly wrong.
- Annatar 10y ago
  The latency claim is totally unfounded, and anyone who has made use of an embedded platform (even as weak as PIC or Arduino) to collect data can see it as totally and utterly wrong. Where is the latency coming from, then? Other than disputing what I wrote, no explanation of where the latency is coming from has so far been offered. I will gladly accept an explanation where the latency is coming from, and have even listed concrete models, years, and scenarios to facilitate a concrete explanation. Please, have at it.