5 ms·

If you issue a database query, you have no particular guarantee that it's going to complete in any finite amount of time. At some point, you simply throw up you

If you issue a database query, you have no particular guarantee that it's going to complete in any finite amount of time. At some point, you simply throw up your hands and say it would be unreasonable to wait any longer, and accept the resulting error condition.

acchow 13y ago
No, the spec is saying don't issue a request at all for "at least" 10ms. "At least" because you might have to wait longer, who knows how long, until it's safe to issue a request without triggering a disconnect.
- Zikes 13y ago
  I don't understand that, if devices can take as long as they please then why give the 10ms delay at all? It'd be like telling the hardware engineers "you're not allowed to wake up your device for at least 10ms". Is that just the spec trying to say "this should cover most use cases" and it turns out that's not really the case in practice? Or maybe it's an expected limitation of the technology that it would be nearly impossible to ready a device within 10ms, so the spec is saying it would be pointless to issue a request before that time?
  - sliverstorm 13y ago
    I could simply be budgeting room for the USB core itself to wake.
  - davidp 13y ago
    I imagine it's something along the lines of "ok device, you have 10ms to play with the link before anyone's watching, do what you need to do." For example, electrically detecting the wattage of the power supplied over the link by examining its responses to various inputs. (I have no idea whether that's at all relevant here or if it's even the right part of the stack, I'm just offering an idea of why the device might like the controller to say "I'm not watching right now".)
- nknighthb 13y ago
  > No I don't know who you think you're disagreeing with, but it clearly isn't me.
  - Dylan16807 13y ago
    acchow is disagreeing with your database query likeness. Your comment was effectively saying that it's just waiting until it's ready. And this is clearly something that can be disagreed with. Based on the way this article is worded, it seems like there is no way to check when TRSMRCY is over. Imagine if you were waiting for a database query and if the database wasn't done thinking yet, simply accessing the socket would make the query abort.
    - nknighthb 13y ago
      Your understanding of the problem is in error, and will be corrected by reading the linux-usb thread linked to by the article.
      - Dylan16807 13y ago
        Good! But that doesn't mean your original comment was infallible, since it didn't actually clarify such a thing.
- deleted 13y ago
  [deleted]

acchow 13y ago

No, the spec is saying don't issue a request at all for "at least" 10ms. "At least" because you might have to wait longer, who knows how long, until it's safe to issue a request without triggering a disconnect.

Zikes 13y ago
I don't understand that, if devices can take as long as they please then why give the 10ms delay at all? It'd be like telling the hardware engineers "you're not allowed to wake up your device for at least 10ms". Is that just the spec trying to say "this should cover most use cases" and it turns out that's not really the case in practice? Or maybe it's an expected limitation of the technology that it would be nearly impossible to ready a device within 10ms, so the spec is saying it would be pointless to issue a request before that time?
- sliverstorm 13y ago
  I could simply be budgeting room for the USB core itself to wake.
- davidp 13y ago
  I imagine it's something along the lines of "ok device, you have 10ms to play with the link before anyone's watching, do what you need to do." For example, electrically detecting the wattage of the power supplied over the link by examining its responses to various inputs. (I have no idea whether that's at all relevant here or if it's even the right part of the stack, I'm just offering an idea of why the device might like the controller to say "I'm not watching right now".)
nknighthb 13y ago
> No I don't know who you think you're disagreeing with, but it clearly isn't me.
- Dylan16807 13y ago
  acchow is disagreeing with your database query likeness. Your comment was effectively saying that it's just waiting until it's ready. And this is clearly something that can be disagreed with. Based on the way this article is worded, it seems like there is no way to check when TRSMRCY is over. Imagine if you were waiting for a database query and if the database wasn't done thinking yet, simply accessing the socket would make the query abort.
  - nknighthb 13y ago
    Your understanding of the problem is in error, and will be corrected by reading the linux-usb thread linked to by the article.
    - Dylan16807 13y ago
      Good! But that doesn't mean your original comment was infallible, since it didn't actually clarify such a thing.
deleted 13y ago
[deleted]