[Bismark-devel] about ready to do another build

[Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

Aside from chrome and an overaggresive default for the shaper (good numbers
from the field, please) I'm unaware of any package changes that has landed
since yesterday.

I'm about to do another build in 2 hours.

Anyone?


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 424 bytes --]

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

I'll be happy to test it out.

On May 20, 2011, at 10:27 PM, Dave Taht wrote:

> Aside from chrome and an overaggresive default for the shaper (good numbers from the field, please) I'm unaware of any package changes that has landed since yesterday.
> 
> I'm about to do another build in 2 hours.
> 
> Anyone?
> 
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com 
> _______________________________________________
> Bismark-devel mailing list
> Bismark-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bismark-devel

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

btw, I think we will have to disable QoS for the deployments anyhow initially, since we wont get accurate measurements with the shaper turned on.

-Nick

On May 20, 2011, at 11:40 PM, Nick Feamster wrote:

> I'll be happy to test it out.
> 
> On May 20, 2011, at 10:27 PM, Dave Taht wrote:
> 
>> Aside from chrome and an overaggresive default for the shaper (good numbers from the field, please) I'm unaware of any package changes that has landed since yesterday.
>> 
>> I'm about to do another build in 2 hours.
>> 
>> Anyone?
>> 
>> 
>> -- 
>> Dave Täht
>> SKYPE: davetaht
>> US Tel: 1-239-829-5608
>> http://the-edge.blogspot.com 
>> _______________________________________________
>> Bismark-devel mailing list
>> Bismark-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bismark-devel
> 
> _______________________________________________
> Bismark-devel mailing list
> Bismark-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bismark-devel

Re: [Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

On Fri, May 20, 2011 at 3:41 PM, Nick Feamster <feamster@cc.gatech.edu>wrote:

> btw, I think we will have to disable QoS for the deployments anyhow
> initially, since we wont get accurate measurements with the shaper turned
> on.
>
>
And your customer experience will be poor, and you will be measuring tcp/ip
malfunctioning rather than working properly.

How hard would it be for your scripts, when doing bandwidth testing, to do a


/etc/init.d/qos stop
do the test
/etc/init.d/qos start

When do they do bandwidth testing? What script does it?

-Nick
>
> On May 20, 2011, at 11:40 PM, Nick Feamster wrote:
>
> > I'll be happy to test it out.
> >
> > On May 20, 2011, at 10:27 PM, Dave Taht wrote:
> >
> >> Aside from chrome and an overaggresive default for the shaper (good
> numbers from the field, please) I'm unaware of any package changes that has
> landed since yesterday.
> >>
> >> I'm about to do another build in 2 hours.
> >>
> >> Anyone?
> >>
> >>
> >> --
> >> Dave Täht
> >> SKYPE: davetaht
> >> US Tel: 1-239-829-5608
> >> http://the-edge.blogspot.com
> >> _______________________________________________
> >> Bismark-devel mailing list
> >> Bismark-devel@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/bismark-devel
> >
> > _______________________________________________
> > Bismark-devel mailing list
> > Bismark-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bismark-devel
>
>


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 2795 bytes --]

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

Srikanth, Walter --- please chime in.

Dave has a point here about the possibility of stopping QoS during testing.

Thoughts?

-Nick


On May 21, 2011, at 12:11 AM, Dave Taht wrote:

> And your customer experience will be poor, and you will be measuring tcp/ip malfunctioning rather than working properly. 
> 
> How hard would it be for your scripts, when doing bandwidth testing, to do a 
> 
> /etc/init.d/qos stop
> do the test
> /etc/init.d/qos start
>  
> When do they do bandwidth testing? What script does it?

Re: [Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On Fri, May 20, 2011 at 4:12 PM, Nick Feamster <feamster@cc.gatech.edu>wrote:

> Srikanth, Walter --- please chime in.
>
> Dave has a point here about the possibility of stopping QoS during testing.
>
> Thoughts?
>

Well, actually, doing this this way, would get some GREAT data from the
field that simply doesn't exist right now...

/etc/init.d/qos stop
do the test (which I assume includes shaperprobe and a bandwidth test)
/etc/init.d/qos start
do the bandwidth test

I've also been collecting data via usb sticks on these puppies. For slow
connections (less than 2MB/sec) the writes to stick and the dump do not seem
to permute the results much.


>
> -Nick
>
>
> On May 21, 2011, at 12:11 AM, Dave Taht wrote:
>
> > And your customer experience will be poor, and you will be measuring
> tcp/ip malfunctioning rather than working properly.
> >
> > How hard would it be for your scripts, when doing bandwidth testing, to
> do a
> >
> > /etc/init.d/qos stop
> > do the test
> > /etc/init.d/qos start
> >
> > When do they do bandwidth testing? What script does it?
>
>


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 1869 bytes --]

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

On May 21, 2011, at 12:15 AM, Dave Taht wrote:

> Well, actually, doing this this way, would get some GREAT data from the field that simply doesn't exist right now...
> 
> /etc/init.d/qos stop
> do the test (which I assume includes shaperprobe and a bandwidth test)
> /etc/init.d/qos start
> do the bandwidth test

