BTW, I haven't studied it, but some of the later TCP variants, I believe, watch for sudden jumps in latency, which often indicates congestion. When such a TCP variant believes there's congestion, it could go into congestion avoidance. I.e. basically, and possibly, the same effect as if classical TCP notes a packet drop. This might account for the classical TCP saw tooth throughput graph even without drop.
Also, similar to my prior reply, drops and/or congestion delay need not be happening on the device whose stats you're recording. Anywhere along the path would cause the flow rate to vary as seen.
If what I've described is happening, it would take a bit of work to demonstrate that's the actual cause. However, an alternative approach, would be to determine if PTRG has some "issue". If you use a non-TCP bandwidth test tool, saturate your monitored port(s) at a rate 5 to 10% above capacity. Then see if PTRG shows a "flatline" rate.
