Of interest to BT BT2700HGV/2WIRE users

This has appeared in the closed BT broadband newsgroup and may be of
interest to someone:

http://superuser.com/questions/28006...hen-under-load

or http://tinyurl.com/5t5dj7c

On Sat, 7 May 2011 19:34:38 +0100, "Brian" <(E-Mail Removed)> wrote:

>This has appeared in the closed BT broadband newsgroup and may be of
>interest to someone:
>
>http://superuser.com/questions/28006...hen-under-load
>
>or http://tinyurl.com/5t5dj7c
>


Interesting, Thanks.
--
The End

"DC" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Sat, 7 May 2011 19:34:38 +0100, "Brian" <(E-Mail Removed)> wrote:
>
>>This has appeared in the closed BT broadband newsgroup and may be of
>>interest to someone:
>>
>>http://superuser.com/questions/28006...hen-under-load
>>
>>or http://tinyurl.com/5t5dj7c
>>
>
>
> Interesting, Thanks.

New.....not

Interesting .....why?

If, as the OP states they are using the full bandwidth to download,
everything else will stop, no error checks, no rec or accs. Nothing else
will get through as, as they originally stated they are using all the
bandwidth for the download.

"kraftee" <kraftee:b&e-cottee.me.uk> wrote in message
news:_(E-Mail Removed)...
>
> "DC" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On Sat, 7 May 2011 19:34:38 +0100, "Brian" <(E-Mail Removed)> wrote:
>>
>>>This has appeared in the closed BT broadband newsgroup and may be of
>>>interest to someone:
>>>
>>>http://superuser.com/questions/28006...hen-under-load
>>>
>>>or http://tinyurl.com/5t5dj7c
>>>
>>
>>
>> Interesting, Thanks.
>
> New.....not
>
> Interesting .....why?
>
> If, as the OP states they are using the full bandwidth to download,
> everything else will stop, no error checks, no rec or accs. Nothing else
> will get through as, as they originally stated they are using all the
> bandwidth for the download.

That is not true.

Packets coming in the downstream direction can be from many sources, of
course we cant exceed our allocation but if we did so this would create
random packet drops across all incoming applications, this in itself would
lead to TCP slowing down the flow to avoid the congestion or the Application
that uses UDP namely DNS to do the same and re-transmission would ensure a
reliable service with multiple IP streams, Now I know this sounds
complicated but put simply these mechanisms adjust to the available
bandwidth and delay in the network to be efficient. What they dont do is hog
it all to one application/download.

Without these mechanisms the Internet would just have died very early on.

So this does seem to be a router problem and most probably with DNS Relay
only, I dont though have a 2wire or HH3 but the only workaround I can think
of is to check the router via it's web based gui for the dns ip addresses
and set them up in the network settings on your computer so that the router
does not relay any more but just routes the DNS requests like any other IP
Packet.

Toby

In article <(E-Mail Removed)>,
Toby <(E-Mail Removed)> wrote:
>
>Packets coming in the downstream direction can be from many sources, of
>course we cant exceed our allocation but if we did so this would create
>random packet drops across all incoming applications, this in itself would
>lead to TCP slowing down the flow to avoid the congestion or the Application
>that uses UDP namely DNS to do the same and re-transmission would ensure a
>reliable service with multiple IP streams, Now I know this sounds
>complicated but put simply these mechanisms adjust to the available
>bandwidth and delay in the network to be efficient. What they dont do is hog
>it all to one application/download.

This is supposed to happen, but it doesn't. The problem is that modern
routers (not just domestic routers but ISP-level) have so much RAM and
such large buffers that the algorithms developed when buffer sizes were
small relative to transit times are no longer working.

Added to this, some service providers have taken to just chucking out as
much data as they can at the start of the connection so as to maximise
"throughput", not realising that they are defeating the very mechanisms
which are supposed to ensure throughput is maximised for the bandwidth
actually available.

This "Bufferbloat" phenomenon was discovered and analysed by Jim
Gettys last year, and has led to projects to address it via new IP level
mechanisms as well as to raise the profile of the problem amongst software
and hardware developers and standards organisations.

See http://www.bufferbloat.net/projects/bloat/wiki for more information
(various documents at various technical levels, take your pick).

>Without these mechanisms the Internet would just have died very early on.

The early Internet did in fact collapse on one occasion before congestion
mechanisms were added to it.

