We have a rather large site with total 50,000+ modbus points coming from 200+ modbus IP devices. All of it is coming into 1 modbus TCP network on the supervisor. Supervisor is running on an expensive Windows Server VM.
We’re seeing 95%+ busy time…
If we split the devices into multiple modbus TCP networks in the config tree would that help with the busy time? Will this basically create new threads for the modbus “stack” if you will?
Do we need to change the TCP port to accomplish multi threading or just simply adding a new ModbusTCPNetwork to the tree?
I would believe that yes, it would help break down the busy time.
But separating and making sure your tuning policy are correctly set also helps a lot.
You can also optimize through the device poll config that bundles up points that are sequential and request one reading for all at the same time.
after we split the devices across multiple networks we did indeed confirm the busy time went down and things are working better now. we combined that with using prime numbers as poll intervals as well. poll configs we luckily setup correctly in the beginning.
The prime number poll intervals trick is gold — avoids those nasty harmonic spikes when everything tries to poll on the exact same second. Just curious, did you keep the default ThreadPoolWorker settings on the Supervisor host, or did you have to bump the thread pool count in the system configuration after splitting into multiple Modbus networks? With 50k points across 200 devices, standard tuning policies often queue up if the worker pool hits its cap during network hiccups. Glad to hear the busy time dropped though!
thanks we didn’t touch the threadpoolworker since we are still unsure how it exactly works. im sure that with the specs on our VM we can but i wish tridium would publish an official doc on threads and JVM settings to maximize the available server resources…