I really like this idea.

-Nick

Re: [Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

And btw, what are the results of a speedtest from your location without QoS
on?

With QoS on, set to up/dl values within a few percentage points of that (and
the overhead calculation disabled)

I can bake a better default into the next build, but I was figuring you'd be
lucky to be gettting 1000 down....

I want to note that according to your previous study, the first 30 seconds
of data need to be discarded in order for a speedtest to be valid, and
speedtest.net doesn't do that...


On Fri, May 20, 2011 at 4:16 PM, Nick Feamster <feamster@cc.gatech.edu>wrote:

>
> On May 21, 2011, at 12:15 AM, Dave Taht wrote:
>
> > Well, actually, doing this this way, would get some GREAT data from the
> field that simply doesn't exist right now...
> >
> > /etc/init.d/qos stop
> > do the test (which I assume includes shaperprobe and a bandwidth test)
> > /etc/init.d/qos start
> > do the bandwidth test
>
> I really like this idea.
>
> -Nick




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 1570 bytes --]

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

On May 21, 2011, at 12:28 AM, Dave Taht wrote:

> 
> And btw, what are the results of a speedtest from your location without QoS on?
> 

Have run it 2x now.

I see about 850 kbps down and 400 kbps up.

The default upload setting is abusive.

> With QoS on, set to up/dl values within a few percentage points of that (and the overhead calculation disabled)
> 
> I can bake a better default into the next build, but I was figuring you'd be lucky to be gettting 1000 down....
> 
> I want to note that according to your previous study, the first 30 seconds of data need to be discarded in order for a speedtest to be valid, and speedtest.net doesn't do that...

Yep yep... though I don't think PowerBoost is enabled over here.  Although, we'll find out. :-)

-Nick

Re: [Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

On Fri, May 20, 2011 at 4:35 PM, Nick Feamster <feamster@cc.gatech.edu>wrote:

>
> On May 21, 2011, at 12:28 AM, Dave Taht wrote:
>
> >
> > And btw, what are the results of a speedtest from your location without
> QoS on?
> >
>
> Have run it 2x now.
>
> I see about 850 kbps down and 400 kbps up.
>
> The default upload setting is abusive.
>

Sorry. Nicaragua typically had 64k-128k up. Took my best guess.


>
> > With QoS on, set to up/dl values within a few percentage points of that
> (and the overhead calculation disabled)
> >
>

And with QoS set to say 840/380, with the overhead calculation disabled?
Should be about 15% below that for a long bulk transfer. Can get closer...

Please note that setting these values on the basis of one datapoint in a
majorish city will result in bad values deeper in the country....

Helps to also ping somewhere at the same time of the test to see your
latencies start to go to heck as you get closer to the "edge". You'll see it
start to jitter... then go wildly late... and at extreme values, tcp/ip will
start to malfunction as per the bufferbloat diagrams...

I'd LOVE for a few tcpdumps of stuff like this, from where you are.....

> I can bake a better default into the next build, but I was figuring you'd
> be lucky to be gettting 1000 down....
> >
> > I want to note that according to your previous study, the first 30
> seconds of data need to be discarded in order for a speedtest to be valid,
> and speedtest.net doesn't do that...
>
> Yep yep... though I don't think PowerBoost is enabled over here.  Although,
> we'll find out. :-)
>
> -Nick




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 2651 bytes --]

Re: [Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

A much longer test would be to download this

wget -4
http://gw.lab.bufferbloat.net/capetown/capetown-wndr3700v2/OpenWrt-ImageBuilder-ar71xx-for-Linux-x86_64.tar.bz2

while pinging somewhere fairly close by.

Over your wired and wireless connection(s)...

Over multiple downloads, too...

Sorry to make you work so hard. I am SO OVERJOYED to get some data on this
problem, however.....

(yes, I'll change it to lab.bismarkproject.net as soon as DNS lands)

On Fri, May 20, 2011 at 4:42 PM, Dave Taht <dave.taht@gmail.com> wrote:

>
>
> On Fri, May 20, 2011 at 4:35 PM, Nick Feamster <feamster@cc.gatech.edu>wrote:
>
>>
>> On May 21, 2011, at 12:28 AM, Dave Taht wrote:
>>
>> >
>> > And btw, what are the results of a speedtest from your location without
>> QoS on?
>> >
>>
>> Have run it 2x now.
>>
>> I see about 850 kbps down and 400 kbps up.
>>
>> The default upload setting is abusive.
>>
>
> Sorry. Nicaragua typically had 64k-128k up. Took my best guess.
>
>
>>
>> > With QoS on, set to up/dl values within a few percentage points of that
>> (and the overhead calculation disabled)
>> >
>>
>
> And with QoS set to say 840/380, with the overhead calculation disabled?
> Should be about 15% below that for a long bulk transfer. Can get closer...
>
> Please note that setting these values on the basis of one datapoint in a
> majorish city will result in bad values deeper in the country....
>
> Helps to also ping somewhere at the same time of the test to see your
> latencies start to go to heck as you get closer to the "edge". You'll see it
> start to jitter... then go wildly late... and at extreme values, tcp/ip will
> start to malfunction as per the bufferbloat diagrams...
>
> I'd LOVE for a few tcpdumps of stuff like this, from where you are.....
>
>  > I can bake a better default into the next build, but I was figuring
>> you'd be lucky to be gettting 1000 down....
>> >
>> > I want to note that according to your previous study, the first 30
>> seconds of data need to be discarded in order for a speedtest to be valid,
>> and speedtest.net doesn't do that...
>>
>> Yep yep... though I don't think PowerBoost is enabled over here.
>>  Although, we'll find out. :-)
>>
>> -Nick
>
>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 4045 bytes --]

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

We actually have a test exactly like this in bismark active.  I'll give it a try.

Remember: people have data caps here. Another complication. :-)

