When you download a 100MB file you will deplete the burst size at 8mbps. The burst size counter is depleted as you download over 2mbps, and replenished when you download under 2mbps. For example a common implementation would have the following values (I haven't worked with Cisco QOS much, so it may be implemented differently but the principals are the same): You can set a sustained rate, peek rate, and burst size.

Most shapers (including the ones in their broadband routers) allow a variety of parameters. There may be other outbound queues within the shaper to provide fair queuing and such, but that gets too complicated for this post. They are going to shape all the traffic going to your cable modem as a single stream. They aren't shaping based on individual downloads. Is there any valid reason why Comcast would front-load transfers in this way, or is it merely an effort to prevent end-users from being able to assess their bandwidth accurately? Does anybody know of other ISPs using similar practices?' Doing a download and upload test using a significantly large file (100+ MB) yields results more in line with everyday usage experience, usually about 1.2 Mbps down and about 250 Kbps up (but it varies). (This can be quite annoying when trying to determine whether a client needs to switch over to a T1 or if their current ISP will suffice.) Upon further investigation, it appears that Comcast is delivering this bandwidth only for a few seconds after any new request and it is immediately throttled down. Of course, clients get nowhere near this performance in everyday usage. Over the last few months, I have noticed that any time I run any type of bandwidth testing for clients with Comcast accounts, the results have been amazingly fast - with some connections, Speakeasy will report up to 15 Mbps down and 4 Mbps up. Dynamo52 writes 'I'm a freelance network admin serving mainly small business clients.

Download speed test comcast