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)