Two questions:
1. What do you want lab.projectbismark.net pointing to?  I'll update the dreaded godaddy until DNS lands.
2. How do you run the babel multihop stuff?  Can I run it in this build?  I'm in a fairly big house with *zero* wireless connectivity downstairs and would like to try it out.  
I would like  Host <----wireless----> WNDR Relay <---wireless-->WNDR Relay <---wired ---> Modem
Not sure how to set up the relays.

Thanks,
-Nick

On May 21, 2011, at 12:47 AM, Dave Taht wrote:

> A much longer test would be to download this
> 
> wget -4 http://gw.lab.bufferbloat.net/capetown/capetown-wndr3700v2/OpenWrt-ImageBuilder-ar71xx-for-Linux-x86_64.tar.bz2
> 
> while pinging somewhere fairly close by.
> 
> Over your wired and wireless connection(s)...
> 
> Over multiple downloads, too...
> 
> Sorry to make you work so hard. I am SO OVERJOYED to get some data on this problem, however.....
> 
> (yes, I'll change it to lab.bismarkproject.net as soon as DNS lands)
> 
> On Fri, May 20, 2011 at 4:42 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> 
> On Fri, May 20, 2011 at 4:35 PM, Nick Feamster <feamster@cc.gatech.edu> wrote:
> 
> On May 21, 2011, at 12:28 AM, Dave Taht wrote:
> 
> >
> > And btw, what are the results of a speedtest from your location without QoS on?
> >
> 
> Have run it 2x now.
> 
> I see about 850 kbps down and 400 kbps up.
> 
> The default upload setting is abusive.
> 
> Sorry. Nicaragua typically had 64k-128k up. Took my best guess.
>  
> 
> > With QoS on, set to up/dl values within a few percentage points of that (and the overhead calculation disabled)
> >
> 
> And with QoS set to say 840/380, with the overhead calculation disabled? Should be about 15% below that for a long bulk transfer. Can get closer...
>  
> Please note that setting these values on the basis of one datapoint in a majorish city will result in bad values deeper in the country....
> 
> Helps to also ping somewhere at the same time of the test to see your latencies start to go to heck as you get closer to the "edge". You'll see it start to jitter... then go wildly late... and at extreme values, tcp/ip will start to malfunction as per the bufferbloat diagrams...
> 
> I'd LOVE for a few tcpdumps of stuff like this, from where you are.....
> 
> > I can bake a better default into the next build, but I was figuring you'd be lucky to be gettting 1000 down....
> >
> > I want to note that according to your previous study, the first 30 seconds of data need to be discarded in order for a speedtest to be valid, and speedtest.net doesn't do that...
> 
> Yep yep... though I don't think PowerBoost is enabled over here.  Although, we'll find out. :-)
> 
> -Nick
> 
> 
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com 
> 
> 
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com 

Re: [Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3903 bytes --]

On Fri, May 20, 2011 at 5:22 PM, Nick Feamster <feamster@cc.gatech.edu>wrote:

> We actually have a test exactly like this in bismark active.  I'll give it
> a try.
>
> Remember: people have data caps here. Another complication. :-)
>

Well, yea, but I wanted a good number to bake into the build which I'm
hovering over the build button for...



>
> Two questions:
> 1. What do you want lab.projectbismark.net pointing to?  I'll update the
> dreaded godaddy until DNS lands.
>

A problem is that the routers register themselves in DNS (or will), and we
need bind9 for that.

I hope to have real dns after meeting with netops monday.


2. How do you run the babel multihop stuff?  Can I run it in this build?
>  I'm in a fairly big house with *zero* wireless connectivity downstairs and
> would like to try it out.
> I would like  Host <----wireless----> WNDR Relay <---wireless-->WNDR Relay
> <---wired ---> Modem
> Not sure how to set up the relays.
>

Yes, you can do that. I'm tickled you're willing to try it...
There are a couple ways, but I'd prefer to get you through it in irc?



