6 ms·

1 seconds seems a rather arbitrary measure. In HCI 100ms seems to be the value that's generally taken under which an action seems to be happening instantaneousl

1 seconds seems a rather arbitrary measure. In HCI 100ms seems to be the value that's generally taken under which an action seems to be happening instantaneously [1] It's quite sad to see how we hardly use the computing power offered by our modern computers to actually speed up common tasks, but instead bloat it up with all kinds of stuff. [1] http://cogsci.stackexchange.com/questions/1664/what-is-the-threshold-where-actions-are-perceived-as-instant http://cogsci.stackexchange.com/questions/1664/what-is-the-t...

cm2187 11y ago
But 1s is sufficiently small so that you don't notice that the system is loading between the time you switch on the engine of a car and the time you start using it.
sharpneli 11y ago
I completely agree with the general idea. Bloat is too high and has far reaching consequences. And it's actually even worse than that. 100ms is nowhere near enough to be sufficient for all applications. For audio applications you need 10ms [http://superpowered.com/androidaudiopathlatency http://superpowered.com/androidaudiopathlatency] which incidentally is the reason why Android is unusable for any interactive audio applications. Same applies to Virtual Reality. You need sub 20ms latency for head tracking to eyes latency or you will feel sick (effectively less than 10ms from the cpu side. Display scanning is summed on top). The 100ms figure applies mostly to traditional UI workflow. Whenever you need a realtime interaction that's 10x too high.
- jahnu 11y ago
  > which incidentally is the reason why Android is unusable for any interactive audio applications. Everybody says this and yet programs like Caustic seem to do a fine job in my experience.
  - hrnnnnnn 11y ago
    Have you tried performing using an android app? I used a drum-pad app the other week and the latency makes it unplayable. There's a great explanation here as to why it's so bad: http://superpowered.com/androidaudiopathlatency http://superpowered.com/androidaudiopathlatency
    - MarkyC4 11y ago
      This is fixed in newer Android phones: https://source.android.com/devices/audio/latency_measurements.html https://source.android.com/devices/audio/latency_measurement...
      - sharpneli 11y ago
        That's a relief. They are finally taking the issue seriously then. There are also indications that they are going to lower the display path latency, which also stands several times higher than what is in iDevices. It just takes some time to get a certain class of software architects to realize that buffering a frame several times each step might not be the smartest way after all.
      - hrnnnnnn 11y ago
        That's awesome to hear, I just got a new phone so I'm going to try this out :)
- theandrewbailey 11y ago
  > which incidentally is the reason why Android is unusable for any interactive audio applications. Strange. The primary use of my (Android) phone is interactive audio. I do not recognize latency as an issue.
- l1ambda 11y ago
  I'm glad you posted this. Even the 10ms rule of thumb is...well, not always true either! FWIW, if you are playing virtual drums, drummers need something like under 2ms response time; even 10ms can be easily felt by a drummer and cause their timing to get way off! On top of that, if you are doing, say, a real-time effect on a vocal track, even a tiny sub 1ms delay causes a weird reverb effect in her monitor vs. the singer hearing herself, which will cause your singer's singing to get out of sync!
