controls:protocols:bacnet:qanda
Differences
This shows you the differences between two versions of the page.
controls:protocols:bacnet:qanda [2015/10/01 17:51] – created frozenlock | controls:protocols:bacnet:qanda [2015/10/01 17:56] (current) – removed frozenlock | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Questions / Answers ====== | ||
- | |||
- | Here are a few interesting Q&A gathered from the BACnet mailing list. | ||
- | |||
- | |||
- | ==== max_info_frames ==== | ||
- | |||
- | === Question === | ||
- | |||
- | < | ||
- | Does anyone have experience as to adjusting the max_info_frames to increase overall network speed? | ||
- | |||
- | Would it matter if the devices do NOT support read_property_multiple? | ||
- | |||
- | - Bob Kline | ||
- | </ | ||
- | |||
- | === Answer === | ||
- | |||
- | < | ||
- | Adjusting max_info_frames can improve performance – or make it worse. | ||
- | |||
- | If the link has a “system controller” who initiates most requests (read a bunch, write a bunch, repeat), then increasing that device’s max_info_frames is usually a good idea, to avoid needing to wait for a token pass that no one else will use anyway. | ||
- | |||
- | Similarly, a router from IP to MS/TP should usually have a reasonably large max_info_frames, | ||
- | |||
- | BUT: if you go TOO large, then one device can dominate the link, slowing the token rotation time, so that everyone else will have to wait longer to send their own requests. | ||
- | |||
- | - John Hartman | ||
- | </ | ||
- | |||
controls/protocols/bacnet/qanda.1443721894.txt.gz · Last modified: 2015/10/01 13:51 (external edit)