Jul 19, 2012View Source
Thanks for all the responses.
I think I am spending too much time trying to figure out how to operate on links with lame devices. I started to write out the scenario where increasing the token retry helps (based on several third party devices that have caused us problems in the field), but it became clear that it helped because of the specific flaws in their implementation. And as several people pointed out, increasing the retry count could CAUSE problems in some other scenarios.
So I think that the best approach may be for me to quietly allow this as a non-compliant setting that we can configure in the field as necessary, just as we can stretch Tusage_timeout beyond 100 msec to deal with various implementations that can’t meet that (much less the 15 msec Tusage_delay they are SUPPOSED to meet).
My 2 cents:
My concern with adding in retries for the token is that it makes it easier for lame implementations to slow the whole network down. I would hate to see implementation that always take 3 token passes before they pick it up.
I expect that any device that does a reply-postponed does not go and build the response when it receives the token. The packet is built while it doesn’t have the token. When the token is received, the processing is interrupted and any queued packet is sent out. So it really should not matter that the device is busy building some other response; it is either has the packet ready to go or it doesn’t and the receipt of a token has to interrupt the normally app layer processing.
We had no problem meeting the timing requirements back in 96, why would we have a problem now?
What John is proposing was discussed during a meeting recently (I forget where it was, but I believe it was within context of the new baud rates or making max-master configurable). The idea was, why drop the token and start a (potentially lengthy) PFM cycle when the NS "was just there a few milliseconds ago". I agree with John that a second (or even third) token retry isn't that much more overhead, and it's actually way faster than waiting for a complete PFM cycle.
I don't think it was discarded, but it was tabled as outside of the scope of that particular proposal. I'm all for opening the discussion on this topic again as I think the concept is beneficial to MS/TP.
The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.