Loading ...
Sorry, an error occurred while loading the content.

Should a node be allowed to do more than one token retry?

Expand Messages
  • nomeekgeek
    Clause 9 currently says that when a node passes the token, it waits for NS to begin using it. If no such usage is seen, the node may retry ONCE, after which
    Message 1 of 12 , Jul 17 12:09 PM
    • 0 Attachment
      Clause 9 currently says that when a node passes the token, it waits for NS to begin using it. If no such usage is seen, the node may retry ONCE, after which it uses PFM to find a new NS.

      This seems a bit severe: most nodes will do 3 or more retries at the APDU level - not just one.

      Once a node has been dropped from the rotation, it is locked out until it is offered a PFM. The PFM poll may not come for 50 rotations. I have seen links with large max-info-frames where rotation time is 5 seconds or more, so it could be a looong time.

      If the dropped node uses postponed replies, either always or as part of transferring a segmented reply, it can easily become overwhelmed - other nodes continue to make requests of it, but responses must be queued until it can send previously queued responses.

      It would be trivial in both the standard and most implementations to increase the token retry count.

      Is this worth a formal proposal, or have the Olympians already considered this and discarded the idea?
    • Clifford.H.Copass@jci.com
      My understanding is that one retry is part of the concept of minimizing the chance of multiple tokens being active at once. Since a sender not seeing activity
      Message 2 of 12 , Jul 18 10:57 AM
      • 0 Attachment

        My understanding is that one retry is part of the concept of minimizing the chance of multiple tokens being active at once.  Since a sender not seeing activity could be either a sender fault or a receiver fault, more reties would increase the chance of multiple tokens being active (a good receiver could pass the token while a flaky sender is still retrying its previous token pass).

        If a token pass had a positive acknowledgement back to the sender (and all the extra performance robbing overhead that adds), I would agree with offering more retries.  Lacking that, I am not so sure.

        In my experience, there is a greater chance of being dropped from the token ring than would be considered ideal, but it is seldom a real problem unless the communication reliability is bad enough that there are a lot of data messages being lost also.  Thus when things start to "fall apart", there is a lot that falls apart, not just token passing.

        Cliff Copass
        Johnson Controls, Inc.



        From:"nomeekgeek" <jhartman@...>
        To:bacnet-mstpwg@yahoogroups.com
        Date:07/17/2012 02:09 PM
        Subject:[bacnet-mstpwg] Should a node be allowed to do more than one token retry?





        Clause 9 currently says that when a node passes the token, it waits for NS to begin using it.  If no such usage is seen, the node may retry ONCE, after which it uses PFM to find a new NS.

        This seems a bit severe: most nodes will do 3 or more retries at the APDU level - not just one.

        Once a node has been dropped from the rotation, it is locked out until it is offered a PFM.  The PFM poll may not come for 50 rotations.  I have seen links with large max-info-frames where rotation time is 5 seconds or more, so it could be a looong time.

        If the dropped node uses postponed replies, either always or as part of transferring a segmented reply, it can easily become overwhelmed - other nodes continue to make requests of it, but responses must be queued until it can send previously queued responses.

        It would be trivial in both the standard and most implementations to increase the token retry count.

        Is this worth a formal proposal, or have the Olympians already considered this and discarded the idea?



        ------------------------------------

        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
           
        http://groups.yahoo.com/group/bacnet-mstpwg/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           
        http://groups.yahoo.com/group/bacnet-mstpwg/join
           (Yahoo! ID required)

        <*> To change settings via email:
           bacnet-mstpwg-digest@yahoogroups.com
           bacnet-mstpwg-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
           bacnet-mstpwg-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
           
        http://docs.yahoo.com/info/terms/



      • Coleman Brumley
        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
        Message 3 of 12 , Jul 18 11:06 AM
        • 0 Attachment

          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.

           

          From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
          Sent: Wednesday, July 18, 2012 1:58 PM
          To: bacnet-mstpwg@yahoogroups.com
          Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

           

           


          My understanding is that one retry is part of the concept of minimizing the chance of multiple tokens being active at once.  Since a sender not seeing activity could be either a sender fault or a receiver fault, more reties would increase the chance of multiple tokens being active (a good receiver could pass the token while a flaky sender is still retrying its previous token pass).

          If a token pass had a positive acknowledgement back to the sender (and all the extra performance robbing overhead that adds), I would agree with offering more retries.  Lacking that, I am not so sure.

          In my experience, there is a greater chance of being dropped from the token ring than would be considered ideal, but it is seldom a real problem unless the communication reliability is bad enough that there are a lot of data messages being lost also.  Thus when things start to "fall apart", there is a lot that falls apart, not just token passing.

          Cliff Copass
          Johnson Controls, Inc.


          From:

          "nomeekgeek" <jhartman@...>

          To:

          bacnet-mstpwg@yahoogroups.com

          Date:

          07/17/2012 02:09 PM

          Subject:

          [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

           





          Clause 9 currently says that when a node passes the token, it waits for NS to begin using it.  If no such usage is seen, the node may retry ONCE, after which it uses PFM to find a new NS.

          This seems a bit severe: most nodes will do 3 or more retries at the APDU level - not just one.

          Once a node has been dropped from the rotation, it is locked out until it is offered a PFM.  The PFM poll may not come for 50 rotations.  I have seen links with large max-info-frames where rotation time is 5 seconds or more, so it could be a looong time.

          If the dropped node uses postponed replies, either always or as part of transferring a segmented reply, it can easily become overwhelmed - other nodes continue to make requests of it, but responses must be queued until it can send previously queued responses.

          It would be trivial in both the standard and most implementations to increase the token retry count.

          Is this worth a formal proposal, or have the Olympians already considered this and discarded the idea?



          ------------------------------------

          Yahoo! Groups Links

          <*> To visit your group on the web, go to:
             
          http://groups.yahoo.com/group/bacnet-mstpwg/

          <*> Your email settings:
             Individual Email | Traditional

          <*> To change settings online go to:
             
          http://groups.yahoo.com/group/bacnet-mstpwg/join
             (Yahoo! ID required)

          <*> To change settings via email:
             bacnet-mstpwg-digest@yahoogroups.com
             bacnet-mstpwg-fullfeatured@yahoogroups.com

          <*> To unsubscribe from this group, send an email to:
             bacnet-mstpwg-unsubscribe@yahoogroups.com

          <*> Your use of Yahoo! Groups is subject to:
             
          http://docs.yahoo.com/info/terms/


        • Carl Neilson
          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
          Message 4 of 12 , Jul 18 2:30 PM
          • 0 Attachment

            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?


            Carl

             

            From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Coleman Brumley
            Sent: Wednesday, July 18, 2012 11:06 AM
            To: bacnet-mstpwg@yahoogroups.com
            Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

             

             

            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.

             

            From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
            Sent: Wednesday, July 18, 2012 1:58 PM
            To: bacnet-mstpwg@yahoogroups.com
            Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

             

             


            My understanding is that one retry is part of the concept of minimizing the chance of multiple tokens being active at once.  Since a sender not seeing activity could be either a sender fault or a receiver fault, more reties would increase the chance of multiple tokens being active (a good receiver could pass the token while a flaky sender is still retrying its previous token pass).

            If a token pass had a positive acknowledgement back to the sender (and all the extra performance robbing overhead that adds), I would agree with offering more retries.  Lacking that, I am not so sure.

            In my experience, there is a greater chance of being dropped from the token ring than would be considered ideal, but it is seldom a real problem unless the communication reliability is bad enough that there are a lot of data messages being lost also.  Thus when things start to "fall apart", there is a lot that falls apart, not just token passing.

            Cliff Copass
            Johnson Controls, Inc.



            From:

            "nomeekgeek" <jhartman@...>

            To:

            bacnet-mstpwg@yahoogroups.com

            Date:

            07/17/2012 02:09 PM

            Subject:

            [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

             





            Clause 9 currently says that when a node passes the token, it waits for NS to begin using it.  If no such usage is seen, the node may retry ONCE, after which it uses PFM to find a new NS.

            This seems a bit severe: most nodes will do 3 or more retries at the APDU level - not just one.

            Once a node has been dropped from the rotation, it is locked out until it is offered a PFM.  The PFM poll may not come for 50 rotations.  I have seen links with large max-info-frames where rotation time is 5 seconds or more, so it could be a looong time.

            If the dropped node uses postponed replies, either always or as part of transferring a segmented reply, it can easily become overwhelmed - other nodes continue to make requests of it, but responses must be queued until it can send previously queued responses.

            It would be trivial in both the standard and most implementations to increase the token retry count.

            Is this worth a formal proposal, or have the Olympians already considered this and discarded the idea?



            ------------------------------------

            Yahoo! Groups Links

            <*> To visit your group on the web, go to:
               
            http://groups.yahoo.com/group/bacnet-mstpwg/

            <*> Your email settings:
               Individual Email | Traditional

            <*> To change settings online go to:
               
            http://groups.yahoo.com/group/bacnet-mstpwg/join
               (Yahoo! ID required)

            <*> To change settings via email:
               bacnet-mstpwg-digest@yahoogroups.com
               bacnet-mstpwg-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
               bacnet-mstpwg-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
               
            http://docs.yahoo.com/info/terms/



          • Coleman Brumley
            Carl, I see your point. In my experience, it s not a matter of meeting the timing. When I ve seen this occur, it s usually because of some comm. error
            Message 5 of 12 , Jul 18 3:14 PM
            • 0 Attachment

              Carl,

               

              I see your point.

               

              In my experience, it's not a matter of meeting the timing. When I've seen this occur, it's usually because of some comm. error (framing, parity, collision, pick your favorite) which causes the receiving node to "miss" the token and for whatever reason sends the receiving device into a the incorrect state, then the sending guy retries and now the retry is received when the receiver isn't ready for it. So, it's more of case of "Gee, I wish the sending device had retried one more time." Sorry, but I don't have the exact transitions handy that can cause this.

               

              Anyway, when we talked about it, it seemed like a good idea.  That's all I'm saying.

               

              Coleman

               

              From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Carl Neilson
              Sent: Wednesday, July 18, 2012 5:30 PM
              To: bacnet-mstpwg@yahoogroups.com
              Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

               

               

              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?


              Carl

               

              From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Coleman Brumley
              Sent: Wednesday, July 18, 2012 11:06 AM
              To: bacnet-mstpwg@yahoogroups.com
              Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

               

               

              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.

               

              From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
              Sent: Wednesday, July 18, 2012 1:58 PM
              To: bacnet-mstpwg@yahoogroups.com
              Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

               

               


              My understanding is that one retry is part of the concept of minimizing the chance of multiple tokens being active at once.  Since a sender not seeing activity could be either a sender fault or a receiver fault, more reties would increase the chance of multiple tokens being active (a good receiver could pass the token while a flaky sender is still retrying its previous token pass).

              If a token pass had a positive acknowledgement back to the sender (and all the extra performance robbing overhead that adds), I would agree with offering more retries.  Lacking that, I am not so sure.

              In my experience, there is a greater chance of being dropped from the token ring than would be considered ideal, but it is seldom a real problem unless the communication reliability is bad enough that there are a lot of data messages being lost also.  Thus when things start to "fall apart", there is a lot that falls apart, not just token passing.

              Cliff Copass
              Johnson Controls, Inc.




              From:

              "nomeekgeek" <jhartman@...>

              To:

              bacnet-mstpwg@yahoogroups.com

              Date:

              07/17/2012 02:09 PM

              Subject:

              [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

               





              Clause 9 currently says that when a node passes the token, it waits for NS to begin using it.  If no such usage is seen, the node may retry ONCE, after which it uses PFM to find a new NS.

              This seems a bit severe: most nodes will do 3 or more retries at the APDU level - not just one.

              Once a node has been dropped from the rotation, it is locked out until it is offered a PFM.  The PFM poll may not come for 50 rotations.  I have seen links with large max-info-frames where rotation time is 5 seconds or more, so it could be a looong time.

              If the dropped node uses postponed replies, either always or as part of transferring a segmented reply, it can easily become overwhelmed - other nodes continue to make requests of it, but responses must be queued until it can send previously queued responses.

              It would be trivial in both the standard and most implementations to increase the token retry count.

              Is this worth a formal proposal, or have the Olympians already considered this and discarded the idea?



              ------------------------------------

              Yahoo! Groups Links

              <*> To visit your group on the web, go to:
                 
              http://groups.yahoo.com/group/bacnet-mstpwg/

              <*> Your email settings:
                 Individual Email | Traditional

              <*> To change settings online go to:
                 
              http://groups.yahoo.com/group/bacnet-mstpwg/join
                 (Yahoo! ID required)

              <*> To change settings via email:
                 bacnet-mstpwg-digest@yahoogroups.com
                 bacnet-mstpwg-fullfeatured@yahoogroups.com

              <*> To unsubscribe from this group, send an email to:
                 bacnet-mstpwg-unsubscribe@yahoogroups.com

              <*> Your use of Yahoo! Groups is subject to:
                 
              http://docs.yahoo.com/info/terms/




            • Hartman, John
              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
              Message 6 of 12 , Jul 19 7:44 AM
              • 0 Attachment

                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).

                 

                From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Carl Neilson
                Sent: Wednesday, July 18, 2012 4:30 PM
                To: bacnet-mstpwg@yahoogroups.com
                Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

                 




                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?


                Carl

                 

                From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Coleman Brumley
                Sent: Wednesday, July 18, 2012 11:06 AM
                To: bacnet-mstpwg@yahoogroups.com
                Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

                 

                 

                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.

                 

                From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
                Sent: Wednesday, July 18, 2012 1:58 PM
                To: bacnet-mstpwg@yahoogroups.com
                Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

                 

                 


                My understanding is that one retry is part of the concept of minimizing the chance of multiple tokens being active at once.  Since a sender not seeing activity could be either a sender fault or a receiver fault, more reties would increase the chance of multiple tokens being active (a good receiver could pass the token while a flaky sender is still retrying its previous token pass).

                If a token pass had a positive acknowledgement back to the sender (and all the extra performance robbing overhead that adds), I would agree with offering more retries.  Lacking that, I am not so sure.

                In my experience, there is a greater chance of being dropped from the token ring than would be considered ideal, but it is seldom a real problem unless the communication reliability is bad enough that there are a lot of data messages being lost also.  Thus when things start to "fall apart", there is a lot that falls apart, not just token passing.

                Cliff Copass
                Johnson Controls, Inc.


                From:

                "nomeekgeek" <jhartman@...>

                To:

                bacnet-mstpwg@yahoogroups.com

                Date:

                07/17/2012 02:09 PM

                Subject:

                [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

                 





                Clause 9 currently says that when a node passes the token, it waits for NS to begin using it.  If no such usage is seen, the node may retry ONCE, after which it uses PFM to find a new NS.

                This seems a bit severe: most nodes will do 3 or more retries at the APDU level - not just one.

                Once a node has been dropped from the rotation, it is locked out until it is offered a PFM.  The PFM poll may not come for 50 rotations.  I have seen links with large max-info-frames where rotation time is 5 seconds or more, so it could be a looong time.

                If the dropped node uses postponed replies, either always or as part of transferring a segmented reply, it can easily become overwhelmed - other nodes continue to make requests of it, but responses must be queued until it can send previously queued responses.

                It would be trivial in both the standard and most implementations to increase the token retry count.

                Is this worth a formal proposal, or have the Olympians already considered this and discarded the idea?



                ------------------------------------

                Yahoo! Groups Links

                <*> To visit your group on the web, go to:
                   
                http://groups.yahoo.com/group/bacnet-mstpwg/

                <*> Your email settings:
                   Individual Email | Traditional

                <*> To change settings online go to:
                   
                http://groups.yahoo.com/group/bacnet-mstpwg/join
                   (Yahoo! ID required)

                <*> To change settings via email:
                   bacnet-mstpwg-digest@yahoogroups.com
                   bacnet-mstpwg-fullfeatured@yahoogroups.com

                <*> To unsubscribe from this group, send an email to:
                   bacnet-mstpwg-unsubscribe@yahoogroups.com

                <*> Your use of Yahoo! Groups is subject to:
                   
                http://docs.yahoo.com/info/terms/


                 







                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.
              • Steve Karg
                Hi MS/TP working group! Since we are discussing Token retries... I received some comments a week ago from an engineer (Bill) at Siemens (via Bernhard) on the
                Message 7 of 12 , Jul 23 9:01 AM
                • 0 Attachment
                  Hi MS/TP working group!

                  Since we are discussing Token retries...

                  I received some comments a week ago from an engineer (Bill) at Siemens
                  (via Bernhard) on the Zero Config MS/TP proposal that is sitting in
                  SSPC. He had some of the usual critique that we have already
                  discussed in our working group, but he also had a small suggestion.

                  He suggested having the ZeroConfiguration nodes only respond to the
                  Token on the Token Retry, allowing any legitimate fixed MAC nodes
                  access to the first Token. My thoughts were that this practice would
                  make the MS/TP network sluggish and prone to dropped Tokens for
                  ZeroConfiguration nodes, but it would provide better protection for
                  fixed MAC nodes (it could even offer the full range of Master Node MAC
                  addresses for ZeroConfiguration nodes).

                  Thoughts?

                  Steve
                  --
                  http://steve.kargs.net/
                • Clifford.H.Copass@jci.com
                  I agree with the sluggish comment and actually believe that is an understatement. Increasing susceptibility to dropping tokens is also true. To even think
                  Message 8 of 12 , Jul 24 5:55 AM
                  • 0 Attachment

                    I agree with the "sluggish" comment and actually believe that is an understatement.  Increasing susceptibility to dropping tokens is also true.

                    To even think about this approach (which I am not convinced is the best approach overall), it would need to be limited to occasional use - such as during Zero Configuration node startup.  I don't think it should even be considered for normal operation.  We should be looking for ways to improve MS/TP performance, not thinking about changes that would cripple it.

                    Cliff Copass
                    Johnson Controls, Inc.



                    From:Steve Karg <steve@...>
                    To:bacnet-mstpwg@yahoogroups.com
                    Date:07/23/2012 11:02 AM
                    Subject:Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?





                    Hi MS/TP working group!

                    Since we are discussing Token retries...

                    I received some comments a week ago from an engineer (Bill) at Siemens
                    (via Bernhard) on the Zero Config MS/TP proposal that is sitting in
                    SSPC.  He had some of the usual critique that we have already
                    discussed in our working group, but he also had a small suggestion.

                    He suggested having the ZeroConfiguration nodes only respond to the
                    Token on the Token Retry, allowing any legitimate fixed MAC nodes
                    access to the first Token.  My thoughts were that this practice would
                    make the MS/TP network sluggish and prone to dropped Tokens for
                    ZeroConfiguration nodes, but it would provide better protection for
                    fixed MAC nodes (it could even offer the full range of Master Node MAC
                    addresses for ZeroConfiguration nodes).

                    Thoughts?

                    Steve
                    --
                    http://steve.kargs.net/


                    ------------------------------------

                    Yahoo! Groups Links

                    <*> To visit your group on the web, go to:
                       
                    http://groups.yahoo.com/group/bacnet-mstpwg/

                    <*> Your email settings:
                       Individual Email | Traditional

                    <*> To change settings online go to:
                       
                    http://groups.yahoo.com/group/bacnet-mstpwg/join
                       (Yahoo! ID required)

                    <*> To change settings via email:
                       bacnet-mstpwg-digest@yahoogroups.com
                       bacnet-mstpwg-fullfeatured@yahoogroups.com

                    <*> To unsubscribe from this group, send an email to:
                       bacnet-mstpwg-unsubscribe@yahoogroups.com

                    <*> Your use of Yahoo! Groups is subject to:
                       
                    http://docs.yahoo.com/info/terms/



                  • Hartman, John
                    I don t think waiting for token retry would make ZeroConfig any safer : if there is a device with a fixed MAC at the chosen address, that device should have
                    Message 9 of 12 , Jul 25 10:24 AM
                    • 0 Attachment
                      I don't think waiting for token retry would make ZeroConfig any "safer": if there is a device with a fixed MAC at the chosen address, that device should have answered the PFM as well.

                      You might consider making the ZeroConfig node wait for MORE THAN ONE PFM of its chosen address before it takes the token. That would take longer (several PFM cycles), but in my view the delay might be a good thing: if a bunch of nodes from various vendors have just powered up after a building power event, they are likely to have different boot times. Waiting longer before "stealing" an address gives all nodes more time to boot up monitor or join the link under their pre-assigned addresses before the ZeroConfig free for all.



                      I have a number of problems with the proposed ZeroConfig in general (I like the you-are proposal much better):

                      1) The algorithm stretches the current state-machine description beyond the breaking point. The Extended Frame addendum makes things complicated, but ZeroConfig is beyond that. If we want to go with ZeroConfig, I think we need a new method of description. Maybe pseudo-code. There must be other standards with a format we could use.

                      2) Once a node starts talking at an address, my experience leads me to be skeptical of a node reliably detecting that there is someone else at the same address. If the node has any kind of protection circuitry (series PTCs or the like), it typically won't see conflicts while it is transmitting. When a token is sent to an address, any and all nodes that think they own the address will begin talking more or less at once. When they send, the recipient(s) MAY see CRC errors due to collision. Or they may see the message from the node next door swamping out the message from the guy at the other end of the long cable.

                      I presume that the purpose of sending the Test message is to hope for a collision. I guess we would get a chance to see how many people have actually IMPLEMENTED Test...


                      I suspect that you already have an implementation of this running. And with a bunch of devices from one vendor, it might even work pretty well. But with nodes from various vendors I am skeptical.


                      -----Original Message-----
                      From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Steve Karg
                      Sent: Monday, July 23, 2012 11:01 AM
                      To: bacnet-mstpwg@yahoogroups.com
                      Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

                      Hi MS/TP working group!

                      Since we are discussing Token retries...

                      I received some comments a week ago from an engineer (Bill) at Siemens
                      (via Bernhard) on the Zero Config MS/TP proposal that is sitting in
                      SSPC. He had some of the usual critique that we have already
                      discussed in our working group, but he also had a small suggestion.

                      He suggested having the ZeroConfiguration nodes only respond to the
                      Token on the Token Retry, allowing any legitimate fixed MAC nodes
                      access to the first Token. My thoughts were that this practice would
                      make the MS/TP network sluggish and prone to dropped Tokens for
                      ZeroConfiguration nodes, but it would provide better protection for
                      fixed MAC nodes (it could even offer the full range of Master Node MAC
                      addresses for ZeroConfiguration nodes).

                      Thoughts?

                      Steve
                      --
                      http://steve.kargs.net/


                      ------------------------------------

                      Yahoo! Groups Links





                      ________________________________

                      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.
                    • Hartman, John
                      Immediately after hitting Send , it occurred to me that use-token-on-retry only during the ZeroConfig startup as Cliff suggests DOES have the advantage over
                      Message 10 of 12 , Jul 25 10:41 AM
                      • 0 Attachment

                        Immediately after hitting “Send”, it occurred to me that use-token-on-retry only during the ZeroConfig startup as Cliff suggests DOES have the advantage over multiple PFMs in that it means that a ZeroConfig node is less likely to step on a fixed-mac node.

                         

                        Does nothing to eliminate the chance of two ZeroConfig nodes choosing the same address and stepping on EACH OTHER, however.  Not clear how BTL could test that the address is chosen “randomly”, so the odds of competition for a given address seem high.

                         

                        The more I think about this, the more I like the You-Are service.

                         

                         

                        From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
                        Sent: Tuesday, July 24, 2012 7:56 AM
                        To: bacnet-mstpwg@yahoogroups.com
                        Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

                         




                        I agree with the "sluggish" comment and actually believe that is an understatement.  Increasing susceptibility to dropping tokens is also true.

                        To even think about this approach (which I am not convinced is the best approach overall), it would need to be limited to occasional use - such as during Zero Configuration node startup.  I don't think it should even be considered for normal operation.  We should be looking for ways to improve MS/TP performance, not thinking about changes that would cripple it.

                        Cliff Copass
                        Johnson Controls, Inc.


                        From:

                        Steve Karg <steve@...>

                        To:

                        bacnet-mstpwg@yahoogroups.com

                        Date:

                        07/23/2012 11:02 AM

                        Subject:

                        Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?

                         





                        Hi MS/TP working group!

                        Since we are discussing Token retries...

                        I received some comments a week ago from an engineer (Bill) at Siemens
                        (via Bernhard) on the Zero Config MS/TP proposal that is sitting in
                        SSPC.  He had some of the usual critique that we have already
                        discussed in our working group, but he also had a small suggestion.

                        He suggested having the ZeroConfiguration nodes only respond to the
                        Token on the Token Retry, allowing any legitimate fixed MAC nodes
                        access to the first Token.  My thoughts were that this practice would
                        make the MS/TP network sluggish and prone to dropped Tokens for
                        ZeroConfiguration nodes, but it would provide better protection for
                        fixed MAC nodes (it could even offer the full range of Master Node MAC
                        addresses for ZeroConfiguration nodes).

                        Thoughts?

                        Steve
                        --
                        http://steve.kargs.net/


                        ------------------------------------

                        Yahoo! Groups Links

                        <*> To visit your group on the web, go to:
                           
                        http://groups.yahoo.com/group/bacnet-mstpwg/

                        <*> Your email settings:
                           Individual Email | Traditional

                        <*> To change settings online go to:
                           
                        http://groups.yahoo.com/group/bacnet-mstpwg/join
                           (Yahoo! ID required)

                        <*> To change settings via email:
                           bacnet-mstpwg-digest@yahoogroups.com
                           bacnet-mstpwg-fullfeatured@yahoogroups.com

                        <*> To unsubscribe from this group, send an email to:
                           bacnet-mstpwg-unsubscribe@yahoogroups.com

                        <*> Your use of Yahoo! Groups is subject to:
                           
                        http://docs.yahoo.com/info/terms/









                        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.
                      • kerlyn2001
                        Rather than increasing the number of token retries, would it make sense (in the case of a lost token) for ThisStation to begin the PFM cycle at NS rather than
                        Message 11 of 12 , Oct 4, 2012
                        • 0 Attachment
                          Rather than increasing the number of token retries, would it make sense (in the
                          case of a lost token) for ThisStation to begin the PFM cycle at NS rather than
                          NS+1? This would allow just a little extra time for NS to recover from its funk
                          w/o adding to the overall token rotation time. I'll appeal to the institutional
                          memory to see if this has been suggested before.

                          -K-

                          --- In bacnet-mstpwg@yahoogroups.com, "Hartman, John" <jhartman@...> wrote:
                          >
                          > 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).
                          >
                          > From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Carl Neilson
                          > Sent: Wednesday, July 18, 2012 4:30 PM
                          > To: bacnet-mstpwg@yahoogroups.com
                          > Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
                          >
                          >
                          >
                          >
                          > 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?
                          >
                          > Carl
                          >
                          > From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Coleman Brumley
                          > Sent: Wednesday, July 18, 2012 11:06 AM
                          > To: bacnet-mstpwg@yahoogroups.com
                          > Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
                          >
                          >
                          > 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.
                          >
                          > From: bacnet-mstpwg@yahoogroups.com<mailto:bacnet-mstpwg@yahoogroups.com> [mailto:bacnet-mstpwg@yahoogroups.com]<mailto:[mailto:bacnet-mstpwg@yahoogroups.com]> On Behalf Of Clifford.H.Copass@...<mailto:Clifford.H.Copass@...>
                          > Sent: Wednesday, July 18, 2012 1:58 PM
                          > To: bacnet-mstpwg@yahoogroups.com<mailto:bacnet-mstpwg@yahoogroups.com>
                          > Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
                          >
                          >
                          >
                          > My understanding is that one retry is part of the concept of minimizing the chance of multiple tokens being active at once. Since a sender not seeing activity could be either a sender fault or a receiver fault, more reties would increase the chance of multiple tokens being active (a good receiver could pass the token while a flaky sender is still retrying its previous token pass).
                          >
                          > If a token pass had a positive acknowledgement back to the sender (and all the extra performance robbing overhead that adds), I would agree with offering more retries. Lacking that, I am not so sure.
                          >
                          > In my experience, there is a greater chance of being dropped from the token ring than would be considered ideal, but it is seldom a real problem unless the communication reliability is bad enough that there are a lot of data messages being lost also. Thus when things start to "fall apart", there is a lot that falls apart, not just token passing.
                          >
                          > Cliff Copass
                          > Johnson Controls, Inc.
                          >
                          >
                          > From:
                          >
                          > "nomeekgeek" <jhartman@...<mailto:jhartman@...>>
                          >
                          > To:
                          >
                          > bacnet-mstpwg@yahoogroups.com<mailto:bacnet-mstpwg@yahoogroups.com>
                          >
                          > Date:
                          >
                          > 07/17/2012 02:09 PM
                          >
                          > Subject:
                          >
                          > [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
                          >
                          >
                          >
                          >
                          > ________________________________
                          >
                          >
                          >
                          > Clause 9 currently says that when a node passes the token, it waits for NS to begin using it. If no such usage is seen, the node may retry ONCE, after which it uses PFM to find a new NS.
                          >
                          > This seems a bit severe: most nodes will do 3 or more retries at the APDU level - not just one.
                          >
                          > Once a node has been dropped from the rotation, it is locked out until it is offered a PFM. The PFM poll may not come for 50 rotations. I have seen links with large max-info-frames where rotation time is 5 seconds or more, so it could be a looong time.
                          >
                          > If the dropped node uses postponed replies, either always or as part of transferring a segmented reply, it can easily become overwhelmed - other nodes continue to make requests of it, but responses must be queued until it can send previously queued responses.
                          >
                          > It would be trivial in both the standard and most implementations to increase the token retry count.
                          >
                          > Is this worth a formal proposal, or have the Olympians already considered this and discarded the idea?
                          >
                          >
                          >
                          > ------------------------------------
                          >
                          > Yahoo! Groups Links
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          >
                          > ________________________________
                          >
                          > 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.
                          >
                        • Hartman, John
                          I don t see how that differs much from just doing another token retry. Clause 9 specifies the same timeout (Tusage_delay, 15 msec) for a node to begin using
                          Message 12 of 12 , Oct 8, 2012
                          • 0 Attachment
                            I don't see how that differs much from just doing another token retry. Clause 9 specifies the same timeout (Tusage_delay, 15 msec) for a node to begin using the token or respond to a PFM; and the same timeout (Tusage_timeout, 20 to 100 msec) for the sender of the token or PFM to time out.

                            So the funk-ridden device would have the same amount of time to respond to either frame.

                            Actually, since maintenance PFMs are common and token retries are (hopefully) rare, some Trane devices use a longer timeout (near 100 msec) for token retries and a shorter timeout (30 to 50 msec) on PFMs. That way, if the device is just SLOW in using the token (as opposed to having not seen the token at all), we give it more time in order to avoid the pain of dropping a device from the rotation. Using a 100 msec timeout on PFM could adversely affect the link bandwidth unless max-masters is kept tight, which isn't always possible or desirable.

                            -----Original Message-----
                            From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
                            Sent: Thursday, October 04, 2012 12:36 PM
                            To: bacnet-mstpwg@yahoogroups.com
                            Subject: [bacnet-mstpwg] Re: Should a node be allowed to do more than one token retry?

                            Rather than increasing the number of token retries, would it make sense (in the
                            case of a lost token) for ThisStation to begin the PFM cycle at NS rather than
                            NS+1? This would allow just a little extra time for NS to recover from its funk
                            w/o adding to the overall token rotation time. I'll appeal to the institutional
                            memory to see if this has been suggested before.

                            -K-

                            --- In bacnet-mstpwg@yahoogroups.com, "Hartman, John" <jhartman@...> wrote:
                            >
                            > 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).
                            >
                            > From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Carl Neilson
                            > Sent: Wednesday, July 18, 2012 4:30 PM
                            > To: bacnet-mstpwg@yahoogroups.com
                            > Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
                            >
                            >
                            >
                            >
                            > 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?
                            >
                            > Carl
                            >
                            > From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Coleman Brumley
                            > Sent: Wednesday, July 18, 2012 11:06 AM
                            > To: bacnet-mstpwg@yahoogroups.com
                            > Subject: RE: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
                            >
                            >
                            > 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.
                            >
                            > From: bacnet-mstpwg@yahoogroups.com<mailto:bacnet-mstpwg@yahoogroups.com> [mailto:bacnet-mstpwg@yahoogroups.com]<mailto:[mailto:bacnet-mstpwg@yahoogroups.com]> On Behalf Of Clifford.H.Copass@...<mailto:Clifford.H.Copass@...>
                            > Sent: Wednesday, July 18, 2012 1:58 PM
                            > To: bacnet-mstpwg@yahoogroups.com<mailto:bacnet-mstpwg@yahoogroups.com>
                            > Subject: Re: [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
                            >
                            >
                            >
                            > My understanding is that one retry is part of the concept of minimizing the chance of multiple tokens being active at once. Since a sender not seeing activity could be either a sender fault or a receiver fault, more reties would increase the chance of multiple tokens being active (a good receiver could pass the token while a flaky sender is still retrying its previous token pass).
                            >
                            > If a token pass had a positive acknowledgement back to the sender (and all the extra performance robbing overhead that adds), I would agree with offering more retries. Lacking that, I am not so sure.
                            >
                            > In my experience, there is a greater chance of being dropped from the token ring than would be considered ideal, but it is seldom a real problem unless the communication reliability is bad enough that there are a lot of data messages being lost also. Thus when things start to "fall apart", there is a lot that falls apart, not just token passing.
                            >
                            > Cliff Copass
                            > Johnson Controls, Inc.
                            >
                            >
                            > From:
                            >
                            > "nomeekgeek" <jhartman@...<mailto:jhartman@...>>
                            >
                            > To:
                            >
                            > bacnet-mstpwg@yahoogroups.com<mailto:bacnet-mstpwg@yahoogroups.com>
                            >
                            > Date:
                            >
                            > 07/17/2012 02:09 PM
                            >
                            > Subject:
                            >
                            > [bacnet-mstpwg] Should a node be allowed to do more than one token retry?
                            >
                            >
                            >
                            >
                            > ________________________________
                            >
                            >
                            >
                            > Clause 9 currently says that when a node passes the token, it waits for NS to begin using it. If no such usage is seen, the node may retry ONCE, after which it uses PFM to find a new NS.
                            >
                            > This seems a bit severe: most nodes will do 3 or more retries at the APDU level - not just one.
                            >
                            > Once a node has been dropped from the rotation, it is locked out until it is offered a PFM. The PFM poll may not come for 50 rotations. I have seen links with large max-info-frames where rotation time is 5 seconds or more, so it could be a looong time.
                            >
                            > If the dropped node uses postponed replies, either always or as part of transferring a segmented reply, it can easily become overwhelmed - other nodes continue to make requests of it, but responses must be queued until it can send previously queued responses.
                            >
                            > It would be trivial in both the standard and most implementations to increase the token retry count.
                            >
                            > Is this worth a formal proposal, or have the Olympians already considered this and discarded the idea?
                            >
                            >
                            >
                            > ------------------------------------
                            >
                            > Yahoo! Groups Links
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            > ________________________________
                            >
                            > 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.
                            >




                            ------------------------------------

                            Yahoo! Groups Links





                            ________________________________

                            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.
                          Your message has been successfully submitted and would be delivered to recipients shortly.