4.2.1.1 In-line device Port Turnaround during Discovery

[prwatE120]

In 4.2.1.1 I have forgotten why there is a special case for requiring that the in-line device NOT return to forward data flow before 5.6ms for messages of command class DISCOVERY_COMMAND.

Can anyone enlighten me ?

I can see that once any start of response from a responder is detected, the in-line device must return to forward data flow no later than 5.8ms, but if there is NO response commencing within 2ms (Table 3-4 Line2) plus an allowance for data delay (4.2.2), cannot an in-line device legimately return to forward data flow, as indeed it must for messages that are NOT of command class DISCOVERY_COMMAND.

Why the special case?

For "normal" operation I assume the return to forward data flow must be within 3ms, in order to allow operation with controllers in accordance with Table 3-2 line 5.

[sblair]

Peter,

I don't recall the exact reasons as I've managed some sleep since then. Looking at it, I can see a couple possible reasons though.

Table 3-4 timings are from Controller EOP to Responder SOP. Since there are no BREAKS this can make things confusing sometimes to detect SOP for the Responder.

You could have multiple responders on a link that respond far enough apart to get multiple discovery responses with no collisions in that time frame.

Because of the possibility for error, I think the safe position for 'dumb' splitters was to remain in this reverse data flow direction for the entire response window to ensure things functioned.

Regardless of the reasons, it doesn't really matter as this is a SHALL requirement so all in-line devices are required to observe the timing requirement.