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

Objections to CLB-018 proposal.

Expand Messages
  • cliffcopass
    In looking at the CLB-018 proposal, some things came to mind that could be classified as objections to the change. Since I did not see any time allocated to
    Message 1 of 2 , Apr 27, 2009
    • 0 Attachment
      In looking at the CLB-018 proposal, some things came to mind that could be classified as objections to the change. Since I did not see any time allocated to MS/TP discussion at Germantown, I am sending this message.

      In particular:

      If max-master is not writable, but is not set to 127, it may be difficult or impossible to add new MS/TP devices to an existing network without involving all of the companies who have installed existing equipment on the network so that they can adjust their devices to the new maximum MAC address. This is very hostile to the idea of interoperability. On the other hand, max-info-frames can affect network performance, but generally will not prevent a newly added device from either joining the ring or transmitting data.

      In our experience, the (mostly) sequential use of MS/TP MAC addresses along with support for the read multiple service is far more important to performance than the setting of max-master as long as the device doing the poll-for-master has a reasonably tight time-out. Since the MS/TP trunk only allows one poll-for-master from any one device during any single token loop, when the MAC addresses are used sequentially, only the highest address device will be sending poll-for-master (PFM) messages at all, and then only one each time the token goes around (max). If the PFM time-out is close to the specification, this has minimal affect on network performance.

      Cliff Copass
      Johnson Controls, Inc.
    • David Fisher
      Cliff, At the request of the SSPC chairman, all WGs were asked to forego their time at Germantown in favor of addressing the large proposal backlog in plenary
      Message 2 of 2 , Apr 27, 2009
      • 0 Attachment

        Cliff,

        At the request of the SSPC chairman, all WGs were asked to forego their time at Germantown

        in favor of addressing the large proposal backlog in plenary sessions. It was my view that

        there was no pressing business in MSTP-WG that required immediate debate and discussion

        especially considering that several of our proposals are already in queue for SSPC face time.

         

        There will be ample opportunity to discuss CLB-018 and any other MSTP proposals going

        forward.

         

        It seems to me that the nub of this proposal (CLB-018) was to unify the language for these

        two MSTP parameters. As they stand now, implementors are forced to choose between

        writability and performance, when in at least some cases such a compromise isn't

        necessary.

         

        >...it may be difficult or impossible to add new MS/TP devices to an existing network

        >without involving all of the companies who have installed existing equipment on the

        >network so that they can adjust their devices to the new maximum MAC address.

         

        This presumes that the adjustment is difficult, or secret, or intentionally hidden.

        All of those possibilities are indeed hostile to end users and subsequent installers

        (who of course might be competitors). If we take the user-centric view that the method

        of making these changes is clear and open to the owner of the devices, this is

        not such a terrible thing. If they want the "feature" of having poor performance,

        they can always set the MaxMaster to 127 and leave it that way.

         

        >This is very hostile to the idea of interoperability.

         

        Actually it is hostile to competitors if it is intentionally hidden. Once configured,

        the devices will be perfectly interoperable. BACnet does not purport to solve the issues

        of configurability in standard ways.

         

        If ease of configuration is the issue, then a thermostat type of device, which is typical

        of MS/TP devices, that has a local display would be much easier to configure for

        MS/TP on the display than requiring that one carry around a notebook computer with

        485 interface just so that the thermostat can be configured. The current language of

        the standard precludes that kind of feature unless the device also allows writability

        of that Device object property.

         

        >In our experience, the (mostly) sequential use of MS/TP MAC addresses along with

        >support for the read multiple service is far more important to performance than the

        >setting of max-master as long as the device doing the poll-for-master has a reasonably

        >tight time-out. Since the MS/TP trunk only allows one poll-for-master from any one

        >device during any single token loop, when the MAC addresses are used sequentially,

        >only the highest address device will be sending poll-for-master (PFM) messages at all,

        >and then only one each time the token goes around (max). If the PFM time-out is close

        >to the specification, this has minimal affect on network performance.

         

        Actually, every Npoll token cycles (every 50 cycles) the end node does a complete

        collection of PFMs. On a typical network with say 50 nodes on the segment,

        that means that 77 nodes are polled with back-to-back PFMs every 50 cycles.

        Even in the strictest implementation of Tusage_timeout (20ms) that's at least a full second

        of lost network time, every 50 cycles. At 76K that represents 1.5 second out of every 12.

        Many devices elect to use more lenient Tusage_timeout, even though the popular

        wisdom is not to do that. If this is relaxed to say 50ms then the wasted time is more like

        3.85 seconds out of every 15.

         

        In our experience one of the most common performance issues are networks

        where MaxMaster is defaulted to 127 and burns network time pointlessly, just in case

        some day, the maximal number of nodes will be added to a segment.

        David Fisher

        PolarSoft® Inc.

        914 South Aiken Ave

        Pittsburgh PA 15232-2212

        dfisher@...

        www.polarsoft.biz

        412-683-2018

        412-683-5228 fax

         


        From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of cliffcopass
        Sent: Monday, April 27, 2009 12:38 PM
        To: bacnet-mstpwg@yahoogroups.com
        Subject: [bacnet-mstpwg] Objections to CLB-018 proposal.

         




        In looking at the CLB-018 proposal, some things came to mind that could be classified as objections to the change. Since I did not see any time allocated to MS/TP discussion at Germantown , I am sending this message.

        In particular:

        If max-master is not writable, but is not set to 127, it may be difficult or impossible to add new MS/TP devices to an existing network without involving all of the companies who have installed existing equipment on the network so that they can adjust their devices to the new maximum MAC address. This is very hostile to the idea of interoperability. On the other hand, max-info-frames can affect network performance, but generally will not prevent a newly added device from either joining the ring or transmitting data.

        In our experience, the (mostly) sequential use of MS/TP MAC addresses along with support for the read multiple service is far more important to performance than the setting of max-master as long as the device doing the poll-for-master has a reasonably tight time-out. Since the MS/TP trunk only allows one poll-for-master from any one device during any single token loop, when the MAC addresses are used sequentially, only the highest address device will be sending poll-for-master (PFM) messages at all, and then only one each time the token goes around (max). If the PFM time-out is close to the specification, this has minimal affect on network performance.

        Cliff Copass
        Johnson Controls, Inc.

      Your message has been successfully submitted and would be delivered to recipients shortly.