HVAC-Talk: Heating, Air & Refrigeration Discussion banner
Cancel
Create thread New Forums

Free BACnet Widget/Tool- MSTP Speed Estimator

Tags
bacnet is sweet free prog ms/tp tools
Jump to Latest
1 - 20 of 50 Posts
B

BACnet

· Banned
Joined
·
2,457 Posts
Discussion starter · #1 · (Edited by Moderator)
I finally got a few free hours this weekend and I decided to build and release another free BACnet tool! Updated Link.
I know a number of you have mentioned that you have used my BACnet TimeSync tool, and I hope you will all find this one as useful. This tool allows you to specify the details of your MS/TP network and then run a simulation that shows what you can expect in the way of network speed.

You can easily adjust parameters such as baud rate, max master, the number of master and slave units, the average bytes in a data message, and many more. Then by running the simulation you are able to see the effect of those decisions on the number of points you can expect the OWS could pull from the network every second.

Please note that this is just the first release of this program. I fully intend to refine this project with more variables/settings as it matures. But it is fundamentally sound and worthy of an initial release.

Here's a screenshot of the program:

Image


Please let me know what you think!

-BACnet

P.S. If you're interested in the free TimeSync tool, the thread for that is here.
 
Discussion starter · #4 ·
Thanks for the vote of confidence!

I think that this tool will serve as a good guideline both when people are commissioning and when they are troubleshooting BACnet networks.

I can't tell you how many times people say things like "it takes at least 15 seconds to get the data to the front end." When in reality what they mean is that the front end is tied up and unable to ask the question for 14.8 seconds and the answer is returned in 0.2 seconds.

Even though it was not my initial intent, this program also helps to suggest ways to optimize the network. That's why the Max_Master setting is not directly writeable. By answering the questions above the MAX_Master setting it will set the value for you. The questions are: how many units are there, how many need the token (presumably for COV or alarming) and how many open slots you want for plugging in new BACnet devices. By being forced to enter those premises instead of blindly setting Max_Master you end up with a highly optimized network right from the start.

Soon I hope to post some graphs of the ramifications of these settings. They should be an even easier tool to use in the field as you should be able to tell immediately just how much unused capacity is in any given BACnet network. But I want to refine the program a bit more before that- Specifically, I want to take into account the different header sizes between local peer-to-peer messages vs those that come through a router. Minor tweaks like that shouldn't effect the overall results that the simulator creates, but it might give me a few more decimal places of precision in my numbers.

Take a look at the text file it generates every time it runs. Every thousandth of a millisecond is accounted for in the printout so if people doubt the results they can always look that over to see where the numbers come from.

Let me know if any of you find it useful. :)
 
Discussion starter · #6 ·
TheControlsFreak said:
BACnet, I have a blog about DDC Controls. Can you PM me and let me know if I would be allowed to offer your MSTP Speed Estimator for download to my readers?
Click to expand...

I just Emailed you with this same message, but I figured that there is no reason not to put it in this thread as well.

Abel,

I am honored that you would want to use my BACnet estimator on your blog. You may use and distribute it as you see fit, but on a personal level I would ask three things of you.

First, please host the download locally. I am simply using a free dropbox account and I cannot ensure that the current link will always work. I'd hate to offend anyone simply because the link has gone dead due to unforeseen events in the future.

Secondly as this is version 1.00, it is simply the first cut for this widget and I would appreciate it if people realized that it was only a first cut. I wrote it in two sittings last weekend and while it is extremely solid, it is not yet perfect. There are options that I would like to add, things like generating wireshark-parsable .pcap files as an output, allowing for varying the parameters of the controllers individually, etc.

And the third request I would have is that you provide me with any feedback you may get. If anyone finds a flaw in it, I'd love to hear about it!

Again, thanks for the interest, and good luck to you,

-BACnet
 
#7 ·
Hello BACnet,
thank you for the tool!
I downloaded it and did some test runs.
I have one questions where I do not understand the results I see:
I have settings 38400, 40 units, 10 requiring tokens and have the MaxMaster set to 127.
I set the number of simulated loops to 100. When I run the simulation, I get a certain Average loop time. I keep all parameters and only modify the number of simulated loops. I set it to 200, 300, ... up to the maximum of 800. When I look at the average loop time, the value increases with the number of simulated loops. What I would expect is, that for some numbers of simulated loop the average is higher, for some the average is lower - depending on how often the highest present master searches for a higher master up to the MaxMaster.
Probably I am missing something, but I would like to understand the result.
Can you please explain?