There is concern that it may be close to another collapse, with wildly
fluctuating and unreliable connections as we all observe every day due
to the fact that routers buffer up so much data that the flow control
is responding too slow, too little and too late.

Doesn't directly help in analysing the OP's DNS problems, but if his link
is maxed out much of the time then the DNS replies could indeed be stuck
in a buffer somewhere behind several minutes worth of download traffic.

Nick
--
Serendipity: http://www.leverton.org/blosxom (last update 29th March 2010)
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

"Nick Leverton" <(E-Mail Removed)> wrote in message
news:ir5der$kqi$(E-Mail Removed)...
> In article <(E-Mail Removed)>,
> Toby <(E-Mail Removed)> wrote:
>>
>>Packets coming in the downstream direction can be from many sources, of
>>course we cant exceed our allocation but if we did so this would create
>>random packet drops across all incoming applications, this in itself would
>>lead to TCP slowing down the flow to avoid the congestion or the
>>Application
>>that uses UDP namely DNS to do the same and re-transmission would ensure a
>>reliable service with multiple IP streams, Now I know this sounds
>>complicated but put simply these mechanisms adjust to the available
>>bandwidth and delay in the network to be efficient. What they dont do is
>>hog
>>it all to one application/download.
>
> This is supposed to happen, but it doesn't. The problem is that modern
> routers (not just domestic routers but ISP-level) have so much RAM and
> such large buffers that the algorithms developed when buffer sizes were
> small relative to transit times are no longer working.
>
> Added to this, some service providers have taken to just chucking out as
> much data as they can at the start of the connection so as to maximise
> "throughput", not realising that they are defeating the very mechanisms
> which are supposed to ensure throughput is maximised for the bandwidth
> actually available.
>
> This "Bufferbloat" phenomenon was discovered and analysed by Jim
> Gettys last year, and has led to projects to address it via new IP level
> mechanisms as well as to raise the profile of the problem amongst software
> and hardware developers and standards organisations.
>
> See http://www.bufferbloat.net/projects/bloat/wiki for more information
> (various documents at various technical levels, take your pick).
>
>>Without these mechanisms the Internet would just have died very early on.
>
> The early Internet did in fact collapse on one occasion before congestion
> mechanisms were added to it.
>
> There is concern that it may be close to another collapse, with wildly
> fluctuating and unreliable connections as we all observe every day due
> to the fact that routers buffer up so much data that the flow control
> is responding too slow, too little and too late.
>
> Doesn't directly help in analysing the OP's DNS problems, but if his link
> is maxed out much of the time then the DNS replies could indeed be stuck
> in a buffer somewhere behind several minutes worth of download traffic.
>
> Nick
> --
> Serendipity: http://www.leverton.org/blosxom (last update 29th March 2010)
> "The Internet, a sort of ersatz counterfeit of real life"
> -- Janet Street-Porter, BBC2, 19th March 1996

Thanks Nick

I will read up on bufferbloat as that may be interesting.

This is not the problem here though as it has been reported on the
bt.broadband.support newsgroup that the problem disappears if the user
reconfigures the dns settings on the pc to not use the broadband router as a
relay.

Toby

