3 ms·

Well the Linux USB maintainer has spent the last month or so trying to get Linus to be more polite, so I guess those kind of things have a higher priority! I k

by RyanZAG 13y ago

Well the Linux USB maintainer has spent the last month or so trying to get Linus to be more polite, so I guess those kind of things have a higher priority! I kid, I kid... The reason is that it is incredibly difficult to link the disconnect to the cause as the 10ms is likely sufficient in 99% of cases - until it suddenly isn't. This means that you could be running test cases on a certain device for a year, and suddenly the test will fail the day after. When the test case mysteriously fails randomly like that on only a subset of devices, the assumption is that the hardware is faulty. These kind of failures would likely be higher on lower quality, less optimized hardware as well, furthering the perception. As far as I can tell, the reason this is fixed now is because known good hardware from Intel started exhibiting the same error which got people at Intel to track it down directly, as they knew it wasn't their hardware at fault.

masklinn 13y ago
> the 10ms is likely sufficient in 99% of cases from TFA: > the time is above 10 ms in about 8% of the remote wakeup events I've tested. So 10ms is sufficient in about 92% of cases, barely more than 9 in 10.
- miga 13y ago
  I add it to my list of hard-to-replicate-and-locate bugs then.
- claudius 13y ago
  Which depends on the cases tested by Sharp – as the GP, depending on the hardware you use, you can probably get 100% or 0% (if you try really hard).
- raphman 13y ago
  This figure is just for two specific devices [1]: >Out of 227 remote wakeup events from a USB mouse and keyboard: > - 163 transitions from RExit to U0 were immediate ( < 1 microsecond) > - 47 transitions from RExit to U0 took under 10 ms > - 17 transitions were over 10ms So, 10 ms might indeed be sufficient for 99% of devices. But some devices (i.e. this mouse/kb combo) needs between 10 ms and 12 ms in 8% of all wakeups. [1] http://marc.info/?l=linux-usb&m=137714769606183&w=2 http://marc.info/?l=linux-usb&m=137714769606183&w=2

by RyanZAG 13y ago

masklinn 13y ago

> the 10ms is likely sufficient in 99% of cases from TFA: > the time is above 10 ms in about 8% of the remote wakeup events I've tested. So 10ms is sufficient in about 92% of cases, barely more than 9 in 10.

miga 13y ago
I add it to my list of hard-to-replicate-and-locate bugs then.
claudius 13y ago
Which depends on the cases tested by Sharp – as the GP, depending on the hardware you use, you can probably get 100% or 0% (if you try really hard).
raphman 13y ago
This figure is just for two specific devices [1]: >Out of 227 remote wakeup events from a USB mouse and keyboard: > - 163 transitions from RExit to U0 were immediate ( < 1 microsecond) > - 47 transitions from RExit to U0 took under 10 ms > - 17 transitions were over 10ms So, 10 ms might indeed be sufficient for 99% of devices. But some devices (i.e. this mouse/kb combo) needs between 10 ms and 12 ms in 8% of all wakeups. [1] http://marc.info/?l=linux-usb&m=137714769606183&w=2 http://marc.info/?l=linux-usb&m=137714769606183&w=2