5 ms·

True that. I feel like we've really gone backwards on that aspect concerning TV. I remember a time where I could turn on the TV and be 3 channels further all wi

by yoran 9y ago

True that. I feel like we've really gone backwards on that aspect concerning TV. I remember a time where I could turn on the TV and be 3 channels further all within the space of 2 seconds. Now my "smart" TV takes 5 seconds just for a first paint, and changing a channel once takes a second. You just can't beat the latency of analog circuits!

Asooka 9y ago
You mean uncompressed data. Yes, analogue is uncompressed, but digital could also be uncompressed. However, everyone wants to stuff more video, more audio over the link, so we compress... Bandwidth goes up, latency also goes up, and things get more complicated...
- blattimwind 9y ago
  Analogue video signals are absolutely compressed (interlacing, PAL, NTSC, SECAM). It's just not as efficient as MPEG-X combined with hyper-aggressive modulation schemes and forward-error correction, channel-capacity wise.
mark-r 9y ago
My new car has a radio with a touch-screen interface. When I turn the car on there's a space of about 10 seconds where the radio is operating but I can't change the station or volume or even turn it off. It's quite annoying when you were rocking out last time you were in the car and now you have passengers.
- wpietri 9y ago
  To me this is symptomatic of a long or broken feedback loop in the development process. E.g., a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. In that setting, nobody's going to say, "Hey, let's just pop this radio into our cars, live with it for a few weeks, and then figure out where we need to go next." It's too late. Instead I think the thing to do is force convergence early and often in the product timeline, so that the supposedly-little things like this have plenty of time to get noticed and fixed. A good example of this is Apple. I'm told that in consumer electronics the typical number of iterations with physical prototypes is 3-7. For the first iPod, Apple went through more than 100. The difference was enough for them to crush the competition so thoroughly that people these days are surprised to hear that there were MP3 players before the iPod (and smartphones before the iPhone).
  - userbinator 9y ago
    a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. ...which is actually quite suitable for the safety-critical parts of a car like the ECU and other controllers that control the actual driving aspect, but not for everything else that doesn't need such a level of process. On the other hand, I suppose it could also be blamed on the lack of "performance is a feature" --- if they specified the radio to be as responsive as the accelerator and brake, for example.
    - wpietri 9y ago
      I think the choice of process is basically orthogonal. Waterfall and Agile processes done well both have been demonstrated to produce safety-critical software. (See, e.g., Nancy van Schooenderwoert's work in medical devices.) Both can produce dangerous software. (E.g., Toyota's "unintended acceleration" issues.) The question is much more about what practices you put in place to assure quality. I do think short-cycle methods have some intrinsic advantages, though. By making critical functionality available much earlier for testing, you get more time and more chances to make sure it's really safe. If early versions are bad, you get early warning signs that aren't available in a Waterfall process. And if testing turns up issues early on, it's much cheaper to make fundamental architectural changes: less code to change and more time to change it in. And Waterfall processes aren't at good at dealing with unknown unknowns; some things you only learn by trying them out.
- FireBeyond 9y ago
  Same, and it's all the more frustrating with the realization that what is effectively a tablet should be able to sleep for an inordinately long time, especially in "airplane mode" (mine has a SIM card, but there's no reason to be running an AP or Bluetooth when off), rather than cold booting, off a car battery.
ryandrake 9y ago
The radios from my various cars throughout the years are just as bad. My 1970s era radio turned on instantly and there was zero delay as I tuned through channels with a nice smooth analog dial. My 1990s era radio took about 500ms from power on to audio output. The "dial" had steps in it though and was not continuous, and there was a noticeable (again probably around 500ms) delay between when 'click' tactile feedback and when the station was successfully tuned. My current car takes 15 seconds just to boot (WTF), and then I have to navigate some horrible menu just to get to the radio controls. It's like these guys are actively trying to make things worse.
- userbinator 9y ago
  Even the 1980s car radios with digital controls had no perceptible delay, despite containing microcontrollers with a tiny fraction of the speed and memory of the modern ones. Maybe it's the whole "let's run Linux on it because we can" phenomenon. The microcontrollers in the old electronic radios didn't run an OS but interacted with the hardware directly. The number of instructions executed from sensing the dial change to updating the tuner and display would probably be less than 100. Now it's half a dozen layers of abstraction and millions of instructions to do the same thing, on a processor which is maybe "only" 1000x faster at most...