Thank you!
 
Discussion starter · #8 ·
709, thanks for trying the tool!

I think I know what's got you puzzled, and I think it's just that I need to make more clear in the user interface.

But first, I'd like to point out that by pressing the "Set Max Master" you will find that it improves the OWS throughput from 35 to 39 questions a minute. This is because the "units requiring the token" and the "desired open slots in the token ring" variables are used only to set the max_master setting. (Which is why I made it not directly writable).

But regardless of the "max master" setting, I think I know what's happening here. I made the simulation able to loop anywhere from 50 to 800 loops each time it is run. My reasoning for this was twofold- I wanted the printout, MSTP_Speed_Test_Output.slaiv, to not be so large that it was more than 65535 lines long so that I could load it into excel if I wanted, but also I wanted to be able to make it run just a few loops if people wanted a more manageable file to peruse through. But the higher the number of loops, the closer it is to an exact answer.

In your case, because you have the max master setting set to 127, you are offering the token to 118 open slots each time through the circuit. Device number 9 goes in pfm mode every 50 times it gets the token, but it goes out of that mode after 118 more tokens, then it waits 50 loops before it goes back into pfm mode for the next 118 loops. This means that the whole network operates one complete circuit approximately every 168 times through the loop. I say "approximately" because the peer to peer data transactions are yet another variable that operates on its own time frame which is where the simulation gets interesting.

So the real answer is that more loops give you a far better answer, just as observing any system over a longer period of time gives you a closer approximation of what its up to in total. Assuming you have all default variables except for the ones you posted above, I am showing the following results:

Average Loop Time:
50 Loops = 0.253864 seconds
100 loops = 0.274685
200 loops = 0.285195
400 loops = 0.290450
600 loops = 0.292168
800 loops = 0.293053
10,000 loops = 0.295374 (I modified my program to allow it to run this for you)

So for your simulation the actual average loop time is 0.295374 seconds.

I should have made it default to a very large number, and add a variable to have people toggle on and off the ability to generate the file. That way people will likely start with higher loop counts by default.

I hope this answers your questions and thanks for the feedback I will improve the interface in the next release to make these things more obvious. :cheers:
 
Discussion starter · #9 ·
One more thing- I noticed experimentally that the actual time per loop settles to within one one hundred thousandth of a second once the number of loops to simulate is set to above 7000. (Stepping by thousands).

But this tool shouldn't be used to make measurements quite that fine. Just changing the average data length parameter by one single byte effects the overall loop speed by 5ms and setting the max master lower can shave an entire 42ms off. So while higher loop numbers are preferable, carefully setting the parameters of the simulation is far more important.

I will make changes to the program to help better emphasize these points.

:cheers:
 
#10 ·
Hi BACnet,
thanks for your clarification - but I still do not understand the results I see.
Let me try to explain using the example above - it is a quite realistic one because many installers leave the MaxMaster setting to a default of 127 and do not adjust it to the real MaxMaster - and also do not take care that the setting is the same on all nodes (but your tool clearly shows how important this setting is and how much it can improve network throughput - good work!)

Anyway, lets talk about the example.
I would expect, that there are basically 2 different "average loop times": the first one when the highest master is in "normal mode" and the second one when it is in PFM mode. PFM mode would add a PFM timeout to the cycle time. Of course there are more timing parameters like the peer-to-peer communication, but for calculating the average values this should be considered to be constant for both loop times.

The nodes in your simulation start with the PFM mode every 50 cycles.

