I have a machine that can drive 50Gbps on the NIC and 10Mpps with a 5Gbps limit per flow. When I try to stress test it with multicast I can't. I performed the following tests.
For 200, 250, 300, 500 and 700 Bytes Unicast I am CPU bound and understandably cannot drive the 5Gbps per flow, on 1000, 1500 and 8000bytes I can achieve the 5Gbps.
However with Multicast I cannot get close to the unicast numbers and CPU does not hit 100%. Can someone explain this behavior?
On the Multicast side there is no ACK from the server, correct?
The Client is just pushing the traffic into the network and the server does
not matter. If this is not the case, how multiple servers (receivers) are
handled?
And for -P doesn't help because I the unicast scenario since the server
becomes the bottleneck and -P is not supported for MCAST.
On the Multicast side there is no ACK from the server, correct?
The Client is just pushing the traffic into the network and the server side does not matter. If this is not the case, how multiple servers (receivers) are handled?
And for -P doesn't help. In the unicast scenario the server becomes the bottleneck since the server thread becomes CPU constrained. But the unicast piece is not a problem because I can achieve my machine limits with several iperf server threads and cliente. On multicast -P is not supported.
My test is trying to identify single flow limits. I know on the network is 5Gbps, and CPU is ~600K pps, I can achieve these with unicast.
On the multicast side I can achieve the 5Gbps with large packets (8000Bytes) so I know the network is throttling the flow, but when I use small packets I cannot get close to 600K pps and core CPU never hits 100%.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a machine that can drive 50Gbps on the NIC and 10Mpps with a 5Gbps limit per flow. When I try to stress test it with multicast I can't. I performed the following tests.
For 200, 250, 300, 500 and 700 Bytes Unicast I am CPU bound and understandably cannot drive the 5Gbps per flow, on 1000, 1500 and 8000bytes I can achieve the 5Gbps.
However with Multicast I cannot get close to the unicast numbers and CPU does not hit 100%. Can someone explain this behavior?
I don't see the multicast output. Do you have server side?
Also, it might be good to increase the number of traffic threads via -P to match the core count of the machine this is running on.
Hi Robert,
On the Multicast side there is no ACK from the server, correct?
The Client is just pushing the traffic into the network and the server does
not matter. If this is not the case, how multiple servers (receivers) are
handled?
And for -P doesn't help because I the unicast scenario since the server
becomes the bottleneck and -P is not supported for MCAST.
On Thu, Mar 16, 2023 at 7:41 PM Robert McMahon rjmcmahon@users.sourceforge.net wrote:
Hi Robert,
On the Multicast side there is no ACK from the server, correct?
The Client is just pushing the traffic into the network and the server side does not matter. If this is not the case, how multiple servers (receivers) are handled?
And for -P doesn't help. In the unicast scenario the server becomes the bottleneck since the server thread becomes CPU constrained. But the unicast piece is not a problem because I can achieve my machine limits with several iperf server threads and cliente. On multicast -P is not supported.
My test is trying to identify single flow limits. I know on the network is 5Gbps, and CPU is ~600K pps, I can achieve these with unicast.
On the multicast side I can achieve the 5Gbps with large packets (8000Bytes) so I know the network is throttling the flow, but when I use small packets I cannot get close to 600K pps and core CPU never hits 100%.
hmm, no reason to not support -P with multicast. I fixed that. It's in master. I can get about 3.8M pps for multicast with 256 byte payloads
and similar for unicast
Last edit: Robert McMahon 2023-03-17
Also, one can use port ranges too, e.g. -p 5001-5008