[GRLUG] NOT LINUX - broadband test

[Michael Mol]

On Sun, Jun 27, 2010 at 12:40 PM, Bob Kline <bob.kline at gmail.com> wrote:
> On Sun, Jun 27, 2010 at 11:13 AM, Michael Mol <mikemol at gmail.com> wrote:
>> On Sun, Jun 27, 2010 at 10:58 AM, Bob Kline <bob.kline at gmail.com> wrote:
>> > On Sun, Jun 27, 2010 at 9:55 AM, John-Thomas Richards
>> > <jtr at jrichards.org>
>> > wrote:
>> >> On Sun, Jun 27, 2010 at 08:44:26AM -0400, Luan Pham wrote:
>> >> > On Sat, 2010-06-26 at 20:57 -0400, John-Thomas Richards wrote:

[snipped]

>>
>> As I mentioned earlier, if you have Comcast, you have SpeedBoost. If
>> you have SpeedBoost, your transfer rate cap changes over the course of
>> the transfer.  A 1MB file will have a different average transfer rate
>> from a 1GB file, because that 1GB file will see a throughput drop
>> somewhere early into the file.  What you *really* want to do is
>> measure your throughput along 10s intervals over the course of a 2min
>> transfer.  You should be able to find where SpeedBoost drops out
>> there.
>>
>
> Indeed.  Speedboost give a 25% boost.
> Time?  Clearly if it didn't cut out you'd
> have a higher speed service.  I don't have
> a hard number handy, but it takes a pretty
> large file to get past it.  The goal seems to
> be to provide the higher speed for a large
> fraction of what you do, and in my experience
> it does that.

I see it *regularly*, but primarily because my largest bandwidth
usages are uploading large photosets. I'm paying for the 6Mb/s
service, so 19Mb/s is a HUGE amount higher than a "25% boost".

> But it doesn't seem to be that simple.
> Downloading large things, like a Linux
> distribution, I've also seen the speed go
> substantially above the nominal rate, well
> in to the transfer.
> I've also seen rates of 34 Mbps early on
> a weekend morning.  I still have the tests.
> It seems that Comcast was testing something.
> Again, I could download a large file, and
> directly test the rates - I didn't simply rely
> on someone's speed-o-meter.

My argument is that simply taking a start, end and time is
insufficient when measuring your bandwidth--*especially* when you're
considering things like how long until a transfer is completed. I'm
beginning to think that "response curves" like what laptops use to
predict battery life might soon be applicable to download ETAs. There
are consistent, accountable variances in throughput.

> Now one can go on and on about what all

Apparently.

-- 
:wq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.