...
All the details of this analysis can be found at:
Jira |
---|
server | ICT |
---|
serverId | b8c705e3451c03fa-ed92a384-32db3e36-b3d095b3-8ff450afc2493ef4dae081ba |
---|
key | ICT-19921 |
---|
|
IPerf Network Analysis (10 Gbps link)
...
The limitations imposed by the existing infrastructure and technologies are as follows:
- Network (x13): Allows about thirteen times the current required bandwidth
- Reliable multicast protocol RTI DDS (x12): Allows about twelve times the current required bandwidth
- BulkDataNT (x4): Allows about four times the current required bandwidth
The BulkDataNT implementation is not effectively taking advantage of the underlying technology that is using, achieving around a 35% of what the underlying technology offers.
There are different alternatives to tackle this:
- #1: 0.00 FTE: Change the underlying infrastructure to a faster link (i.e. 100 Gbps)
- #2: 0.25 FTE: Investigate and redesign BulkDataNT to make better use of RTI DDS
- #3: 1.50 FTE: Change the implementation of BulkDataNT to a different technology
- 0.50 FTE for investigation + 1.00 FTE for implementation if an appropriate technology is found during the investigation
The expected bandwidth increases with each of the previous alternatives is as follows:
- #1: x40: We still expect inefficiencies in the BulkDataNT system, but should still achieve ~35% of the network capabilities
- #2: x12: This is what the underlying technology offers, so it's the limit we can aim towards
- #3: x13: It depends on the chosen technology, but to choose a change of technology, we should aim towards a higher throughput than the one offered by using RTI DDS efficiently
- #1+#2: x120: Although there are no formal analysis of RTI DDS over a 100 Gbps link, we expect it to scale in a similar fashion than it did on 10 Gbps
- #1+#3: x130: There are a lot of unknowns in this scenario, but again, it should only be followed if the chosen technology behaves better than the an efficient RTI DDS implementation