>
> Thanks,
> -Nick
>
> On May 21, 2011, at 12:47 AM, Dave Taht wrote:
>
> > A much longer test would be to download this
> >
> > wget -4
> http://gw.lab.bufferbloat.net/capetown/capetown-wndr3700v2/OpenWrt-ImageBuilder-ar71xx-for-Linux-x86_64.tar.bz2
> >
> > while pinging somewhere fairly close by.
> >
> > Over your wired and wireless connection(s)...
> >
> > Over multiple downloads, too...
> >
> > Sorry to make you work so hard. I am SO OVERJOYED to get some data on
> this problem, however.....
> >
> > (yes, I'll change it to lab.bismarkproject.net as soon as DNS lands)
> >
> > On Fri, May 20, 2011 at 4:42 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >
> >
> > On Fri, May 20, 2011 at 4:35 PM, Nick Feamster <feamster@cc.gatech.edu>
> wrote:
> >
> > On May 21, 2011, at 12:28 AM, Dave Taht wrote:
> >
> > >
> > > And btw, what are the results of a speedtest from your location without
> QoS on?
> > >
> >
> > Have run it 2x now.
> >
> > I see about 850 kbps down and 400 kbps up.
> >
> > The default upload setting is abusive.
> >
> > Sorry. Nicaragua typically had 64k-128k up. Took my best guess.
> >
> >
> > > With QoS on, set to up/dl values within a few percentage points of that
> (and the overhead calculation disabled)
> > >
> >
> > And with QoS set to say 840/380, with the overhead calculation disabled?
> Should be about 15% below that for a long bulk transfer. Can get closer...
> >
> > Please note that setting these values on the basis of one datapoint in a
> majorish city will result in bad values deeper in the country....
> >
> > Helps to also ping somewhere at the same time of the test to see your
> latencies start to go to heck as you get closer to the "edge". You'll see it
> start to jitter... then go wildly late... and at extreme values, tcp/ip will
> start to malfunction as per the bufferbloat diagrams...
> >
> > I'd LOVE for a few tcpdumps of stuff like this, from where you are.....
> >
> > > I can bake a better default into the next build, but I was figuring
> you'd be lucky to be gettting 1000 down....
> > >
> > > I want to note that according to your previous study, the first 30
> seconds of data need to be discarded in order for a speedtest to be valid,
> and speedtest.net doesn't do that...
> >
> > Yep yep... though I don't think PowerBoost is enabled over here.
>  Although, we'll find out. :-)
> >
> > -Nick
> >
> >
> >
> > --
> > Dave Täht
> > SKYPE: davetaht
> > US Tel: 1-239-829-5608
> > http://the-edge.blogspot.com
> >
> >
> >
> > --
> > Dave Täht
> > SKYPE: davetaht
> > US Tel: 1-239-829-5608
> > http://the-edge.blogspot.com
>
>


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 5878 bytes --]

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

1. Once you get real DNS, we want to also want to do redirection to the nearest measurement server for measurements.projectbismark.net, etc.
2.  babel, yep.  though it's 1:30a here and I might not try it tonight... last night, the faulty ethernet cable deprived me of sleep.  but, I do really want to try this out.  sounds awesome.  will look for you on IRC in any case.

-Nick

On May 21, 2011, at 1:27 AM, Dave Taht wrote:

> 
> 
> On Fri, May 20, 2011 at 5:22 PM, Nick Feamster <feamster@cc.gatech.edu> wrote:
> We actually have a test exactly like this in bismark active.  I'll give it a try.
> 
> Remember: people have data caps here. Another complication. :-)
> 
> Well, yea, but I wanted a good number to bake into the build which I'm hovering over the build button for...
> 
>  
> 
> Two questions:
> 1. What do you want lab.projectbismark.net pointing to?  I'll update the dreaded godaddy until DNS lands.
> 
> A problem is that the routers register themselves in DNS (or will), and we need bind9 for that.
>  
> I hope to have real dns after meeting with netops monday.
> 
> 
> 2. How do you run the babel multihop stuff?  Can I run it in this build?  I'm in a fairly big house with *zero* wireless connectivity downstairs and would like to try it out.
> I would like  Host <----wireless----> WNDR Relay <---wireless-->WNDR Relay <---wired ---> Modem
> Not sure how to set up the relays.
> 
> Yes, you can do that. I'm tickled you're willing to try it...
> There are a couple ways, but I'd prefer to get you through it in irc?
> 
>  
> 
> Thanks,
> -Nick
> 
> On May 21, 2011, at 12:47 AM, Dave Taht wrote:
> 
> > A much longer test would be to download this
> >
> > wget -4 http://gw.lab.bufferbloat.net/capetown/capetown-wndr3700v2/OpenWrt-ImageBuilder-ar71xx-for-Linux-x86_64.tar.bz2
> >
> > while pinging somewhere fairly close by.
> >
> > Over your wired and wireless connection(s)...
> >
> > Over multiple downloads, too...
> >
> > Sorry to make you work so hard. I am SO OVERJOYED to get some data on this problem, however.....
> >
> > (yes, I'll change it to lab.bismarkproject.net as soon as DNS lands)
> >
> > On Fri, May 20, 2011 at 4:42 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >
> >
> > On Fri, May 20, 2011 at 4:35 PM, Nick Feamster <feamster@cc.gatech.edu> wrote:
> >
> > On May 21, 2011, at 12:28 AM, Dave Taht wrote:
> >
> > >
> > > And btw, what are the results of a speedtest from your location without QoS on?
> > >
> >
> > Have run it 2x now.
> >
> > I see about 850 kbps down and 400 kbps up.
> >
> > The default upload setting is abusive.
> >
> > Sorry. Nicaragua typically had 64k-128k up. Took my best guess.
> >
> >
> > > With QoS on, set to up/dl values within a few percentage points of that (and the overhead calculation disabled)
> > >
> >
> > And with QoS set to say 840/380, with the overhead calculation disabled? Should be about 15% below that for a long bulk transfer. Can get closer...
> >
> > Please note that setting these values on the basis of one datapoint in a majorish city will result in bad values deeper in the country....
> >
> > Helps to also ping somewhere at the same time of the test to see your latencies start to go to heck as you get closer to the "edge". You'll see it start to jitter... then go wildly late... and at extreme values, tcp/ip will start to malfunction as per the bufferbloat diagrams...
> >
> > I'd LOVE for a few tcpdumps of stuff like this, from where you are.....
> >
> > > I can bake a better default into the next build, but I was figuring you'd be lucky to be gettting 1000 down....
> > >
> > > I want to note that according to your previous study, the first 30 seconds of data need to be discarded in order for a speedtest to be valid, and speedtest.net doesn't do that...
> >
> > Yep yep... though I don't think PowerBoost is enabled over here.  Although, we'll find out. :-)
> >
> > -Nick
> >
> >
> >
> > --
> > Dave Täht
> > SKYPE: davetaht
> > US Tel: 1-239-829-5608
> > http://the-edge.blogspot.com
> >
> >
> >
> > --
> > Dave Täht
> > SKYPE: davetaht
> > US Tel: 1-239-829-5608
> > http://the-edge.blogspot.com
> 
> 
> 
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com 

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

