Customer Service Center

Environment/Versions Adding some other key words for searchability of this article. Unexpected traffic rate Rate not sent as configured Answer For this example, it uses 1.111% as the load per stream block: The overall configured rate shows 29.997% and the actual rate shows up as 29.994% Environment: The interface is 10G There are 27 streams set for 1.111% (111.1M) There are 3 types of frame sizes, 64B, 1500, 9000. Convert to bits: 64B + IFG + Preamble = 84B = 672 bits 1500 + IFG + Preamble = 1520B = 12160 bits 9000 + IFG + Preamble = 9020B = 72160 bits Frame rate in fps for 1.111% (111,100,000 bps) 64B = 165,327 (672 bits x 165,327 = 111,099,744) (as close to 111,100,000 without going over) 1500 = 9136 (12160 x 9136 = 111,093,760) (as close to 111,100,000 without going over) 9000 = 1539 (72160 x 1539 = 111,054,240) (as close to 111,100,000 without going over) There are 27 streams, 9 of each frame size 64B = 111,099,744 x 9 = 999,897,696 bps 1520B = 111,093,760 x 9 = 999,843,840 9020B = 111,054,240 x 9 = 999,488,160 Total = 2,999,229,696 bps 2,999,229,696 / 10G = 29.9923% (We can see the overall actual rate is different from the configured rate.) From the calculation above it is not possible to get exactly 1.111% with any of the 3 frames sizes.  Rate is load per stream block so I would expect each stream block would behave similarly as well as individually. So if each stream block has just a little less than 1.111%, when you add the rates of multiple stream blocks, we can see that the overall actual rate will get further away from the overall Configured rate. If all streams were the same size the TestCenter algorithm could compensate a bit and even with multiple frame sizes but there is probably some limitations and more so with multiple frames sizes. Still, from just going by the calculations it is not possible to reach exactly 1.111% thus the configured rate may not match the actual rate.