Since we now create an explicit packet set even for interleaved mode, we can
calculate and use the packet set delay instead of using the list loop delay.
With this change both sequential and interleaved mode do not use list loop
delay at all, but we still retain the code for that - in case we need to use
it later for some reason.
Creation of explicit packet sets had both a packet set delay and a list loop
delay set leading to lower than configured rate at tx. Earlier implicit
packet set always had set delay as 0 and only list loop delay was used.
Fix is to always set list loop delay to 0 in sequential mode as packet set
will have the correct delay set due to explicit packet sets.
Crash was due to loopDelay being 0 in case of topSpeed. For ttags, we
recalculatue loopDelay based on max line rate and avg pkt size.
The problem doesn't exist in interleaved mode because minGap and duration
are non-zero in the top speed tx case.
Tx/Rx stream stats related threads no longer have a direct reference to the
port's stream stats - instead they have their own copy that they keep and
return (in a reset-on-read fashion) when asked for. Each copy also has it's
own lock to prevent contention for read/update/clear.
PcapPort now fetches Tx(Transmitter) and Rx(Poller) stats on demand and
updates the port's stream stats - under protection of a lock.
The interleaved mode's single packet set MUST always have 0 delay
for accurate rate.
Before latency code, the interleaved packet set was added implicitly
and had 0 delay. Latency code added explicit packet set and used
avgDelay for the set. The avgDelay was needed for the original algo
used to determine when to send ttag packets. That algo is no longer
used (ttag markers are now explicitly configured by AbstractPort).
Turbo still needs avgDelay for other use, but changes will be made in
Turbo code for that.
In a previous commit, we start/stop these timers based on number of
ports tracking stream stats triggered by RPCs. However, timers cannot
be triggered across threads (RPC thread and main thread in this case).
This fix uses a queued connection to post it to the other queue.
The previous commit changed the algo to determine which packets were Ttag'd,
but changes were done only for interleaved mode.
This commit adds the changes required for sequential mode.
The algo works for the following cases of interleaved streams -
* pktListDuration < ttagTimeInterval
* pktListDuration > ttagTimeInterval
* some streams have Ttag, some don't
- first stream has Ttag
- first stream does NOT have Ttag
* no streams have Ttag
Changes for sequential mode are pending
Interleaved mode used an implicitly added packet set in both base and Turbo
code. This has been chaned to use an explicit mode to keep things consistent.
Turbo code still has the implicit packet set related code - that needs to be
removed, once the explicit packet set code is validated and tested.
When building packets in interleaved mode, we do 2 passes over the
streams.
In the first pass, we build a number of lists of variables for each
**enabled** stream. One of these variables is the pktBuf content.
In the second pass, we use these lists to build the packets. If the
stream is not variable, we just use the packet content built in the
first pass. However, if the stream is variable we call frameValue to get
the packet content, but we index with the wrong value into stream list
if we have some disabled streams before us.
Fixes#328
* Rename track_stream_stats to is_tracking_stream_stats for consistency
with other bool params
* Change signature magic value to CODA
* Resolve notify memory leak
Start/StopStreamStatsTracking() methods made private helper functions
specific to PcapPort. AbstractPort::setStreamStatsTracking() virtual
function should be implemented by subclasses as required