"Toby" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Nick Leverton" <(E-Mail Removed)> wrote in message
> news:ir5der$kqi$(E-Mail Removed)...
>> In article <(E-Mail Removed)>,
>> Toby <(E-Mail Removed)> wrote:
>>>
>>>Packets coming in the downstream direction can be from many sources, of
>>>course we cant exceed our allocation but if we did so this would create
>>>random packet drops across all incoming applications, this in itself
>>>would
>>>lead to TCP slowing down the flow to avoid the congestion or the
>>>Application
>>>that uses UDP namely DNS to do the same and re-transmission would ensure
>>>a
>>>reliable service with multiple IP streams, Now I know this sounds
>>>complicated but put simply these mechanisms adjust to the available
>>>bandwidth and delay in the network to be efficient. What they dont do is
>>>hog
>>>it all to one application/download.
>>
>> This is supposed to happen, but it doesn't. The problem is that modern
>> routers (not just domestic routers but ISP-level) have so much RAM and
>> such large buffers that the algorithms developed when buffer sizes were
>> small relative to transit times are no longer working.
>>
>> Added to this, some service providers have taken to just chucking out as
>> much data as they can at the start of the connection so as to maximise
>> "throughput", not realising that they are defeating the very mechanisms
>> which are supposed to ensure throughput is maximised for the bandwidth
>> actually available.
>>
>> This "Bufferbloat" phenomenon was discovered and analysed by Jim
>> Gettys last year, and has led to projects to address it via new IP level
>> mechanisms as well as to raise the profile of the problem amongst
>> software
>> and hardware developers and standards organisations.
>>
>> See http://www.bufferbloat.net/projects/bloat/wiki for more information
>> (various documents at various technical levels, take your pick).
>>
>>>Without these mechanisms the Internet would just have died very early on.
>>
>> The early Internet did in fact collapse on one occasion before congestion
>> mechanisms were added to it.
>>
>> There is concern that it may be close to another collapse, with wildly
>> fluctuating and unreliable connections as we all observe every day due
>> to the fact that routers buffer up so much data that the flow control
>> is responding too slow, too little and too late.
>>
>> Doesn't directly help in analysing the OP's DNS problems, but if his link
>> is maxed out much of the time then the DNS replies could indeed be stuck
>> in a buffer somewhere behind several minutes worth of download traffic.
>>
>> Nick
>> --
>> Serendipity: http://www.leverton.org/blosxom (last update 29th March
>> 2010)
>> "The Internet, a sort of ersatz counterfeit of real life"
>> -- Janet Street-Porter, BBC2, 19th March 1996
>
> Thanks Nick
>
> I will read up on bufferbloat as that may be interesting.
>
> This is not the problem here though as it has been reported on the
> bt.broadband.support newsgroup that the problem disappears if the user
> reconfigures the dns settings on the pc to not use the broadband router as
> a relay.

Surely most experienced users wouldn't do that anyway.

On Sat, 21 May 2011 17:55:35 +0100, "kraftee"
<kraftee:b&e-cottee.me.uk> wrote:

>
>"Toby" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed)...
>> "Nick Leverton" <(E-Mail Removed)> wrote in message
>> news:ir5der$kqi$(E-Mail Removed)...
>>> In article <(E-Mail Removed)>,
>>> Toby <(E-Mail Removed)> wrote:
>>>>
>>>>Packets coming in the downstream direction can be from many sources, of
>>>>course we cant exceed our allocation but if we did so this would create
>>>>random packet drops across all incoming applications, this in itself
>>>>would
>>>>lead to TCP slowing down the flow to avoid the congestion or the
>>>>Application
>>>>that uses UDP namely DNS to do the same and re-transmission would ensure
>>>>a
>>>>reliable service with multiple IP streams, Now I know this sounds
>>>>complicated but put simply these mechanisms adjust to the available
>>>>bandwidth and delay in the network to be efficient. What they dont do is
>>>>hog
>>>>it all to one application/download.
>>>
>>> This is supposed to happen, but it doesn't. The problem is that modern
>>> routers (not just domestic routers but ISP-level) have so much RAM and
>>> such large buffers that the algorithms developed when buffer sizes were
>>> small relative to transit times are no longer working.
>>>
>>> Added to this, some service providers have taken to just chucking out as
>>> much data as they can at the start of the connection so as to maximise
>>> "throughput", not realising that they are defeating the very mechanisms
>>> which are supposed to ensure throughput is maximised for the bandwidth
>>> actually available.
>>>
>>> This "Bufferbloat" phenomenon was discovered and analysed by Jim
>>> Gettys last year, and has led to projects to address it via new IP level
>>> mechanisms as well as to raise the profile of the problem amongst
>>> software
>>> and hardware developers and standards organisations.
>>>
>>> See http://www.bufferbloat.net/projects/bloat/wiki for more information
>>> (various documents at various technical levels, take your pick).
>>>
>>>>Without these mechanisms the Internet would just have died very early on.
>>>
>>> The early Internet did in fact collapse on one occasion before congestion
>>> mechanisms were added to it.
>>>
>>> There is concern that it may be close to another collapse, with wildly
>>> fluctuating and unreliable connections as we all observe every day due
>>> to the fact that routers buffer up so much data that the flow control
>>> is responding too slow, too little and too late.
>>>
>>> Doesn't directly help in analysing the OP's DNS problems, but if his link
>>> is maxed out much of the time then the DNS replies could indeed be stuck
>>> in a buffer somewhere behind several minutes worth of download traffic.
>>>
>>> Nick
>>> --
>>> Serendipity: http://www.leverton.org/blosxom (last update 29th March
>>> 2010)
>>> "The Internet, a sort of ersatz counterfeit of real life"
>>> -- Janet Street-Porter, BBC2, 19th March 1996
>>
>> Thanks Nick
>>
>> I will read up on bufferbloat as that may be interesting.
>>
>> This is not the problem here though as it has been reported on the
>> bt.broadband.support newsgroup that the problem disappears if the user
>> reconfigures the dns settings on the pc to not use the broadband router as
>> a relay.
>
>Surely most experienced users wouldn't do that anyway.

