stateless TX bps question
Andreas Bourges
...we're currently doing some measurements for traffic-shaping in our NUT. TRex is running in software-mode and streams are created using python API.
e.g.
base_pkt = Ether(src=src_mac, dst=d_mac)/ \
Dot1Q(vlan=self.src_outer_vlan)/ \
Dot1Q(vlan=self.src_vlan, prio=self.cos)/ \
IP(flags="DF", tos=self.tos, src=self.src_ip,dst=self.dst_ip)/ \
UDP(dport=self.dst_port,sport=self.src_port)
pad = max(0, self.pktSize - len(base_pkt)) * 'x'
finalPkt = base_pkt/pad
Initially we started with pktSize = 100 and pps=125000 to achieve a BW of 100 mbit for a single stream:
125000 pps * 100 bytes/packet * 8 bits/bytes = 100 mbps
If we use wireshark to capture the packets we can see a value of 100 bytes "on-wire" for a single udp-packet. So far so good.
However, if I look at the statistics gathered from the STLClient() class (or looking at the trex-server console directly), the TX bps for the corresponding trex-port is slightly higher. For 100 mbps as calculated above, we get 103 mbps. Funnily, if we decrease the packet-rate and increase the pkt-size, the "overhead" goes down (e.g. 100.3 mbps when using rate of 12500 and size 1000). So to me it looks like there's something counted additionally on the TX port on a per-packet base. Interestingly, when the packets arrive on the second port coming back from the NUT, the calculated rate corresponds to our expected rate of 100 mbps.
Do you have any explanation on the above symptom?
Thanks and best regards,
Andreas
hanoh haim
Hi Andreas,
It is expected as we add the FCS (4 bytes) to the L2 calculation.
I assume the total scapy packet size is 100 right (self.pktSize ==100)?
To make it clearer, let's take a simple UDP example
14(Eth)+20(IP)+8(UDP)+58(Pyld)=100 bytes
This packet will be counted on the TX side as 104 (L2) and in Rx side as 104 because we add FCS (4 bytes).
We did that because we wanted to be consistent with IXIA.
So the expected L2 BW should be 104mbps and *not* 100mbps.
With bigger packets the 4 will be less significant .
L1 BW add the L1 headers 24 bytes.
thanks
Hanoh
--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+unsubscribe@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/6ac39800-518a-44d4-a5ca-21660fe22951%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.