remote push doesn't load more than 5Gbps

[Franck Malka]

Hello,

I am using remote push to injest a 7GB pcap file.

No matter what I try, I can't get the output throughput to more than 5-6Gbps.

What would be the better way to send the pcap payloads at higher speed?

-Franck.

[Besart Dollma]

Hi Franck,

Not sure what the size of the PCAP file has to do with the throughput.

Have you changed the speedup field in push_remote? https://trex-tgn.cisco.com/trex/doc/cp_stl_docs/api/client_code.html?highlight=push_remote#trex.stl.trex_stl_client.STLClient.push_remote

Thanks 

[Franck Malka]

Yes, sure no matter what value i put in the speedup field, i still get the same throughput speed.

The file size is relevant because if i use a local push with a small pcap file, then i can go higher in throughput with no problem.

The large file can be used only with the remote push and in this mode it looks like i hit a limitation but i can't see what it is.

-Franck.

[Besart Dollma]

The moment you said remote push the file limitation becomes irrelevant. 

I am taking a guess here, I will need to check this better in code but I think that since we don't limit file sizes, we can't load them in memory. Hence the bottleneck would be disk read. However, let me check this better and get back to you.

[hanoh haim]

Hi Franck, 

Remote pcap is limited to one core and the read disk IO speed is the limiting factor. 5Gb/sec is ~ 600MB/sec IO read speed which makes sense for high speed HDD or low speed SSD.

Thanks

Hanoh

[Franck Malka]

So you think a ramdisk will bring up the performance?

--
You received this message because you are subscribed to a topic in the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/trex-tgn/6NgtCU-5X7g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to trex-tgn+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/CA%2BYxBo%2B3P7%3DMknRc-B-bMvsK%2BkyumS5mqE-8KcD90t9XiGiFKg%40mail.gmail.com.

[hanoh haim]

Hi Frank, 

Good question, the next limit will be the number of cores, which is one that can read the file and parse it, 

You might have a higher rate, but not the speed you can do with raw streams. 

Thanks

Hanoh

[Franck Malka]

So what would be recommended if i need to send large amount of telecom packets in the right order at high speed?

[hanoh haim]

Hi Franck,

You can add a feature to trex to push multiple files with multiple cores (file in RAM). 

Try to verify what is the speed from ram disk file with one core first

Thanks

Hanoh

[Franck Malka]

ramdisk doesn't improve the speed.

so i guess i am hitting the limitation of a single core

[Boris Pismenny]

Hi Hanoch,

I'm experiencing the same problem. Was there any change in this front?

Thanks,

Boris.

[Franck Malka]

To workaround this issue i created multiple VF on the same port, so i ended with one core per VF instead of one core for the entire physical port. But this was possible only because i was on a virtual environment.

-Franck.

--

You received this message because you are subscribed to a topic in the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/trex-tgn/6NgtCU-5X7g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to trex-tgn+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/5a46fbd1-d114-4773-841d-bd59f55df854n%40googlegroups.com.

[Jean Prince MELLO NGUIE]

Hello everyone,

I got recently a similar issue with TRex when I was trying to replay a huge pcap (around 7 GB size) which was stored on remote server.
The problem is I was limited to around 700 Mbps in Tx.

To solve that, I  had copied the pcap file in my /de/shm then when I had replayed the pcap again, I had reached 3.5 Gbps in Tx.
Hoping that, this could help someone.

Jean Prince

[ALI RAZA]

Tell me how you push traffic on remote, and if you can, send me a script in Python.