I would have thought the opposite. Better to have a local DNS cache
than needing to send every request to your DNS server.
--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.

Mark wrote:
> On Sat, 21 May 2011 17:55:35 +0100, "kraftee"
> <kraftee:b&e-cottee.me.uk> wrote:
>
>> "Toby" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> "Nick Leverton" <(E-Mail Removed)> wrote in message
>>> news:ir5der$kqi$(E-Mail Removed)...
>>>> In article <(E-Mail Removed)>,
>>>> Toby <(E-Mail Removed)> wrote:
>>>>> Packets coming in the downstream direction can be from many sources, of
>>>>> course we cant exceed our allocation but if we did so this would create
>>>>> random packet drops across all incoming applications, this in itself
>>>>> would
>>>>> lead to TCP slowing down the flow to avoid the congestion or the
>>>>> Application
>>>>> that uses UDP namely DNS to do the same and re-transmission would ensure
>>>>> a
>>>>> reliable service with multiple IP streams, Now I know this sounds
>>>>> complicated but put simply these mechanisms adjust to the available
>>>>> bandwidth and delay in the network to be efficient. What they dont do is
>>>>> hog
>>>>> it all to one application/download.
>>>> This is supposed to happen, but it doesn't. The problem is that modern
>>>> routers (not just domestic routers but ISP-level) have so much RAM and
>>>> such large buffers that the algorithms developed when buffer sizes were
>>>> small relative to transit times are no longer working.
>>>>
>>>> Added to this, some service providers have taken to just chucking out as
>>>> much data as they can at the start of the connection so as to maximise
>>>> "throughput", not realising that they are defeating the very mechanisms
>>>> which are supposed to ensure throughput is maximised for the bandwidth
>>>> actually available.
>>>>
>>>> This "Bufferbloat" phenomenon was discovered and analysed by Jim
>>>> Gettys last year, and has led to projects to address it via new IP level
>>>> mechanisms as well as to raise the profile of the problem amongst
>>>> software
>>>> and hardware developers and standards organisations.
>>>>
>>>> See http://www.bufferbloat.net/projects/bloat/wiki for more information
>>>> (various documents at various technical levels, take your pick).
>>>>
>>>>> Without these mechanisms the Internet would just have died very early on.
>>>> The early Internet did in fact collapse on one occasion before congestion
>>>> mechanisms were added to it.
>>>>
>>>> There is concern that it may be close to another collapse, with wildly
>>>> fluctuating and unreliable connections as we all observe every day due
>>>> to the fact that routers buffer up so much data that the flow control
>>>> is responding too slow, too little and too late.
>>>>
>>>> Doesn't directly help in analysing the OP's DNS problems, but if his link
>>>> is maxed out much of the time then the DNS replies could indeed be stuck
>>>> in a buffer somewhere behind several minutes worth of download traffic.
>>>>
>>>> Nick
>>>> --
>>>> Serendipity: http://www.leverton.org/blosxom (last update 29th March
>>>> 2010)
>>>> "The Internet, a sort of ersatz counterfeit of real life"
>>>> -- Janet Street-Porter, BBC2, 19th March 1996
>>> Thanks Nick
>>>
>>> I will read up on bufferbloat as that may be interesting.
>>>
>>> This is not the problem here though as it has been reported on the
>>> bt.broadband.support newsgroup that the problem disappears if the user
>>> reconfigures the dns settings on the pc to not use the broadband router as
>>> a relay.
>> Surely most experienced users wouldn't do that anyway.
>
> I would have thought the opposite. Better to have a local DNS cache
> than needing to send every request to your DNS server.

Answer is simple.. Run your own DNS server. Everything is cached locally.

No interception of your requests..