Cable modems do rate limiting (or rather, the headend equipment does).
This can be done in at least two ways:

a) "accurately", where a packet is dropped if the recent average is
above the rate limit, or something like that.  Of course, only
transmitted packets count towards the average.

b) "1 second granularity", where each second, enough data is let
through to hit the rate limit * 1s, and then all data is dropped until
the next second.

With (b), TCP opens the congestion window way up, since it is seeing a
pipe with a 6 Mb/s or so capacity - whatever the line rate is in the
cable system, which is higher than the allowed rate.  Then it hits the
blackout period, and multiple segments are dropped.  This forces TCP
into slow start.

Your description sounds similar, but the time constants are a bit
large, although you are looking at progress bars, not packet traces.


I ran into the above when a friend's cable modem was acting broken in
a similar way; another friend in a different town's was not showing
the issue and was getting TCP downloads at the rate limit.  Oddly, the
download speed was slightly better during evenings, which makes sense,
since then TCP doesn't open up so quickly.

We captured traces with tcpdump, and I used tcpdump2xplot to view them
(install /usr/pkgsrc/graphics/xplot to get this).  I was seeing rapid
transfers followed by slow start, and comparing traces from both ends
of the TCP connection showed multiple dropped packets.

Amazingly, giving a copy of all this data to a regular field tech (the
kind that fix bad wiring and adjust the variable taps to equalize the
upstream signal levels) resulted in the tech showing this to the
router guy at the headend - the problem went away at 1 am a few days
later.  Cisco has some docs on how to configure a vs b on some of
their cable headend equipment.

-- 
        Greg Troxel <gdt@ir.bbn.com>