On May 21, 2011, at 12:47 AM, Dave Taht wrote:

> while pinging somewhere fairly close by.

trying to find a nearby site that doesn't actually filter pings.  hopefully this will be our server soon. :-)

Re: [Bismark-devel] about ready to do another build

[Srikanth Sundaresan]

My concern about QoS is that without knowing the exact connection, it's pretty useless. If the QoS settings are less ( I think it's set to 128K up, I see 500k up in my hotel), then it's overly restrictive. If it's set to more than that, then it's useless as it never is activated. With long last mile DSL lines, which I think is the default here, it's impossible to predict the actual connection parameters, even if we knew the exact SLA.

It's easy enough to disable QoS during testing. More important than our testing is to make sure we don't cripple the internet connection. Unless the QoS setting is adaptive, I am opposed to turning it on unless we test it in a more controlled setting first.

- Srikanth


On May 21, 2011, at 12:12 AM, Nick Feamster wrote:

> Srikanth, Walter --- please chime in.
> 
> Dave has a point here about the possibility of stopping QoS during testing.
> 
> Thoughts?
> 
> -Nick
> 
> 
> On May 21, 2011, at 12:11 AM, Dave Taht wrote:
> 
>> And your customer experience will be poor, and you will be measuring tcp/ip malfunctioning rather than working properly. 
>> 
>> How hard would it be for your scripts, when doing bandwidth testing, to do a 
>> 
>> /etc/init.d/qos stop
>> do the test
>> /etc/init.d/qos start
>> 
>> When do they do bandwidth testing? What script does it?
> 
> _______________________________________________
> Bismark-devel mailing list
> Bismark-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bismark-devel

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

Perhaps we can disable it by default, but (1) suggest QoS settings based on our measurements (2) give people a link for where to set them.  We could perhaps even provide a button on the Web interface to automate an update of the QoS settings.

-Nick

On May 21, 2011, at 10:12 AM, Srikanth Sundaresan wrote:

> My concern about QoS is that without knowing the exact connection, it's pretty useless. If the QoS settings are less ( I think it's set to 128K up, I see 500k up in my hotel), then it's overly restrictive. If it's set to more than that, then it's useless as it never is activated. With long last mile DSL lines, which I think is the default here, it's impossible to predict the actual connection parameters, even if we knew the exact SLA.
> 
> It's easy enough to disable QoS during testing. More important than our testing is to make sure we don't cripple the internet connection. Unless the QoS setting is adaptive, I am opposed to turning it on unless we test it in a more controlled setting first.
> 
> - Srikanth
> 
> 
> On May 21, 2011, at 12:12 AM, Nick Feamster wrote:
> 
>> Srikanth, Walter --- please chime in.
>> 
>> Dave has a point here about the possibility of stopping QoS during testing.
>> 
>> Thoughts?
>> 
>> -Nick
>> 
>> 
>> On May 21, 2011, at 12:11 AM, Dave Taht wrote:
>> 
>>> And your customer experience will be poor, and you will be measuring tcp/ip malfunctioning rather than working properly. 
>>> 
>>> How hard would it be for your scripts, when doing bandwidth testing, to do a 
>>> 
>>> /etc/init.d/qos stop
>>> do the test
>>> /etc/init.d/qos start
>>> 
>>> When do they do bandwidth testing? What script does it?
>> 
>> _______________________________________________
>> Bismark-devel mailing list
>> Bismark-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bismark-devel
> 

