To answer this question, we must first evaluate the application. There are several E3 resources that consume bandwidth, such as: alarm summaries; Viewer queries; Viewer scripts accessing server objects (such as Application.GetObject); downloading screens, libraries, and resources; and activating and deactivating links (such as opening and closing windows); among others.
To measure bandwidth consumption, a sample application was developed with the following objects:
- 1000 displays;
- 1000 internal tags; and
- 1000 demo tags.
This application was developed so that all displays on screen are linked to internal tags, and each internal tag linked to a demo tag with a 1-second variation. This link uses the following functions: CStr, CInt, CLng, CByte, and CSng.
Example: InternalTag51 has the following linked tag: CInt(Data2. DemoTag51.Value)
By analyzing E3’s statistics logs, you can check the necessary bandwidth to rout data.
Example 1:
RECClient(1): Viewer connected to RAIMANN Sent=1891(115872B) Recv=1903(29164159B) Pending=0(0B) Elapsed=15:01.920 REC=v2.90 Remote=v4.0.043
Routed packets in a 5-minute interval: 596
Routed packets per second: 1,98
Bandwidth consumption in a 5 minute-interval: 9252408B
Bandwidth consumption per packet: 15525B = 15,5KB
Bandwidth consumption per second: 30843B = 31KB/s
Please notice that in this scenario, the option for level of compression of REC packets is off.
If we retake the test, but now with the highest level of REC compression (9), we will have:
Example 2:
RECClient(1): Viewer connected to RAIMANN Sent=1848(49709B/114468B) Recv=1851(2431899B/27975352B) Pending=0(0B) Elapsed=15:00.640 REC=v2.90 Remote=v4.0.043
Routed packets in a 5-minute interval: 594
Routed packets per second: 1,98
Bandwidth consumption in a 5 minute-interval: 802383B
Bandwidth consumption per packet: 1350B = 1,3KB
Bandwidth consumption per second: 2674B = 2,7KB/s
With the highest level of REC compression, you can see the consumption of bandwidth is somewhat smaller.
The following table analyzes other types of data.
Note: In CStr types, the strings are small (the double value of a demo tag converted into string must be around 10 characters). If the strings are larger, the bandwidth must be higher.
Please notice that the tags’ update on screen must not be a bottleneck point. In the case of scripts that access the server (or other synchronous commands), the latency can make a lot of difference, even when the bandwidth is high. Therefore, we believe the bottleneck points should be:
- Time of screens switchover (it involves creating links and occasionally downloading screens/libraries and/or resources): sensitive to network latency. The application can work with a very slow network, depending on the acceptable time for the switchover. We recommend: Organizing libs, and occasionally exchanging some resources for their smaller versions.
- Time of execution for scripts accessing the server (usually a sequence of operations): very sensitive to network latency. The application can work with a slow network, depending on the acceptable time for terminal operations. We recommend: A careful development of the application by, for example, moving scripts to the server.
