3 ms·

That interpretation doesn't seem to make much sense though, because there would be no point in specifying the 10ms at all - it means nothing, and doesn't put an

by caf 13y ago

That interpretation doesn't seem to make much sense though, because there would be no point in specifying the 10ms at all - it means nothing, and doesn't put any restrictions on anyone.

delinka 13y ago
It does indeed put restrictions on the software author not to expect hardware to be ready in less than 10ms. Perhaps the specification is somewhat nonsensical. That does not permit the software author to create restrictive interpretations. IMHO, it informs the software author that flexibility should be allowed in their code.
- caf 13y ago
  But under your interpretation, the software can't expect the hardware to be ready in less than 100ms, 10s or 10 minutes either - so the value "10ms" is meaningless.
  - delinka 13y ago
    Indeed. And the software should continue to wait for readiness or decide when to give up. Giving up at the 10ms mark isn't against spec, it's just not prudent.
shabble 13y ago
An alternative interpretation is that by forbidding the host from issuing any commands for that initial period, the target device could (if it happens to be expedient) do all sorts of otherwise spec-violating things, safe in the knowledge that nobody will ever find out[2]. After that grace period, it has to go back to playing by the rules, but doesn't necessarily have to be operational. Whether or not it's operational yet can be queried[1] (after the first timeout), and a decision to use it, retry the query after a fixed or variable additional fallback, or mark it as failed. A better spec might recommend or mandate values for fallback quanta and repetitions, or a maximum bound on the delay, rather than leaving it vendor-gets-to-choose. I didn't look too hard, but a decently marked timing diagram would be nice, and might make it easier to spot the unbounded nature of it, rather than having to cross-reference the inline '10ms' value with the minmax table elsewhere. [1] At least, if I understand it correctly. If accessing the status info uses the same mechanism as general traffic, it's obviously subject to the flaw described, and this interpretation is wrong. [2] c.f. https://en.wikipedia.org/wiki/Don%27t-care_term https://en.wikipedia.org/wiki/Don%27t-care_term and perhaps https://en.wikipedia.org/wiki/Virtual_particle https://en.wikipedia.org/wiki/Virtual_particle

by caf 13y ago

That interpretation doesn't seem to make much sense though, because there would be no point in specifying the 10ms at all - it means nothing, and doesn't put any restrictions on anyone.

delinka 13y ago

It does indeed put restrictions on the software author not to expect hardware to be ready in less than 10ms. Perhaps the specification is somewhat nonsensical. That does not permit the software author to create restrictive interpretations. IMHO, it informs the software author that flexibility should be allowed in their code.

caf 13y ago
But under your interpretation, the software can't expect the hardware to be ready in less than 100ms, 10s or 10 minutes either - so the value "10ms" is meaningless.
- delinka 13y ago
  Indeed. And the software should continue to wait for readiness or decide when to give up. Giving up at the 10ms mark isn't against spec, it's just not prudent.

shabble 13y ago

An alternative interpretation is that by forbidding the host from issuing any commands for that initial period, the target device could (if it happens to be expedient) do all sorts of otherwise spec-violating things, safe in the knowledge that nobody will ever find out[2]. After that grace period, it has to go back to playing by the rules, but doesn't necessarily have to be operational. Whether or not it's operational yet can be queried[1] (after the first timeout), and a decision to use it, retry the query after a fixed or variable additional fallback, or mark it as failed. A better spec might recommend or mandate values for fallback quanta and repetitions, or a maximum bound on the delay, rather than leaving it vendor-gets-to-choose. I didn't look too hard, but a decently marked timing diagram would be nice, and might make it easier to spot the unbounded nature of it, rather than having to cross-reference the inline '10ms' value with the minmax table elsewhere. [1] At least, if I understand it correctly. If accessing the status info uses the same mechanism as general traffic, it's obviously subject to the flaw described, and this interpretation is wrong. [2] c.f. https://en.wikipedia.org/wiki/Don%27t-care_term https://en.wikipedia.org/wiki/Don%27t-care_term and perhaps https://en.wikipedia.org/wiki/Virtual_particle https://en.wikipedia.org/wiki/Virtual_particle