In short: yes, too much latency can lower your total bandwidth, and the effect is more pronounced on serial-type connections - ie: connection which can not transfer any more data until an ACK for previous transmission is received.
The latency/bandwidth correlation become a problem only when the two values are much apart, for example having a very "wide", but high latency, link (or vice-versa - a very low latency but extremely "narrow" link).
Let me do an example using something as simple as a ping of 32 bytes on a WAN connection with about 50 ms latency (100 ms RTT). With such a connection, you can send a maximum of 10x 32b pings, for a grand total of 320b/s only in each direction! It is not a surprise that ping floods explicitly do not wait for the other party confirmation, or the flood would be non-existent.
If you can't lower latency, how can you work around the problem? Mainly using two ways:
- sending larger packets (eg: using 1400 bytes sized pings);
- sending more packets before waiting for confirmation.
TCP uses both systems: after a streaming connection is established (eg: a download is started), it both increases packet size up to a maximum value (the MSS - maximum segment size) and the number of packet sent without waiting for any confirmation/ack - aka TCP window scaling. Much work was spent on creating network stack capable of dynamically adjust the TCP window scaling, so this rarely needs to be manually adjusted nowadays. However, sometime a bad network driver and/or a strange corner case can prevent correct scaling, leading to reduced bandwidth.
Protocols which does not natively implement a window scaling (ie: IP and UDP) are more sensible to the bandwidth problem, and generally need assistence from the higher level application (where possible) or specific system tuning (for example, increasing maximum packet size, know as MTU).
Clearly, WAN connections are, due to their intrinsics higher latency, more prone to the problem. However, even very fast local connections can be affected.
Cases in point:
- on a 10 Gb/s ethernet network, with ping RTT in the range of 0.05 ms, I initially achieved only about 30-40% of the total available bandwidth. Increasing the interface MTU to 9000 bytes (up from the standard 1500 bytes) completely solved the problem;
- on a Gigabit ethernet connection, an Athereos interface driver interacted with the Linux network stack in a manner that prevented the TCP window to "open" to its maximum value, reducing performance. Manually setting an TCP window solved the problem.