Gateway Network Bandwidth Issue

I would like to know what kind of bandwidth others are seeing over the gateway network. I have a remote site that is a tag provider to another gateway in the cloud. The tag provider is also sending historical data to the cloud gateway across the gateway network. The cloud gateway is the HMI server running the Vision module along with the tag historian. I am seeing about 7GB\day in total data throughput. In a months time it is ~220GB of data. As we are now deploying sites which only has a cellular modem for an internet connection this data throughput is way to high. Most providers start throttling the bandwidth once you pass 22GB\month. I am curious what others are seeing for total bandwidth being used. I expected the gateway network to be more efficient than this. I have attached a screen shot of the tag counts and scan classes etc. for reference.

Also, if you have any good ideas on reducing the amount of data throughput please let me know.

Thanks,

1 Like

Given the tag quantities shown, I would expect the bulk of your traffic to be the vision clients. Run them from your local gateways. At least run a test with them running locally to quantify the bandwidth contribution.

1 Like

I believe that Ignition is migrating its clients from a polling to update on change subscription model. I believe this will affect vision clients starting in Ignition 8.0. Until then here are some practices that you can do now. First, change the database polling to ‘off’ and add a refresh buttons on your tables. Second, save your tables in your clients with empty datasets. Otherwise the data is stored in the client only to be updates at the first poll of the data from the database. Do this by disabling the connection in the designer, open the table dataset, kill the content, but retain the query, and save the designer.Third, increase your client poll rate in the project properties. Finally, there is an alarm setting in the gateway that changes the relationship of how remote gateways share alarm data with the other gateway. I cannot recall exactly but perhaps some one else here knows.

Vision clients currently poll for changes -- subscribed tag changes and push notifications accumulate in the gateway for a particular client and are delivered together at the client's poll interval. Vision clients do not poll everything all the time. This model is not expected to change for 8.0, though hopefully it will for 8.1. When it does change, do not expect dramatic changes in data traffic.

The change presumably would be to the websocket model used in the Perspective client, which pushes changes down to the client as they occur. The change can increase traffic in some cases, and decrease traffic in others. The poll overhead goes away. Tags that change less often than current polling will yield less traffic. Tags that change more often will increase traffic.

2 Likes

Hello Folks,

Digging this up because I have pretty much the same issue, with the same setup:
Gateways on the field acting as remote tag providers for a cloud based gateway where the client’s interface lives.
We’re seeing higher traffic on the field gateways (using vnstat) than we expected, and this will soon or later cause issues.

Now, I’m wondering how to get more details about this. How can I figure out what’s so heavy to carry ?

Thanks in advance and a good day to you all wonderful people !

Hi Pascal and KGrindstaff,

Did you resolve the bandwidth issue in the end? and if so, how?

Either add details about your setup here or start a new post. The only thing in common people reviving this topic seem to have is bandwidth concerns, but without more details there's nothing we can tell you.