Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Drops (anywhere end-to-end) against TCP flows will very much slow their performance. Don't recall whether this particular TTCP program provides additional TCP stats, such as retransmits. (I recall Cisco's IOS hidden TTCP command [only in some/few IOS images] can.)
For TCP to saturate a link, receiving host's RWIN must be at least large enough for the path's BDP (usually not an issue for Windows' clients with the NextGen stack; Vista and later, but often worth checking).
Devices along the way also need to be able to buffer slow start TCP transmission window expansion.
TCP does take time to ramp up to full speed; very dependent on end-to-end latency. A small enough transmission window might not reach full transmission speed as it could still be ramping up. Quick test of that, with TTCP, increase total amount of transmission data (for example, increase from 16 MB to 32 MB and see if overall speed jumps; take special note if you monitor transmission rate whether it continues to increase over time of the transmission test).