by yoran 9y ago

Asooka 9y ago

You mean uncompressed data. Yes, analogue is uncompressed, but digital could also be uncompressed. However, everyone wants to stuff more video, more audio over the link, so we compress... Bandwidth goes up, latency also goes up, and things get more complicated...

blattimwind 9y ago
Analogue video signals are absolutely compressed (interlacing, PAL, NTSC, SECAM). It's just not as efficient as MPEG-X combined with hyper-aggressive modulation schemes and forward-error correction, channel-capacity wise.

mark-r 9y ago

My new car has a radio with a touch-screen interface. When I turn the car on there's a space of about 10 seconds where the radio is operating but I can't change the station or volume or even turn it off. It's quite annoying when you were rocking out last time you were in the car and now you have passengers.

wpietri 9y ago
To me this is symptomatic of a long or broken feedback loop in the development process. E.g., a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. In that setting, nobody's going to say, "Hey, let's just pop this radio into our cars, live with it for a few weeks, and then figure out where we need to go next." It's too late. Instead I think the thing to do is force convergence early and often in the product timeline, so that the supposedly-little things like this have plenty of time to get noticed and fixed. A good example of this is Apple. I'm told that in consumer electronics the typical number of iterations with physical prototypes is 3-7. For the first iPod, Apple went through more than 100. The difference was enough for them to crush the competition so thoroughly that people these days are surprised to hear that there were MP3 players before the iPod (and smartphones before the iPhone).
- userbinator 9y ago
  a classic waterfall approach where somebody writes a big spec, a team spends a bunch of time implementing, and then sometime at or after the deadline, a working model is produced. ...which is actually quite suitable for the safety-critical parts of a car like the ECU and other controllers that control the actual driving aspect, but not for everything else that doesn't need such a level of process. On the other hand, I suppose it could also be blamed on the lack of "performance is a feature" --- if they specified the radio to be as responsive as the accelerator and brake, for example.
  - wpietri 9y ago
    I think the choice of process is basically orthogonal. Waterfall and Agile processes done well both have been demonstrated to produce safety-critical software. (See, e.g., Nancy van Schooenderwoert's work in medical devices.) Both can produce dangerous software. (E.g., Toyota's "unintended acceleration" issues.) The question is much more about what practices you put in place to assure quality. I do think short-cycle methods have some intrinsic advantages, though. By making critical functionality available much earlier for testing, you get more time and more chances to make sure it's really safe. If early versions are bad, you get early warning signs that aren't available in a Waterfall process. And if testing turns up issues early on, it's much cheaper to make fundamental architectural changes: less code to change and more time to change it in. And Waterfall processes aren't at good at dealing with unknown unknowns; some things you only learn by trying them out.
FireBeyond 9y ago
Same, and it's all the more frustrating with the realization that what is effectively a tablet should be able to sleep for an inordinately long time, especially in "airplane mode" (mine has a SIM card, but there's no reason to be running an AP or Bluetooth when off), rather than cold booting, off a car battery.

ryandrake 9y ago

The radios from my various cars throughout the years are just as bad. My 1970s era radio turned on instantly and there was zero delay as I tuned through channels with a nice smooth analog dial. My 1990s era radio took about 500ms from power on to audio output. The "dial" had steps in it though and was not continuous, and there was a noticeable (again probably around 500ms) delay between when 'click' tactile feedback and when the station was successfully tuned. My current car takes 15 seconds just to boot (WTF), and then I have to navigate some horrible menu just to get to the radio controls. It's like these guys are actively trying to make things worse.

userbinator 9y ago
Even the 1980s car radios with digital controls had no perceptible delay, despite containing microcontrollers with a tiny fraction of the speed and memory of the modern ones. Maybe it's the whole "let's run Linux on it because we can" phenomenon. The microcontrollers in the old electronic radios didn't run an OS but interacted with the hardware directly. The number of instructions executed from sensing the dial change to updating the tuner and display would probably be less than 100. Now it's half a dozen layers of abstraction and millions of instructions to do the same thing, on a processor which is maybe "only" 1000x faster at most...