Increasing consistent small packet loss

[Bill]

Put your details in here http://www.dslchecker.bt.com/

Hmm... when I put my number in there it says that FTTPoD is available 

But I don't think I'll bother.

[Lance]

If the cabinet is right outside the front door the install cost isn't massive because they charge the basic plus a per meter charge. I think I recently read that the costs (install and per month cost) are increasing a fair bit too in the not too distant future (if indeed they've not increased already)

[Bill]

If the cabinet is right outside the front door the install cost isn't massive

Unfortunately it's about 450m away... but that would be the least of the problems. I spent over ten grand last year having the front landscaped, getting an underground fibre across it to the house would be seriously expensive!

[sobranie]

Getting iffy after a good week!

[Tacitus]

Another post from Adrian Kennard that might be worth reading....

http://revk.www.me.uk/2014/02/bt-21cn-not-fit-for-purpose.html

[Bill]

Those packet loss graphs at bottom look strangely familiar...

[Technical Ben]

Yep Sobranie. It seems skittish again.

Another post from Adrian Kennard that might be worth reading....

http://revk.www.me.uk/2014/02/bt-21cn-not-fit-for-purpose.html

PS, sometimes silence is a good thing. As when it goes quiet, it's because real action is being taken. The kind they are not allowed to talk about... with base ball bats... I mean strong words and legal departments.   

At the suggestion it was the SVLAN not the exchange I said "If you say it not the exchange it is the SVLAN, then that is the same thing - if the pipe to the exchange is getting full, then that is congestion at the exchange". I was told "no" and "but if you want to be stupid then I won't argue with you". These are the com

Wow. Way to miss the point Mr Chief Engineer. "The boat is sinking", "It's not a boat you idiot, it's a ship..." (Ship sinks due to chief engineer not taking note over a perceived error/technical difference).
There is a reason I use the tag "technical", as I jokingly know you can redefine many things. Redefining the location of a problem does not remove it, especially when your going from an "in" to an "out" connection and it's still on BT's own hardware. 

[Tacitus]

Those packet loss graphs at bottom look strangely familiar...

I thought the interesting thing was that AAISP have been talking to other ISPs about the problem, which makes me wonder if Simon_idnet has been involved.  Also the threat to move people to TalkTalk's wholesale network.  I know that a while ago iDNet used Be, but since their demise I'm not sure which of the other wholesalers they're using

[zappaDPJ]

Those packet loss graphs at bottom look strangely familiar...

Indeed they do Thankfully I'm not getting the same level of disconnections as I was a couple of weeks ago. The packet loss in the evenings is still quite dreadful and my latency increases ten fold but apart from a lot of video buffering my connection is almost usable.

[zappaDPJ]

Thankfully I'm not getting the same level of disconnections as I was a couple of weeks ago.

Liar liar pants on fire...

[Gary]

Getting iffy after a good week!

I noticed on a Zen graph some random packetloss too the other day. Seems getting off BT's backhaul would be advantageous for some fibre users as packetloss is creeping in more and more as FTTC uptake continues. Its bad when Talk Talks networks does not suffer it.

[joe]

Yesterday I migrated to a provider that others in this thread have also joined.

First indications serves as a warning that the iDNet may not be the problem.

similar bleeding simply later:-



awful speed:-



as reflected by BT test at 9.26pm. :-

18.33 Mbps from my possible 68.75 Mbps be more helpful as to causes and solutions.

[Steve]

I think IDNet have currently solved their afternoon problem which I assume was related to heavy business use,the remaining issues I think are local exchange congestion occurring in the peak evening time for home users. The latter is obviously not ISP dependent and thankfully something I don't suffer from yet!

[Baz]

just checked mine and had this yesterday

[Bill]

First indications serves as a warning that the iDNet may not be the problem.

An example of BT's competence wrt their own network:

BT say they can find no problems with my connection (I don't believe them, but that's a separate issue) and asked me log in to the speedtest domain and run the extended diagnostics.

Fait enough, if that's what their script says... except that the tests wouldn't run.

I won't detail what I tried, but eventually I had an idea- I logged in to the test domain again and tried pinging the test server.

"Host not found".

Log back in to IDNet and run the ping again- timeout.

In other words, BT can't even set up their own DNS servers properly

[Steve]

Which DNS were you using Bill at the time?

[Bill]

Which DNS were you using Bill at the time?

At which time?

In both cases, the one provided by the server I logged in to, so a BT one for the the speedtest domain and IDNet's for normal login.

[Steve]

Just that I couldn't get anywhere either from the test login, I guess it's broke.

[Bill]

I just tried something else... logged in to the test domain, then entered the IP address (from the ping) of the test server into Safari's address bar... that still didn't work, it just sat there with a blank screen!

I guess it's broke.

I hereby award you the trophy for the understatement of the decade.

[Technical Ben]

I think IDNet have currently solved their afternoon problem which I assume was related to heavy business use,the remaining issues I think are local exchange congestion occurring in the peak evening time for home users. The latter is obviously not ISP dependent and thankfully something I don't suffer from yet!

If the info is correct, it may not be IDnet, but BT that's failing to "switch over" when lines are congested? IE, IDnet have the details forwarded to BT, but BTs system is buggy in implementing?

[Bill]

I've just realised why BT can't find any issues with my connection: their monitoring software probably doesn't work either

[Steve]

If the info is correct, it may not be IDnet, but BT that's failing to "switch over" when lines are congested? IE, IDnet have the details forwarded to BT, but BTs system is buggy in implementing?

I think it's the same old problem, the local capacity whether it be exchange or street cabinet is congested prior to the IDNet hand off and until BT upgrade capacity those with evening issues will continue to suffer .

[Bill]

I think it's the same old problem, the local capacity whether it be exchange or street cabinet is congested prior to the IDNet hand off and until BT upgrade capacity those with evening issues will continue to suffer .

If BT would admit that I'd be a bit happier, at least I'd know that there was a problem and that they were aware of it. I accept that they can't increase capacity at a moment's notice.

But their reflexive denial that there's any problem is no use to anybody!

[Tacitus]

If the info is correct, it may not be IDnet, but BT that's failing to "switch over" when lines are congested? IE, IDnet have the details forwarded to BT, but BTs system is buggy in implementing?

Which is much the same as Adrian Kennard is suggesting.  It's not simply an iDNet problem but down to congestion and BT's network failing to adjust. 

[Technical Ben]

I think it's the same old problem, the local capacity whether it be exchange or street cabinet is congested prior to the IDNet hand off and until BT upgrade capacity those with evening issues will continue to suffer .

From the post on the blog though, it suggest the congestion is either virtual and/or after the exchange. The providers were getting the products (virtual or physical) from BT with adequate bandwidth, but seeing congestion like packet loss. When asking BT, BTs response was "the exchange is under capacity, not congested". Which, along with it only effecting some providers some of the time, suggests it's else where and BT are missing/passing by the real problem?