Posted at 2009-09-17 14:34 BST by RevK
Update #0: 2009-09-17 14:43 BST

The handbook for BT IPStream now defines that they consider it
acceptable for a line that syncs at the full ADSL1 rate of 8,128Kb/s to
only get 600Kb/s download. This means a serious congestion fault within
their network, which they admit is a hot VP will not be fixed.

It used to be that IPStream lines were defined in terms of contention
ratio. BT used to upgrade these hot VPs but it seems they are not
planning to do so for some of their customers on Liphook exchange, it
seems.

We are somewhat surprised considering the amount charged for this
bandwidth.

We are pushing for this to be resolved for our customer, but this may
take some time given BT's view on bandwidth.[IMAGE]

URL: http://aaisp.blogspot.com/2009/09/600kbs-is-acceptable-for-broadband.html

-- 
AAISP Status Blog
URL:http://aaisp.blogspot.com/

RevK wrote:

> The handbook for BT IPStream now defines that they consider it
> acceptable for a line that syncs at the full ADSL1 rate of 8,128Kb/s to
> only get 600Kb/s download.

But what about when the congestion causing this also causes them to drop the
ppp session? Repeatedly, when attempting to download a file or run the
speedtester. Which is the problem I'm seeing, and which I don't think I'm
alone in seeing given converssation on the IRC channel.

(Router debugging indicates it's receiving a LCP disconnect request, which
it's acting on).

And do you have a feel for when you'll have the final pricing for the BE
service and feel confident in offering this to customers as their sole
connection? Because so long as you go ahead with the proposed 95-percentile
charging model I think I'll want to move, given BT have lost the plot and my
line remains somewhat broken.

Matt Balyuzi

Matt Balyuzi  wrote:
> RevK wrote:
> 
>> The handbook for BT IPStream now defines that they consider it
>> acceptable for a line that syncs at the full ADSL1 rate of 8,128Kb/s to
>> only get 600Kb/s download.
> 
> But what about when the congestion causing this also causes them to drop the
> ppp session? Repeatedly, when attempting to download a file or run the
> speedtester. Which is the problem I'm seeing, and which I don't think I'm
> alone in seeing given converssation on the IRC channel.

Ah, it gives me some comfort to hear about others' experiences along
those lines.

> And do you have a feel for when you'll have the final pricing for the BE
> service and feel confident in offering this to customers as their sole
> connection? Because so long as you go ahead with the proposed 95-percentile
> charging model I think I'll want to move, given BT have lost the plot and my
> line remains somewhat broken.

I'll certainly be interested if the price is even vaguely affordable.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

On 17/09/2009 14:43, RevK wrote:
> Posted at 2009-09-17 14:34 BST by RevK
> Update #0: 2009-09-17 14:43 BST
>
> The handbook for BT IPStream now defines that they consider it
> acceptable for a line that syncs at the full ADSL1 rate of 8,128Kb/s to
> only get 600Kb/s download. This means a serious congestion fault within
> their network, which they admit is a hot VP will not be fixed.
>
> It used to be that IPStream lines were defined in terms of contention
> ratio. BT used to upgrade these hot VPs but it seems they are not
> planning to do so for some of their customers on Liphook exchange, it
> seems.
>
> We are somewhat surprised considering the amount charged for this
> bandwidth.
>
> We are pushing for this to be resolved for our customer, but this may
> take some time given BT's view on bandwidth.[IMAGE]
>
> URL: http://aaisp.blogspot.com/2009/09/600kbs-is-acceptable-for-broadband.html
>
Our little (850 residential lines) village exchange was fine until last 
year. Then overnight the entire exchange went to hell and ever since it 
will drop to ~1mb/s during peak times. AAisp have tried over and over to 
get BT to fix it, but the fixes are only temporary. IMO, BT 
intentionally reduced the bandwidth to the exchange, either to make room 
on the network elsewhere for 21cn or to increase the number of engineer 
call-outs.