[STL] RX/TX/DroP bps counter

[andyb...@googlemail.com]

Hi,

 

…sorry for spamming the list, but I thought it might be better to open a separate thread for each topic 😊

 

We’re running STL streams in our test-environment, it looks like the DUT is dropping some packets (even in medium-load situations). To show TX/RX/drop BPS I use Grafana (see attachment rx-tx-diff-4.png). When running in loopback-setup, there’s no diff between RX and TX and drop-bps is zero. But in this example, rx is smaller than tx (250 mbps), but the drop-bps-counter ist still 0 ? When sending way more traffic than the DUT can handle, drop bps increases (see rx-tx-diff-with-drops.png).

 

How can I explain the difference between (tx-rx) != drops ? Is there any explanation, that’s caused by implementcation-specific details? Or should the counters be exact?

 

 

Thanks,

 

Andreas

 

[hanoh haim]

Drop counter is an estimation. We don’t have a marker for every packets.

To be sure if there is a drop you should stop the test and read the counters.

Latency streams could be a real time indicator but not at max speed due to seq numbers inside the packet.

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+u...@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/043c01d412e9%2435164980%249f42dc80%24%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.

--

Hanoh

Sent from my iPhone

[Andreas Bourges]

Hi Hanoch,

...customer needs a more precise drop estimation. My guess was to just subtract the m_total_rx_bytes from m_total_tx_bytes on a per second bases (knowing, that time of measurement may lead to not 100% correct values). But when looking at the rx/tx counters - they show much lower throughput than what I get from m_total_tx_bps/m_total_rx_bps ?! I think I read s.th. about XL710 not having byte-counters ... Could that be the issue?

Any recommendation to calculate the drop-rate from existing counters in a more precise way than using drop-bps ?

Thanks,

Andreas

[Andreas Bourges]

sorry - looking at ASTF right now - but probably a similar problem with stl (which I will look into once AST is resolved...)

[Andreas Bourges]

Ah - I could just subtract Rx/tx bps counters...?!?

[hanoh haim]

You could. You can subtract the delta of total bytes in a specific window of time (e.g 100 msec) which could be more accurate.

Bps is calculated as a low pass filter, so your read is a temporary read from specific time.

I’m not aware of any counter issue with XL710 except STL per stream stats in HW supports only pkts and not bytes

Thanks,

Hanoh

On Thu, 5 Jul 2018 at 19:57 'Andreas Bourges' via TRex Traffic Generator <trex...@googlegroups.com> wrote:

Ah - I could just subtract Rx/tx bps counters...?!?

--
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+u...@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/e6155cf7-4602-4784-8594-396c43a8d761%40googlegroups.com.

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

[smura...@gmail.com]

"Bps is calculated as a low pass filter, so your read is a temporary read from specific time."

I assume the same is true for pps? This means even if the duration of a test was 60 seconds, the returned value is not averaged across the 60 seconds? (sorry I dont really grasp the concept of low pass filter enough)

So reading the total number of packets divided by test duration, would always be more stable?

I am asking as if reading rx pps, the numbers vary from run to run , upto 5-6%.

[Matt Callaghan]

are you using the `rx-check` feature?

https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_flow_order_latency_verification