A few weeks ago, one of y’all told ne that there were some test in progress to determine bandwidth usage for your products.
Any results yet?
Yep - we’re writing them up right now.
The bandwidth needed for a client depends on how many tags are subscribed at once, and how frequently those tags are changing.
In our tests, a client processing 15 tags/sec used about 3.5k/sec, and processing 150 tags/sec used about 4.5k/sec.
We are evaluating the product and need to understand bandwidth consumption of clients. Is this information still relevant today? Any final results that scale up to the 10-15k tag range? Based on what you mentioned, a 10x increase in tags was only a 28% increase over the previous.
Also, when you refer to client processing tags, does that mean all tags in a project, or only those present on screen (current windows, popups, in background scripts)?
Ignition works on a subscription model: if you open a window, the client will subscribe to the tags, if you close the window, it will unsubscribe. When the client subscribes to the tags, it will also get the tags from the server, which causes quite some bandwidth usage when opening a window (other things also need to be fetched, like the window layout).
The server keeps track of what client is subscribed to what. The client polls the server for updates, and for every poll, the server replies with the updated tags.
The polling itself has a small overhead
Note that you don’t need to close a window. You can also leave a window open and just push some other window in front of it, this keeps the subscription active and allows for faster navigation, at the cost of more bandwidth usage if the window is constantly in the background.
So if you expect users to constantly switch between windows, it might be better to keep the windows open, as then only updated tags are transmitted. If you expect that most clients will mainly use one screen (f.e. depending on what part of the installation they need to see), it’s probably better to close the windows.
We usually have projects with 15000 to 30000 tags(*), and although I can’t give bandwith information (it depends way too much on how active the installation is, which is difficult to measure), we’ve never experienced bandwidth issues.
Though on one project, we’ve experienced CPU performance issues on the server. There were too many clients open (over 30 clients) and a lot of tags (about 30000). The server just couldn’t keep up with the subscription management. On that installation, we needed to change our navigation strategy to swap windows (close them when showing a new window) instead of leaving them open.
(*) Many of our tags are static though; they’re used f.e. in a motor struct to set the motor name, whether the motor can run backwards, minimum/maximum speeds, … Of the 15-ish tags per motor, there’s only a few that frequently change.
I appreciate the quick follow up. My background has been in Wonderware, so it sounds like it is very similar in terms of how they operate from a tag subscription standpoint.
I was trying to get an understanding of bandwidth because I have varying requirements to meet, where some sites are on small links (1.5 Mbps) with other users and need to understand the impacts this could have on those connections.
I have been able to understand the Gateway to Device bandwidth through understanding of the protocol that would be used to acquire the data, and because that is local, I am not normally going to be concerned, but if I wasn't local, I wanted to know. In my case, I was looking at Modbus with a 50/50 split between discrete inputs/outputs and input/holding registers for 15k tags that came out to about 32 kbps.
I was more concerned on the client side, and given the above bandwidth numbers from Carl, I can use something like 3 kbps for overhead and roughly 1 kpbs per 100 tags. Not sure on fetching window layout information (is this included in the overhead?) but if it is not as frequent and/or can be cached, then I'm less concerned about that as I am the continuous feed from tags.
You would probably agree that having 15k tags subscribed all the time is intense, but I think I can keep that to under 1-2k tags normally (window swapping, scripting, etc...), and keep by bandwidth to around 15-30 kbps. Seem fair?
Many of our tags are the same.
Great feedback, though.
Just checking at a random installation, there are currently 8 clients open, all are subscribed to 12k up to 21k tags. And the Ignition process is using about 600 kbps. Though that also included traffic to and from the database, as the database is on a different server.
So something like 600kbps for 120k tag subscriptions, Which means about 0.5 kbps/100 tags.
3 Likes
Thanks for looking into this. This is a great benchmark to keep in mind.