This is not scp's fault, it really is buffer bloat. It is noticeable in DSL connections, but it is worst with 3G connections.
When I run some (down/up)loads via my UMTS dongle, I easily fill the buffer in my modem, the buffers at my ISP. I can still ping remote hosts, with a latency of up to 60 seconds. The problem is, TCP doesn't understand what happens, because the packets get acknowledged after all. Only eventually my TCP connections throttle themselves, and it reaches a somewhat stable balance where the buffer still introduces about 10 to 20 seconds of lag.
The solution for me was to shape my own traffic on the edge of my "network" and to never let the buffer be filled in the first place. This leads to a much better ping (< 1 second) and a higher bandwidth utilization (when looking at the big picture).
Don't you think the slow part is the link between your modem and the ISP? My guess is that the buffer you are filling is your TCP write buffer. If I make mine tiny, then scp reports what my bandwidth actually is.
I blame scp because it chooses a moving-average algorithm instead of an instantaneous rate-of-change measurement.
I don't have this problem with my UMTS dongle; ping times are about half a second, but TCP works fine at this latency. You need a big buffer to keep the data flowing, though.
When I run some (down/up)loads via my UMTS dongle, I easily fill the buffer in my modem, the buffers at my ISP. I can still ping remote hosts, with a latency of up to 60 seconds. The problem is, TCP doesn't understand what happens, because the packets get acknowledged after all. Only eventually my TCP connections throttle themselves, and it reaches a somewhat stable balance where the buffer still introduces about 10 to 20 seconds of lag.
The solution for me was to shape my own traffic on the edge of my "network" and to never let the buffer be filled in the first place. This leads to a much better ping (< 1 second) and a higher bandwidth utilization (when looking at the big picture).