Re: [Bismark-devel] about ready to do another build

[Srikanth Sundaresan]

I do not have a problem with it when we know the effective bandwidth. My question is, what when do not? We cannot rely on volunteers to give us reliable information on that.

I say we turn it *on only while testing*. That too, after we get an idea about each user's bandwidth. THis is feature that, in its current form needs to be tailored to each user. It is not a good idea to give everyone a default setting - as I mentioned in my previous email, unless we hit bulls eye (unlikely), it is either crippling, or useless. It could potentially seriously downgrade user experience. 

- Srikanth

On May 21, 2011, at 2:58 PM, Dave Taht wrote:

> This is the result of a simple latency under load test from Nick's site in South Africa (single threaded iperf + ping)
> with QoS disabled:
> 
> 64 bytes from 72.51.34.34: seq=0 ttl=44 time=706.813 ms
> 64 bytes from 72.51.34.34: seq=1 ttl=44 time=653.739 ms
> 64 bytes from 72.51.34.34: seq=2 ttl=44 time=616.698 ms
> 64 bytes from 72.51.34.34: seq=3 ttl=44 time=878.976 ms
> 64 bytes from 72.51.34.34: seq=4 ttl=44 time=844.259 ms
> 64 bytes from 72.51.34.34: seq=5 ttl=44 time=815.939 ms
> 64 bytes from 72.51.34.34: seq=6 ttl=44 time=825.318 ms
> 64 bytes from 72.51.34.34: seq=7 ttl=44 time=819.073 ms
> 64 bytes from 72.51.34.34: seq=8 ttl=44 time=886.615 ms
> 64 bytes from 72.51.34.34: seq=9 ttl=44 time=876.255 ms
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-12.3 sec   640 KBytes   426 Kbits/sec
> 
> with the revised numbers :
> 
> TCP window size: 16.0 KByte (default)
> ------------------------------------------------------------
> [  3] local 192.168.1.106 port 41609 connected with 149.20.54.82 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-11.3 sec   384 KBytes   279 Kbits/sec
> 
> 
> 64 bytes from 72.51.34.34: seq=11 ttl=44 time=313.169 ms
> 64 bytes from 72.51.34.34: seq=12 ttl=44 time=313.524 ms
> 64 bytes from 72.51.34.34: seq=13 ttl=44 time=314.121 ms
> 64 bytes from 72.51.34.34: seq=14 ttl=44 time=312.999 ms
> 64 bytes from 72.51.34.34: seq=15 ttl=44 time=313.931 ms
> 64 bytes from 72.51.34.34: seq=16 ttl=44 time=313.966 ms
> 64 bytes from 72.51.34.34: seq=17 ttl=44 time=312.992 ms
> 64 bytes from 72.51.34.34: seq=18 ttl=44 time=313.621 ms
> 64 bytes from 72.51.34.34: seq=19 ttl=44 time=406.354 ms
> 64 bytes from 72.51.34.34: seq=20 ttl=44 time=314.305 ms
> 64 bytes from 72.51.34.34: seq=21 ttl=44 time=313.683 ms
> 
> [  3] local 192.168.1.106 port 41609 connected with 149.20.54.82 port 5001
> [ ID] Interval       Transfer     Bandwidth
> [  3]  0.0-11.3 sec   384 KBytes   279 Kbits/sec
> 
> Tweaking the qos-script some got me to about 310Kbits/second, and I was going to bake that into the build.
> 
> On Sat, May 21, 2011 at 2:12 AM, Srikanth Sundaresan <srikanth@gatech.edu> wrote:
> My concern about QoS is that without knowing the exact connection, it's pretty useless. If the QoS settings are less ( I think it's set to 128K up, I see 500k up in my hotel), then it's overly restrictive. If it's set to more than that, then it's useless as it never is activated. With long last mile DSL lines, which I think is the default here, it's impossible to predict the actual connection parameters, even if we knew the exact SLA.
> 
> 
> Which is why we test.
> 
> It's easy enough to disable QoS during testing. More important than our testing is to make sure we don't cripple the internet connection. Unless the QoS setting is adaptive, I am opposed to turning it on unless we test it in a more controlled setting first.
> 
> 
> I agree it should be somehow adaptive. Having results with QoS on and off makes it possible to have data to provide that to the users and for researchers to work on better QoS systems.
> 
> Without QoS enabled in some form, long last mile lines are effectively crippled in the first place. Worldwide. 
> 
> In the above case, sans QoS:
> 
> DNS, NTP, UDP, etc are all delayed an extra 
> 
> *half a second* 
> 
> by the presence of a single TCP stream.
> 
> Multiple streams, such as you get by typing a single letter into google's front page with the interactive feature on, would also suffer, as (for example) the last one I tried issued 37 DNS lookups to load the page.
> 
> Testing only in controlled settings, rather than in the field, is what has caused this problem in the first place.
> 
> 
> 
> - Srikanth
> 
> 
> On May 21, 2011, at 12:12 AM, Nick Feamster wrote:
> 
>> Srikanth, Walter --- please chime in.
>> 
>> Dave has a point here about the possibility of stopping QoS during testing.
>> 
>> Thoughts?
>> 
>> -Nick
>> 
>> 
>> On May 21, 2011, at 12:11 AM, Dave Taht wrote:
>> 
>>> And your customer experience will be poor, and you will be measuring tcp/ip malfunctioning rather than working properly.
>>> 
>>> How hard would it be for your scripts, when doing bandwidth testing, to do a
>>> 
>>> /etc/init.d/qos stop
>>> do the test
>>> /etc/init.d/qos start
>>> 
>>> When do they do bandwidth testing? What script does it?
>> 
>> _______________________________________________
>> Bismark-devel mailing list
>> Bismark-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bismark-devel
> 
> 
> 
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com 