SiVal 11y ago
If you can boot faster than the screen can come to life, you don't need to be faster. IoT and servers might not have screens, so this doesn't apply to everything, but for devices with screens, just beating the screen warmup is good enough to feel like immediate startup. Also, for devices that require user authentication, such as logging in to an account, if you could offload the authentication (such as fingerprint or other biometrics) to something out of the OS itself (ROM routine that starts up with a 0 in a certain memory address and changes it to 1 on authentication), you could be booting up the OS in the background while you take a second or two to log in, and if the OS can get up and running by the time you log in, the OS can pretend that it started up immediately and was the thing that logged you in. For many devices, there is need to boot up in less than a second or so to seem as though boot up was instantaneous.
oliwarner 11y ago
One second, ten seconds... The problem isn't that it takes time, it's that the user has to sit there and wait while it takes that time. My desktop takes about two seconds to resume from suspend. I'd sit down, lean down to the floor and press the power button and then wait that two seconds. I fixed the whole problem by moving the case up onto the desk so that I have to walk past it to sit down. Now I press the button and then sit down, by which time the computer is waiting for me. The way it should be. Sidebar: Now I'm slightly concerned that an AI in the future is going to call me out for my blatant display of meatbag privilege. We can throw tons of money at engineering boot times but but really the biggest gains are made when you can predict what the user wants. Imagine you approach your car. If it can detect you or your key, it can start doing stuff it'd normally do when you put the key in the ignition. Suddenly it doesn't matter than it takes 5-10 seconds to boot because it also takes 10 seconds to get in the car. All this stuff is going to get better once we have widespread adoption of technology for fine indoor tracking. When we can tell our relative positions to our gadgets, they'll be able to sleep deeper, ring louder, shine brighter and start booting earlier.
- andrewstuart2 11y ago
  The problem with anticipation is that nobody except you can truly know your intent. For example, walking up to a car with my keys might just mean I want to grab something out of the trunk; or the car might be in a closed garage and that wouldn't be quite safe at the moment. The easiest and safest thing is usually still to let people control more of what happens because there's a lot of edge cases that might add up, or have really bad consequences for when they rarely occur.
  - caskance 11y ago
    That's not a problem with anticipation as a concept, that's a problem with bad anticipation. Certainly it's possible to detect whether the car is in a closed garage, and it will eventually be possible to predict whether you want to grab something out of the trunk or go for a drive. Even though it often feels like you do, humans generally don't know their own intents. It's not that high of a bar for a predictive system to clear.
scott_s 11y ago
Comparing the richness of the user experience for a wide variety of applications of now versus a decade or two ago, I think we are doing plenty of useful things with modern systems that is not actually "bloat".
dghughes 11y ago
Even that may be debunked it seems it's now down to 13ms and that number is only due to testing equipment limitations of 13ms. According to "Mary Potter, an MIT professor of brain and cognitive sciences and senior author of the study". http://news.mit.edu/2014/in-the-blink-of-an-eye-0116 http://news.mit.edu/2014/in-the-blink-of-an-eye-0116

cm2187 11y ago

But 1s is sufficiently small so that you don't notice that the system is loading between the time you switch on the engine of a car and the time you start using it.

sharpneli 11y ago

I completely agree with the general idea. Bloat is too high and has far reaching consequences. And it's actually even worse than that. 100ms is nowhere near enough to be sufficient for all applications. For audio applications you need 10ms [http://superpowered.com/androidaudiopathlatency http://superpowered.com/androidaudiopathlatency] which incidentally is the reason why Android is unusable for any interactive audio applications. Same applies to Virtual Reality. You need sub 20ms latency for head tracking to eyes latency or you will feel sick (effectively less than 10ms from the cpu side. Display scanning is summed on top). The 100ms figure applies mostly to traditional UI workflow. Whenever you need a realtime interaction that's 10x too high.

jahnu 11y ago
> which incidentally is the reason why Android is unusable for any interactive audio applications. Everybody says this and yet programs like Caustic seem to do a fine job in my experience.
- hrnnnnnn 11y ago
  Have you tried performing using an android app? I used a drum-pad app the other week and the latency makes it unplayable. There's a great explanation here as to why it's so bad: http://superpowered.com/androidaudiopathlatency http://superpowered.com/androidaudiopathlatency
  - MarkyC4 11y ago
    This is fixed in newer Android phones: https://source.android.com/devices/audio/latency_measurements.html https://source.android.com/devices/audio/latency_measurement...
    - sharpneli 11y ago
      That's a relief. They are finally taking the issue seriously then. There are also indications that they are going to lower the display path latency, which also stands several times higher than what is in iDevices. It just takes some time to get a certain class of software architects to realize that buffering a frame several times each step might not be the smartest way after all.
    - hrnnnnnn 11y ago
      That's awesome to hear, I just got a new phone so I'm going to try this out :)