I would expect that when I simulate up to 50 cycles, I would get the "short loop time" (let's call it SLT) as the total average loop time.
Then it goes into the PFM mode, then cycling through the "long loop time" (LLT).
If I would simulate 168 loops, I would get (50*SLR + 118 * LLT)/168 which is greater than SLT.
When I simulate 50 more cycles, I would expect to get (100 * SLT + 118 LLT)/218 which is greater than the SLT but lower than the second calculation.

So what I would expect to see is, that the total average loop time goes up and down depending how many cycles of PFM mode loops are included. As you write - it get's more accurate the higher the number of cycles is.

In your calculation results:
50 Loops = 0.253864 seconds
100 loops = 0.274685
200 loops = 0.285195
400 loops = 0.290450
600 loops = 0.292168
800 loops = 0.293053
10,000 loops = 0.295374

the result get's always slightly higher - until it settles for high loop counts.
And this is what puzzles me. I am wondering if I still get something wrong of if this might have something todo with rounding in your code.

Don't get me wrong - I think the tool can be _very_ useful. I only want to understand how it works and want to give some input where there might be some room for improvement.

One setting that might also be interesting to simulate is, what happens if a number of nodes on the channel fail. Another interesting number would be to have not only the average loop time, but also the maximum loop time. Because in case you get communication timeout errors in your controller or OWS, this can help you adjusting the APDU timeout.
 
Discussion starter · #11 ·
Having slept on this overnight I think I know what's got you bothered- the starting conditions.

"Loop 1" through the token ring begins at the (exidently unlikely) timing where all of the appropriate (in this case unit number 9) units have just completed the pfm cycle, meaning that it is a full 50 times through the loop before that begins. As a result, the very first time through the loop and the loops closely folowing are the shortest duration loops of the cycle. By increasing the test times the fact that it starts in this mode can be averaged out to a realistic average.

Also as a starting condition I assume that the very last peer to peer communication was just completed at the prior loop. This means that I wait (1/Comms_per_second) before I send out the first peer to peer request.

So I could start at a random part of the cycle to eliminate this effect but I am not sure that I want to do that. The beauty of this simulator is that every single part of the timing is written out for you in the log file, literally every single bit. So if there was a bug, it would be written plain as day. More importantly, by starting at this starting point it is easier for people to read the log and see what's happening- they don't need to wonder why unit nine went into pfm mode after say 5 loops.

So while I actually really do appreicate your analysis, and you have given me direction for the next release I do think that you're spending a lot of time trying to use this for something other than its intended purpose.

The average loop time is one of three important outputs from this simulation- OWS throughput, the peer to peer throughput and the average loop time are the three ways to define the system's performance. The average loop time is meaningful only in that if a peer unit (as in, not the router or ows) gets into an alarm condition or needs to send out a COV, this number (here somewhere around 0.3 seconds) is the average maximum time it would need to wait for a token to report the event. Again, I've clearly shot myself in the foot by not clamping down on the 6 digits of precision.

Again, once you make an appropriate large sample, (say above 400 loops, or just above 2 cycles) the variations based on loop duration are thousands of times less significant than any of the other variables.

I will make the changes to the code to better nudge people into looking at the important stuff. If on the other hand you believe that I've maxed out the double point precision variables that I use under the hood, I'd encourage you to add up the numbers in the log to see for yourself that that is not the case.

:cheers:

And again, I never thought that people would step through the duration of the loops for any reason other than to save time or make an easier to read log file. The fact that you step through them with no other changes was literally something that I didn't intend last weekend when I wrote it. Let's see if anyone has any other different uses for me and I'll change them as well. :)
 
Discussion starter · #12 ·
709 said:
One setting that might also be interesting to simulate is, what happens if a number of nodes on the channel fail. Another interesting number would be to have not only the average loop time, but also the maximum loop time. Because in case you get communication timeout errors in your controller or OWS, this can help you adjusting the APDU timeout.
Click to expand...

I think I missed this part of your comment when I initially replied this morning.

I think that this is a wonderful idea and one that should probably be done in some way. I just wonder how best to accomplish it. (And I'll openly admit that I want to polish the tool in its own form before I start trying to simulate controllers that don't conform to the standard). But if I could provide a heatmap of controllers and every one you clicked on went offline until you unclicked on it, you'd very quickly see the perils of having a BINO (BACnet In Name Only) controller on your network... Interesting. :grin2:
 
#13 ·
BACnet,
I just read through your post and had a close look at the text file output of the tool. To be honest, I did not do this before, so now I understand how you sum up the values and how the tool operates. By lowering the values (only 2 units on network, 2 requiring token, 1 open slot -> MaxMaster=2 and 5 Max Info Frames for OWS, the tool gave me the results that I was expecting: constant average loop time up to 45 loop cycles, then increased average loop time for 50 cycles and again a lower value for 55 cycles. Now I am happy ;-)

When making my suggestion for new tool features I did not have non-standard conform controllers in my mind. For simulating an offline controller I was just thinking about a controller that fails - and let the tool give an estimation how this influences the network. That could help getting an idea how robust the network operates.
And for the APDU timeout, I don't think that it is a matter of non-conformity if the timeout expires before a response is received on a request. In my opinion this is a trade-off between how sensitive a device is to the load on the channel vs. how much the network traffic is delayed when a node does not respond to a request.

Could be very interesting to see the results of this thoughts in the simulator.
 
Discussion starter · #18 ·
Just a quick update folks-

I've cleaned up the interface, added the ability to simulate network problems, made the output txt file an optional feature, simplified the results section and made the simulation duration setting less confusing.

I'm got all of the updates added/coded but I'm just starting the testing phase of this update. I hope to release version 1.01 to you all sometime tomorrow if I get a few minutes to myself between now and then. Stay tuned!

:cheers:


Image


(Special thanks to 709 for the suggestions, keep them coming!)
 
#19 ·
Hi BACnet,
looking forward to test the new version!

BACnet said:
(Special thanks to 709 for the suggestions, keep them coming!)
Click to expand...
You asked for it, so here is some more requests.
This is something I came across last week and I believe that your tool can help in situations like this:

Let's say we have a network with 49 MSTP master nodes and one OWS - so in total we have 50 masters and no slave on the network.
The 49 nodes are some kind of sensor nodes. Each of these nodes has 10 server objects. The OWS is placing COV subscriptions for all data points in all 49 nodes. So we have in total 490 COV subscriptions. Now we set a COV expiry interval of 90s in the OWS - the algorithm in the OWS then causes to resubscribe every 60s. The subscription message causes that one message is sent from the OWS to a node (Subscribe COV), and the node responds with two messages (confirmation of the subscription and sending the current value).

One more input parameter to the simulation would be the average COV update rate per node.
This setup causes a certain load on the MSTP channel. Depending no the APDU timeout set in the OWS, the communication in the OWS will time out and will be faulty, or the communication is fine.

The user could get the following answers from your tool:

* Are the selected parameters for APDU timeout and COV expiry working on that channel?

* How do I have to set the APDU timeout in the OWS in order to get the system working?

* What value should I use for the COV expiry time to reduce the basic load on the channel?

When you allow to enter some parameters to simulate a random network load from the unconfirmed COV updates of the nodes, this would also give some information on how robust the network communication is.


I know that this simulation can get pretty complex, but I also think that this could be done and would make the tool _very_ useful :cool:
 
Discussion starter · #20 ·
709 said:
Hi BACnet,
looking forward to test the new version!



You asked for it, so here is some more requests.
This is something I came across last week and I believe that your tool can help in situations like this:

Let's say we have a network with 49 MSTP master nodes and one OWS - so in total we have 50 masters and no slave on the network.
The 49 nodes are some kind of sensor nodes. Each of these nodes has 10 server objects. The OWS is placing COV subscriptions for all data points in all 49 nodes. So we have in total 490 COV subscriptions. Now we set a COV expiry interval of 90s in the OWS - the algorithm in the OWS then causes to resubscribe every 60s. The subscription message causes that one message is sent from the OWS to a node (Subscribe COV), and the node responds with two messages (confirmation of the subscription and sending the current value).

One more input parameter to the simulation would be the average COV update rate per node.
This setup causes a certain load on the MSTP channel. Depending no the APDU timeout set in the OWS, the communication in the OWS will time out and will be faulty, or the communication is fine.

The user could get the following answers from your tool:

* Are the selected parameters for APDU timeout and COV expiry working on that channel?

* How do I have to set the APDU timeout in the OWS in order to get the system working?

* What value should I use for the COV expiry time to reduce the basic load on the channel?

When you allow to enter some parameters to simulate a random network load from the unconfirmed COV updates of the nodes, this would also give some information on how robust the network communication is.


I know that this simulation can get pretty complex, but I also think that this could be done and would make the tool _very_ useful :cool:
Click to expand...
This request would take a 30 to 60 question setup wizard that people woudl have to step through every time they ran the simulation. Factors get out of hand very quickly as you might imagine since there the COV threshold for each device would have to be specified as well as the frequency of hitting that threshold, etc.

At this point it seems that you could pencil in the added comms per second and use that in the master settings that are already provided. But I may get COV working at some point but I have to admit that read/write property multiple would be higher on the list since I wouldn't have to radically change the user interface or implement a complex and confusing wizard to accomplish it.

:cheers:
 
1 - 20 of 50 Posts
You have insufficient privileges to reply here.
About this Discussion
49 Replies
15 Participants
Last post:
orion242
HVAC-Talk: Heating, Air & Refrigeration Discussion
posts
5M
members
275K
Since
2000
The #1 HVACR Community
Full Forum Listing
Explore Our Forums
AOP Residential HVAC/Refrigeration(Beenthere Zone) General Discussion Tech to Tech Chat - Residential Controls Refrigeration & Ice Making