Re: [Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Sat, May 21, 2011 at 9:48 AM, Srikanth Sundaresan <srikanth@gatech.edu>wrote:

> I do not have a problem with it when we know the effective bandwidth. My
> question is, what when do not? We cannot rely on volunteers to give us
> reliable information on that.
>
> I say we turn it *on only while testing*. That too, after we get an idea
> about each user's bandwidth. THis is feature that, in its current form needs
> to be tailored to each user. It is not a good idea to give everyone a
> default setting - as I mentioned in my previous email, unless we hit bulls
> eye (unlikely), it is either crippling, or useless.
>


> It could potentially seriously downgrade user experience.
>
>
What part about 800ms latencies under load without QoS isn't about  a
degraded user experience?

Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 1409 bytes --]

Re: [Bismark-devel] about ready to do another build

[Srikanth Sundaresan]

On May 21, 2011, at 6:08 PM, Dave Taht wrote:

> 
> 
> On Sat, May 21, 2011 at 9:48 AM, Srikanth Sundaresan <srikanth@gatech.edu> wrote:
> I do not have a problem with it when we know the effective bandwidth. My question is, what when do not? We cannot rely on volunteers to give us reliable information on that.
> 
> I say we turn it *on only while testing*. That too, after we get an idea about each user's bandwidth. THis is feature that, in its current form needs to be tailored to each user. It is not a good idea to give everyone a default setting - as I mentioned in my previous email, unless we hit bulls eye (unlikely), it is either crippling, or useless.
>  
> It could potentially seriously downgrade user experience.
> 
> 
> What part about 800ms latencies under load without QoS isn't about  a degraded user experience?

If the cost of reduced upload speed,  which could perhaps be as much as 30%, (if the default is 340kbps - the DSL connection here in my B&B gets up to 450k), can't be reduced, I certainly think that it's the higher price to pay than reduced latency.

- Srikanth

Re: [Bismark-devel] about ready to do another build

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]

On Sat, May 21, 2011 at 10:33 AM, Srikanth Sundaresan
<srikanth@gatech.edu>wrote:

>
> On May 21, 2011, at 6:08 PM, Dave Taht wrote:
>
> >
> >
> > On Sat, May 21, 2011 at 9:48 AM, Srikanth Sundaresan <
> srikanth@gatech.edu> wrote:
> > I do not have a problem with it when we know the effective bandwidth. My
> question is, what when do not? We cannot rely on volunteers to give us
> reliable information on that.
> >
> > I say we turn it *on only while testing*. That too, after we get an idea
> about each user's bandwidth. THis is feature that, in its current form needs
> to be tailored to each user. It is not a good idea to give everyone a
> default setting - as I mentioned in my previous email, unless we hit bulls
> eye (unlikely), it is either crippling, or useless.
> >
> > It could potentially seriously downgrade user experience.
> >
> >
> > What part about 800ms latencies under load without QoS isn't about  a
> degraded user experience?
>
> If the cost of reduced upload speed,  which could perhaps be as much as
> 30%, (if the default is 340kbps - the DSL connection here in my B&B gets up
> to 450k), can't be reduced, I certainly think that it's the higher price to
> pay than reduced latency.
>
>
I would urge you strongly to do more realistic testing, with more real users
using the network...

...before making that call. I am assuming you are unleashing these devices
on real users? with more than one person on the network?

RTT times will probably get even worse than 800ms with multiple streams
running. I have not tested that, I'll get to it.

Certainly chats with network operators and cybercafe operators down there
will also prove fruitful.

If you could exit the hotel and see if you can obtain some information from
the real world around you down there about those kinds of usage, (or
non-usage) of QoS techniques on their systems...

you might get some really good coffee and meet some interesting people.

Lastly your results pointed to a knee in the curves that I was not aware of,
that happens at 256kbit, which is perilously close to the speeds you are
encountering down there. I was getting about 12% overall single-threaded
performance loss and nearly flat utilization with multi-threaded, while
retaining good dns performance, with the existing scripts set to both 24Mbit
and with them set to 1000/100, I was not aware of this knee until I got some
data back from the field yesterday and had a chance to look it over this
morning. I'm simulating it in the lab (or will be whenever I get there), and
can hopefully do better.