theandrewbailey 11y ago
> which incidentally is the reason why Android is unusable for any interactive audio applications. Strange. The primary use of my (Android) phone is interactive audio. I do not recognize latency as an issue.
l1ambda 11y ago
I'm glad you posted this. Even the 10ms rule of thumb is...well, not always true either! FWIW, if you are playing virtual drums, drummers need something like under 2ms response time; even 10ms can be easily felt by a drummer and cause their timing to get way off! On top of that, if you are doing, say, a real-time effect on a vocal track, even a tiny sub 1ms delay causes a weird reverb effect in her monitor vs. the singer hearing herself, which will cause your singer's singing to get out of sync!

SiVal 11y ago

If you can boot faster than the screen can come to life, you don't need to be faster. IoT and servers might not have screens, so this doesn't apply to everything, but for devices with screens, just beating the screen warmup is good enough to feel like immediate startup. Also, for devices that require user authentication, such as logging in to an account, if you could offload the authentication (such as fingerprint or other biometrics) to something out of the OS itself (ROM routine that starts up with a 0 in a certain memory address and changes it to 1 on authentication), you could be booting up the OS in the background while you take a second or two to log in, and if the OS can get up and running by the time you log in, the OS can pretend that it started up immediately and was the thing that logged you in. For many devices, there is need to boot up in less than a second or so to seem as though boot up was instantaneous.

oliwarner 11y ago

One second, ten seconds... The problem isn't that it takes time, it's that the user has to sit there and wait while it takes that time. My desktop takes about two seconds to resume from suspend. I'd sit down, lean down to the floor and press the power button and then wait that two seconds. I fixed the whole problem by moving the case up onto the desk so that I have to walk past it to sit down. Now I press the button and then sit down, by which time the computer is waiting for me. The way it should be. Sidebar: Now I'm slightly concerned that an AI in the future is going to call me out for my blatant display of meatbag privilege. We can throw tons of money at engineering boot times but but really the biggest gains are made when you can predict what the user wants. Imagine you approach your car. If it can detect you or your key, it can start doing stuff it'd normally do when you put the key in the ignition. Suddenly it doesn't matter than it takes 5-10 seconds to boot because it also takes 10 seconds to get in the car. All this stuff is going to get better once we have widespread adoption of technology for fine indoor tracking. When we can tell our relative positions to our gadgets, they'll be able to sleep deeper, ring louder, shine brighter and start booting earlier.

andrewstuart2 11y ago
The problem with anticipation is that nobody except you can truly know your intent. For example, walking up to a car with my keys might just mean I want to grab something out of the trunk; or the car might be in a closed garage and that wouldn't be quite safe at the moment. The easiest and safest thing is usually still to let people control more of what happens because there's a lot of edge cases that might add up, or have really bad consequences for when they rarely occur.
- caskance 11y ago
  That's not a problem with anticipation as a concept, that's a problem with bad anticipation. Certainly it's possible to detect whether the car is in a closed garage, and it will eventually be possible to predict whether you want to grab something out of the trunk or go for a drive. Even though it often feels like you do, humans generally don't know their own intents. It's not that high of a bar for a predictive system to clear.

scott_s 11y ago

Comparing the richness of the user experience for a wide variety of applications of now versus a decade or two ago, I think we are doing plenty of useful things with modern systems that is not actually "bloat".

dghughes 11y ago

Even that may be debunked it seems it's now down to 13ms and that number is only due to testing equipment limitations of 13ms. According to "Mary Potter, an MIT professor of brain and cognitive sciences and senior author of the study". http://news.mit.edu/2014/in-the-blink-of-an-eye-0116 http://news.mit.edu/2014/in-the-blink-of-an-eye-0116