4 ms·
"There’s another overly-fat-pipe symptom that’s been increasingly in my face. I routinely copy big files here and there around the Internet, most commonly from
by gvb 16y ago
"There’s another overly-fat-pipe symptom that’s been increasingly in my face. I routinely copy big files here and there around the Internet, most commonly from my laptop to tbray.org." ...and then Tim describes a symptom of a fast initial burst followed by a much lower average transfer rate.
Note he is going external (over the internet). The problem is quite likely traffic shaping by his ISP. I would contend it isn't really a "fat pipe" issue so much as his ISP ...um... stretching the truth with respect to how much bandwidth they really can give to him. ISPs are in a "bandwidth battle" (kind of like the CPU clock rate wars) - they advertise the maximum bandwidth that they can theoretically provide, but if all subscribers tried to use that much bandwidth at once, the ISP does not have the back-end infrastructure to handle it. As a result, the ISP does traffic shaping: transfers a short burst (the initial burst in the case of a big file transfer) at maximum speed and then throttles the connection so that the average bandwidth doesn't overwhelm their back-end capabilities.
- jedsmith 16y agoI observe this with "PowerBoost", and that was the first thing I thought of when I read what he was describing.
- detst 16y agoI love the marketing. "PowerBoost, the few seconds before we throttle your connection."
- wmf 16y agoA simpler explanation is that he's seeing TCP buffering; scp probably counts data as sent after write(), not after it has been ACKed. Also, all the bursting I've seen by ISPs is above the nominal speed.
- fhars 16y agoThere is no way that the observed behaviour is caused by traffic shaping, as that would require a residential DSL line with a raw upstream bandwidth of roundabout 6GBit/s. (Otherwise it could never fit the initial 700MB/s.)