ASTF mode traffic could not stop in time when the actual CPS is lower than expected

[chenbq83]

We meet an issue that the traffic could not stop in time when the actual CPS is lower than expected.
Trex does not stop the traffic after the duration, but continue injecting new flows.

Suppose in a test case, the expected cps is 100, and the duration is 120s, the total flows is 12000. but if due to some performance issue, the actual cps is not 100, but 50, then it would take extra 120s to inject 12000 flows.
The behavior of the trex is: at the end of duration, 120s, trex does NOT stop the traffic, but continue injecting new flows until all 12000 new flows are done. This takes much longer than expected.

The "duration" in start() means: Start new flows for this duration. Negative value means infinite
https://trex-tgn.cisco.com/trex/doc/cp_astf_docs/api/client_code.html

This behavior contradicts the definition of "duration", which specifies that new flows should only start ​within the configured duration.
Is it a bug?

The code leading to such behavior is here

trex-core/src/bp_sim_tcp.cpp

Line 642 in 10e1d19

if (node->m_time_stop && m_cur_time_sec >= node->m_time_stop) {

the node->m_time is used to check if the duration ends.
While, problably the realtime now_sec() should be used here.