See the ongoing bug:

http://www.bufferbloat.net/issues/171



> - Srikanth
>
>


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 3610 bytes --]

Re: [Bismark-devel] about ready to do another build

[Nick Feamster]

On May 21, 2011, at 6:49 PM, Dave Taht wrote:

> I would urge you strongly to do more realistic testing, with more real users using the network...

On that note, one of the tasks for tonight/tomorrow should be going all out with some recruiting mails, so that we're ready to try to paper the campus on Monday. :-)

-Nick

Re: [Bismark-devel] about ready to do another build

[Srikanth Sundaresan]

> 
> 
> I would urge you strongly to do more realistic testing, with more real users using the network...
> 
> ...before making that call. I am assuming you are unleashing these devices on real users? with more than one person on the network?
> 
> RTT times will probably get even worse than 800ms with multiple streams running. I have not tested that, I'll get to it.

It is unlikely that the RTT will be worse than what they are experiencing now - the size of the pipes mean that the buffers are easily filled with a single TCP connection. But applying the wrong default will have an impact, which could well be noticable. 
> 
> Certainly chats with network operators and cybercafe operators down there will also prove fruitful. 
> 
> If you could exit the hotel and see if you can obtain some information from the real world around you down there about those kinds of usage, (or non-usage) of QoS techniques on their systems...
> 
> you might get some really good coffee and meet some interesting people.

I agree that real information will be good. We don't really have it, which is why  setting a default (based on 2 data points) is not good. The qos-scripts should be tailored to each user.

Re: [Bismark-devel] about ready to do another build

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

On 05/21/2011 12:49 PM, Dave Taht wrote:
>
>
> On Sat, May 21, 2011 at 10:33 AM, Srikanth Sundaresan 
> <srikanth@gatech.edu <mailto:srikanth@gatech.edu>> wrote:
>
>
>     On May 21, 2011, at 6:08 PM, Dave Taht wrote:
>
>     >
>     >
>     > On Sat, May 21, 2011 at 9:48 AM, Srikanth Sundaresan
>     <srikanth@gatech.edu <mailto:srikanth@gatech.edu>> wrote:
>     > I do not have a problem with it when we know the effective
>     bandwidth. My question is, what when do not? We cannot rely on
>     volunteers to give us reliable information on that.
>     >
>     > I say we turn it *on only while testing*. That too, after we get
>     an idea about each user's bandwidth. THis is feature that, in its
>     current form needs to be tailored to each user. It is not a good
>     idea to give everyone a default setting - as I mentioned in my
>     previous email, unless we hit bulls eye (unlikely), it is either
>     crippling, or useless.
>     >
>     > It could potentially seriously downgrade user experience.
>     >
>     >
>     > What part about 800ms latencies under load without QoS isn't
>     about  a degraded user experience?
>
>     If the cost of reduced upload speed,  which could perhaps be as
>     much as 30%, (if the default is 340kbps - the DSL connection here
>     in my B&B gets up to 450k), can't be reduced, I certainly think
>     that it's the higher price to pay than reduced latency.
>
>
> I would urge you strongly to do more realistic testing, with more real 
> users using the network...
>
> ...before making that call. I am assuming you are unleashing these 
> devices on real users? with more than one person on the network?
>
> RTT times will probably get even worse than 800ms with multiple 
> streams running. I have not tested that, I'll get to it.
>

Take a look at the ISCI data on bufferbloat. The colour versions are in: 
http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/  
You can get an explanation for the structure you will see from the 
Netalyzr papers. The diagonal lines show the potential latency, and the 
"green" line of .5 seconds is already 3x telephony standards.  So a high 
fraction of the internet has serious bloat problems.

Several things:

1) the dataset *underdetected* the problem: there was a bug in Netalyzr 
only detected last October (and the dataset covers most of 2010 and back 
into 2009).  So the situation is worse than that shown.  How much, we 
don't know.

2) the amount of bloat varies *all* over; some DSL lines are up in the 6 
second range.

3) the amount of buffering is fixed: so the lower the provisioning, the 
longer the latency on the same devices.  I was seeing > 1.2 seconds on 
20Mbps cable, at which point web surfing is painful indeed.

4) If the bottleneck is elsewhere, then the broadband connection 
bufferbloat isn't the buffers that will affect the results.  So if the 
backhaul is lower bandwidth than the broadband/wireless connections, 
then the problem will be in the network routers, where RED (if enabled!) 
can control it.

I call the problem the "Daddy, the Internet is slow today" problem: I 
was usually the person who was causing saturation on the line, so when 
my family was experiencing slowdowns, they would come to me and I'd try 
to debug it, and stop whatever it was that was doing them in.  Who may 
be saturating the link most often varies from household to household: 
bittorrent can induce bufferbloat suffering.

Now, what you do is for you to determine; just understand the 
bufferbloat problem is extremely common and extremely variable.  Your 
mileage *will* vary.
                     - Jim




[-- Attachment #2: Type: text/html, Size: 5532 bytes --]