After configuring meter, the small packet speed limit is inaccurate.

[wangjun0728]

When I configure the meter to 10Mbps, the small packet speed limit is inaccurate.

Send packet command： iperf3 -c 192.168.0.1 -u -b 20m -l 16 -t 600 iperf3 -c 192.168.0.1 -u -b 20m -l 64 -t 600 iperf3 -c 192.168.0.1 -u -b 20m -l 128 -t 600 iperf3 -c 192.168.0.1 -u -b 20m -l 256 -t 600 iperf3 -c 192.168.0.1 -u -b 20m -l 512 -t 600 iperf3 -c 192.168.0.1 -u -b 20m -l 1024 -t 600

• payload | packet size | actual speed （Mbps ）| Difference （Mbps）

          16           |            58          |                 2.76                    |               7.24
          64           |            106         |                 6.04                    |               3.96
         128           |            170         |                 7.53                    |               2.47
         256           |            298         |                 8.59                    |               1.41
         512           |            554         |                 9.24                    |               0.76
        1024           |            1066        |                 9.58                    |               0.42                  

[wangjun0728]

IPv6 has the same problem

• payload | packet size | actual speed （Mbps ）| Difference （Mbps）

             16    |  78        | 2.05                  |  7.95
             64    | 126        | 5.08                  |  4.92
             128   | 190        | 6.74                  |  3.26
             256   | 318        | 8.05                  |  1.95
             512   | 574        | 8.92                  |  1.08
            1024   | 1086       | 9.43                  |  0.57

[igsilya]

@wangjun0728 Meters count sizes of ethernet frames, not the payload, but the 'actual speed' appears to be measured in terms of payload. Recalculating results from payload into packet size, shows results very close to 10M:

>>> 2.76 / 16 * 58
10.004999999999999

>>> 8.59 / 256 * 298
9.999296875

[wangjun0728]

It looks like this, so is this a meter bug? @igsilya

[igsilya]

@wangjun0728 it's not a bug. It is by design. OpenFlow meters limit the rate of packets. And a packet is defined in OpenFlow specification as a series of bytes comprising a header, a payload and optionally a trailer, in that order, and treated as a unit for purposes of processing and forwarding. So, headers are included.

It makes sense from the perspective of a switch. It doesn't generally matter what information the source and destination deems useful. What matters is how many bytes actually pass through the switch. The same is true for network cards, for example, you can't pass 10Mbps of payload via 10Mbps network card. Also, statistics on OpenFlow rules will report n_bytes the same way, i.e. including all the headers.

[wangjun0728]

@igsilya Got it, thank you very much. It seems to be a problem with the iperf statistics tool. It only counts the bandwidth of the payload.

[igsilya]

@wangjun0728 It's not really a problem in iperf per se, it's just a little different perspective. Application vs network appliance. iperf doesn't actually know what is the size of the packet will be in the end, because it doesn't know how the network is actually configured. For example, if the packet will go through a tunnel interface, another set of headers will be added. These will impact bandwidth, but application (iperf) doesn't know that. It can only count the data it puts into a socket, which is a payload.