(This could be for the Niagara-Central forum but I am not 100% sure. I am initially posting here rather than the wider Niagara community, please redirect if necessary)
To test performance of multiple Sedona controllers in a niagara setting, we have setup the following:
- One PC, running 15 instances of Sedona device, on different ports
---- Each virtual sedona device running at 50 msec scan time
---- Each virtual sedona device has 20 components, with a slot that changes every cycle
- A jace6, running a station with the TXS1.1 sedonanet, subscribing to all 20 points of all 15 virtual sedona devices.
You open up 15 tabs in Workbench so all these points are subscribed and everything works as expected. Then you introduce a major load in the system by clicking the RefreshTabs menu. This causes a major instability in the system with a whole lot of "queue full exception" messages. Many of the points, seemingly randomly, go into fault status. Others seem normal, but stop updating. Some others do receive updates, but only occasionally. There seems to be no way out of this situation, other then restarting the station.
It seems either the Sedona side or the Niagara driver needs some sort of prevention mechanism to recover from this sort of instability. The load described above is not exceptional (15 devices with a total 300
evenly distributed
subscribed points). The intervention (refreshTabs) can be called exceptional, but it is impossible to tell all conditions real-life installations will experience.