Using ostinato as 10 gbit traffic generator

[Luca Deri]

Hi all,
I have made some changes to my open-source PF_RING library (see http://www.ntop.org/PF_RING.html) so that ostinato could use it. You can now use ostinato to generate traffic at 10 Gbit using commodity hardware (no costly FPGA-based NICs are needed). The result is described on http://www.ntop.org/blog/pf_ring/building-a-10-gbit-traffic-generator-using-pf_ring-and-ostinato/. Perhaps some of you might be interesting in using it too.

Enjoy Luca

[Srivats P]

Luca,

That's great!

Assuming some knowledge of linux kernel and ethernet device drivers,
what's a good place to learn about tnapi, pf_ring and dna and how they
are different pieces of the same puzzle?

Regards,
Srivats

> --
> Get Ostinato News and Updates on Twitter - Follow @ostinato (http://twitter.com/ostinato)
> ---------
> You received this message because you are subscribed to the Google Groups "ostinato" group.
> To post to this group, send email to osti...@googlegroups.com
> To unsubscribe from this group, send email to ostinato+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ostinato?hl=en
>

[Luca Deri]

Hi Srivats
first of all thanks for developing ostinato: this was a really missing piece in the open-source networking world.

This said, ostinato is both RX and TX. PF_RING is mostly RX, TNAPI is only RX, and DNA 10G is both RX and TX (I am working at a new 1G DNA version for both RX and TX). The nice thing is that PF_RING is a consistent API that based on the driver used (vanilla, TNAPI, DNA) is able to exploit them without you noticing any difference.

Like I have written on my blog post, one of the next things I would like to do is to develop some native code for running ostinato at full rate. Do you have any hint/suggestions for me? This would allow us to have a full wire rate RX+TX ostinato running at 10G on commodity hardware.

Regards Luca

---
Keep looking, don't settle - Steve Jobs

[Srivats P]

Luca,

I had a quick look at pfsend.c.

You use pfring_send() while Ostinato uses the PCAP api
pcap_sendpacket(). Is that what makes the difference between 6.6 and
14.88? Does libpcap have that much overhead?

Regards,
Srivats

[Srivats P]

Luca,

Note that I'm assuming in the pf_ring enhanced libpcap,
pcap_sendpacket() eventually calls pfring_send(). Which is why I was
asking if libpcap is adding so much overhead on top of native
pfring_send().

What is the expected Tx throughput for an application using
pcap_sendpacket() and linked with the pfring enhanced libpcap? Is it
expected to do 14.88 line rate?

Srivats

[Luca Deri]

Hi Srivats
Thanks for your time reding my code. Yes with pfring_send() you can reach wire rate. Honestly I can't remember what is the performance achieved when using it over pcap. I am not sure that pcap is the problem: I will make some tests next week to confirm you this.

The first issue is that when we send data we do not have to send packet by packet, but rather send packets in chunks. The last parameter of pfring_send() specifies if the packet has to be sent immediately and when used over pcap it is set to 1 thus packets go out immediately. This is the correct behavior if you send few pps, but when you send many pps (let's say 10k or more pps) we need to send packets in chunk. If you set it to 0, is. If you set it to 0 is. The pfring library that takes care of "auto flush" when a specified watermark (default 128 packets) is reached. So I think we need to play a bit with this watermark, setting it to the right value based on how Ostinato send out packet (I.e. The rate).

The second thing to do is to make sure that all packets a re pre-forged in memory, so that you can send out with no delay. A far as I remember you are already doing this, don't you?

Regards Luc

Sent from my iPad

[rans...@gmail.com]

Hello,

I know it is old topic, but I still find it very important.

I need to use traffic generator and anlayzer , 10gbe.

1. Does the ostinato+PF_RING, is still a good solution for doing this, or are there prefered options ?

2. Is this solution relevant only for TX ? 

Regards,

Ran

[Srivats P]

Ran,

Using Ostinato with PF-Ring enabled libpcap is arguably the easiest
way to maximize transmit performance.

Srivats

--
http://ostinato.org/
@ostinato

[Luca Deri]

HI Ran

It is quite some time we do not run ostinato with pfring: our API didn't change but probably ostinato did change. I suggest you to test it again and if not working to file a bug on http://github.com/ntop on PF_RING so we can fix it

Regards Luca

Sent from my iPad

[Srivats P]

Ran,

By receive if you mean just stats, it can do a high rate, but if you
mean capture, I doubt you'll be able to capture at high rate. Even if
you did, the capture file would be so huge to be virtually useless.

Srivats

On Mon, Jun 6, 2016 at 11:05 PM, Ran Shalit <rans...@gmail.com> wrote:
> Thank you Srivat !
> But what abour receiving, does ostinato can manage high rate in receive too
> ?
>
> Regards,
> Ran

--
http://ostinato.org/
@ostinato

[mino...@gmail.com]

Hi All,

First of all, thank you Srivats for developing Ostinato, I have selected your software for functional testing.

Regarding to performance, I want to comment you several points and this topic is a good place because I want to use Ostinato as packet generator with 10 Gb nics.

I have done several tests until now for select OS, library (netmap, pf_ring) compatible with libpcap and so with Ostinato. I test the environments with Ostinato and with iperf3.

My results conclude that Ostinato is CPU bound application and regarding other topic (https://groups.google.com/forum/#!topic/ostinato/W_1GQydYLkI) Ostinato probably improve receiving performance with multiple threads and there are a libpcap multithread from a university project, but sincerely I don´t prove it.

I put following a few tests, with ostinato I generate a UDP packet of 1518 with empty data pattern:

Case 1: Ostinato without any improvement

• Software: Ostinato
• Situation: Kernel 3.19.0-56 + ixgbe 4.3.15
• Commands:
  • sudo drone on fastio1
  • ostinato on WS
• Viewer of results: Wireshark
• Results: 419040378 bytes in 0.827 seconds --> 4.05 Gbps     

Basic test over Ubuntu 14.04 LTS.

Case 2: iperf3 without any improvement

• Software: iperf3
• Situation: Kernel 3.19.0-56 + ixgbe 4.3.15 + script disableLoopbackUse.sh launched
• Commands:
  • iperf3 -B 198.19.1.14 -s
  • iperf3 -B 198.18.1.12 -c 198.19.212.14
• Viewer of results: iperf3
• Results: 7.90 Gbps
• Viewer of results: Wireshark
• Results: 988427762 bytes in 1.159s --> 6.82 Gbps

Same with iperf3 to see the difference.

 

• Case 5: iperf3 mapping the sender and receiver process to specific CPU core
  • Software: iperf3
  • Situation: map sender to core 0 and receiver to core 0
  • Commands:
    • taskset -c 0 iperf3 -B 198.19.1.14 -s
    • taskset -c 0 iperf3 -B 198.18.1.12 -c 198.19.212.14
  • Viewer of results: iperf3
  • Results: 8.31 Gbps
• Case 6: iperf3 mapping the sender and receiver process to multiple specific cores
• Software: iperf3
• Situation: map sender to core 0,1 and receiver to core 6,7
• Commands:
  • taskset -c 0,1 iperf3 -B 198.19.1.14 -s
  • taskset -c 6,7 iperf3 -B 198.18.1.12 -c 198.19.212.14
• Viewer of results: iperf3
• Results: 7.97 Gbps\

 Two previous tests shows that split the receiving traffic in two queues and go after to the core that run iperf is a wrong idea. iperf in monothread app and split in queues not is good.

Case 7: iperf3 with multiple queues and sender and receiver assigned to one core

• Software: iperf3
• Situation: assign one ip alias (ifconfig eth2:0 198.18.1.22 netmask 255.255.255.0 up) on each nic, fake ips for the new interfaces and the NAT table trick for the new nics
• Commands:
  • taskset -c 0 iperf3 -B 198.19.1.14 -s
  • taskset -c 1 iperf3 -B 198.19.1.24 -s
  • taskset -c 6 iperf3 -B 198.18.1.12 -c 198.19.212.14
  • taskset -c 7 iperf3 -B 198.18.1.22 -c 198.19.212.24
• Viewer of results: iperf3
• Results: 9.89 Gbps

Good result if split both queues and application.

Case 9: ostinato mapping the process to multiples cores

• Software: ostinato
• Situation: assign multiple cores to drone
• Commands:
• • sudo su
  • taskset -c 0,1,2,3,4,5,6 drone
• Viewer of results: htop
• Results: Ostinato doesn´t have in account the task affinity and not run multiples cores 

I think that this previous idea, split ostinato in threads probably is a good idea.

• Case 10: iperf with netmap-libpcap
  • Software: iperf3 over libpcap over netmap
  • Situation: install netmap and netmap-libpcap
  • Commands:
    • iperf3 -B 198.19.1.14 -s
    • iperf3 -B 198.18.1.12 -c 19.19.224.14
  • Viewer of results: iperf3
  • Results: 9.41 Gbps
• Case 11: ostinato with netmap-libpcap
• Software: ostinato over libpcap over netmap
• Situation: install netmap and netmap-libpcap
• Commands:
  • drone on fastio1
  • ostinato on WS
• Viewer of results: wireshark
• Results: 5.26 Gbps

Ostinato over libpcap from netmap improve preformance.

• Case 14: Ostinato with RateAccuracy=Low
  • Software: Ostinato
  • Situation: CentOS with default driver and script disableLoopbackUse.sh launched and set RateAccuracy=Low on Ostinato drone configuration file
  Commands:
  • • sudo drone on fastio1
    • ostinato on WS
  • Viewer of results: htop
  • Results: CPU at 100% and same bandwitch
• Case 15: Ostinato with CPU frequency set to 3.06 GHz
  • Software: Ostinato
  • Situation: CentOS default but setting CPU frequency to 3.06 GHz
  • Commands:
    • cpupower frequency-set -g userspace
    • cpupower frequency-set -f 3060000
    • sudo drone on fastio1
    • ostinato on WS
  • Viewer of results: htop and Ostinato
  • Results: CPU at 100% and BW=6.4 Gbps
• Case 16: Ostinato with CPU frequency set to 1.6 GHz
• Software: Ostinato
• Situation: CentOS default but setting CPU frequency to 1.6 GHz
• Commands:
  • cpupower frequency-set -g userspace
  • cpupower frequency-set -f 1600000
  • sudo drone on fastio1
  • ostinato on WS
• Viewer of results: htop and Ostinato
• Results: CPU at 100% and BW=4 Gbps

These two previous tests are for conclude that Ostinato is a CPU bound application. And these tests shows the BW reported by ostinato at the received port without capturing, only receiving.

• Case 17: iperf3 with driver 4.3.15 from Intel
  • Software: iperf3
  • Situation: CentOS with 4.3.15 intel driver for ixgbe NICs
  • Commands:
    • iperf3 -B 198.19.1.14 -s
    • iperf3 -B 198.18.1.12 -c 198.19.212.14
  • Viewer of results: iperf3
  • Results: 9.41 Gbps
• Case 18: iperf3 over PF_Ring
• Software: iperf3 over pf_ring-libpcap
• Situation: CentOS, driver 4.1.15 from PR_RING and libpcap from PF_RING
• Commands:
  • taskset -c 0 iperf3 -B 198.19.1.14 -s
  • taskset -c 6 iperf3 -B 198.18.1.12 -c 198.19.212.14
• Viewer of results: iperf3
• Results: 9.41 Gbps

• Case 21: iperf3 over PF_Ring with two queues
  • Software: iperf3 over pf_ring-libpcap
  • Situation: CentOS, driver 4.1.15 from PR_RING, libpcap from PF_RING, create alias for eth2 and eth4 and run disableAliasInterfaces.sh
  • Commands:
    • taskset -c 0 iperf3 -B 198.19.1.14 -s
    • taskset -c 1 iperf3 -B 198.19.1.24 -s
    • taskset -c 6 iperf3 -B 198.18.1.12 -c 198.19.212.14
    • taskset -c 7 iperf3 -B 198.18.1.22 -c 198.19.212.24
  • Viewer of results: iperf3
  • Results: 4.98 + 4.74 = 9.72 Gbps
• Case 22: iperf3 with 4.3.15 driver and two queues
• Software: iperf3
• Situation: CentOS, driver 4.3.15 from Intel, alias for eth2 and eth4 and run disableAliasInterfaces.sh
• Commands:
  • taskset -c 0 iperf3 -B 198.19.1.14 -s
  • taskset -c 1 iperf3 -B 198.19.1.24 -s
  • taskset -c 6 iperf3 -B 198.18.1.12 -c 198.19.212.14
  • taskset -c 7 iperf3 -B 198.18.1.22 -c 198.19.212.24
• Viewer of results: iperf3
• Results: 4.91 + 4.90 = 9.81 Gbps

Tests with pf_ring and iperf3.

I conclude until now:

- CentOS have best network stack by default than Ubuntu (I don´t know the reason yet). 

- I think that I can´t achieve better performance without DPDK probably.

- Ostinato is a CPU bound program, proven with Case 14, Case 15 and Case 16. Probably multi-threading improve it.

- The use of two queues is a trick but it able to us to see the queue limitation at the receiving point.

- iperf3 is limited by the NICs and the improvements have been reached improving the reception part of the tests, probably iperf3 is able to inject more packets than is able to receive.

Sorry for the length of the e-mail but I want to show the tests for explain conclusions well, and also, I apologize my english, but I think that you can understand me. Thank you again for developing Ostinato and for your time.

Best regards,

Mariano.

[Luca Deri]

Hi Mariano,

from your tests I believe the bottleneck is Ostinato and your statement "- I think that I can´t achieve better performance without DPDK probably." is not correct IMHO. 

Do not think in term of Gbit but of pps and you will see that the number of pps you can generate with ostinato is much less than those you can generate with native tools. If Ostinato adds per packet X usec, then the performance will drop down. As of PF_RING with PF_RING ZC (zero copy) you can saturate a 10G link with one core on a low-end box, so you can use ZC too but the numbers won't change as you are trying to accelerate a path that is fast, whereas the slow path is not this. Please note that I am *not* saying the Ostinato is not efficient, just that it needs time to generate traffic. Pre-generating traffic (as PF_RING ZC does) can help however.

Regards Luca

[MinoX]

Hi Luca,

For the first point yes, I think that my bottleneck is Ostinato (CPU) and the phrase I wanted to put is the opposite, I want to say that the performance I would achieve with DPDK probably is not more bigger than I achieved with netmap or pf_ring or kernel drivers because these tests are near to 10Gbit wire rate. I have starting to tests DPDK yesterda.

I think in terms of Gbit because is my goal at this moment, saturate 10 Gbps network card, so I  am testing with large packets, in other moment and for other type of tests, I will test with 64 bytes packets and other patterns and sizes. I want to implement RFC 2544 and partially 2889. Also, I should make some functional testing.

My conclusion and the main idea I tried to explain to Srivats is that Ostinato performance is limited by CPU, multi threading probably improve it, even with the NIC congestion. For my current goal Ostinato is not the selected tool for performance testing due by this reason because in a future project and for improve the software it is an interesting field to work in it, I think.

Today I would try Moongen and T-rex packet generator for testing performance over DPDK, I start to use yesterday PKTGen but is a more difficult tool for me :S and for a few hours that I have for this point.

Thank you for the answer and I´m waiting for the Srivats point of view, probably busy with the 0.8 release :P Thank you Srivats again for Ostinato piece of software. I thought on implementing DPDK driver for Ostinato (for have also functional and performance testing) but I haven´t more time and at this moment I cant help with this topic. 

Best regards,

Mariano.

You received this message because you are subscribed to a topic in the Google Groups "ostinato" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ostinato/ZdiR2ZXdt0c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ostinato+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carlos G Mendioroz]

Luca,
AFAIK, Ostinato does pregenerate the traffic, so in fact the point might
be that Drone is not "efficient".
I guess the problem is that Drone tries hard to do timing with CPU
throtling to be precise (low jitter).
That in turn forces its logic to be monothread.

May be many users do not really want that precision and just want to hog
the network. Running many concurrent drones in the same machine might be
an alternative?

On the other side, literally, I don't fully follow the receiving side
impact of Mariano's tests. 10G Nics are, IMHO, over what a single core
an handle while doing other chores in a multitasking environment.
Given that both sending and receiving are affected, doing the metering
in the same host using VMs seems not to be a good idea, but sometimes
users do not see where are the botlenecks. Also what is in the path
(cable, switch, ???) and buffers, and ?.

I would say that for serious BW testing, agents with special purpouse RT
kernels seem like a nice option to me.

-Carlos

Luca Deri @ 28/06/2016 03:53 -0300 dixit:

> <https://groups.google.com/forum/#!topic/ostinato/W_1GQydYLkI>)

> Ostinato probably improve receiving performance with multiple
> threads and there are a libpcap multithread from a university
> project, but sincerely I don´t prove it.
>
> I put following a few tests, with ostinato I generate a UDP packet
> of 1518 with empty data pattern:
>
> Case 1: Ostinato without any improvement
>

> * Software: Ostinato
> * Situation: Kernel 3.19.0-56 + ixgbe 4.3.15
> * Commands:
> o sudo drone on fastio1
> o ostinato on WS
> * Viewer of results: Wireshark
> * Results: 419040378 bytes in 0.827 seconds --> *4.05 Gbps *
>
> *
> *

> Basic test over Ubuntu 14.04 LTS.

> *
> *

> Case 2: iperf3 without any improvement
>

> * Software: iperf3
> * Situation: Kernel 3.19.0-56 + ixgbe 4.3.15 + script
> disableLoopbackUse.sh launched
> * Commands:
> o iperf3 -B 198.19.1.14 -s
> o iperf3 -B 198.18.1.12 -c 198.19.212.14
> * Viewer of results: iperf3
> * Results: *7.90 Gbps*
> * Viewer of results: Wireshark
> * Results: 988427762 bytes in 1.159s --> *6.82 Gbps*
>
> *
> *

> Same with iperf3 to see the difference.
>
>

> * Case 5: iperf3 mapping the sender and receiver process to
> specific CPU core
> o Software: iperf3
> o Situation: map sender to core 0 and receiver to core 0
> o Commands:
> + taskset -c 0 iperf3 -B 198.19.1.14 -s
> + taskset -c 0 iperf3 -B 198.18.1.12 -c 198.19.212.14
> o Viewer of results: iperf3
> o Results: *8.31 Gbps*
> * Case 6: iperf3 mapping the sender and receiver process to
> multiple specific cores
> o Software: iperf3
> o Situation: map sender to core 0,1 and receiver to core 6,7
> o Commands:
> + taskset -c 0,1 iperf3 -B 198.19.1.14 -s
> + taskset -c 6,7 iperf3 -B 198.18.1.12 -c 198.19.212.14
> o Viewer of results: iperf3
> o Results: *7.97 Gbps\*

>
> Two previous tests shows that split the receiving traffic in two
> queues and go after to the core that run iperf is a wrong idea.
> iperf in monothread app and split in queues not is good.
>
> Case 7: iperf3 with multiple queues and sender and receiver assigned
> to one core
>

> * Software: iperf3
> * Situation: assign one ip alias (ifconfig eth2:0 198.18.1.22

> netmask 255.255.255.0 up) on each nic, fake ips for the new
> interfaces and the NAT table trick for the new nics

> * Commands:
> o taskset -c 0 iperf3 -B 198.19.1.14 -s
> o taskset -c 1 iperf3 -B 198.19.1.24 -s
> o taskset -c 6 iperf3 -B 198.18.1.12 -c 198.19.212.14
> o taskset -c 7 iperf3 -B 198.18.1.22 -c 198.19.212.24
> * Viewer of results: iperf3
> * Results: *9.89 Gbps*
>
> *
> *

> Good result if split both queues and application.
>
> Case 9: ostinato mapping the process to multiples cores
>

> * Software: ostinato
> * Situation: assign multiple cores to drone
> * Commands:
> *
> o sudo su
> o taskset -c 0,1,2,3,4,5,6 drone
> * Viewer of results: htop
> * Results: *Ostinato doesn´t have in account the task affinity and
> not run multiples cores *
>
> *
> *

> I think that this previous idea, split ostinato in threads probably
> is a good idea.

> *
> *
>
> * Case 10: iperf with netmap-libpcap
> o Software: iperf3 over libpcap over netmap
> o Situation: install netmap and netmap-libpcap
> o Commands:
> + iperf3 -B 198.19.1.14 -s
> + iperf3 -B 198.18.1.12 -c 19.19.224.14
> o Viewer of results: iperf3
> o Results: *9.41 Gbps*
> * Case 11: ostinato with netmap-libpcap
> o Software: ostinato over libpcap over netmap
> o Situation: install netmap and netmap-libpcap
> o Commands:
> + drone on fastio1
> + ostinato on WS
> o Viewer of results: wireshark
> o Results:* 5.26 Gbps*

>
>
> Ostinato over libpcap from netmap improve preformance.
>

> * Case 14: Ostinato with RateAccuracy=Low
> o Software: Ostinato
> o Situation: CentOS with default driver and script

> disableLoopbackUse.sh launched and set RateAccuracy=Low on
> Ostinato drone configuration file
> Commands:

> o
> + sudo drone on fastio1
> + ostinato on WS
> o Viewer of results: htop
> o Results: *CPU at 100% and same bandwitch*
> * Case 15: Ostinato with CPU frequency set to 3.06 GHz
> o Software: Ostinato
> o Situation: CentOS default but setting CPU frequency to 3.06 GHz
> o Commands:
> + cpupower frequency-set -g userspace
> + cpupower frequency-set -f 3060000
> + sudo drone on fastio1
> + ostinato on WS
> o Viewer of results: htop and Ostinato
> o Results: *CPU at 100% and BW=6.4 Gbps*
> * Case 16: Ostinato with CPU frequency set to 1.6 GHz
> o Software: Ostinato
> o Situation: CentOS default but setting CPU frequency to 1.6 GHz
> o Commands:
> + cpupower frequency-set -g userspace
> + cpupower frequency-set -f 1600000
> + sudo drone on fastio1
> + ostinato on WS
> o Viewer of results: htop and Ostinato
> o Results: *CPU at 100% and BW=4 Gbps*
>
> *
> *

> These two previous tests are for conclude that Ostinato is a CPU
> bound application. And these tests shows the BW reported by ostinato
> at the received port without capturing, only receiving.

> *
> *
>
> * Case 17: iperf3 with driver 4.3.15 from Intel
> o Software: iperf3
> o Situation: CentOS with 4.3.15 intel driver for ixgbe NICs
> o Commands:
> + iperf3 -B 198.19.1.14 -s
> + iperf3 -B 198.18.1.12 -c 198.19.212.14
> o Viewer of results: iperf3
> o Results: *9.41 Gbps*
> * Case 18: iperf3 over PF_Ring
> o Software: iperf3 over pf_ring-libpcap
> o Situation: CentOS, driver 4.1.15 from PR_RING and libpcap
> from PF_RING
> o Commands:
> + taskset -c 0 iperf3 -B 198.19.1.14 -s
> + taskset -c 6 iperf3 -B 198.18.1.12 -c 198.19.212.14
> o Viewer of results: iperf3
> o Results: *9.41 Gbps*
>
> * Case 21: iperf3 over PF_Ring with two queues
> o Software: iperf3 over pf_ring-libpcap
> o Situation: CentOS, driver 4.1.15 from PR_RING, libpcap from

> PF_RING, create alias for eth2 and eth4 and run
> disableAliasInterfaces.sh

> o Commands:
> + taskset -c 0 iperf3 -B 198.19.1.14 -s
> + taskset -c 1 iperf3 -B 198.19.1.24 -s
> + taskset -c 6 iperf3 -B 198.18.1.12 -c 198.19.212.14
> + taskset -c 7 iperf3 -B 198.18.1.22 -c 198.19.212.24
> o Viewer of results: iperf3
> o Results: 4.98 + 4.74 = *9.72 Gbps*
> * Case 22: iperf3 with 4.3.15 driver and two queues
> o Software: iperf3
> o Situation: CentOS, driver 4.3.15 from Intel, alias for eth2

> and eth4 and run disableAliasInterfaces.sh

> o Commands:
> + taskset -c 0 iperf3 -B 198.19.1.14 -s
> + taskset -c 1 iperf3 -B 198.19.1.24 -s
> + taskset -c 6 iperf3 -B 198.18.1.12 -c 198.19.212.14
> + taskset -c 7 iperf3 -B 198.18.1.22 -c 198.19.212.24
> o Viewer of results: iperf3
> o Results: 4.91 + 4.90 = *9.81 Gbps*
>
> *
> *

> <http://www.ntop.org/PF_RING.html>) so that ostinato could use it.

> >> >> >>>>> You can now
> >> >> >>>>> use ostinato to generate traffic at 10 Gbit using
> commodity
> >> >> >>>>> hardware (no
> >> >> >>>>> costly FPGA-based NICs are needed). The result is
> described on
> >> >> >>>>>
> >> >> >>>>>
> http://www.ntop.org/blog/pf_ring/building-a-10-gbit-traffic-generator-using-pf_ring-and-ostinato/

> <http://www.ntop.org/blog/pf_ring/building-a-10-gbit-traffic-generator-using-pf_ring-and-ostinato/>.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to ostinato+u...@googlegroups.com
> <mailto:ostinato+u...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Carlos G Mendioroz <tr...@huapi.ba.ar> LW7 EQI Argentina

[Luca Deri]

Carlos
I am not an expert of the ostinato internals but if you run multiple
drones you need to sync them and you're probably moving the problem.

IMHO for efficiency Ostinato must speak directly with the NIC queues,
pre-compute packets (optionally) and void brute force (threads and
threads and threads). A simple architecture will do the job

Luca

[Carlos Mendioroz]

The one thing that is known is that Drone is monothreaded. Current
processors are multicore, so you can not utilize the full processor
power without using multiple threads.

On the other hand, iff your goal is to load test a 10G, having a mix of
load components is good enough. That's the idea of my proposition of
running multiple drones. Obviously you need a kernel that knows how to
feed a 10G, and keep it happy. Given that the whole thing is about
metering, the receive side is not to be forgotten either :)

-Carlos


Luca Deri @ 28/06/2016 07:38 -0400 dixit:

[MinoX]

Hi All,

First point, I tried to set task affinity in Ostinato with taskset and Ostinato doesn't have in account. But really I don't try to send two drones, one for capturing and one for injecting.Thanks, I will try this and comment the results due by I only want a stream injected in one port and pcap with the captured traffic of other port, I don't need any more, probably this reduce the CPU load of Ostinato (drone) injecting code.

I always say Ostinato but the program I run is drone, I run drone in one server and run Ostinato GUI in my Workstation.

I doesn't use VM, I use one server with 2 processors with 6 cores by processor (without multithreading, turbo boost or other technologies that can disturb the results). I'm using a crossbar ethernet link beetween one port of one NIC and one of the other. I have two Intel X540-T2 but I only use 1 port of each. I think that strict real time O.S are not necessary for this preliminary tests. I assign the cores for each iperf3 application and probably linux scheduler don't change this core of context because is assigned to one application that use the core all the time.

I will try with two drones, one for injecting and one for receiving to check the bandwidth.

Best regards,

Mariano.

You received this message because you are subscribed to a topic in the Google Groups "ostinato" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ostinato/ZdiR2ZXdt0c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ostinato+u...@googlegroups.com.

[MinoX]

Hi All,

I don't see a big difference between run on one or two drone in the same machine. I achieve the same bandwidth.

Finally, I don't know the reason about drone injecting or receiving limitation on performance but is a CPU limitation.

I only try to explain test cases for improve the software and for say to Srivats some tests cases and some values about performance in different O.S and with different network libraries. If somebody will leverage of my results for his benefit I'm happy.

The cases than I previously exposed are only preliminary tests for conclude what tool I should use for a certain project. And finally I conclude that Ostinato is a good tool for functional testing not for performance. Probably I could do some tunning in the kernel (I done previously for storage systems) and in other points of the NIC but for this preliminary tests is enough with the tests done. 

Thanks and Ostinato is a great tool, I don't have intention of say the opposite never.

Best regards,

Mariano. 

[Srivats P]

This is a very interesting and pertinent discussion wrt Ostinato.

Having just released 0.8, my mind is refusing to even think and
comprehend at this point. So I'm taking some downtime to recoup and
refresh.

Will reply back soon.

Srivats

--
http://ostinato.org/
@ostinato

[mia...@gmail.com]

hi I have a question if I want to change the identification field of the packet within the same stream how can I do that (I mean if i have 5 packets within the same stream I  want an identification field different for each one of them ) how can I implement that in ostinato ??? 

[Srivats P]

Use variable fields when configuring the stream

On 08-Mar-2017 4:50 AM, <mia...@gmail.com> wrote:

hi I have a question if I want to change the identification field of the packet within the same stream how can I do that (I mean if i have 5 packets within the same stream I  want an identification field different for each one of them ) how can I implement that in ostinato ??? 

--

Get Ostinato News and Updates on Twitter - Follow @ostinato (http://twitter.com/ostinato)
---

You received this message because you are subscribed to the Google Groups "ostinato" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ostinato+unsubscribe@googlegroups.com.

[Jimit Salvi]

Hi,
Is it possible to use SRIOV network port to increase throughput for Ostinato?

Thanks,

-Jimit

[Geoffrey Lisk]

Jimit:

  In my experience, the SR-IOV extensions are necessary if you are using Ostinato from a VM.  As I am sure you have found, using Ostinato from a VM without SR-IOV can be...  challenging.  :-)  With SR-IOV you can expect close to 9Gbps from a VM.

Obviously, if you are running on "bare metal" then you do not need them.

Good Luck

--

Get Ostinato News and Updates on Twitter - Follow @ostinato (http://twitter.com/ostinato)
---
You received this message because you are subscribed to the Google Groups "ostinato" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ostinato+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Geoffrey Lisk - Principal Architect +1 602 850 5366  www.limelight.com Delivering Faster Better

Join the conversation at Limelight Connect

[Srivats P]

Geoffrey,

I'm curious - at what packet size did you get 9Gbps?

Srivats

Creator, Ostinato

http://ostinato.org/
@ostinato

[Jimit Salvi]

Hi Geoffery,
I was able to achieve close to 7.4Gbps traffic rate at 9000 MTU using SRIOV. Can you please share your experience as to how you managed to achieve 9Gbps.


Thanks,
Jimit

On Wednesday, January 10, 2018 at 8:37:18 AM UTC-5, Srivats P wrote:

Geoffrey,

I'm curious - at what packet size did you get 9Gbps?

Srivats

Creator, Ostinato

On Tue, Jan 9, 2018 at 11:05 PM, Geoffrey Lisk <gl...@llnw.com> wrote:

Jimit:

  In my experience, the SR-IOV extensions are necessary if you are using Ostinato from a VM.  As I am sure you have found, using Ostinato from a VM without SR-IOV can be...  challenging.  :-)  With SR-IOV you can expect close to 9Gbps from a VM.

Obviously, if you are running on "bare metal" then you do not need them.

Good Luck

On Tue, Jan 9, 2018 at 9:05 AM, Jimit Salvi <jimits...@gmail.com> wrote:

Hi,
Is it possible to use SRIOV network port to increase throughput for Ostinato?

Thanks,

-Jimit

On Wednesday, August 17, 2011 at 7:24:58 PM UTC-4, Luca Deri wrote:

Hi all,
I have made some changes to my open-source PF_RING library (see http://www.ntop.org/PF_RING.html) so that ostinato could use it. You can now use ostinato to generate traffic at 10 Gbit using commodity hardware (no costly FPGA-based NICs are needed). The result is described on http://www.ntop.org/blog/pf_ring/building-a-10-gbit-traffic-generator-using-pf_ring-and-ostinato/. Perhaps some of you might be interesting in using it too.

Enjoy Luca

--

Get Ostinato News and Updates on Twitter - Follow @ostinato (http://twitter.com/ostinato)
---
You received this message because you are subscribed to the Google Groups "ostinato" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ostinato+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Geoffrey Lisk - Principal Architect +1 602 850 5366  www.limelight.com Delivering Faster Better

Join the conversation at Limelight Connect

--
Get Ostinato News and Updates on Twitter - Follow @ostinato (http://twitter.com/ostinato)
---
You received this message because you are subscribed to the Google Groups "ostinato" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ostinato+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://ostinato.org/
@ostinato

[Geoffrey Lisk]

​I apologize for confusing issues.  The 9Gbps I was able to achieve with SR-IOV came from iperf3. :-(   I have been able to achieve 9Gbps using SR-IOV but have not yet achieved that using Ostinato inside a VM.  I assumed that because I was able to get 9Gbps with iperf3 that the reason Ostinato was *not* able to achieve the 9Gbps (I got somewhere in the neighborhood of 7Gbps like you) was user error on my part.  I assumed that I needed to do some further kernel parameter tuning but have not had the time to follow-up.  

To show what is possible with SR-IOV, this is a direct VM-to-VM transfer, hairpinned through an Arista switch.  I put the VFs on the same VLAN and made the switch-server link a trunk.  Yes, there is some error in bandwidth calculation on iperf3's part.  The number I calculated from SNMP counters had the transfer at around 9.8Gbps.

root@trafgen:/home/labrat# iperf3 -c 10.100.1.101 -w 4M 

Connecting to host 10.100.1.101, port 5201

[  4] local 10.100.1.10 port 60234 connected to 10.100.1.101 port 5201

[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd

[  4]   0.00-1.00   sec  1.35 GBytes  11.6 Gbits/sec    0    397 KBytes       

[  4]   1.00-2.00   sec  1.35 GBytes  11.6 Gbits/sec    0    397 KBytes       

[  4]   2.00-3.00   sec  1.17 GBytes  10.1 Gbits/sec    0    397 KBytes       

[  4]   3.00-4.00   sec  1.27 GBytes  10.9 Gbits/sec    0    397 KBytes       

[  4]   4.00-5.00   sec  1.27 GBytes  10.9 Gbits/sec    0    397 KBytes       

[  4]   5.00-6.00   sec  1.29 GBytes  11.1 Gbits/sec    0    397 KBytes       

[  4]   6.00-7.00   sec  1.16 GBytes  9.99 Gbits/sec    0    397 KBytes       

[  4]   7.00-8.00   sec  1.15 GBytes  9.85 Gbits/sec    0    397 KBytes       

[  4]   8.00-9.00   sec  1.15 GBytes  9.86 Gbits/sec    0    397 KBytes       

[  4]   9.00-10.00  sec  1.14 GBytes  9.83 Gbits/sec    0    397 KBytes       

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval           Transfer     Bandwidth       Retr

[  4]   0.00-10.00  sec  12.3 GBytes  10.6 Gbits/sec    0             sender

[  4]   0.00-10.00  sec  12.3 GBytes  10.6 Gbits/sec                  receiver

iperf Done.

root@trafgen:/home/labrat# 

Warm regards,

-Geoff

On bare metal I can get (effectively) 10Gbps with a 9100-byte packet size.​

To unsubscribe from this group and stop receiving emails from it, send an email to ostinato+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Srivats P]

One reason why iperf will provide better in a pure bandwidth test is because it operates on the TCP/UDP socket level whereas Ostinato operates on a L2 packet level. This level difference means that across one system call (context switch from user to kernel), iperf can transfer data worth multiple packets on the wire whereas one system call is needed for every packet in case of Ostinato. So Ostinato will experience multiple context switches (leading to more overhead cost) compared to iperf.

Srivats

http://ostinato.org/
@ostinato

[Geoffrey Lisk]

Yes, the CPU requirement for the syscalls put an upper limit on what we can hope to achieve, but ​I still believe there may be some efficiencies to be gained by tuning.  I was using a completely stock system when doing my testing.​

Just so I am clear, I do not believe this diminishes the value of Ostinato as a tool in any way. :-)