Kitz Forum
Broadband Related => ISPs => Topic started by: tommy45 on January 18, 2015, 08:44:00 PM
-
http://community.plus.net/forum/index.php/topic,135389.0.html (http://community.plus.net/forum/index.php/topic,135389.0.html)
The above issue has been ongoing for far too long now without a resolution is sight, it's clear to me that discussing on the plusnet forums isn't helping, maybe it's greater exposure in the public domain regarding this peak time issue is what is required to get answers and a satisfactory resolution that many of plusnets customers seek
I posted this here to see if those who have a FTTC service in particular the 80/20 product with any of the many smaller independent ISP's out there, in a bid to see if this issue at peak times is confined to Plusnet and possibly BT retail customers or not, if they are then maybe this needs the media to ask them what is going on?
-
I get it with TalkTalk and its something they continue to deny.
However, TalkTalk install their own bandwidth backhaul for fibre so I think what you're experiencing is a BT Wholesale issue.
Although I have a theory that the fibre link from the cab to the exchange may be what I'd actually congested, not the exchange itself.
-
If i was even 90% sure i wouldn't be asking here, as so far i haven't seen any one with isp's such as ZEN or Aquiss or Xilo reporting such issues, although the increases in latency and packet loss where detected last week by AAISP , but no reports of reduction in throughput at peak time in particular single threaded downloads , this reduction isnt just a 10-15mbps dip it's 25+mbps for some, and the hopping between gateways and invisibly hopping endpoints gives varying results even full throughput for a limited number of days to me says it's plusnet and not BTW For me on the current endpoint that i'm on,currently i'm not seeing packet loss but do see increased jitter,and a small reduction in throughput at peak times, but on a previous endpoint /serveral gateways, i was seeing packet loss and increased latency as well as really poor throughput levels on single threads
-
I have been noticing jitter, and speeds going from 65 to 30 at its lowest point.
See if others respond if they're experiencing similar issues
-
Looks like I have some sort of congestion
pcl-bng01 gateway
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142161959176118556950.png&hash=8f6c701d0dfc2a351537dc209db870ab2df2eebc) (http://www.thinkbroadband.com/speedtest/results.html?id=142161959176118556950)
Not been using my connection that much today, but looks like I may have had a few lost packets when I run that speedtest.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2Fddabf21ce93cd0648feb47b988b781ec-18-01-2015.png&hash=f2de408276f36daf1277992ac0e10fbff65b71f7) (http://www.thinkbroadband.com/ping/share/ddabf21ce93cd0648feb47b988b781ec-18-01-2015.html)
Tracert seems fine though.
-----------
ETA
My SVLAN is currently blue (OK)
-
and then it looked okish for a minute....
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142162102109433445950.png&hash=45ed409d01b589c006ecf855e74cde05dc5cc6ec) (http://www.thinkbroadband.com/speedtest/results.html?id=142162102109433445950)
... and them immediately after that bad again.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142162104267402975014.png&hash=3ca91d6aea27b43b0ca7e5685509d1b4875296bd) (http://www.thinkbroadband.com/speedtest/results.html?id=142162104267402975014)
-
I tell you andyH is really winding me up on that forum, the way he posts its as if he gets offended plusnet is seen in a bad light, its as if its an employee posing as a customer.
Anyway, plusnet remain silent and are refusing to even confirm if their infrastructure is the cause or not, also seem happy to let people get misled into thinking its SVLAN issues.
-
I'm getting plus.net FTTC this week.
I'm going to be really unhappy if my ping is anything other than perfect :)
-
My latency seems ok, its just mostly throughput here.
-
I'm getting plus.net FTTC this week.
I'm going to be really unhappy if my ping is anything other than perfect :)
http://community.plus.net/ping-graphs/ (http://community.plus.net/ping-graphs/) some of the ping monitors of plusnet customers shows a few horror stories, and a distinctive trend of increased rates of jitter and some degree in latency increases also And if you have any ubisoft game that uses their server farm in Canada then it will a poor experience, the worst i have encountered so far in fact with base latency rising to 140ms and packet loss of 4-6% at times which is due to the pee poor peering they use , ping to ubisoft used to be 89ms on plusnet in 2013 currently they are no lower than 105-109ms at any time, They where made aware of this last year but did nothing about , ping's to the same server farm from customers of other isp's are a lot lower
latency to some uk sites is ok, base latency outside peak times is normal , but peering is a weak point
-
http://community.plus.net/ping-graphs/ (http://community.plus.net/ping-graphs/) some of the ping monitors of plusnet customers shows a few horror stories, and a distinctive trend of increased rates of jitter and some degree in latency increases also
Yet other lines seem ok.. its all rather strange. I feel some answers are needed hence me putting in my 2p over there.
If someone came out and categorically stated that there are issues with the BTw core routing.. or some of the endpoints are having problems at least we'd know where we stand. atm we dont know whats going on.
-
I have a 'day off' today to catch up on a couple of things, so I'll try monitor my connection tonight and add further results as the evening progesses.
Gateway pcl-bng01
4pm
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142168368121269889803.png&hash=c3dc41b166cac01cb9202196589e8a7f70dfc4b6) (http://www.thinkbroadband.com/speedtest/results.html?id=142168368121269889803)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fkitz.co.uk%2Ftemp%2Fspeeds%2F4pm.gif&hash=a215bd18d10f627baa018b5bc1d4835200b37160)
1. TBB speedtest 2. http download av 60Mbps
6.45 pm
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F14216932265802459858.png&hash=0dc4d49ae8fce0777c6721bb3ce23c8dafbbf96d) (http://www.thinkbroadband.com/speedtest/results.html?id=14216932265802459858)
7pm
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142169381107543681995.png&hash=e77d11d548798bb2394ba8496f2800b2cfff2143) (http://www.thinkbroadband.com/speedtest/results.html?id=142169381107543681995)
7.30pm
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142169560343524562230.png&hash=2441766178d0641f7f153ad1e19f021e9821f816) (http://www.thinkbroadband.com/speedtest/results.html?id=142169560343524562230)
BTw Speedtest
Download speed achieved during the test was - 74.06 Mbps
For your connection, the acceptable range of speeds is 40 Mbps-77.42 Mbps .
Additional Information:
IP Profile for your line is - 77.42 Mbps
Upload speed achieved during the test was - 17.31Mbps
Additional Information:
Upstream Rate IP profile on your line is - 20 Mbps
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fkitz.co.uk%2Ftemp%2Fspeeds%2F7-30.gif&hash=ede3026287b07504f714f5c4d4598c448e60ff2a)
1. BTw speedtest. 2. http download av 27Mbps. 3.TBB speedtest
9pm
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142170087905366057926.png&hash=c57d3e1b5d2c64b93f24cf10495b322e797690f1) (http://www.thinkbroadband.com/speedtest/results.html?id=142170087905366057926)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fkitz.co.uk%2Ftemp%2Fspeeds%2F9pm.gif&hash=be2e632f75d4e431cf39837dc4295b3fa2a16b30)
1. TBB speedtest 2.http download av 27Mbps
10pm
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142170490123638317350.png&hash=9968343f8ebdd3411605916ed8bb503e4a8ab045) (http://www.thinkbroadband.com/speedtest/results.html?id=142170490123638317350)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fkitz.co.uk%2Ftemp%2Fspeeds%2F10pm.gif&hash=fbd75a27128081ad38477d84e4d6de59a40e2871)
1. TBB speedtest 2. http download av 26 Mbps.
10-30 pm
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F14217067384493031138.png&hash=c67d194ea99cd732ca204bd3d802bb4e617a163a) (http://www.thinkbroadband.com/speedtest/results.html?id=14217067384493031138)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fkitz.co.uk%2Ftemp%2Fspeeds%2F10-30.gif&hash=e0f31a18a2b8702dcb72a0f49390ec4d4faa99fc)
1. TBB speedtest. 2. http download av 45Mbps
BTw Performance Test
Download speedachieved during the test was - 74.09 Mbps
For your connection, the acceptable range of speedsis 40 Mbps-77.42 Mbps .
Additional Information:
IP Profile for your line is - 77.42 Mbps
Upload speed achieved during the test was - 17.52Mbps
Additional Information:
Upstream Rate IP profile on your line is - 20 Mbps
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fkitz.co.uk%2Ftemp%2Fspeeds%2Fbtw.gif&hash=314515788603070f042d1794185738eef75cbdae)
TBB BQM for 19/01/2015
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F5df290f41df8a183e933226fcb03ef9d-19-01-2015.png&hash=f141bb4af7e88f534edd6872ce3c47769835127b) (http://www.thinkbroadband.com/ping/share/5df290f41df8a183e933226fcb03ef9d-19-01-2015.html)
-
http://community.plus.net/ping-graphs/ (http://community.plus.net/ping-graphs/) some of the ping monitors of plusnet customers shows a few horror stories, and a distinctive trend of increased rates of jitter and some degree in latency increases also
Yet other lines seem ok.. its all rather strange. I feel some answers are needed hence me putting in my 2p over there.
If someone came out and categorically stated that there are issues with the BTw core routing.. or some of the endpoints are having problems at least we'd know where we stand. atm we dont know whats going on.
thanks as you are seen as credible in the community this will add some weight, like yourself for me its only throughput not latency.
Something is seriously borked, I had "apparent" congestion at 2.30am.
-
Something is seriously borked, I had "apparent" congestion at 2.30am.
This one on their forum seems to have a 'little' problem..... :'(
-
For clarity is our OP also the OP in the link he/she gave to the PN forum?
-
no.
-
Ok here are my findings after Gateway hopping I have been on PTN AG 04 for the past 4 days, but tonight it started showing issues from slower loading of some we pages to a lower upstream throughput as well even with 6 threads to a known good ftp server i experienced upstream speeds of around 75% or less than i normally see the tbb speedtester picked up on this to a certain extent, how ever following a change in gateway and possibly endpoint too this returned to near normal again
my ping monitor shows jitter
here are some speed tests on each gateway i hopped onto
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F14217039439671898319.png&hash=d2ec5745cf1b922b303e594a0e6d5fd14847bacb) PTN-AG04
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142170418243355176243.png&hash=c7605492729de7fa766a2be437d0f1b8f005ecc7) PCL-AG04 Which have an increased latency of 4ms and high levels of jitter
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F14217044605039942137.png&hash=c8829632e53d9583df9bf8153a0b0cd605d35595) PCLBNG01 +3MS of latency
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142170477044992728836.png&hash=a3d10668be8f69b0b7d58ca4af3746aa30d71888) PCL-BNG03
http://www.thinkbroadband.com/speedtest/button/142170493312767335380.png (http://www.thinkbroadband.com/speedtest/button/142170493312767335380.png) PTN02 jitter
http://www.thinkbroadband.com/speedtest/button/142170520675436326789.png (http://www.thinkbroadband.com/speedtest/button/142170520675436326789.png) PCL07
http://www.thinkbroadband.com/speedtest/button/142170533424576952324.png (http://www.thinkbroadband.com/speedtest/button/142170533424576952324.png)PCL-BNG01 again but base latency normal this time so different end point would make sense
http://www.thinkbroadband.com/speedtest/button/142170553207929476391.png (http://www.thinkbroadband.com/speedtest/button/142170553207929476391.png) currently on PCL-BNG02 which isnt perfect it does like the other PCL's route to ubisoft from level3 using tinet so latency is lower
-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142170672317398091014.png&hash=f3aa7f5d0cd6570d215e5071b971894ba925f8e4) and once again as the plusnet useage starts to drop back down i start to see normal throughput and latency , This in my case i believe is down to a lack of capacity plusnet side or equipment malfunction/configured incorrectly or software, even maybe ( some sort of shaping being done in a stealthy way )
I can still remember them (plusnet saying that they don't /can't shape upstream traffic) but obviously some of their endpoints /gateways are doing this as the speedtest result and other testing that a carried out prove this
-
kitz next time you do a slow speedtest please do a gateway hop, retest, and if still slow hop again, try this at least 6 times, if you keep getting repeated slow, I am curious specifically if gateway hopping recovers performance.
-
Ive updated my post with the speedtests done at various points.
However a couple of friends called and I wasnt able to monitor things closely. I just kept nipping into the PC room to set off a speed test or download, and stacked the results until theyd gone so I could post now.
Therefore I wasnt able to do any gateway hopping tonight. :/
-
Watch out for andy apparently we all idiots for doing speedtests.
-
That's yet another attempt to distract us by implying that doing speed tests is un cool ect ect , he does have a habit of doing this near enough every time some one finds a fault or even suspects their to be a fault with Plusnet it's like he has an financial or other interest that he ain't making public, or he is just one of those people who are obsessed with their isp, and in their eyes the isp can do no wrong
-
http://en.wikipedia.org/wiki/Shill
-
http://en.wikipedia.org/wiki/Shill
could be, could be one of plusnet's staffers alter ego's which i suppose amounts to the same thing
-
Well not even 1 customer from any of the isp's or any other isp who's fttc service uses BTW has posted here regarding these peak time issues, could it be that this issue is effecting only plusnet customers? excluding the svlan issues of course ,which now appear to be resolved , "Well do you proud", maybe asa should make them remove that slogan from their advertising as so far they haven't done anything
-
What were the svlan issues? :)
-
It seems plusnet are using bt 21cn core team more & more(mx960's) might explain the lack of any updates /details.
Might be better off asking Mr Shakir ;)
-
What were the svlan issues? :)
According to what was said on the plusnet forum, and info regarding this on AAISP status pages, but it only affected some areas not a national problem, which as far as can tell from what others are saying on forums it's been resolved ,
As for this peak time issue with lower throughput and increased latency/jitter this problem has been evident in some form for most of the time since i joined plusnet there have been a few months where no visible signs appeared on the ping monitor and as far as i am aware no throughput issues,(doesn't mean that there wasn't) just because i didn't notice any, and during November/December last year i wasn't home most of the time,
Well as far as I'm concerned Plusnet have had more than enough time to have resolved this, 18mths another observation in the past 2013 early 2014 plusnet would announce that they added capacity, every few mths, and the problem would either vanish for a short time or would show little improvement, they would appear to have stopped adding capacity but not customers to me this race to the bottom (cheaper than cheap) is part of the underlying cause as they cannot support the demand or their customers properly
-
For me the bad gateway issues are not limited to peak time, if I am on one of the dodgy endpoints it slows down for a lot of the day, I had slow speedtests at 10am and 2.30am, which are both outside peak.
This to me suggests its not necessarily saturation related but possibly a configuration issue somewhere.
The thing is now i have managed to get on a good endpoint, so I am no longer providing them feedback, it would seem to push this along now the core network team is supposedly involved one would need to get themselves on a bad endpoint and stay there so they can be monitored.
-
I bet they won't be compensating them for having to tolerate a degraded service whilst they allegedly monitor things
I in the past have seen poor throughput outside peak time, but was Sunday afternoon, on a few occasions but i can't recall any other day time events
-
last night after gateway hopping i thought i had found a good endpoint but i guess that is not possible with minus-net
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142178693830209285559.png&hash=bddc77d0ec0f80ebce1c23697f524e0e2253bc56)and i've got the packet loss as well I hopped gateways once and landed on BNG 04 and no packet loss and full throughput levels but latency on that gateway isn't the lowest
-
post in the thread, tell them you will stay on that endpoint for a few days to allow them to check whats going on.
-
I didn't stay on it, and i have little faith in their support actually doing anything so see it as a pointless exercise, I think the only way to be rid of this is to migrate away from minus net,
the thing that really boils the urine is that you hop gateways and eventually get a connection that works as is expected ,then less than 24hrs later it's worse than the previous gateway connection, Also i noticed another thing whilst hopping gateways base latency, even on the same gateway but different central ie 10 /11 changes it, one shows a low,normal latency but the other shows a increase, and the difference in latency between gateways is another weird thing, their can be upto 8ms difference between the lowest and highest, something ain't right with that IMO
-
kitz I see you did the hop, thanks :)
http://community.plus.net/forum/index.php/topic,135389.msg1193503.html#msg1193503
-
Hi All,
My current speeds with Plusnet:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142213384517999030691.png&hash=8e2dc1d298736802ea7d617ed9db03856951065a) (http://www.thinkbroadband.com/speedtest/results.html?id=142213384517999030691)
I have also attached a BQM graph which I think illustrates the contention issues well.
Outside peak times I get 37.5Mbps down and 17.4Mbps up.
Plusnet are investigating this for me but the issues have been ongoing since early December.
My old ADSL connection achieved a constant 5Mbps.
I have tried to get out of my contract but they insist that the speeds they quote are only the sync speeds to my cabinet at the end of my road so no joy there.
Something seems to be seriously wrong with their network
I can't even stream Netflix or NOWTV when it's this slow so I'm paying for services I can't use.
-
Sadly in the t&c no speeds are guaranteed,
It is a shared user platform meaning contention.
However if we look at how plusnet estimate sync speeds, I believe they do not specifically state "sync speed" but rather just "speed", if I am correct (you should check), then its a way out of the contract if your thoughput is significantly below the estimated speed.
Also the fact plusnet now at least once a year bump up prices, just wait for the bump and get out then if you not happy.
-
This is my TBB graph.
It is from 08:48 this morning (not a peak period), but it doesn't differ much at all during peak periods.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F1422175706662764355.png&hash=504a991221b213662287b963a002b46665f096ef)
As mentioned by WWWombat in the other thread, it does appear to be something much more local to Stephen71
-
Well these issues still prevail i after connecting to a good endpoint had 2 good days 48hrs whoopee do do !!! where i had no packet loss ,no jitter ,and full throughput during peak times , but tonight,back to the jitter and increases in latency, no packet loss ,but low & crappy throughput again, hopped onto several gateways some had really erratic latency with 10-20ms frequent spiking going on to several targets i have loaded into pingplotter
Eventually i found a gateway/endpoint with little/no jitter that was providing full throughput, too me 30mins this is not on
plusnet staff on the forums saying that they can't find anything wrong with their network, no congestion,
then they read from the script
post speedtest results from tbb,speedtest.net and BTWholesale PT The best line is suggesting that we run a Tap3 test, when speeds are not low enough , as they have to be really low before it will offer a tap 3, and then after changing your log in credentials there's a strong possibility from reading various forums that it won't run so even more frustrating
for the customer who they think are sheeple and know nothing
well i for one have had enough this doesn't look like it will be resolved any time soon therefore this leaves only 2 choices
1, put up with it and shut up
2, get a MAC code and migrate to a ISP who hopefully is able to provide full throughput 24/7 with the exception of network failures be they BTW or their own, As broadband is sold as a always on product, therefore i should be able to use it when i wish without these sort of problems
-
To which provider are you thinking of migrating?
-
Zen most probably unless i can haggle a deal with Aquiss,& if they did an unlimited product for a sensible amount of money AAISP,
-
What are the chances this is local congestion and not PN? What's the capacity from the cabs to the exchange? The exchange to the... whatever is next, core?
*consults the kitz site*
:D
-
I think kitz is right that the problem is either plusnet or close to plusnet on the BTw side.
Sadly it seems plusnet either are failing to diagnose it or their staff have been told to keep quiet.
As it stands for me tho my endpoint still seems ok and I dont have as much trouble as you tommy finding a good one. So at least for now I am staying put, but let us know how you get on after moving.
If I did jump ship I think it would be to aaisp.
-
What are the chances this is local congestion and not PN? What's the capacity from the cabs to the exchange? The exchange to the... whatever is next, core?
*consults the kitz site*
:D
given hopping can fix it I think it makes it unlikely its close to the end user as that part of the routing is static, also the capacity between cabinet and exchange is at a point where congestion is extremely unlikely.
-
I jumped to another pipe and its been fine for the past 10 days.
Since Ive been on central12.pcl-bng2 Ive been getting full 75Mbps even @ peak.
-
What are the chances this is local congestion and not PN? What's the capacity from the cabs to the exchange? The exchange to the... whatever is next, core?
*consults the kitz site*
:D
given hopping can fix it I think it makes it unlikely its close to the end user as that part of the routing is static, also the capacity between cabinet and exchange is at a point where congestion is extremely unlikely.
I've just had a glance at the stats for the MSANs. It isn't immediately obvious how many ports are allocated for uplinks? Nowhere is it mentioned they support 10GbE, either... do we know either of these?
256 subscribers x 80Mb/s? A few Gigabit uplinks is hardly going to be enough?
Also, what processors are these MSANs sporting? What if you've got a street full of people torrenting? The processor load may be enough to cause reduced throughput and latency?
I've no idea why a disconnect/reconnection seems to sort it (briefly, it seems?) but unless PN is outright lying ('our network is fine, y0' - the cabs and backhauls are not their network), it might be worth questioning what else might be going on...?
-
plusnet (and most other isps) would be congested way before the cabinet is plus the fibre links can do more than a gigabit of throughput. Of course on top of that many cabinets are not full and not everyone will be synced at 80mbit, most dont even sign up to the 80/20 package.
also hopping doesnt just sort it briefly, I have been ok for a week or so now, and so has kitz it seems.
So if we assume say avg 40mbit per customer, and every customer is a torrent nutcase, it still would take 200 customers to reach 800mbit of throughput, this is an extremely low contention ratio compared to the isp's backhauls.
-
Well since the other night i to may of landed on a good endpoint , but only time will tell, no reduction in throughput at peak times or jitter on the ping monitor , so far but although ,maybe not related it have noticed packetloss to Steampowered.com from the plusnet hop immediately before level3 to end of destination again during the same times as plusnets peak time,
-
plusnet (and most other isps) would be congested way before the cabinet
I find that difficult to believe. These cabs are almost certainly provisioned on an over-subscription model and there are almost certainly some use cases where it doesn't align with The Spreadsheet.
also hopping doesnt just sort it briefly, I have been ok for a week or so now, and so has kitz it seems.
Sounds like they've isolated the fault then? Excellent!
So if we assume say avg 40mbit per customer, and every customer is a torrent nutcase, it still would take 200 customers to reach 800mbit of throughput, this is an extremely low contention ratio compared to the isp's backhauls.
I mentioned torrents in the context of them being able to ravage processor usage. The bandwidth they consume is just an aside!
Well since the other night i to may of landed on a good endpoint , but only time will tell, no reduction in throughput at peak times or jitter on the ping monitor , so far but although ,maybe not related it have noticed packetloss to Steampowered.com from the plusnet hop immediately before level3 to end of destination again during the same times as plusnets peak time,
Control plane policing is often the reason for the erroneous packet loss you see in the middle. Big expensive looking routers don't care about traffic directed AT them, they only care about the traffic going THROUGH them :)
I'm just e-clutching at straws though tbh. I'm sure there must be someone on here with intimate knowledge of all this kit...
-
So if we assume say avg 40mbit per customer, and every customer is a torrent nutcase, it still would take 200 customers to reach 800mbit of throughput, this is an extremely low contention ratio compared to the isp's backhauls.
Sorry, but shouldn't that be 20 customers?
-
you right it isnt 1:1 contention but its low enough that you will see 1:1 performance.
I believe tho the upload speeds are uncontended. That is how highly provisioned they are, remember its expensive for openreach to deploy fibre, so they have done excess amounts of it as they wont want to do it again.
In short the bandwidth provisioned per end user at a cabinet level is far higher than what the isp's provision.
I think the most realistic point of congestion nearest the customer is the SVLAN and mine is confirmed BLUE.
Of course as well as you pointed out, there is no way 200 users are going to be maxing their lines out at the same time.
Sorry for my bad maths it would take 20 40mbit customers to reach 800mbit of throughput. A 10:1 contention ratio (or there abouts) for a consumer broadband product is very low. The isp's will be contending way higher then that.
Also a quick read of the plusnet forums, doesnt suggest the problem is fixed, merely just me and kitz have found good endpoints and kept our PPP sessions running since.
Also i forgot to mention, there is a openreach document somewhere that states how much they provision per customer, if i remember correctly its basically 4:1 contention ratio as a worse case scenario (20mbit provisioned for 80mbit customers) meaning if 200 users are in the cab synced at 80mbit, then there will for sure be more than 1 gigabit port connected.
-
Well the usual jitter is back tonight , and i'm seeing some strange latency effects to the BBC the latency as from earlier today has also increased to the bbc by 8-10ms
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| home.gateway.home.gateway - 0 | 101 | 101 | 7 | 14 | 23 | 13 |
| lo0.10.Central10.ptw-bng02.plus.net - 0 | 100 | 100 | 18 | 33 | 89 | 31 |
| irb.10.PTW-CR01.plus.net - 0 | 100 | 100 | 18 | 29 | 63 | 24 |
| kingston-gw.thdo.bbc.co.uk - 0 | 100 | 100 | 18 | 31 | 67 | 24 |
| No response from host - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 19 | 0 | 0 | 0 | 0 | 0 |
| ae0.er01.telhc.bbc.co.uk - 0 | 100 | 100 | 19 | 31 | 48 | 30 |
| 132.185.255.149 - 0 | 100 | 100 | 19 | 30 | 84 | 26 |
| fmt-vip71.telhc.bbc.co.uk - 0 | 100 | 100 | 19 | 29 | 73 | 28 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Were as when i run the same test to|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| home.gateway.home.gateway - 0 | 104 | 104 | 0 | 0 | 1 | 0 |
| lo0.10.Central10.ptw-bng02.plus.net - 0 | 104 | 104 | 11 | 13 | 51 | 11 |
| irb.10.PTW-CR02.plus.net - 0 | 104 | 104 | 11 | 12 | 29 | 11 |
| lonap-gw1.thdo.ncuk.net - 0 | 104 | 104 | 11 | 16 | 203 | 12 |
| te1-1-1-31.core-rs2.thdo.ncuk.net - 0 | 104 | 104 | 12 | 15 | 51 | 12 |
| pingbox1.thinkbroadband.com - 0 | 104 | 104 | 11 | 12 | 22 | 12 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider Gives normal results (apart from the variation in latency/jitter)
Maybe down to plusnets perfect networking that's never at fault ,apparently
-
iplayer started buffering on my amazon firetv box so I hopped onto my pc to see some disturbing speedtests.
Both download and upload erratic so about to do a hop, I did 5 tests in a row to see if results consistent and they are.
post hop
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142317161915095595730.png&hash=efb4866e19d1fcb6c53d4679ecec9ffc0b99d921) (http://www.thinkbroadband.com/speedtest/results.html?id=142317161915095595730)
pre hop
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142317108337849658643.png&hash=6a8883b00a414aaeca5a4f02c2fc469a9fa13bf3) (http://www.thinkbroadband.com/speedtest/results.html?id=142317108337849658643)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142317114084516092525.png&hash=d16e023010e0266962c390381191a582db63ace6) (http://www.thinkbroadband.com/speedtest/results.html?id=142317114084516092525)
iplayer not retested yet tho.
Although the average speeds were still high it was very spiky on dumeter, and a dodgy upload meaning something clearly wasnt right.
-
iplayer is fine again.
some more info.
After the hop I am back on the same plusnet gateway, although I could well be on a different endpoint.
The iplayer buffering was very extreme, basically it would be a spinning circle for over a minute and then play just one second.
-
to kitz, tommy and co, seems jelv did some digging.
http://community.plus.net/forum/index.php/topic,136571.msg1198558.html#msg1198558
I've just searched the service status archive - the last announcement of increased capacity was last July (June for 20CN which I am on).
My gut feeling is that we are back in the bad old days of Plusnet not having enough capacity. The rate at which they've been installing FTTC connections we should have been seeing regular announcements
-
Thanks for pointing out that post. I am getting a weird felling of deja vu over there.
I cant really say much atm though since Im not getting home until late evenings, but afaik everything has been fine since my last pipe hop and its why Im staying on this pipe. Before I got on this pipe it was bad for weeks.
-
also here is the tbb graph, note the before and after red line in evening.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F108391d8d980a96b1f2d65a20e16e0de-05-02-2015.png&hash=53bb60bd7a329c00246be519c471d1bd32c0eb37) (http://www.thinkbroadband.com/ping/share/108391d8d980a96b1f2d65a20e16e0de-05-02-2015.html)
-
Mines here.
btw Ive noticed 2hrly peaks on my graph for a while and note that there also appears to be some evidence of it on yours. Im pretty certain its not coming from this end. I keep meaning to isolate the PC and turn off wi-fi one day, but that means it would also turn off dslstats and hg612 modem stats.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F0ae5bfae11894cf2c9ac364f53b33660.png&hash=1a834b77bb700111ab21634589b37fe3e1108672) (http://www.thinkbroadband.com/ping/share/0ae5bfae11894cf2c9ac364f53b33660.html)
-
, but afaik everything has been fine since my last pipe hop and its why Im staying on this pipe. Before I got on this pipe it was bad for weeks.
Seemed to be stuck on one pipe for few months on BTw (Carlisle) even after numerous new PPP sessions ???
-
Well 8 days is the record for me in the past 2 and a bit months , again tonight i get plusnot's jitter and poor throughput hopping gateways took me an age to find another gateway or/and endpoint that was able to provide a slightly better throughput, there was several gateways /endpoints that where providing less throughput , they typically also had higher base latency and jitter levels hopping gateways is not real answer it's like a minefield, Its also about time plusnet owners BT started buying more capacity instead of investing further into the race to the bottom
cash backs free months subs, bb & phone & free tv deals, need to go
-
I have to say I'm beginning to regret joining Plusnet.
Web pages stalling etc.
-
I have to say I'm beginning to regret joining Plusnet.
Web pages stalling etc.
I've seen this behaviour too. Their DNS is crap, presumably (my connection is otherwise flawless).
I've avoided changing to Google DNS to see if the issue persists but it might be worth a try for you?
-
Plusnet are going down the same route as BT with dns.
If you're still experiencing problems with blocked content, this may be due to you using a different DNS to Plusnet.
http://www.plus.net/support/safeguard.shtml
Would be wise to change settings while this is being implemented. As if its anything like the Mx960's " Junos OS crack team " its going to be fun and games all round. ;)
-
are you making assumptions? I dont see anything about enforced dns rerouting.
Also that safeguard is disabled on my account.
-
Well the peak time congestion is still ongoing for some of their customer base, and they are still in denial that a problem exists they have started blaming customers connections suggesting that they must have a line fault, basically so far their support has been as much use as udders on a bull!! imo
I Still intend on migrating but not until i have explored the formal complaint route all the way to ADR if need be,
-
I switched to Google DNS. The stalling web page issue has disappeared for me.
-
See http://forum.kitz.co.uk/index.php?topic=15087.msg281445#msg281445
This is not just a Fibre or even a 21CN issue, I'm seeing classic congestion symptoms (single stream must slower than x6) on 20CN Max Premium.
There's a significant fact here: Max Premium has a higher priority on the BT network. So that leaves one conclusion - it's Plusnet.
Oh, if anyone suggests it's a line fault causing a high error rate, my current stats:
Uptime: 5 days, 13:10:12
DSL Type: ITU-T G.992.1
Bandwidth (Up/Down) [kbps/kbps]: 832 / 8,128
Data Transferred (Sent/Received) [MB/GB]: 752.71 / 4.34
Output Power (Up/Down) [dBm]: 12.3 / 19.9
Line Attenuation (Up/Down) [dB]: 11.0 / 20.0
SN Margin (Up/Down) [dB]: 15.0 / 6.5
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / TSTC
Loss of Framing (Local/Remote): 0 / -
Loss of Signal (Local/Remote): 0 / -
Loss of Power (Local/Remote): 0 / -
Loss of Link (Remote): -
Error Seconds (Local/Remote): 26 / -
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 16 / 27
HEC Errors (Up/Down): - / 24
-
Is it a co-incidence that the peak time issues which suggest under investment in capacity started appearing around the same time as Plusnet started going crazy with cash back offers?
-
You must surely mean the race to the bottom? yes i have noticed a concerning trend in a downward direction, and not only jitter at peak times but packet loss during those times is becoming more common place, and i get the feeling they don't care, staff will be told to keep shtum and do what they have so far blame everyone and everything apart from their selves
-
See http://forum.kitz.co.uk/index.php?topic=15087.msg281445#msg281445
I'm seeing classic congestion symptoms (single stream must slower than x6) on 20CN Max Premium.
Is this really classic congestion? If there's only 10% of a pipe left and you launch 6 * 10% threads, do you get 60%?
At best (worst?) this is some sort of congestion avoidance/management. Shaping and/or weighted tail drop perhaps? I think it's important to draw these distinctions if we are to truly understand wtf is going on here.
Or we can peddle myths? That could be fun too :P
So... let's assume this is real. At what point, EXACTLY, in the network might it be happening? What device?
-
I think it's where BT's network meets the internal network of plusnets Handover point/s As if by hopping gateways throughput is restored sometime even if returning to the same gateway that you first saw congestion low throughput on,
I came across one endpoint whilst hopping gateways,offering a sub 10mbps down and less than 1 mbps upstream it also had a base latency of over 100ms, I'm on FTTC 80/20 With ip profile of 77.44 if it isn't congestion then something is seriously wrong with their traffic management , maybe that it's unable to function properly once customer usage reaches a certain level ? The BTW PT Tap 3 test will not resolve to the speed-test page once i change log in credentials as per on-screen instructions , that's a convenience in plusnets favour too
But whatever the cause plusnet should of fixed the problem long before now,instead of denying that it's their networking by saying we cant find anything wrong, lame to say the least
-
@boost
When all is fine a single thread will run at near line speed and 6 threads will run at 1/6 line speed.
When there's congestion all threads for all users will run at say 50% speed. So a single thread speed test will be significantly impacted and a x6 speed test will still get near line speed. The other classic sign is that speeds during a test are up and down like a yo-yo.
So if it's not congestion somewhere what is it?
Outside peak times I can get a rock steady download (both single and x6) at around 94% of my IP profile. I've been told the status of my exchange/VP is good. Max Premium has higher priority on the BT network. The finger is pointing in one direction.
Also could you explain how on a bad evening some users find a significant improvement by gateway hopping?
-
@boost
When all is fine a single thread will run at near line speed and 6 threads will run at 1/6 line speed.
When there's congestion all threads for all users will run at say 50% speed. So a single thread speed test will be significantly impacted and a x6 speed test will still get near line speed. The other classic sign is that speeds during a test are up and down like a yo-yo.
So if it's not congestion somewhere what is it?
Outside peak times I can get a rock steady download (both single and x6) at around 94% of my IP profile. I've been told the status of my exchange/VP is good. Max Premium has higher priority on the BT network. The finger is pointing in one direction.
Also could you explain how on a bad evening some users find a significant improvement by gateway hopping?
I think you're definitely onto something but I don't understand what exactly. Sorry if it came across as 'shut up foo, there aint no congestion!' :D
I feel pretty ignorant about the whole thing. I've been on the main site, looking at the diagrams and trying to piece it together but I'm a long way off :)
I've been told the status of my exchange/VP is good
What does this mean exactly?
What exactly is a VP?
How is it provisioned?
How many are there, typically?
How many at your exchange?
Who's definition of 'good' are you reporting? What
exactly is their definition of good?
These are the kinda questions that fill my mind when I read stuff on here.
IT has some brilliant people working in it but to say this is the norm would be extremely creative :P
Max Premium has higher priority on the BT network.
Says who?
Why?
How does this higher priority manifest itself on your traffic?
Assuming traffic, what happened when IP Stream became WBC?
Are you on a native IP Stream port? (I can see that you are)
-
Ages ago (pre ADSL Max) BT did residential products with 50:1 contention and business products with 20:1 contention.
When ADSL Max came out the equivalent products were Max and Max Premium.
Plusnet say it provides a prioritised service: http://www.plus.net/support/broadband/products/prioritised-service-faq.shtml (this page is for the prioritised service and says that on 20CN it also gives the faster upload).
See also http://en.wikipedia.org/wiki/ADSL_Max#Max_.27Premium.27
WBC isn't available on 20CN only exchanges!
-
I find it really weird. For weeks I suffered really badly. Speeds were down to circa 20Mbps at peak time. I did all sorts of tests which were completely overlooked by Plusnet. Then one night when things were bad I did a gateway hop and immediately went from 20Mb to 77 Mb. Ive been perfectly fine since Ive been where I am now.... but Ive been on this pipe for several weeks and not disconnected. I dunno how things will be if I have to resync or get a new PPP session.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142567269658048345676.png&hash=b927f6d6a2aa6fad858135cc8db539b3f86e80db) (http://www.thinkbroadband.com/speedtest/results.html?id=142567269658048345676)
-
Today I've had a similar issue, but with the upstream mainly. After a forced resync (for other reasons) web page loading became very sluggish so I did some speed tests. The BTW test didn't record an upstream speed at all, and others recorded upstream speeds of less than 0.5 Mbps. The upstream sync speed is 20 Mbps.
I dropped the PPP session and let it reconnect, and immediately everything was working normally again, with up and down speeds close to the sync speeds.
-
Looks like they have really outdone their selves tonight look at the lag on this (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-large%2F084273e070114d67f6b87eb619f62732-10-03-2015.png&hash=3d7d0c666a3517adb0e3a42b2c91af37a1e29cd9)
No congestion on our network, ::) :D really ?
-
Just to add a little more info.
My +net adsl was recently reset and was switched to fastpath at about 5PM
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fmonitors%2Fgraph-thumb%2Fb4bbce779550036a56495ded24197995-03-03-2015.png&hash=814f0ac0d19372b6fd726337531e69df997536b3)
You can see the congestion/delays kick in at 8PM, but, if I was still on interleaving I would not have seen the problem at all.
The following day and again if my ping was <>40 ms the increase would not have been seen.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fmonitors%2Fgraph-thumb%2Fb4bbce779550036a56495ded24197995-04-03-2015.png&hash=565219ddaf96f86b88336063b0937f3ef2d4baa1)
I think that some people complain too much about broadband problems; what do they expect for a few quid/month.
Ian
-
Firstly the connection shown is FTTC 80/20 service and currently is interleaved The base latency during the peak time was 3 times what it should of been, congestion will still show the same level of increase regardless of interleave /fast path
and I pay a lot more than a few quid per month for it, infact some 2 thirds of what some smaller ISP's charge,
Also they advertise that the cheaper price,doesn't mean a compromise is the service they supply maybe ASA should be informed that this is incorrect ?
Oh and as to what i expect for my money , As the service i pay for is sold as a always on service, then i expect to be able to use that service when ever i want for what i want, and i expect congestion related issues like this to be resolved in a timely manner 3 mths isn't timely i wouldn't consider 3 weeks to be timely either , Then there is their lack of real support , i submitted a ticket some 8 days ago haven't heard a peep from them , a total joke imo
-
I beg to disagree
If you want full speed service 100% of the time buy a leased line - and my goodness will you pay for it.
If you want better/more timely support, change to somewhere like AAISP as your ISP - and yes you will pay for it.
If you want some sort of better service buy a business line - and again you pay more.
Plusnet is a bargain basement low cost ISP aimed at the lowest common denominator of the populous in getting in the ultra price sensitive punter by the ton-load with wheezes like 6 months cheap, cashback etc. Offerings of "unlimited" when they have not got the capacity to service 100% of the subscriber base 100% of the time. Also as evidenced by its advertising association in the past with Big Brother TV "show" - which shows the level they are aiming at.
The majority of their subscribers will be paying low costs prices, and UK broadband is already one one the cheapest in the world.
When Plusnet raised it prices by £1.5/month a while back that was good for some 25 pages of outrage on TBB and plusnets forums with some claiming that BB prices were out of control - should give you an idea of the typical customer socio-economic demographic.
Everyone just wants cheap cheap cheap................
Broadband is no longer a techie product from niche ISP's with ever helpful experienced staff just waiting for your call to discuss the ins and out of some issue - this is mass market consumerised product for the "great unwashed". with so called useless call centers - set up precisely because most of the calls are from customers who are total *****.
Consumer grade broadband is not advertised as or ever intended to be 'on' and 'full' speed capable at all time.
Those advertising cheaper prices should expect to have more problems and issues than those advertising at the more expensive end.
The world does not revolve around what you want. If you don't like it then my advise is to leave them pronto.
-
well the facts appear to be that some of the other mass market ISP's are not having peak time issues BT retail customers aren't having these problems neither are TT and thats saying something ,They really need to stop with their pathetic ads which amount to lies as the service is clearly compromised because of their race to the bottom which their networking clearly isn't able to sustain, and these peak time issues shouldn't be happening never mind being regarded as acceptable for what you pay that is BS The service so matter what should be fit for purpose
-
c6em and kitzuser with all due respect I disagree.
For a few reasons.
1 - the line rental has to be factored in, plusnet subsidise broadband via voice revenue. The package price as a whole isnt that cheap.
2 - the current market expectation which started when BT retail removed their traffic management is that home broadband runs at full speed all the time, its as simple as that.
3 - your arguments where to not see congestion, 1:1 contention required is nonsense. yes its unreasonable for an isp to garuantuee no congestion, for that a 1:1 is required, however that is very different to expecting good performance "most" of the time, with occasions such as IOS updates congestion may occur.
4 - plusnet themselves have not came out and said our service will slow down at peak periods that is our stance, instead they are saying they have enough capacity and slowdowns are considered a fault.
5 - congestion tends to break things, e.g. if a 80mbit line pulls 40mbit on a speedtest, the assumption is that is still plenty for netflix etc. but it isnt that simple, even things with less than 40mbit of throughput will be affected and as such streaming services will usually break. not to mention gamers and the like who need clean latency will obviously be affected.
6 - business services from plusnet are just as affected.
7 - valid point on the support tho. although I think plusnet can do better, based on their competition. waiting a week for a ticket response is unacceptable at any pricepoint.
Seems some people just have very low standards and accept poor service, not all of us work that way. Plusnet used to be better, there is no reason they cannot maintain their early 2014 performance.
I pay £38 month for my plusnet service, thats far from bargain basement.
-
Woops didn't mean to upset anybody.
My recent experience on my market 1 exchange, after leaving plusnet in 2010, I have spent the intervening years wondering around the adsl marketplace
vivacity,post office,zen, back to post office all with poor throughput during peak times.
It was resolved in Nov 2014 by returning to plusnet.
I can now stream in HD during peak times on my 5-6 Mbps adsl connection for a few quid/month (<£30 inc line rental and calls)
Ian
-
http://www.plus.net/support/broadband/speed_guide/broadband_speeds.shtml shows the speeds to be expected for various types of traffic at particular times on the current Unlimited accounts. There is a link to this page from the FAQs on the main sales pages. If they are not meeting that (e.g. speeds are always slower on a Monday evening) then they are guilty of miss-selling!
Perhaps someone needs to contact the ASA.
-
not to mention congestion can be seen as a form of traffic management which the ASA dont allow on unlimited products.
-
[Customer router] 1---> [FTTC modem] 2---> [FTTC MSAN] 3---> [BT Layer 2 Switch] 4---> [GEA Cablelink(s) into the...] 5---> [21CN cloud via MSIL?] 6---> [Host link(s) to CP Infrastructure] 7---> [CP transit to Internet] 8--->1 CP Return Paths to FTTC modem (presumably a reverse of the above but may jump onto CP owned backhaul at certain points to save moola?)
So where might congestion present?
1. The infamous 'customer domain' [Responsibility=Customer]
a. Customer router/PC e.g. high processor usage = reduced throughput and erratic latency
b. Intermittent/pervasive copper faults can look a lot like congestion and should be investigated before anything else. (A recent example is where a HG612 was running over 90% CPU, presumably correcting FECs)
c. Misconfigured PPPoE clients, possible blackholing of frames with MTU between 1492 and 1500? (Mentioned in a BT SIN somewhere)
d. Loads of other stuff we can add later...
2. The TP/copper line/metallic path [Responsibility=Openreach]
a. A copper line fault, disturber or interferer could fire up within the classic peak utilisation period; disruption akin to congestion in some cases, perhaps.
3. Uplinks from street cabinet MSAN to Exchange/Metro node [Responsibility=Openreach]
a. MSAN uplinks to Exchange/Metro node oversubscribed? (Found documentation to suggest the Huawei 5600 supports 10GE uplinks but no proof these are actually used; do they take up a shelf that could otherwise be used for subscriber ports? Also no indication 10GE is supported on *all* FTTC MSANs... ECI? Information for this aspect of the network appears to be extremely thin, hopefully I've just overlooked it somewhere?)
b. MSAN high processor usage contributing to erratic pings/reduced throughput. Software vectoring (which I just made up) or any other intensive calculation could contribute to it; this is ultimately congestion.
c. MSAN not informing BRAS of correct synch speed, wrong policer applied... somewhere/everywhere?
4. Uplinks from L2S to CP handover/aggregator [Responsibility=CP & Openreach]
a. GEA Cablelink is oversubcribed, CP needs to order more [Responsibility=CP]
b. FTTC traffic unevenly distributed over Cablelinks? Worst case... no port aggregation and EUs are staticly assigned per port [Responsibility=Openreach]
c. Some other scenario?
5. MSIL entry point at exchange/Metro node[Responsibility=CP]
a. MSIL bursting above contracted bandwidth excess traffic policed either by BT on upper limit or CP on lower limit to avoid charges.
b. Congestion within the bowels of 21CN (surely not?!)
c. Others...?
6. MSIL exit point at core node / Host links to CP (gleaned from a comment on the PN forum) [Responsibility=CP/Wholesale]
a. Poor traffic distribution across Host links back to CP [Responsibility=Wholesale]
b. Poor traffic distribution across Host links back into 21CN [Responsibility=CP]
c. Host link(s) generally congested/oversubcribed. Presumably 1 and 10Gb. The latter representing significant capex if not opex too? [Responsibility=CP]
7. CP transit to Internet [Responsibility=CP]
a. The transit link
b. The xconnect to get to the transit link
8. Return paths to FTTC modem
As you can tell, I am clutching at straws for some of this but it seems like we may all benefit from understanding this stuff a bit better?
Please offer a correction if you spot an error on this and I will update.
I think the CP handover has to happen at a core node, for example? One of 20~ in the UK? Plusnet have around 20 gateways... seems to fit?
My assumptions:
---------------------
I have found it extremely difficult to understand the BT nomenclature. I have almost zero practical experience of service provider networks so perhaps it's just me.
The MSIL/AP/EP riddle:
MSIL = "Multi Service Interconnect Link" = EVC Trunk? (Metro ethernet forum:An EVC is a conceptual service pipe within the service provider network.)
EP = "Extension Path" = Still not entirely sure. Possibly EFP/Ethernet Flow Point/Service Instance or some accounting instance
AP = "Aggregation Point" = Port+VRF on the BEA (An Aggregation Point (AP). The AP is a logical CP-specific virtual router, in which the CP’s
traffic is managed.)
I've been wondering if AP bandwidth is synonomous with traffic conform rate and the EP is the burst rate? I seem to have made up a few scenarios where they both fit can't be sure of any!
SVLAN = this word has spread like wildfire across various forums but noone seems to know what it specifically applies to. In my mind, this is simply a double tagging scenario. Inner (c) tag is customer, outer tag (s) is service provider/CP. With that in mind, it could apply to almost anywhere in the network, FMSAN to L2S, L2S to CP or elsewhere?
SVLAN upgrades? How one upgrades the outer tag on a frame I'm not sure. Surely the actual upgrade is better allocation to trunk ports? Perhaps this is implied in SVLAN but it's not obvious to me.
General thoughts which may help/hinder the above:
------------------------------------------------------------------
CPs can only order in 1Gb/s chunks from the FTTC (L2S) terminating switch:
From http://www.sinet.bt.com/sinet/SINs/pdf/498v6p0_C.pdf
1.3 GEA Cablelink
The GEA Cablelink product will be offered for the CP to order connectivity to the
L2S in the same Point of Handover building.
This will comprise:
• A 1 Gbit/s Ethernet port into the L2S. The Gigabit Ethernet interface will be
set to auto-negotiate, 1000Base-LX (SingleMode only); and
• Fibre connection from the port on the L2S to the location within the same
Point of Handover specified by the CP.
I've no idea which of the two below Plusnet use. Gut says they relieve as much responsibility from BT as possible and terminate their own PPP sessions?
WBC can be run in two customer handover modes from the AP:
• PPP Termination and Aggregation (PTA), whereby the End User PPP Session is terminated
on the WBC BRAS and Routed IP is used to handover the End User traffic to the CP;
• Layer 2 Tunnelling Protocol (L2TP) handover, whereby the End User PPP session is
tunnelled to a CP-owned L2TP Network Server (LNS) where the PPP session is terminated.
-
I'm seeing issues on a 20CN Max Premium connection. Here's my error counts from nearly 12 days up time:
Error Seconds (Local/Remote): 73 / -
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 51 / 76
HEC Errors (Up/Down): - / 67
It isn't customer domain and it isn't TP/copper line/metallic path!
-
I'm seeing issues on a 20CN Max Premium connection. Here's my error counts from nearly 12 days up time:
Error Seconds (Local/Remote): 73 / -
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 51 / 76
HEC Errors (Up/Down): - / 67
It isn't customer domain and it isn't TP/copper line/metallic path!
I did have a quick look at this actually but couldn't make head or tail of it at the time. What I did manage to find out, is that Max Premium traffic should be marked as AF31 through the BT (Colossus?) network. Whether PN honour that with a similar marking, I've no idea. Did you mention what exchange you're on? Trace route to BBC yield any info?
-
boost its agreed there is many parts within BTw where congestion can occur, but its still plusnet's job to investigate those things on behalf of the end user. Plusnet seem only capable of checking the svlan status, I also dont think its right to mislead customers by telling them there is amber/red svlan's at their exchange but not mentioning the customer's actual svlan is not affected.
Luckily I havent seen congestion for some weeks now, there is a slight increase of latency at peak on my tbb, but by plusnet's standards thats very low and I have no affect on throughput.
-
Also One point that i want to make on this which imo points at plusnet or their interconnects with BTWholesale, my point is that is that possibly lots of customers all from different geographic locations around the uk are experiencing the same underlying issues, but differing in severity i say this because it's happening in a simultaneous or near simultaneous manner the collection of plusnet customers tbb ping graphs demonstrate this i have some that i have copied to my pc , i can upload to a file host and post here if you want , as all are live in the collection so are continuously recording events, this evidence indicates this is not eu connection specific or down to their equipment inc PC , and as there is a distict lack of similar reports from customers with other isp's who use BTW WBMC in particular customers of AAISP ,ZEN ,AQUISS ,ect If it was down to a general BTW issue, then all isp's would be affected by it, Again points to plusnet imo
Looks like yet another night of pish poor throughput and lag (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142618861518561483947.png&hash=5c68375dd60ee2e48491c56872877b1ace11bf75)
-
My VPs have been checked:
Right. There are 8 VPs I can see at your exchange from the report on the 4th Feb.
5 AMBER, 1 GREEN and 2 BLUE.
You're on the GREEN one, so in the date range used to compile the report there was no capacity issues.
I'm going to ask someone more faulty than me to have a look and see what they suggest.
Chris Parr
Plusnet Customer Relations Team
-
My VPs have been checked:
Right. There are 8 VPs I can see at your exchange from the report on the 4th Feb.
5 AMBER, 1 GREEN and 2 BLUE.
You're on the GREEN one, so in the date range used to compile the report there was no capacity issues.
I'm going to ask someone more faulty than me to have a look and see what they suggest.
Chris Parr
Plusnet Customer Relations Team
1 month old results mean nothing. Where does this elusive VP spreadsheet exist? What time of day are these VPs polled? etc etc :D
-
Asking mr kennard at AAISP may yield the info , as i doubt that you would get that from the likes of PN support. BTW you got similar results to me ,I'm on a green VP for what it's worth, thing is though with FTTC i thought it was the SVLAN status that was relevant and not the Exchange VP's?
-
As a quick of a post as I can, because its very late... long days and also having to do lots of backend site stuff when I do get home:(... so Im just going to blurb.
@boost - Theres an explanation and more information on such things as MSILs, APs etc on this page
http://www.kitz.co.uk/adsl/wbc_wbmc.htm
The main Core network is highly unlikely to be congested..ever. Would take a real catatrophic problem to see issues there. Its highly resiliant and the way its meshed means that all major routes could be re-routed.
It's unlikely to see congestion on any of the core nodes (think of this as entry point to the core), although this also could become a problem in a major outage (Say for eg when there was the Manchester fire near to / at the RAS many years ago).
Usual points of congestion are either the VP (for 20CN) or SVLAN (for FTTC) OR the ISP Host links (WBMC/IPsC).
OR Another point of congestion could be the MSILs/APs, but since PN is supposedly WBMC - Shared, then its BTw's responsibililty to maintain sufficient bandwidth on the WBC Interconnects. Ive no idea how BTw monitor these and what their proceedure is for upgrading them.
Re the SVLANs - Im not 100% certain on these.
CVLAN is the customer tag (inner), whilst SVLAN is the Service tag (outer). I think the SVLAN is basically kind of the same as the old VPs and the amount of bandwidth available on that particular tunnel's 'backhaul', ie between the DSLAM and the RAS.
The new MSE bRAS may change things somewhat, because now many of the bRAS are closer to the dslam than they used to be.
It is possible to change SVLANs with much persausion (ie like BT would change you to a different VP if you moaned enough). AFAIK you cant change your CVLAN, but you can (and will be) be grouped with other CVLANs in to an SVLAN. There's 2 distinct different types of SVLANs 1)Copper-21CN 2)Fibre- FTTC. Whatever way, I'm pretty sure that the SVLAN is the backhaul to the bRAS.
Im unsure on FTTC if its from the DSLAM to RAS, or perhaps because of the fact DSLAM is BTor, then its possible it could be from the OLT to the bRAS. Thinking about it further probably most likely to be OLT because this is the point where GEA is handed over... and in which case we also have a possible BT Openreach congestion point between the dslam and the OLT.
Only your ISP or BTw has access to which SVLAN you are on. The SVLANS are constantly monitored to make sure they dont run hot and are supposed to be upgraded whenever they reach a certain threshold. The SVLAN status reports are updated twice weekly, but you need to know which SVLAN youre on to be able to check the reports.
-
kitz: Interesting about the BTW managed interconnects. That might make a bit more sense with regard to people harping on about SVLAN issues.
jelv: You're wiltshire based? I wonder if Sheffield appears in your routing? :P
-
I know I go through Reading - just done a gateway hop and this is in the router log:
<132> Mar 13 09:59:27 PPP link down (Internet) [80.229.*.*]
<38> Mar 13 09:59:42 PPP CHAP Receive challenge from rhost ERX18.Reading (Internet)
<38> Mar 13 09:59:43 PPP CHAP Receive challenge from rhost PCL-AG05 (Internet)
<38> Mar 13 09:59:43 PPP CHAP Receive success (Internet)
<132> Mar 13 09:59:43 PPP link up (Internet) [80.229.*.*]
-
I know I go through Reading - just done a gateway hop and this is in the router log:
<132> Mar 13 09:59:27 PPP link down (Internet) [80.229.7.240]
<38> Mar 13 09:59:42 PPP CHAP Receive challenge from rhost ERX18.Reading (Internet)
<38> Mar 13 09:59:43 PPP CHAP Receive challenge from rhost PCL-AG05 (Internet)
<38> Mar 13 09:59:43 PPP CHAP Receive success (Internet)
<132> Mar 13 09:59:43 PPP link up (Internet) [80.229.*.*]
You, Sir, are on the ball!
What does a trace route to bbc look like out of interest? :)
-
I was looking back at the IPStream stuff earlier and came across a document, from AAISP I think, that said it was possible to move IPStream traffic over to 21CN backhaul, as maintaining the two is expensive. This makes perfect sense. This reminded me of the red flag I saw in one of the BT SINs regarding MTU across the network, specifically for the L2TP tunnels:
I'm making the assumption that PN is L2TP passthrough from the BT LAC. The more I think about it, the less sense it makes. More encapsulation, more latency but perhaps more control. I'm missing several pieces of this jigsaw puzzle, I digress.
A quick reminder of which bit of the network we're talking about - BT BRAS (LAC) to CP BRAS LNS:
http://www.sinet.bt.com/sinet/sins/pdf/472v2p6.pdf
(https://dl.dropboxusercontent.com/u/20271204/dslstats/WBC%20BRAS.png)
http://www.sinet.bt.com/sinet/sins/pdf/472v2p6.pdf
TLDR; the PPP MRU must be equal both sides.
4. WBC End User Handover
4.1 Introduction
WBC can be run in two customer handover modes from the AP:
• PPP Termination and Aggregation (PTA), whereby the End User PPP Session is terminated
on the WBC BRAS and Routed IP is used to handover the End User traffic to the CP;
• Layer 2 Tunnelling Protocol (L2TP) handover, whereby the End User PPP session is
tunnelled to a CP-owned L2TP Network Server (LNS) where the PPP session is terminated.
4.2 L2TP handover
The L2TP handover solution uses IPv4 source & destination addressing.
It should be noted that if a CP opts to use L2TP handover for its end users’ sessions the L2TP control
traffic (“keep alives”) must be prioritised by the CP’s LNS. If this traffic is not prioritised and the link is
congested to the point where some of the control traffic is dropped then the CP runs the risk that the
L2TP tunnel will be dropped. This will result in the users’ sessions on that tunnel being terminated and
the users having to start a new PPP session.
4.3 PPPoE and WBC L2TP Pass through (for information)
If a WBC Customer’s End Users are using PPPoE then they should be aware of the following
behaviour with L2TP Pass through.
PPPoE clients should behave as per RFC2516[15] and RFC1661[9] – if so:-
• PPPoE End User client should send an MRU of 1492 Bytes or less to the BT LAC in the
BRAS.
• The BT LAC (in the BRAS) will send an MRU of 1492 Bytes to the PPPoE client.
• The PPPoE client and BT LAC will agree on the lower value MRU.
• The BT LAC will then proxy on this value towards the WBC Customer’s LNS.
If the PPPoE client does not obey RFC2516[15] and RFC1661[9] (which occurs regularly), one of the
following circumstances will occur:
• If the PPPoE client and BT LAC do not agree a valid MRU then the BT LAC will proxy a value
of 1500 Bytes towards the WBC Customer’s LNS.
• If the PPPoE client does not send an MRU, but agrees the BT LAC MRU of 1492 Bytes then
the BT LAC will proxy that value towards the WBC Customer’s LNS for that End User to the
WBC Customer.
• If the PPPoE client and BT LAC do not agree a valid MRU then the BT LAC will default to
proxying a value of 1500 Bytes towards the WBC Customer’s LNS which will advertise this as
the IP MTU for that End User to the WBC Customer.
• If the End Users PC is behind the device raising the PPPoE session (for example a routed
LAN), then the IP MTU of the PC must be set to 1492 Bytes or lower.
The WBC Customer’s LNS should be set up with the correct MTU depending upon the service they
wish to offer.
• If they wish to offer just PPPoE then they could set up their LNS with a statically configured IP
MTU of 1492 Bytes or lower.
• If they wish to offer just PPPoA then they could set up their LNS with a statically configured IP
MTU of 1500 Bytes. However, if an End User chose to use a PPPoE client then packets over
1492 Bytes will be carried over the WBC network but then dropped by the client.
If the WBC Customer wishes to offer a mixed PPPoE and PPPoA service then their LNS should be
able to accept the MRU proxied on by the BT LAC and assign that on a per End User basis. However,
this will not always be accurate if the PPPoE client does not obey RFC2516[15] and RFC1661[9] (as
detailed in the information above).
Juniper document detailing typical behaviour:
http://www.juniper.net/documentation/en_US/junos14.2/topics/concept/pppoe-subscriber-access-mru-mtu-overview.html
PPP MTU and MRU for Tunneled Subscribers on LNS
For PPP subscribers on L2TP network server (LNS), the configured MTU can be either the explicit MTU size specified using the mtu size statement or the derived MTU using the mtu use-lower-layer statement.
If the PPP MTU is configured as use-lower-layer, the PPP local MTU is determined as:
interface MTU – 58 bytes.
Note: 58 bytes is the PPP overhead payload, which is calculated as the sum of the IP, UDP, L2TP, HDLC, and PPP header payloads.
If the PPP MTU is configured using the mtu size statement, the PPP local MTU is the lesser of the configured MTU and the (interface MTU – 58 bytes) value.
When you configure an explicit MRU value by using the mru size statement, Junos OS determines the PPP local MRU value for PPP subscribers on LNS interfaces based on the following scenarios:
If the MRU value is not configured for PPP subscribers on the LNS and if the proxy LCP options are received from the L2TP access concentrator (LAC), the PPP local MRU value sent for LCP negotiation is the lesser of the local MRU (determined based on the local MTU as explained in the PPP MTU and MRU for PPPoE Subscribers section) and the proxy MRU value. If the LCP options are not received, the local MRU is sent during LCP negotiation.
If, however, the MRU value is configured for the PPP subscribers on the LNS, the local MRU is the lesser of the configured MRU and the local MTU value. Further, if the proxy LCP options are received from the LAC, the MRU value sent during LCP negotiation is the lesser of the local MRU and the proxy MRU value. If the settings are absent, the local MRU is sent as the offered MRU during LCP negotiation.
I then found this other Juniper based document which makes it seem far less black and white, although it's an older document it seems like it may be applicable:
https://www.juniper.net/techpubs/en_US/junose10.3/information-products/topic-collections/broadband-access/l2tp-packet-fragmentation.html
acket Fragmentation
The E Series router supports the reassembly of IP-fragmented L2TP packets. (For more information, see the IP Reassembly for Tunnels chapter in JUNOSe IP Services Configuration Guide.) However, it is preferable to prevent fragmentation within L2TP tunnels because of the effects of fragmentation and reassembly on performance.
To prevent fragmentation, PPP LCP negotiation of the maximum receive unit (MRU) may be used to determine a proper maximum transmission unit (MTU). However, the normal automatic method of determining the proper MRU to negotiate (by evaluating the MRU of all lower layers in the interface stack) is not adequate for L2TP. The initial LCP negotiation between PPP in the client and the LAC is inadequate because it does not cover the entire extent of the eventual PPP session that travels all the way from the client to the LNS. Furthermore, even if PPP in the LNS chooses to renegotiate the MRU, it has no way to determine the proper MRU, since it does not know the minimum MRU on all of the intervening links between it and the LAC.
To overcome the inadequacy of normal determination of the MRU under such circumstances, you can configure the PPP MRU size by using the ppp mru command in Profile Configuration mode, Interface Configuration mode, or Subinterface Configuration mode. Use Profile Configuration mode for dynamic PPP interfaces, and Interface Configuration mode or Subinterface Configuration mode for static PPP interfaces.
When you specify the size, you need to take into account the MRU for all possible links between the LAC and the LNS. You must also take into account the L2TP encapsulation that is added to all packets entering the tunnel.
For example, if the link between the LAC and LNS with the lowest MRU were an Ethernet link, the following calculation applies:
Minimum link MRU
L2TP encapsulating IP header
L2TP encapsulating UDP header
Maximum L2TP header (assumes a maximum of 16 bytes of Offset Pad)
1500
-20
-8
-30
MRU size to specify
1442
If the smallest intervening link is an Ethernet link, specifying ppp mru 1442 at either the LAC or LNS guarantees that no fragmentation will occur within the L2TP tunnel.
So, what's my point?
If Router 1 establishes a tunnel to Router 2 with unknowingly mismatched MRU either side, when the end user tries to send/receive packets that exceed the lower MRU (any reasonably heavy download, video stream, bandwidth test or similar) they are going to get blackholed/dropped in the case of UDP or be constantly dropped/rewindowed (up and down) if TCP. Some tunnels are clever and will resize your packets regardless. Whether this operation can be done at line rate or is passed back to 'software' I don't know. Worst case on both is reduced throughput and increased latency.
How likely is any of this? Pretty unlikely I would have thought. There is no escaping the fact that BTW have deployed 500 odd new MSE BRAS. What is the chance of a misconfiguration or bug on one/several of these devices? Low but not impossible?
Why does the problem only present at peak times? Who knows :) This does provide another answer to the 'why does re-PPP seem to sort my connection out' though possibly.
That's enough straw clutching from me for now :D
-
Plusnet have been using IP Stream Connect (https://www.btwholesale.com/pages/static/Products/Broadband/BT_IPstream_Connect/index.htm) for 20CN for a long time.
-
Good to know :)
Max Premium still has a preferential weighting over WBC; AF31/AF21/AF11 I think so in the case of actual congestion, you are one of the few that should truly benefit.
Although I do seem to remember there being something about the CP having to buy special bandwidth for the Premium users? Can't remember now, will try and find it again.
-
IIRC Plusnet's external (paid) routing is exceptionally limited? ISTR its basically BT public internet service & that's it.
So basically most traffic (60% +) to/from Plusnet goes via AS2856 (BT public internet service - http://bgp.he.net/AS2856#_asinfo ) and then to AS5400 (BT plc - http://bgp.he.net/AS5400#_asinfo )
Also IIRC Plusnet only have L3 peering with them on AS2856 which caused significant issues last year when the BGP routing table exceeded 512k entries and lots of L3 kit fell over in a heap.
Frankly its pretty goddamn awful connectivity & that's where Plusnet save the pennies IMHO. Were it me I think I'd be looking at the interfaces between AS6871 (Plusnet) and AS2856 (BT Public Internet Service)...
Edit - There are differences in routing between IPv4 & IPv6 traffic from what I can see. If anyone can do a speedtest with both protocols (one after the other) from Plusnet then it'd be interesting to see if there is a difference.....
-
ipv6 seems to exclusively use one provider trying to remember who they are but forgot the name, the traceroute entries have no rdns.
I agree the lack of transit diversity is an issue, they seem to have the usual peering to things like youtube, netflix, bbc etc. But when is no peering its nearly always level3.
root@TomatoAC66:/tmp/home/root# traceroute6 google.com
traceroute to google.com (2a00:1450:400b:c02::8a), 30 hops max, 16 byte packets
1 2a02:16c8:0:1::15 (2a02:16c8:0:1::15) 20.028 ms 39.774 ms 16.588 ms
2 2a02:16c8:1:2::19 (2a02:16c8:1:2::19) 15.415 ms 15.382 ms 15.430 ms
3 2a02:16c8::d (2a02:16c8::d) 15.371 ms 15.382 ms 15.017 ms
4 2a02:16c8:1:2::8 (2a02:16c8:1:2::8) 15.795 ms 15.383 ms 15.805 ms
5 2001:4860:1:1:0:1ad7:: (2001:4860:1:1:0:1ad7::) 15.818 ms 15.436 ms 15.770 ms
6 2001:4860::1:0:15f (2001:4860::1:0:15f) 16.207 ms 15.775 ms 15.810 ms
7 2001:4860::8:0:5bb9 (2001:4860::8:0:5bb9) 15.404 ms 15.394 ms 15.471 ms
8 2001:4860::1:0:70c5 (2001:4860::1:0:70c5) 24.552 ms 24.225 ms 24.983 ms
9 2001:4860::2:0:3de7 (2001:4860::2:0:3de7) 25.395 ms 25.379 ms 24.593 ms
10 * * *
11 de-in-x8a.1e100.net (2a00:1450:400b:c02::8a) 24.353 ms 24.847 ms 25.026 ms
I think I just remembered, might be hurricane electric.
-
In that trace it would appear that Plusnet peers direct with Google,Well according to the reverse look up of the IPV6 , IPV4 appear to be the same routing to google.com they would appear to of dropped the use of Level 3 peering by a lot recently , replaced by BT peering now , as if this will be a permanent thing is anyone's guess
-
Don't PN peer with TBB.. or at least they used to.
In which case then there shouldnt be any external transit problems when doing speedtests with TBB
-
I'm making the assumption that PN is L2TP passthrough
Yep afaik practically all of the BTw based ISPs (aside from BTr) use l2tp.
A quick reminder of which bit of the network we're talking about - BT BRAS to CP BRAS:
Only BT has bRAS. The bit you highlighted in red (aside from the MSILs) is mostly CORE transit.
SVLAN & VP is the bit before the bRAS. On 20CN, the VPs are definitely MSAN to BRAS location ie backhaul.
-
Don't PN peer with TBB.. or at least they used to.
In which case then there shouldnt be any external transit problems when doing speedtests with TBB
they peer via linx-gw1.thn.ncuk.net
-
Don't PN peer with TBB.. or at least they used to.
In which case then there shouldnt be any external transit problems when doing speedtests with TBB
Plusnet have LINX peering yeah, of course peering can get congested its not immune to it.
Some of plusnet's recent comments have made things less conclusive from them, they commented that they checked the end points again and is sufficient capacity, but on the same page they also said there was some imbalance and some endpoints were congested. So I take that to mean in a situation where traffic is within plusnet's expectations "and" things are well balanced then there should be no congestion PN side, of course that is an if.
-
I think that recent comment about Plusnet's network being out of balance was referring to a couple of recent events which won't have helped matters, but can't be responsible for the ongoing issues.
The graphs (http://www.plus.net/support/service/network_performance/broadband_bandwidth_usage.shtml) have looked a total mess recently, but it was still possible to spot that all the users got dropped off pcl-bng01 on Wed 11 March, and on Fri 13 March it looks like there were very few users on pcl-ag02 (and there were some service status messages yesterday).
-
I think that recent comment about Plusnet's network being out of balance was referring to a couple of recent events which won't have helped matters, but can't be responsible for the ongoing issues.
The graphs (http://www.plus.net/support/service/network_performance/broadband_bandwidth_usage.shtml) have looked a total mess recently, but it was still possible to spot that all the users got dropped off pcl-bng01 on Wed 11 March, and on Fri 13 March it looks like there were very few users on pcl-ag02 (and there were some service status messages yesterday).
I have been on PCL bng01 since the 11th @10:30pm , The said gateway has endpoints for me that are better for latency than some of the others, both this gateway and PCL BNG 02 always seem to end up with more customers connected than the other bng's maybe lower latency is a factor for everyone ? but there are some endpoints to PCL BNG 01 that have really poor performance at peak times , i do seem to see low level packet loss more so on the ping monitor, in particular when streaming something on youtube
usage last night was lower than it was on the 12 and other nights this week , even so single stream throughput was still affected ,but not as severely as previous nights, there also was the absence of the useual peak time increase in latency ,though there was a small increase in the level of jitter, but overall a better night that the rest of this week,
Those plusnet graphs don't show the full picture IMO, so probably serve to confuse things further maybe ?
-
Don't PN peer with TBB.. or at least they used to.
In which case then there shouldnt be any external transit problems when doing speedtests with TBB
Plusnet have LINX peering yeah, of course peering can get congested its not immune to it.
As you say it's possible, but tbh I dont think its that. Otherwise how could some people do perfectly fine speedtests and others get bad. Also if there was a problem with the linx peering, then that wouldnt explain why those that who do have issues also see problems to other sites that dont use linx peering. If you get hit by the problem it seems to be all routes out affected so I think its more likely to be before or at PN than peer or transit.
Some of plusnet's recent comments have made things less conclusive from them, they commented that they checked the end points again and is sufficient capacity, but on the same page they also said there was some imbalance and some endpoints were congested. So I take that to mean in a situation where traffic is within plusnet's expectations "and" things are well balanced then there should be no congestion PN side, of course that is an if.
That explanation is fine by me, it can and does happen to all BTw based ISPs. It's because of the way BTw load the pipes using round robin then this problem will continue to crop up from time to time. As more people leave their routers on 24/7 things can become unbalanced particularly if there's been any sort of unusual activity.
Several years ago Zen started to every night drop their users off all pipes at just gone midnight for a while in an attempt to keep their centrals balanced. Obviously that proved to be highly unpopular. If pipes become unbalanced the ISP has an option to drop all users on that pipe or leave things unbalanced. When I say drop all users on the pipe, its a little more complicated than that, because they actually instruct their edge router to drop all sessions. Depending upon the ISP network and their equipment and the fact that an edge router can be feeding several links, then you could end up dropping more users than you want. For example in the case of Zen (and PN of old), you could have several centrals attached to the same Redback/Juniper... and hence why in the case of Zen why they were dropping all of their customers every night. I dont keep up with what network equipment PN has these days - they are much bigger now and will have much more equipment... but that doesn't make them immune from imbalanced pipes.
-
I have been on PCL bng01 since the 11th @10:30pm ,
Ive been on central12.pcl-bng02 [195.166.130.153] since
25 2015 Jan 23 21:19:46 PPPoE notice PPPoE ACK, ifName:ppp1.1, assigned ip=81.174.xxx.xxx gateway=195.166.130.153 nameserver=212.159.6.10,212.159.6.9 lastConnectionError=ERROR_NONE servicename=
As you will recall I'd been suffering for few weeks with the same problem you guys are seeing. Then one evening when my speeds had dropped to circa 20Mb across the board, I went pipe hopping. I immediately went from 20Mb straight back up to 76Mb. Since the 23rd Jan Ive not seen any problems my speeds are fine and so are my TBB BQM. Ive remained constantly connected to PCL-BNG2
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F83ae47d6094694debb5a74239264a332-13-03-2015.png&hash=fea70d2f74173a1e8e01a402597819d015c428ee) (http://www.thinkbroadband.com/ping/share/83ae47d6094694debb5a74239264a332-13-03-2015.html)
So I think we can definitely rule out peering or transit.
If Plusnet are saying that their network is fine.. and if we know that the SVLANs/VPs are fine... then I'm beginning to wonder about the MSILs. How on earth they are monitored by BTw Ive no idea.
------------
ETA
Reason I say MSIL's, its because its possible that you may end up using different routing and going through different MSILs each time you drop PPP session. For example your BTw based routing is going to be different if you connect to an endpoint connected say a PTW gateway than a PCL gateway. Because of L2TP we dont see any of the actual routing when we do a tracert.
-
I think that recent comment about Plusnet's network being out of balance was referring to a couple of recent events which won't have helped matters, but can't be responsible for the ongoing issues.
The graphs (http://www.plus.net/support/service/network_performance/broadband_bandwidth_usage.shtml) have looked a total mess recently, but it was still possible to spot that all the users got dropped off pcl-bng01 on Wed 11 March, and on Fri 13 March it looks like there were very few users on pcl-ag02 (and there were some service status messages yesterday).
remember thats just per gateway but is multiple endpoints per gateway, in other words that data isnt very useful.
-
Don't PN peer with TBB.. or at least they used to.
In which case then there shouldnt be any external transit problems when doing speedtests with TBB
Plusnet have LINX peering yeah, of course peering can get congested its not immune to it.
As you say it's possible, but tbh I dont think its that. Otherwise how could some people do perfectly fine speedtests and others get bad. Also if there was a problem with the linx peering, then that wouldnt explain why those that who do have issues also see problems to other sites that dont use linx peering. If you get hit by the problem it seems to be all routes out affected so I think its more likely to be before or at PN than peer or transit.
Some of plusnet's recent comments have made things less conclusive from them, they commented that they checked the end points again and is sufficient capacity, but on the same page they also said there was some imbalance and some endpoints were congested. So I take that to mean in a situation where traffic is within plusnet's expectations "and" things are well balanced then there should be no congestion PN side, of course that is an if.
That explanation is fine by me, it can and does happen to all BTw based ISPs. It's because of the way BTw load the pipes using round robin then this problem will continue to crop up from time to time. As more people leave their routers on 24/7 things can become unbalanced particularly if there's been any sort of unusual activity.
Several years ago Zen started to every night drop their users off all pipes at just gone midnight for a while in an attempt to keep their centrals balanced. Obviously that proved to be highly unpopular. If pipes become unbalanced the ISP has an option to drop all users on that pipe or leave things unbalanced. When I say drop all users on the pipe, its a little more complicated than that, because they actually instruct their edge router to drop all sessions. Depending upon the ISP network and their equipment and the fact that an edge router can be feeding several links, then you could end up dropping more users than you want. For example in the case of Zen (and PN of old), you could have several centrals attached to the same Redback/Juniper... and hence why in the case of Zen why they were dropping all of their customers every night. I dont keep up with what network equipment PN has these days - they are much bigger now and will have much more equipment... but that doesn't make them immune from imbalanced pipes.
I agree its not the peering.
To me its either something within BTw close to PN or PN endpoint's.
If you think it might be MSIL's perhaps you can post in the PN thread to tell them to check?
-
This the second week that saturdays have been affected, so 7 days a week congestion (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F14263689751373593973.png&hash=e2053b94a9169ff244a273bf4b86dc74326589ca)
-
Seems OK here:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142636972114871077649.png&hash=123cb303f60a2da80cea7cda8bf3da90af1c9008)
Trace to speedtest4 = ptn-ag02 > ptn-gw01:
Tracing route to speedtest4.thinkbroadband.com [80.249.107.221]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.254
2 10 ms 16 ms 12 ms lo0-central10.ptn-ag02.plus.net [195.166.128.191
]
3 10 ms 10 ms 9 ms link-a-central10.ptn-gw01.plus.net [212.159.2.13
2]
4 9 ms 9 ms 9 ms xe-1-2-0.ptw-cr01.plus.net [212.159.0.112]
5 10 ms 10 ms 17 ms 195.99.126.138
6 18 ms 17 ms 14 ms 194.72.31.138
7 11 ms 11 ms 10 ms transit2-xe-9-1-0.ilford.ukcore.bt.net [62.172.1
03.167]
8 14 ms 33 ms 11 ms t2c4-xe-10-3-0-0.uk-ilf.eu.bt.net [166.49.168.10
9]
9 11 ms 11 ms 11 ms xe-10-3-1.edge3.London1.Level3.net [195.50.124.2
1]
10 13 ms 14 ms 11 ms 4.68.70.78
11 12 ms 11 ms 11 ms ae10.mpr2.lhr2.uk.zip.zayo.com [64.125.31.194]
12 18 ms 20 ms 19 ms ae5.mpr1.lhr15.uk.zip.zayo.com [64.125.21.10]
13 10 ms 11 ms 10 ms 94.31.40.154.IPYX-080002-001-ZYO.above.net [94.3
1.40.154]
14 11 ms 10 ms 10 ms te2-1-9.star10g.bdr-rt1.thn.ncuk.net [80.249.97.
18]
Trace to bbc = ptn-ag02 > ptn-gw02:
Tracing route to www.bbc.net.uk [212.58.246.90]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.254
2 11 ms 10 ms 10 ms lo0-central10.ptn-ag02.plus.net [195.166.128.191
]
3 10 ms 10 ms 9 ms link-b-central10.ptn-gw02.plus.net [212.159.2.13
4]
4 13 ms 9 ms 10 ms xe-1-2-0.ptw-cr02.plus.net [212.159.0.114]
5 17 ms 9 ms 9 ms ae2.ptw-cr01.plus.net [195.166.129.4]
6 10 ms 9 ms 9 ms kingston-gw.thdo.bbc.co.uk [212.58.239.6]
7 * * * Request timed out.
8 11 ms 10 ms 10 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
9 11 ms 11 ms 11 ms 132.185.255.165
10 12 ms 10 ms 11 ms bbc-vip011.cwwtf.bbc.co.uk [212.58.246.90]
Trace complete.
-
It's ok here too, now that i have hopped gateways & endpoints again although it was approaching 10pm , and the upstream is't that great, a single threaded upload( FTP) wasn't maxing out around 1mbps shy (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142637087682748774784.png&hash=10a16e84f943544f5a3d7f843835c870af10a2b4)So until until this endpoint becomes saturated as well, then it's put up with congestion or hop yet again,
-
Which doodar are you on? Whereabouts? etc?
-
I'm currently on , gateway central10-ptn-bng01 exchange is LCSOU It's GEA parent is LCBIR
-
If you think it might be MSIL's perhaps you can post in the PN thread to tell them to check?
The problem is BTw are very quiet about their MSIL's, and I dont know how they monitor these and when they increase capacity. Information about the BTw MSIL's is exceedingly sparse, but they are likely to have many MSILs at each core location. I don't have sufficient information or knowledge to be able to categorically point my finger at the MSILs.
However MSILs are a known major point of congestion. This can be evidenced by any WBC ISPs (such as Enta) who purchase and maintain their own APs and MSILs.
Anyhow, as requested Ive made a post here (http://community.plus.net/forum/index.php/topic,135389.msg1209653.html#msg1209653).
-
I stumbled across this earlier. I guess it's donkeys old but still interesting:
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.plus.net%2Fimages%2Fnetwork%2Fnetwork-map0210.png&hash=7748dbd47288f42770ce9a526a70b6c066d39a42)
From that, I assume the following from the gateway names:
ptn = Telehouse North
ptw = Telehouse West?
pcl = City Lifeline
AG and BNG are presumably two different types of router. I assume both are MX, with BNG being a newer, shinier version? Or maybe ERX and MX.
Also found this forum post:
http://forums.juniper.net/t5/Routing/VPLS-Multihoming-with-Multiple-sites/td-p/184069
Where the same 3 char abbreviations are used. The topic is VPLS (bridging ethernet to remote sites) and the instance name is 'PROCERA'.
Procera Networks is a networking equipment company based in Fremont, California, United States, that designs and sells deep packet inspection (DPI), policy charging and rules function, data analytics and reporting hardware, software and services.
Because I love leaping to conclusions, my extrapolation is BNG = DPI = Reduced throughput and increased latency once load is greater than n.
Going back to the peering talk earlier, we missed something perhaps; the PN xconnects between PTN/PTW/PCL for any site specific transit. Going by the above image, Telehouse North was their first site to get a 10Gb MSIL to BT.
-
If you think it might be MSIL's perhaps you can post in the PN thread to tell them to check?
The problem is BTw are very quiet about their MSIL's, and I dont know how they monitor these and when they increase capacity. Information about the BTw MSIL's is exceedingly sparse, but they are likely to have many MSILs at each core location. I don't have sufficient information or knowledge to be able to categorically point my finger at the MSILs.
However MSILs are a known major point of congestion. This can be evidenced by any WBC ISPs (such as Enta) who purchase and maintain their own APs and MSILs.
Anyhow, as requested Ive made a post here (http://community.plus.net/forum/index.php/topic,135389.msg1209653.html#msg1209653).
wow yeah thats a good post, thanks.
lets see what they come up with, like yourself my performance has been ok for weeks now as well.
-
I guess it's donkeys old but still interesting:
The diagram is old, but newer than mine here (http://kitz.co.uk/adsl/equip3.htm) which was from back in the days when I was bang up to date with things like centrals and what equipment PN had. I lost track some time around 2009 mostly because I wasn't with PN and lost interest in keeping up to date with what they were doing... it was also a bit harder to get info because they were now owned by BT and most of my contacts had moved on.
I assume the following from the gateway names:
Yep - they've always used that type of naming convention.
PTW = Plusnet Telehouse West
PTN = Plusnet Telehouse North
I always thought that CL = City/Central London. iirc 'PCL' first started when they took over Metronets pipes circa '06. I cant recall for certain, but I think it originally may have been Telecity, Central London. Whatever way City Lifeline also fits nicely now.
Prior to that they also had PTH which originally was Telehouse East, later changed to PTE to match the others. PTH (PTE) was the terminating colo for their original centrals when they first started selling adsl.
AG and BNG are presumably two different types of router.
No, the second part (AG/BNG) isnt specific to the make & model of Edge Router.
'AG' simply denoted 'Aggregator' which was followed by the number at that particular location. These were Juniper ERX 1440s (x6) and iirc by about '09 they also had x8 what were at the time shiny new E320's. Going back even further in history, a couple of Redbacks were the original pth-ag1 & pth-ag2. To be more exact their full name as advertised by their manufacturers was Redback SMS 10000 Broadband Aggregator.
BNG = Broadband Network Gateway. Unsure exactly what model they are, but yes Juniper MX is the route they headed after ERX became EOL (end of life).
From a quick scan of the specs for all the MX models then it would have to be at least an MX960, but it could also be an MX2010/2020.
Depends on how how much they budget, what model was available at which date, and when they bought them. PN always used to go for top of the range capacity model when it came to their edge routing. Makes sense I suppose, they have a lot of customers so the larger models work out more economical in the long term as they can cope with more sessions and multiple endpoints. No point having to buy 2 of the cheaper models when you can save a bit of money by purchasing just one of the higher spec.
As regards to the ERX/E320's - Just because a product is EOL doesnt mean that the ISP will replace them. These are very expensive & sturdy bits of kit and have many replacement slot-in parts. Both the E320s and ERX1440's were top of the range in their time designed to last for years and still have plenty of life in them. Because they were top of the range kit in their time, then they will still happily cope with multiple endpoints and be supported by JunOS. I tried to cost up the price of an ERX many years ago and iirc you're easily looking in the region of £500,000. Not something an ISP is going to replace every few years and why there is a market for powerful second-hand edge routers. As an indication Zen have only just replaced their Redbacks (PN replaced theirs 8/9yrs ago).
my extrapolation is BNG = DPI
Procera as you say is into Deep Packet Inspection. This is a bit of a weird one. Arbor Networks aquired Ellacoya Networks, yet there's quite a lot of same staff at Procera who used to work at Ellacoya. Arbor doesnt seem to be into DPI and Procera quote themselves as being the only company that delivers 'Internet Intelligence'. Ellacoya used to be the most advanced and intelligent when it came to DPI.
Plusnet have for years (since 2006) used Ellacoyas for DPI on their E/ERX's and since Procera was recently awarded a major contract with BT for DPI then I would imagine that they are simply using Procera on the 2 new BNGs because you cant buy 'Ellacoyas' any more.
increased latency once load is greater than n
No - The whole idea of using Ellacoyas/Procera, is so that when things do get busy latency does not suffer.
The Ellacoyas are very intelligent, if the network is busy latency should not be affected at all, instead it will start to throttle back on other protocols such as p2p or nttp. Latency is usually given priority over all other protocols because its essential for gaming and VoIP. HTTP (web browsing) and web based speedtests would also not suffer, as http is usually given priority after latency affecting apps such as VOiP and gaming. You'd notice it on p2p for sure though. The intelligence part of DPI is that you cant fool them by changing ports and attempting to make p2p look like http... and why the name Ellacoya is hated by certain communities.
I'd much rather be on a busy network controlled by Ellacoyas than one without. When on Be* there was one episode when we were waiting for our exchange backhaul to be upgraded. Latency goes to pot without proper traffic shaping, http speeds go to pot.. but heck I could still max out nttp by opening 6 threads.
Hmm you have a point there.. it took PN ages to get the ellacoya configs right... I wonder if there could be something in the fact they are now using Procera its another new learning curve.. I dunno.
hmmm again.. I think if it was a config issue then again it would be all users on the BNGs and they'd be complaining about something other than latency and http. :hmm:
the PN xconnects between PTN/PTW/PCL for any site specific transit.
It had actually crossed my mind the other day, but I soon discarded it because far more users would be complaining - ie all those connected at any PCL or at any PTW gateways would get rubbish speedtests at TBB (Linx @ THN), or out to the Internet via 'x' routing. It would be much easier to spot as it would become more site specific. You'd start seeing silly things like good TBB speeds but poor speedtest.net results and vice versa depending upon location of the gateway you are connected via and which transit/peer was at that location.
found this forum post:
lol it's no surprise that their naming convention is the same... because I know who that is ;)
Gawd am I a mine of useless information or what. :-X
I also just surprised myself that I can remember half this stuff, yet can't recall what I had for tea yesterday. :lol:
-
rizla this may interest you.
Both these graphs are from my FTTC plusnet line, one is my ipv6 ip and the other is ipv4. Date today.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2Fcb474a466186ff11ea76e17f37083e54-16-03-2015.png&hash=d36aae747f57b3e305dcd44016af6505adc64604) (http://www.thinkbroadband.com/ping/share/cb474a466186ff11ea76e17f37083e54-16-03-2015.html)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F2d2447d66dabeb16e19124b43f9524ba-16-03-2015.png&hash=61478c0f93e225b4b0175614f374475d46844d07) (http://www.thinkbroadband.com/ping/share/2d2447d66dabeb16e19124b43f9524ba-16-03-2015.html)
traceroute to google is same as before, but to thinkbroadband.com the last hop has the higher latency as below.
root@TomatoAC66:/tmp/home/root# traceroute6 thinkbroadband.com
traceroute to thinkbroadband.com (2a02:68:1::4), 30 hops max, 16 byte packets
1 2a02:16c8:0:1::15 (2a02:16c8:0:1::15) 284.556 ms 487.026 ms 449.783 ms
2 2a02:16c8:1:2::17 (2a02:16c8:1:2::17) 32.167 ms 22.587 ms 20.722 ms
3 2a02:16c8::c (2a02:16c8::c) 16.868 ms 23.390 ms 17.799 ms
4 2a02:16c8:1:2::6 (2a02:16c8:1:2::6) 16.611 ms 16.208 ms 16.225 ms
5 40ge1-3.core1.lon2.he.net (2001:7f8:4::1b1b:1) 16.178 ms 28.860 ms 28.231 ms
6 linx-gw1.thn.ncuk.net (2001:7f8:4::5394:1) 20.170 ms 22.619 ms 22.609 ms
7 2a02:68:0:9::4 (2a02:68:0:9::4) 23.786 ms 24.590 ms 25.896 ms
8 2a02:68:0:31::9 (2a02:68:0:31::9) 26.573 ms 48.195 ms 37.812 ms
root@TomatoAC66:/tmp/home/root# ping6 2a02:68:0:31::9
PING 2a02:68:0:31::9 (2a02:68:0:31::9): 56 data bytes
64 bytes from 2a02:68:0:31::9: seq=0 ttl=58 time=16.796 ms
64 bytes from 2a02:68:0:31::9: seq=1 ttl=58 time=18.505 ms
64 bytes from 2a02:68:0:31::9: seq=2 ttl=58 time=18.763 ms
64 bytes from 2a02:68:0:31::9: seq=3 ttl=58 time=18.501 ms
64 bytes from 2a02:68:0:31::9: seq=4 ttl=58 time=21.735 ms
64 bytes from 2a02:68:0:31::9: seq=5 ttl=58 time=17.542 ms
64 bytes from 2a02:68:0:31::9: seq=6 ttl=58 time=18.507 ms
64 bytes from 2a02:68:0:31::9: seq=7 ttl=58 time=17.058 ms
64 bytes from 2a02:68:0:31::9: seq=8 ttl=58 time=19.280 ms
64 bytes from 2a02:68:0:31::9: seq=9 ttl=58 time=17.475 ms
64 bytes from 2a02:68:0:31::9: seq=10 ttl=58 time=17.444 ms
64 bytes from 2a02:68:0:31::9: seq=11 ttl=58 time=17.483 ms
64 bytes from 2a02:68:0:31::9: seq=12 ttl=58 time=17.477 ms
64 bytes from 2a02:68:0:31::9: seq=13 ttl=58 time=23.331 ms
64 bytes from 2a02:68:0:31::9: seq=14 ttl=58 time=20.234 ms
64 bytes from 2a02:68:0:31::9: seq=15 ttl=58 time=17.842 ms
64 bytes from 2a02:68:0:31::9: seq=16 ttl=58 time=45.961 ms
64 bytes from 2a02:68:0:31::9: seq=17 ttl=58 time=40.590 ms
64 bytes from 2a02:68:0:31::9: seq=18 ttl=58 time=56.443 ms
64 bytes from 2a02:68:0:31::9: seq=19 ttl=58 time=50.415 ms
64 bytes from 2a02:68:0:31::9: seq=20 ttl=58 time=26.425 ms
64 bytes from 2a02:68:0:31::9: seq=21 ttl=58 time=38.023 ms
64 bytes from 2a02:68:0:31::9: seq=22 ttl=58 time=43.218 ms
64 bytes from 2a02:68:0:31::9: seq=23 ttl=58 time=53.897 ms
64 bytes from 2a02:68:0:31::9: seq=24 ttl=58 time=38.276 ms
64 bytes from 2a02:68:0:31::9: seq=25 ttl=58 time=25.761 ms
64 bytes from 2a02:68:0:31::9: seq=26 ttl=58 time=22.187 ms
64 bytes from 2a02:68:0:31::9: seq=27 ttl=58 time=29.394 ms
64 bytes from 2a02:68:0:31::9: seq=28 ttl=58 time=24.202 ms
64 bytes from 2a02:68:0:31::9: seq=29 ttl=58 time=22.211 ms
64 bytes from 2a02:68:0:31::9: seq=30 ttl=58 time=18.581 ms
64 bytes from 2a02:68:0:31::9: seq=31 ttl=58 time=18.182 ms
64 bytes from 2a02:68:0:31::9: seq=32 ttl=58 time=18.165 ms
64 bytes from 2a02:68:0:31::9: seq=33 ttl=58 time=17.454 ms
64 bytes from 2a02:68:0:31::9: seq=34 ttl=58 time=17.584 ms
64 bytes from 2a02:68:0:31::9: seq=35 ttl=58 time=18.757 ms
64 bytes from 2a02:68:0:31::9: seq=36 ttl=58 time=48.572 ms
64 bytes from 2a02:68:0:31::9: seq=37 ttl=58 time=39.984 ms
64 bytes from 2a02:68:0:31::9: seq=38 ttl=58 time=17.549 ms
64 bytes from 2a02:68:0:31::9: seq=39 ttl=58 time=19.549 ms
64 bytes from 2a02:68:0:31::9: seq=40 ttl=58 time=27.534 ms
64 bytes from 2a02:68:0:31::9: seq=41 ttl=58 time=26.952 ms
64 bytes from 2a02:68:0:31::9: seq=42 ttl=58 time=38.555 ms
64 bytes from 2a02:68:0:31::9: seq=43 ttl=58 time=24.021 ms
64 bytes from 2a02:68:0:31::9: seq=44 ttl=58 time=21.322 ms
64 bytes from 2a02:68:0:31::9: seq=45 ttl=58 time=20.929 ms
64 bytes from 2a02:68:0:31::9: seq=46 ttl=58 time=18.510 ms
64 bytes from 2a02:68:0:31::9: seq=47 ttl=58 time=22.118 ms
64 bytes from 2a02:68:0:31::9: seq=48 ttl=58 time=50.610 ms
64 bytes from 2a02:68:0:31::9: seq=49 ttl=58 time=37.506 ms
64 bytes from 2a02:68:0:31::9: seq=50 ttl=58 time=23.484 ms
64 bytes from 2a02:68:0:31::9: seq=51 ttl=58 time=20.307 ms
64 bytes from 2a02:68:0:31::9: seq=52 ttl=58 time=25.092 ms
64 bytes from 2a02:68:0:31::9: seq=53 ttl=58 time=20.556 ms
64 bytes from 2a02:68:0:31::9: seq=54 ttl=58 time=20.272 ms
64 bytes from 2a02:68:0:31::9: seq=55 ttl=58 time=19.093 ms
64 bytes from 2a02:68:0:31::9: seq=56 ttl=58 time=18.497 ms
64 bytes from 2a02:68:0:31::9: seq=57 ttl=58 time=26.461 ms
64 bytes from 2a02:68:0:31::9: seq=58 ttl=58 time=50.483 ms
64 bytes from 2a02:68:0:31::9: seq=59 ttl=58 time=35.262 ms
64 bytes from 2a02:68:0:31::9: seq=60 ttl=58 time=54.871 ms
64 bytes from 2a02:68:0:31::9: seq=61 ttl=58 time=18.453 ms
64 bytes from 2a02:68:0:31::9: seq=62 ttl=58 time=19.031 ms
64 bytes from 2a02:68:0:31::9: seq=63 ttl=58 time=27.531 ms
64 bytes from 2a02:68:0:31::9: seq=64 ttl=58 time=17.831 ms
64 bytes from 2a02:68:0:31::9: seq=65 ttl=58 time=17.040 ms
64 bytes from 2a02:68:0:31::9: seq=66 ttl=58 time=17.825 ms
64 bytes from 2a02:68:0:31::9: seq=67 ttl=58 time=19.043 ms
64 bytes from 2a02:68:0:31::9: seq=68 ttl=58 time=18.253 ms
64 bytes from 2a02:68:0:31::9: seq=69 ttl=58 time=23.087 ms
64 bytes from 2a02:68:0:31::9: seq=70 ttl=58 time=26.628 ms
64 bytes from 2a02:68:0:31::9: seq=71 ttl=58 time=30.224 ms
64 bytes from 2a02:68:0:31::9: seq=72 ttl=58 time=26.001 ms
64 bytes from 2a02:68:0:31::9: seq=73 ttl=58 time=18.687 ms
64 bytes from 2a02:68:0:31::9: seq=74 ttl=58 time=27.202 ms
64 bytes from 2a02:68:0:31::9: seq=75 ttl=58 time=18.010 ms
64 bytes from 2a02:68:0:31::9: seq=76 ttl=58 time=17.203 ms
64 bytes from 2a02:68:0:31::9: seq=77 ttl=58 time=39.170 ms
64 bytes from 2a02:68:0:31::9: seq=78 ttl=58 time=23.968 ms
64 bytes from 2a02:68:0:31::9: seq=79 ttl=58 time=17.186 ms
64 bytes from 2a02:68:0:31::9: seq=80 ttl=58 time=19.404 ms
64 bytes from 2a02:68:0:31::9: seq=81 ttl=58 time=17.914 ms
64 bytes from 2a02:68:0:31::9: seq=82 ttl=58 time=17.906 ms
64 bytes from 2a02:68:0:31::9: seq=83 ttl=58 time=17.491 ms
64 bytes from 2a02:68:0:31::9: seq=84 ttl=58 time=17.897 ms
64 bytes from 2a02:68:0:31::9: seq=85 ttl=58 time=17.887 ms
64 bytes from 2a02:68:0:31::9: seq=86 ttl=58 time=18.700 ms
64 bytes from 2a02:68:0:31::9: seq=87 ttl=58 time=16.276 ms
64 bytes from 2a02:68:0:31::9: seq=88 ttl=58 time=30.138 ms
64 bytes from 2a02:68:0:31::9: seq=89 ttl=58 time=17.283 ms
64 bytes from 2a02:68:0:31::9: seq=90 ttl=58 time=16.902 ms
64 bytes from 2a02:68:0:31::9: seq=91 ttl=58 time=22.886 ms
64 bytes from 2a02:68:0:31::9: seq=92 ttl=58 time=26.857 ms
64 bytes from 2a02:68:0:31::9: seq=93 ttl=58 time=17.240 ms
64 bytes from 2a02:68:0:31::9: seq=94 ttl=58 time=37.279 ms
64 bytes from 2a02:68:0:31::9: seq=95 ttl=58 time=28.038 ms
64 bytes from 2a02:68:0:31::9: seq=96 ttl=58 time=37.471 ms
64 bytes from 2a02:68:0:31::9: seq=97 ttl=58 time=28.241 ms
64 bytes from 2a02:68:0:31::9: seq=98 ttl=58 time=17.455 ms
64 bytes from 2a02:68:0:31::9: seq=99 ttl=58 time=16.238 ms
64 bytes from 2a02:68:0:31::9: seq=100 ttl=58 time=18.232 ms
--- 2a02:68:0:31::9 ping statistics ---
101 packets transmitted, 101 packets received, 0% packet loss
round-trip min/avg/max = 16.238/25.068/56.443 ms
however the traceroute was just bad timing as I pinged the last 2 hops both have the varying latency.
root@TomatoAC66:/tmp/home/root# ping6 2a02:68:0:31::4
PING 2a02:68:0:31::4 (2a02:68:0:31::4): 56 data bytes
64 bytes from 2a02:68:0:31::4: seq=0 ttl=59 time=44.281 ms
64 bytes from 2a02:68:0:31::4: seq=1 ttl=59 time=40.867 ms
64 bytes from 2a02:68:0:31::4: seq=2 ttl=59 time=38.696 ms
64 bytes from 2a02:68:0:31::4: seq=3 ttl=59 time=35.081 ms
64 bytes from 2a02:68:0:31::4: seq=4 ttl=59 time=43.096 ms
64 bytes from 2a02:68:0:31::4: seq=5 ttl=59 time=31.101 ms
64 bytes from 2a02:68:0:31::4: seq=6 ttl=59 time=23.424 ms
64 bytes from 2a02:68:0:31::4: seq=7 ttl=59 time=49.443 ms
64 bytes from 2a02:68:0:31::4: seq=8 ttl=59 time=37.058 ms
64 bytes from 2a02:68:0:31::4: seq=9 ttl=59 time=31.081 ms
64 bytes from 2a02:68:0:31::4: seq=10 ttl=59 time=18.849 ms
64 bytes from 2a02:68:0:31::4: seq=11 ttl=59 time=27.111 ms
64 bytes from 2a02:68:0:31::4: seq=12 ttl=59 time=24.823 ms
64 bytes from 2a02:68:0:31::4: seq=13 ttl=59 time=56.432 ms
64 bytes from 2a02:68:0:31::4: seq=14 ttl=59 time=62.446 ms
64 bytes from 2a02:68:0:31::4: seq=15 ttl=59 time=55.654 ms
64 bytes from 2a02:68:0:31::4: seq=16 ttl=59 time=31.513 ms
64 bytes from 2a02:68:0:31::4: seq=17 ttl=59 time=37.619 ms
64 bytes from 2a02:68:0:31::4: seq=18 ttl=59 time=48.229 ms
64 bytes from 2a02:68:0:31::4: seq=19 ttl=59 time=30.740 ms
64 bytes from 2a02:68:0:31::4: seq=20 ttl=59 time=61.021 ms
64 bytes from 2a02:68:0:31::4: seq=21 ttl=59 time=56.097 ms
64 bytes from 2a02:68:0:31::4: seq=22 ttl=59 time=65.411 ms
64 bytes from 2a02:68:0:31::4: seq=23 ttl=59 time=65.017 ms
64 bytes from 2a02:68:0:31::4: seq=24 ttl=59 time=61.809 ms
64 bytes from 2a02:68:0:31::4: seq=25 ttl=59 time=53.004 ms
64 bytes from 2a02:68:0:31::4: seq=26 ttl=59 time=43.879 ms
64 bytes from 2a02:68:0:31::4: seq=27 ttl=59 time=63.178 ms
64 bytes from 2a02:68:0:31::4: seq=28 ttl=59 time=43.978 ms
64 bytes from 2a02:68:0:31::4: seq=29 ttl=59 time=43.579 ms
64 bytes from 2a02:68:0:31::4: seq=30 ttl=59 time=51.989 ms
64 bytes from 2a02:68:0:31::4: seq=31 ttl=59 time=50.631 ms
64 bytes from 2a02:68:0:31::4: seq=32 ttl=59 time=57.180 ms
64 bytes from 2a02:68:0:31::4: seq=33 ttl=59 time=70.356 ms
64 bytes from 2a02:68:0:31::4: seq=34 ttl=59 time=55.752 ms
64 bytes from 2a02:68:0:31::4: seq=35 ttl=59 time=44.956 ms
64 bytes from 2a02:68:0:31::4: seq=36 ttl=59 time=40.818 ms
64 bytes from 2a02:68:0:31::4: seq=37 ttl=59 time=65.758 ms
64 bytes from 2a02:68:0:31::4: seq=38 ttl=59 time=44.956 ms
64 bytes from 2a02:68:0:31::4: seq=39 ttl=59 time=48.547 ms
64 bytes from 2a02:68:0:31::4: seq=40 ttl=59 time=33.757 ms
64 bytes from 2a02:68:0:31::4: seq=41 ttl=59 time=42.762 ms
64 bytes from 2a02:68:0:31::4: seq=42 ttl=59 time=57.110 ms
64 bytes from 2a02:68:0:31::4: seq=43 ttl=59 time=61.917 ms
64 bytes from 2a02:68:0:31::4: seq=44 ttl=59 time=67.100 ms
64 bytes from 2a02:68:0:31::4: seq=45 ttl=59 time=155.497 ms
64 bytes from 2a02:68:0:31::4: seq=46 ttl=59 time=42.994 ms
64 bytes from 2a02:68:0:31::4: seq=47 ttl=59 time=38.289 ms
64 bytes from 2a02:68:0:31::4: seq=48 ttl=59 time=34.284 ms
64 bytes from 2a02:68:0:31::4: seq=49 ttl=59 time=37.718 ms
64 bytes from 2a02:68:0:31::4: seq=50 ttl=59 time=31.677 ms
64 bytes from 2a02:68:0:31::4: seq=51 ttl=59 time=30.774 ms
64 bytes from 2a02:68:0:31::4: seq=52 ttl=59 time=26.873 ms
64 bytes from 2a02:68:0:31::4: seq=53 ttl=59 time=50.877 ms
64 bytes from 2a02:68:0:31::4: seq=54 ttl=59 time=76.876 ms
64 bytes from 2a02:68:0:31::4: seq=55 ttl=59 time=58.071 ms
64 bytes from 2a02:68:0:31::4: seq=56 ttl=59 time=69.542 ms
64 bytes from 2a02:68:0:31::4: seq=57 ttl=59 time=62.654 ms
64 bytes from 2a02:68:0:31::4: seq=58 ttl=59 time=34.259 ms
64 bytes from 2a02:68:0:31::4: seq=59 ttl=59 time=16.285 ms
64 bytes from 2a02:68:0:31::4: seq=60 ttl=59 time=26.631 ms
64 bytes from 2a02:68:0:31::4: seq=61 ttl=59 time=20.094 ms
64 bytes from 2a02:68:0:31::4: seq=62 ttl=59 time=15.829 ms
64 bytes from 2a02:68:0:31::4: seq=63 ttl=59 time=38.631 ms
64 bytes from 2a02:68:0:31::4: seq=64 ttl=59 time=17.033 ms
64 bytes from 2a02:68:0:31::4: seq=65 ttl=59 time=16.806 ms
--- 2a02:68:0:31::4 ping statistics ---
66 packets transmitted, 66 packets received, 0% packet loss
round-trip min/avg/max = 15.829/45.754/155.497 ms
now pings to google dns
root@TomatoAC66:/tmp/home/root# ping6 2001:4860:4860::8888
PING 2001:4860:4860::8888 (2001:4860:4860::8888): 56 data bytes
64 bytes from 2001:4860:4860::8888: seq=0 ttl=55 time=25.855 ms
64 bytes from 2001:4860:4860::8888: seq=1 ttl=55 time=21.788 ms
64 bytes from 2001:4860:4860::8888: seq=2 ttl=55 time=34.174 ms
64 bytes from 2001:4860:4860::8888: seq=3 ttl=55 time=22.926 ms
64 bytes from 2001:4860:4860::8888: seq=4 ttl=55 time=21.800 ms
64 bytes from 2001:4860:4860::8888: seq=5 ttl=55 time=28.988 ms
64 bytes from 2001:4860:4860::8888: seq=6 ttl=55 time=22.202 ms
64 bytes from 2001:4860:4860::8888: seq=7 ttl=55 time=21.770 ms
64 bytes from 2001:4860:4860::8888: seq=8 ttl=55 time=27.778 ms
64 bytes from 2001:4860:4860::8888: seq=9 ttl=55 time=38.740 ms
64 bytes from 2001:4860:4860::8888: seq=10 ttl=55 time=31.605 ms
64 bytes from 2001:4860:4860::8888: seq=11 ttl=55 time=27.152 ms
64 bytes from 2001:4860:4860::8888: seq=12 ttl=55 time=21.961 ms
64 bytes from 2001:4860:4860::8888: seq=13 ttl=55 time=21.971 ms
64 bytes from 2001:4860:4860::8888: seq=14 ttl=55 time=23.164 ms
64 bytes from 2001:4860:4860::8888: seq=15 ttl=55 time=21.927 ms
64 bytes from 2001:4860:4860::8888: seq=16 ttl=55 time=21.532 ms
64 bytes from 2001:4860:4860::8888: seq=17 ttl=55 time=36.936 ms
64 bytes from 2001:4860:4860::8888: seq=18 ttl=55 time=21.730 ms
64 bytes from 2001:4860:4860::8888: seq=19 ttl=55 time=29.310 ms
64 bytes from 2001:4860:4860::8888: seq=20 ttl=55 time=21.167 ms
64 bytes from 2001:4860:4860::8888: seq=21 ttl=55 time=22.928 ms
64 bytes from 2001:4860:4860::8888: seq=22 ttl=55 time=22.096 ms
64 bytes from 2001:4860:4860::8888: seq=23 ttl=55 time=21.309 ms
64 bytes from 2001:4860:4860::8888: seq=24 ttl=55 time=22.125 ms
64 bytes from 2001:4860:4860::8888: seq=25 ttl=55 time=22.266 ms
64 bytes from 2001:4860:4860::8888: seq=26 ttl=55 time=21.956 ms
64 bytes from 2001:4860:4860::8888: seq=27 ttl=55 time=34.273 ms
64 bytes from 2001:4860:4860::8888: seq=28 ttl=55 time=21.896 ms
64 bytes from 2001:4860:4860::8888: seq=29 ttl=55 time=22.279 ms
64 bytes from 2001:4860:4860::8888: seq=30 ttl=55 time=22.930 ms
64 bytes from 2001:4860:4860::8888: seq=31 ttl=55 time=21.833 ms
64 bytes from 2001:4860:4860::8888: seq=32 ttl=55 time=22.077 ms
64 bytes from 2001:4860:4860::8888: seq=33 ttl=55 time=26.448 ms
64 bytes from 2001:4860:4860::8888: seq=34 ttl=55 time=22.863 ms
64 bytes from 2001:4860:4860::8888: seq=35 ttl=55 time=22.022 ms
64 bytes from 2001:4860:4860::8888: seq=36 ttl=55 time=21.671 ms
64 bytes from 2001:4860:4860::8888: seq=37 ttl=55 time=25.261 ms
64 bytes from 2001:4860:4860::8888: seq=38 ttl=55 time=22.061 ms
64 bytes from 2001:4860:4860::8888: seq=39 ttl=55 time=22.458 ms
64 bytes from 2001:4860:4860::8888: seq=40 ttl=55 time=22.113 ms
64 bytes from 2001:4860:4860::8888: seq=41 ttl=55 time=23.830 ms
64 bytes from 2001:4860:4860::8888: seq=42 ttl=55 time=21.825 ms
64 bytes from 2001:4860:4860::8888: seq=43 ttl=55 time=22.208 ms
64 bytes from 2001:4860:4860::8888: seq=44 ttl=55 time=21.809 ms
64 bytes from 2001:4860:4860::8888: seq=45 ttl=55 time=28.628 ms
64 bytes from 2001:4860:4860::8888: seq=46 ttl=55 time=21.835 ms
64 bytes from 2001:4860:4860::8888: seq=47 ttl=55 time=21.805 ms
64 bytes from 2001:4860:4860::8888: seq=48 ttl=55 time=22.000 ms
64 bytes from 2001:4860:4860::8888: seq=49 ttl=55 time=22.786 ms
64 bytes from 2001:4860:4860::8888: seq=50 ttl=55 time=22.034 ms
64 bytes from 2001:4860:4860::8888: seq=51 ttl=55 time=22.965 ms
64 bytes from 2001:4860:4860::8888: seq=52 ttl=55 time=22.006 ms
64 bytes from 2001:4860:4860::8888: seq=53 ttl=55 time=35.206 ms
64 bytes from 2001:4860:4860::8888: seq=54 ttl=55 time=21.973 ms
64 bytes from 2001:4860:4860::8888: seq=55 ttl=55 time=21.148 ms
64 bytes from 2001:4860:4860::8888: seq=56 ttl=55 time=22.191 ms
64 bytes from 2001:4860:4860::8888: seq=57 ttl=55 time=22.023 ms
64 bytes from 2001:4860:4860::8888: seq=58 ttl=55 time=22.021 ms
64 bytes from 2001:4860:4860::8888: seq=59 ttl=55 time=23.589 ms
64 bytes from 2001:4860:4860::8888: seq=60 ttl=55 time=24.392 ms
64 bytes from 2001:4860:4860::8888: seq=61 ttl=55 time=21.832 ms
64 bytes from 2001:4860:4860::8888: seq=62 ttl=55 time=21.985 ms
64 bytes from 2001:4860:4860::8888: seq=63 ttl=55 time=21.593 ms
64 bytes from 2001:4860:4860::8888: seq=64 ttl=55 time=22.195 ms
64 bytes from 2001:4860:4860::8888: seq=65 ttl=55 time=22.169 ms
64 bytes from 2001:4860:4860::8888: seq=66 ttl=55 time=22.138 ms
64 bytes from 2001:4860:4860::8888: seq=67 ttl=55 time=21.748 ms
64 bytes from 2001:4860:4860::8888: seq=68 ttl=55 time=21.781 ms
64 bytes from 2001:4860:4860::8888: seq=69 ttl=55 time=22.138 ms
64 bytes from 2001:4860:4860::8888: seq=70 ttl=55 time=22.165 ms
64 bytes from 2001:4860:4860::8888: seq=71 ttl=55 time=22.036 ms
64 bytes from 2001:4860:4860::8888: seq=72 ttl=55 time=21.569 ms
64 bytes from 2001:4860:4860::8888: seq=73 ttl=55 time=22.214 ms
64 bytes from 2001:4860:4860::8888: seq=74 ttl=55 time=21.921 ms
64 bytes from 2001:4860:4860::8888: seq=75 ttl=55 time=21.518 ms
64 bytes from 2001:4860:4860::8888: seq=76 ttl=55 time=22.333 ms
64 bytes from 2001:4860:4860::8888: seq=77 ttl=55 time=26.738 ms
64 bytes from 2001:4860:4860::8888: seq=78 ttl=55 time=21.926 ms
64 bytes from 2001:4860:4860::8888: seq=79 ttl=55 time=21.883 ms
64 bytes from 2001:4860:4860::8888: seq=80 ttl=55 time=22.126 ms
64 bytes from 2001:4860:4860::8888: seq=81 ttl=55 time=28.071 ms
64 bytes from 2001:4860:4860::8888: seq=82 ttl=55 time=22.478 ms
64 bytes from 2001:4860:4860::8888: seq=83 ttl=55 time=22.091 ms
64 bytes from 2001:4860:4860::8888: seq=84 ttl=55 time=34.082 ms
64 bytes from 2001:4860:4860::8888: seq=85 ttl=55 time=22.508 ms
64 bytes from 2001:4860:4860::8888: seq=86 ttl=55 time=22.087 ms
64 bytes from 2001:4860:4860::8888: seq=87 ttl=55 time=27.856 ms
64 bytes from 2001:4860:4860::8888: seq=88 ttl=55 time=22.264 ms
64 bytes from 2001:4860:4860::8888: seq=89 ttl=55 time=22.291 ms
64 bytes from 2001:4860:4860::8888: seq=90 ttl=55 time=22.664 ms
64 bytes from 2001:4860:4860::8888: seq=91 ttl=55 time=22.661 ms
64 bytes from 2001:4860:4860::8888: seq=92 ttl=55 time=27.276 ms
64 bytes from 2001:4860:4860::8888: seq=93 ttl=55 time=22.239 ms
64 bytes from 2001:4860:4860::8888: seq=94 ttl=55 time=23.429 ms
64 bytes from 2001:4860:4860::8888: seq=95 ttl=55 time=22.212 ms
64 bytes from 2001:4860:4860::8888: seq=96 ttl=55 time=22.836 ms
64 bytes from 2001:4860:4860::8888: seq=97 ttl=55 time=21.504 ms
64 bytes from 2001:4860:4860::8888: seq=98 ttl=55 time=22.240 ms
64 bytes from 2001:4860:4860::8888: seq=99 ttl=55 time=26.050 ms
64 bytes from 2001:4860:4860::8888: seq=100 ttl=55 time=22.044 ms
64 bytes from 2001:4860:4860::8888: seq=101 ttl=55 time=24.020 ms
64 bytes from 2001:4860:4860::8888: seq=102 ttl=55 time=23.046 ms
--- 2001:4860:4860::8888 ping statistics ---
103 packets transmitted, 103 packets received, 0% packet loss
round-trip min/avg/max = 21.148/23.724/38.740 ms
-
maybe it's time for Plusnet to offer Kitz a brown envelope and keys to the equipment cabinets :P
-
According to tech support from an isp other than mine there are these 3 21CN-BRAS-RED4-MR-DH, 21CN-BRAS-RED2-PR
and 21CN-ACC-ALN1-SP 2 are ok and one has had a slight issue with latency at peak times
The svlan report shows that some regrades are due, but basically that's all they can tell me without knowing which IPSV im connected to , what does IPSV stand for and what is it? I tonight after finding the IP address for one of the 3 bras the one that was suspect have monitored it from an external source, and there doesn't appear to be any real changes in base latency or any jitter going on,
Where as tonight my latency reached 90ms at one point which to me shouts serious issues that so far have been ignored basically
-
Which gws are you on chrys?
-
what does IPSV stand for
This is almost certainly another made up word that bears no resemblance to networking as anyone knows it.
-
Not being on Plusnet I have not been following this closely but in the last month I have noted TalkTalk Business FTTC (Which may be just the same or TT home or not?) show a bit more sign of evening congestion with TBB pings showing up 3-10ms of blue and up to 10-30ms of yellow. There has always been some signs of this but it has increased this year. Along with the ping, TBB speed test has shown single thread variations but normal speed with multi-thread. I don't notice any impact other than in these tests so it not a worry to me.
I have tended to wonder whether with, ever increasing use of on demand TV and films, things are simply getting stretched towards their limits in parts of the networks? In some case it is also not clear to me how to tell how much of the issue lies outside your ISP's part of the network?
That said some peoples Plusnet issues do look quite bad.
-
what does IPSV stand for
IPSVs are BT's VLANs for copper products. More specifically what used to be the IPStream VLANs
SFBBs are BT's FTTC VLANs - presumably Superfast BroadBand?
You will be on an SFBB SVLAN.... as the IPSVs are just for adsl1/adsl2+ VP backhauls.
-
That said some peoples Plusnet issues do look quite bad.
It's a weird one. I havent read the whole PN thread, but it appears that there's about a dozen people affected? Some people are saying 'me too' but I dont think they are seeing the same issue and its something else different. There is something though because I've seen it myself, but I dont see it now.
Saying that there was something last night, but I wasnt here to be able to do any speedtests to see if and how it affected my connection.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2Fb682b35d03b5b043b107c9a0a9a6091b-16-03-2015.png&hash=a2cb238553b1fc6f49366c0f611effd179a49630) (http://www.thinkbroadband.com/ping/share/b682b35d03b5b043b107c9a0a9a6091b-16-03-2015.html)
I'd love to know what those 2 hr blips are as well.
Previously Ive been like this for weeks.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F83ae47d6094694debb5a74239264a332-13-03-2015.png&hash=fea70d2f74173a1e8e01a402597819d015c428ee) (http://www.thinkbroadband.com/ping/share/83ae47d6094694debb5a74239264a332-13-03-2015.html)
-
This morning my internet access was so sluggish it was almost unusable. I dropped the PPP connection and let it reconnect, and immediately pages were snapping into place again. This was about 07:15, so definitely not a peak time, but it does seem to be related to the routing of the connection.
-
What gw you on? :)
PN DNS?
-
I don't use the PN DNS servers.
Gateway is currently
lo0.11.Central11.ptw-bng02.plus.net (195.166.130.204)
-
I don't use the PN DNS servers.
I'm not actually sure how to find out what gateway I'm on.
Here you go:-
http://usertools.plus.net/@gateway
This is mine:-
Which gateway
You are currently connected to gateway ptn-bng02.
This is located in Telehouse North.
-
Thanks BE1. As it happens, I realised I could get it from a traceroute, and I edited my message.
-
That said some peoples Plusnet issues do look quite bad.
It's a weird one. I havent read the whole PN thread, but it appears that there's about a dozen people affected? Some people are saying 'me too' but I dont think they are seeing the same issue and its something else different. There is something though because I've seen it myself, but I dont see it now.
Saying that there was something last night, but I wasnt here to be able to do any speedtests to see if and how it affected my connection.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2Fb682b35d03b5b043b107c9a0a9a6091b-16-03-2015.png&hash=a2cb238553b1fc6f49366c0f611effd179a49630) (http://www.thinkbroadband.com/ping/share/b682b35d03b5b043b107c9a0a9a6091b-16-03-2015.html)
I'd love to know what those 2 hr blips are as well.
Previously Ive been like this for weeks.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fping%2Fshare-thumb%2F83ae47d6094694debb5a74239264a332-13-03-2015.png&hash=fea70d2f74173a1e8e01a402597819d015c428ee) (http://www.thinkbroadband.com/ping/share/83ae47d6094694debb5a74239264a332-13-03-2015.html)
there may well be a lot more people affected by this, as not everyone will post on internet forums about it, or even be aware that what they are experiencing isn't normal
-
I'd love to know what those 2 hr blips are as well.
Do you have a SamKnows whitebox?
-
Came home tonight to find my 10ms ping is now 25ms. Awesome.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142661766723881086257.png&hash=3707aed77342e7f31e257c6b4186b8fd35fb7d1e)
No obvious difference to download speed but upload has lost about 4Mb/s. I assume someone has been playing with the nest of wires down the road in the small green cupboard.
For once, it'd be nice if xDSL JUST WORKED! >:( >:( >:( >:( >:( >:(
-
I'd love to know what those 2 hr blips are as well.
Do you have a SamKnows whitebox?
Hmm... I do/did but I havent used it for years as its one of the first issue. After getting fttc and a re-organisation of the PC room I wanted to cut down on network kit. I only have one PC now and a NAS so didn't see the point in lots of cables, wires and of course plugs.
-
kitz yesterday or rather 2 nights ago I accidentally dropped my ppp and my tbb changed significantly as well as peak time slowdowns again, so it seems your improvement I think is simply down to you been on a better endpoint and not moving since you got on there, as I was fine for weeks until I changed my session.
-
You're on a BuNGle, aintcha.
-
no as I am a ipv6 tester I am having a hard time to avoid BNG, plusnet now seem to have permanently weighed it higher.
There is something pretty badly wrong as it took me probably over 40 hops in total to get a endpoint capable of giving me max upload throughput.
I think plusnet have an issue with an ellocaya or something been overloaded and they failed to recognise it. In my line of work I have often seen things hit saturation well before cpu maxes out.
-
it seems to be holding ok now and tbb graph is pretty flat.
My ipv6 will stay broken tho (tried to make it work on the BNGs like andyh says is possible) as to adjust ipv6 requires a ppp session change.
-
Are you sure that andyh is a PlusNet rep/employee as you mentioned somewhere?
He seems to have at least the G.INP theory completely back to front judging by a couple of posts I have read in the PN forum.
-
Prolly works for an ISP, not necessarily PN? Only seen a handful of his posts but one of them was where I got the host link thingy from!
-
Are you sure that andyh is a PlusNet rep/employee as you mentioned somewhere?
He seems to have at least the G.INP theory completely back to front judging by a couple of posts I have read in the PN forum.
No he's not a rep/employee
-
he does seem to have a vested interest to shoot down those reporting issues.
Also I have a openreach guy looking into what he is posting as in his own words "its strange".
-
I havent caught up with the thread, but it is strange that whenever a question is asked then he will answer. Unfortunately it winds up a lot of people the wrong way. Its why I specifically aimed my question at Chris.
I notice that Chris has responded, and confirmed that there can be an issue at the MSILs, which as I suspected could appear at first glance to be gateway specific.
http://community.plus.net/forum/index.php/topic,135389.msg1210040.html#msg1210040
He also confirmed that BT are supposed to monitor and upgrade these.
---
To be fair he does generally know most of his stuff.. and as regards to G.INP, I think a lot of us are in the dark and playing the guessing game when it comes to the BT implementation of it. I should do some digging myself, but its something else I don't have time for so Im not even going to begin adding something else to my pile atm.
I think he may well get a lot of his info the same way that I do.
-
Only seen a few of his posts but he strikes me as playing devil's advocate / differential diagnosis.
Sometimes we bind to the breadcrumbs BT discard and refuse to consider alternatives. SVLAN springs to mind despite elephants in the room like zero public domain knowledge of the MSAN to metro switch trunks etc :P
-
BNG = Broadband Network Gateway. Unsure exactly what model they are, but yes Juniper MX is the route they headed after ERX became EOL (end of life).
From a quick scan of the specs for all the MX models then it would have to be at least an MX960,
Just to confirm - They are MX960's, which I found out by searching their forums.
It also pulled up something else interesting which I may have missed.
-
Well they plusnot have lived upto expectations yet again with yet another Sunday night meltdown talk about being caught short these guys are really taking the urine out of their their customers, yet again not enough capacity causing increased latency and jitter levels , as well as abnormal single and in some cases multiple threaded throughput levels which were once again no where near meeting plusnet's advertised 24/7 line speed claims I personally am well and truly sick of the bs and the isp's cult following that will boldly attempt to defend the indefensible,
-
there is one good endpoint, but it took me a LOT of hopping to get back on it, so much hopping was required I am delaying to reenable ipv6 now as that will make me lose the ppp session.
-
Well some of the performance graphs show signs of flattened tops on Sunday evening - which has gained a Plusnet response that the graphs might be removed:
To address some of the points made since I last update this thread, the graphs on our website are outdated and need updating or removing, they don't realistically reflect the real-life capacity of our network or peaks across the network.
Make of that what you will!
-
jelv you have been a plusnet customer for a long time right?
remember back when they had the massive capacity issues on adsl? did they initially pretend it wasnt a problem?
-
Here's what I posted in reply to your same question on the Community forums:
Yes.
Back then I was a member of the Plusnet User Group and thought PUG should be be far more critical of what was going on. The trouble was the then chairman of PUG for some reason seemed to be an apologist for Plusnet and was defending them (sound like anyone at the current time). I went out on a limb and posted on TBB with all guns blazing - it led to a big row and I ended up resigning from PUG so that I could be free to post my honest views without being censored by the PUG leaders. In time I was proved right. Kitz was the other PUG member who at that time was doing sterling work on the issue from inside PUG.
-
So I am getting packet loss and spikes at home. Cant even watch HD youtube clips at night anymore :(
Did loads of tests last night at different times, and went as low down as 3 mbs dl compared to my usual 13. Pings went from 16 to 122 at its peak and packet loss and jitter showed up all the time.
Just 2 questions:
1 - Is this an issue with plusnet or the exchange I am connected to ?
2 - Would all providers suffer from this problem too ?
Please just a yes or no for the second question, as this is a discussion about Plusnet not others, just wanted to know if anyone knew where the issue might lie for my own piece of mind.
-
thanks jelv, sorry I missed your reply earlier.
-
So I am getting packet loss and spikes at home. Cant even watch HD youtube clips at night anymore :(
Did loads of tests last night at different times, and went as low down as 3 mbs dl compared to my usual 13. Pings went from 16 to 122 at its peak and packet loss and jitter showed up all the time.
Just 2 questions:
1 - Is this an issue with plusnet or the exchange I am connected to ?
2 - Would all providers suffer from this problem too ?
Please just a yes or no for the second question, as this is a discussion about Plusnet not others, just wanted to know if anyone knew where the issue might lie for my own piece of mind.
No one knows. Page 6 (http://forum.kitz.co.uk/index.php/topic,14902.msg281899.html#msg281899) contains our best guesses.
As an aside, I noticed the OGEA service test now shows the CVLAN policed rate which, in my mind, suggests #3 is now definitely a contender.
-
you have an example of what the content of the policed rate line displays?
I still think congestion at the CVLAN level would be very unusual to have.
-
I still think congestion at the CVLAN level would be very unusual to have.
You continue to say this. You continue to provide zero evidence to back it up.
Why do you feel so strongly? It would be awesome to rule this out because it removes another possibility from the blame-chain :)
-
you have an example of what the content of the policed rate line displays?
I still think congestion at the CVLAN level would be very unusual to have.
(https://dl.dropboxusercontent.com/u/20271204/fttc/gen/OGEA1.GIF)
(https://dl.dropboxusercontent.com/u/20271204/fttc/gen/OGEA2.GIF)
I assume all FTTC CPs can see the above info.
My personal experience with BTOR and FTTC is that they are very much on the ball.
-
But aren't the SVLANS /CVLAN's shared by lots of EU's that would likely be with different ISP's , in which case it wouldn't be what has so far been unique to Plusnet customers, apart from a few cases earlier on that the cause was identified by AAISP as it affected customers regardless of ISP Also a customer changing endpoints via an isp gateway hop wouldn't also change the SLVAN/Cvlan that they where on would they ?
It IMO is the quantity bandwidth that they are buying from BT not being sufficient (running a large percentage of their links hot) which is probably not helped by the traffic plusnet management which could be causing all sorts of odd issues making it harder to identify the underlying cause ,
It's like some 12 months or more ago, the customers saw the peak time latency hump or excess jitter, again single stream throughput was affected as was the upstream, but not as severely, people complained plusnet a short time later reported that more capacity had been added , a short time ( days ) things improved for a few months then would return again, Plusnet has in particularly during the past 12mths has gained a lot more customers
They have increased the number of BNG's (gateways) but by customers hopping from gateway to gateway until they get connected to a less saturated endpoint which sees line speed throughput restored ,and some times latency as well, goes a long way in proving that it's something with the internal networking ( DPI traffic management ) that plusnet control or the capacity that it buys from BT is not suficient
-
So I am getting packet loss and spikes at home. Cant even watch HD youtube clips at night anymore :(
Did loads of tests last night at different times, and went as low down as 3 mbs dl compared to my usual 13. Pings went from 16 to 122 at its peak and packet loss and jitter showed up all the time.
Just 2 questions:
1 - Is this an issue with plusnet or the exchange I am connected to ?
2 - Would all providers suffer from this problem too ?
Please just a yes or no for the second question, as this is a discussion about Plusnet not others, just wanted to know if anyone knew where the issue might lie for my own piece of mind.
Is your exchange on their list of exchanges with known issues, ? An exchange issue/ VP would affect customers of other isp's in a similar way at the same times,
If FTTC i think it works a little differently , But the status should be easy for the isp to find out ,
-
I still think congestion at the CVLAN level would be very unusual to have.
You continue to say this. You continue to provide zero evidence to back it up.
Why do you feel so strongly? It would be awesome to rule this out because it removes another possibility from the blame-chain :)
well first I already know CVLAN is nothing to do with current issues, as the CVLAN is a fixed path, it doesnt change when hopping, you understand this?
Also you have to look at the numbers to realise congestion from cabinet to exchange would be weird. Not impossible but extremely unlikely.
Retail isp's contend at a level that is many 100s more in multiple than cabinet backhaul.
Trust me that the current issues at plusnet are nothing to do with cvlan/svlan/exchange.
-
you have an example of what the content of the policed rate line displays?
I still think congestion at the CVLAN level would be very unusual to have.
(https://dl.dropboxusercontent.com/u/20271204/fttc/gen/OGEA1.GIF)
(https://dl.dropboxusercontent.com/u/20271204/fttc/gen/OGEA2.GIF)
I assume all FTTC CPs can see the above info.
My personal experience with BTOR and FTTC is that they are very much on the ball.
you work for an isp to be able to see that?
now show one where police rate isnt 0 :)
-
well first I already know CVLAN is nothing to do with current issues, as the CVLAN is a fixed path, it doesnt change when hopping, you understand this?
No, I don't understand. How do you know this? I've not seen the ECI or the Huawei running-config and have no idea what the potential congestion management options may be. Gateway hops could also be purely coincidental with local contention. If it's not black and white, it's an unknown as far as I'm concerned :)
Trust me that the current issues at plusnet are nothing to do with cvlan/svlan/exchange.
I don't disagree but even my own conclusions are far from concrete. If you believe you know something specific, you could let us all know whilst maintaining your anonymity. My problem is, all too often we find flaws in what people believe they know, so their presumptions held no value in the first place. I'm not saying this applies to you but it's a state of mind one acquires when you work in IT; people are sometimes lacking in areas where they should be on top form.
I'm definitely clueless but knowing it allows me to make small gains, here and there.
-
you work for an isp to be able to see that?
Of course. A small no-name with no power :)
I get very few FTTC faults so it's been a long time since I needed to look at that screen but I'm pretty sure the cvlan stuff is newish :D
-
ok if you ever come across one without 0s then you will have my attention :)
As far as I know each cabinet only has one CVLAN, so basically its a CVLAN per cabinet, possibly multiple cabinets per CVLAN. But not more than one CVLAN per cabinet. Which should mean it would be impossible to change CVLAN's without physical presence.
-
You may be right but that doesn't make any sense in my mind.
We already know that customer traffic appears to be running on VLAN 101 with BT traffic running on VLAN 301. The HG612 shows that PTM 301 traffic runs at COS 5 (prioritised) and 101 runs at 1~. You have to have a VLAN tag in order to write the 802.1p bits so this suggests to me the entire frame makes it to the MSAN. The MSAN probably strips it and adds a customer specific one but even at this early point, there are many things which could be considered the CVLAN.
I might well be missing something / oversimplifying though?
-
I see Andrew over at TBB has started a thread entitled "Are PlusNet speeds in meltdown?"
That implies (to me) he's seeing speedtest stats which suggest there is something amiss with Plusnet & only Plusnet and is looking for confirmation before an article.....
-
I see Andrew over at TBB has started a thread entitled "Are PlusNet speeds in meltdown?"
That implies (to me) he's seeing speedtest stats which suggest there is something amiss with Plusnet & only Plusnet and is looking for confirmation before an article.....
Asking around other isp's i would say that the bulk of the problem has been and what remains is unique to Plusnet ,As some of the earlier reports of issues back in December 2014 where down to BTW network limited to a few areas, was apparently resolved by in Jan/FEB 15 , these where well documents by other ISP's including AAISP
As well increased Jitter and base latency levels during peak times,packet loss has been seen too, and some external peering shows a bigger increase in latency (on some links)
But as a customer for nearly 2 yrs i can categorically say that they have more often than not had these same type of issues (except for packet loss) which was mostly confined to a Sunday or and Monday evening's, but as of late this has extended into an almost nightly event , though some nights are not as bad as other nights, frequently having to drop PPPOE session in order to connect to a less saturated endpoint ,This also of late has been requiring a lot more attempts So is becoming troublesome and frustrating before achieving the desired effect,
And when these issues are going on the like of I player or ITV player are also impacted on streams are interrupted (buffering )
As for the thread you referred to i think that is dead alreadyhttp://forums.thinkbroadband.com/plusnet/t/4398100-conclusion.html (http://forums.thinkbroadband.com/plusnet/t/4398100-conclusion.html) If that is his final word on it
-
Its my understanding that the CVLANs are between the DSLAM and the OLT. Ive seen a doc somewhere stating that the CVLANS are fixed and cant be changed as eventually they form an 'inner part' of the SVLAN. ie many CVLANs in the one SVLAN. The C for CVLAN stands for customer and is set when the line goes live and the customer retains that same CVLAN for the service lifetime.
In the case of GEA fibre, the SPs (such as sky) are handed over the CVLAN which is customer specific and never changes. I'm uncertain when they say customer specific whether they mean all EU's from that DSLAM to the OLT will have the same CVLAN and if a particular DSLAM can have more than one CVLAN.
Requests can be made though for a change of ServiceVLAN which is what does the QoS and has a limited amount of bandwidth. Many SVLANs can be within in the one cable... ie these are 'partitioned' parts of the total cable bandwidth and differently tagged SVLANs may get priority over others. My understanding is that any priorities ie 100/301 tagging are at the SVLAN level.
Edit this (https://www.openreach.co.uk/orpg/home/products/productdevelopment/latestempenhancements/latestempenhancements/R1800_downloads/Move_end_user_Customer_vlans.pdf) could imply the CVLAN is line specific - not DSLAM
A Customer VLAN
(CVLAN) is created when a service (e.g. Data or Voice) is provisioned for one of your customers. At this
point you may specify a particular Service VLAN (SVLAN) or no SVLAN in which the CVLAN is placed. You
can create new SVLANs by raising a Modify order against your GEA Cablelink product
-
Ive just had a quick look over there. Not sure there is much point posting because someone seems to take it on their behalf to reply on behalf of Plusnet.
What Andy says about the host links is true and can easily be confirmed on the BTw website.
However I agree for me there's been an awful lot of deja vu over the past six months since the drops on the BNGs late last year. Some of you may recall at the time that it was like a repeat of history when the Junipers way back in about 2005 couldnt cope with the number of sessions and I put that forward as a suggestion. Then I later see that theyve had to limit the MX960's to 50k users :-X
They also denied the first time round about capacity issues, but it could be seen way more clearly - ie that the graphs were getting full and flat-lined. The graph on Sat night showed indication of this, but it does usually seem to be ok.
I really cant understand why the Ellacoyas arent properly controlling latency and jitter such as jelv is seeing. This should not be happening if the issue was on PN's network.
... but back to the fact that you cant now buy ellacoyas and its Proceras. I wonder if they are having teething problems getting config right like they originally did with the ellacoyas. Im only throwing suggestions because deja vu was mentioned.. but if it was that then you'd only expect the issue to happen on the BNGs which is where I assume theyve purchased proceras for.
However, you cannot exceed the physical capacity between the WBMC handover nodes and your network (irrespective of any burst caps) without traffic being dropped.
This I cannot understand... If it were an issue then PN should be using the Ellacoyas/Proceras to ensure that jitter doesnt occur and no packets are dropped. It just doesnt make sense from here what is going on.
-
I'm on 20CN via IPSC which never connects to a bng!
They did suggest it might be something to do with being on the IPv6 trail so for a week or so I reverted to my normal connection (Extra) with IPv6 disabled on router and PC. I was still getting issues with VoIP call quality and Lync losing connection during the evening.
-
Install MX960s they said. You'll be able to inspect at line rate they said. Don't worry about bugs they said :P
Far easier to let the community to squabble over perceived bandwidth problems whilst you write the press release about how your spying efforts are going horribly awry.
jelv, how do you know you never connect to a bng? You could be tunnelled through any one of them. Isn't that the whole point of IPSC?
I think you have it right, kitz. The nomenclature is very confusing but assuming metro speak, then the L2S needs to be capable of receiving untagged/single or double tagged from the MSAN (multi-VRF CPE attached to modem) all of which I would assume fall under CVLAN in BT spake.
Isn't this fun? :)
-
how do you know you never connect to a bng?
The IPSC connections are directed to specific gateways: ie the older AGs (E320's and ERX's).
The newer BNGs are those with the MX960's and 10Gb host links.
It shall be interesting to see how my line goes now - Due to a resync caused by the dslam/exchange equipment, Ive lost that nice gateway I was on. Im now on a totally different gateway and at a different colo.
lo0.12.central12.pcl-bng02.plus.net [195.166.130.153] (old)
lo0.11.Central11.ptn-bng02.plus.net [195.166.130.191] (new)
-
Well I need to take a break from the plusnet forum, had enough of it.
-
Chrys. I noticed on there that you said you had issues with the upstream.
That should never be a problem for the host links which are fully symmetrical. There should always be plenty on the upstream.
If you look at their graphs upstream doesnt ever reach anywhere near the limits. It never has done and its why some ISPs never included upstream for bandwidth caps. Its one of the reason why when I see someone's upstream graph doing the wavy lines or doing a slow start, I tend to discount contention... and its pointing to something else.
-
I have notice that the upstream will almost pause, drops to sub 1mbps sometimes then back to full again , i have only seen this happen around the peak time on the tbb speedtest ,as it appears to only affect single threaded, In testing i ran a single threaded file upload using FTP and it wouldn't stay anywhere near the max throughput, it was yo yo ing , but at a quieter time it will upload at full tilt , so ? something is a bottleneck but for me this isn't really new, as i have been seeing similar since shortly after my service went live ,on and off for around 18mths , mainly sun & mon peak time
I read one of the REV k's rants and some of his customers where having issues , he put them on elevated traffic, and there was an improvement , yet btw were saying not faults ect iirc, if plusnet would for testing switch off their traffic shaping for a week or so, if it still persists then they could put a number of those seeing issues on elevated to see if that showed improvements or not, process of elimination maybe is what is required, or some truths from plusnet, because whatever is /are the reasons for it it has been allowed to go on for too long already, plusnet saying we don't know or it isn't our fault, ain't good enough
-
Chrys. I noticed on there that you said you had issues with the upstream.
That should never be a problem for the host links which are fully symmetrical. There should always be plenty on the upstream.
If you look at their graphs upstream doesnt ever reach anywhere near the limits. It never has done and its why some ISPs never included upstream for bandwidth caps. Its one of the reason why when I see someone's upstream graph doing the wavy lines or doing a slow start, I tend to discount contention... and its pointing to something else.
yep which is why I said I suspect issues with something cpu intensive such as their ellocoyas.
-
Chrys. I noticed on there that you said you had issues with the upstream.
That should never be a problem for the host links which are fully symmetrical. There should always be plenty on the upstream.
If you look at their graphs upstream doesnt ever reach anywhere near the limits. It never has done and its why some ISPs never included upstream for bandwidth caps. Its one of the reason why when I see someone's upstream graph doing the wavy lines or doing a slow start, I tend to discount contention... and its pointing to something else.
That's interesting, because several days ago my upstream connection became so slow that the connection was virtually unusable. I did a gateway hop and everything was working normally again.
-
I read one of the REV k's rants and some of his customers where having issues , he put them on elevated traffic, and there was an improvement , yet btw were saying not faults ect iirc, if plusnet would for testing switch off their traffic shaping for a week or so, if it still persists then they could put a number of those seeing issues on elevated to see if that showed improvements or not, process of elimination maybe is what is required, or some truths from plusnet, because whatever is /are the reasons for it it has been allowed to go on for too long already, plusnet saying we don't know or it isn't our fault, ain't good enough
tbh I almost posted on TBB yesterday, then decided against it.. but one of the things I was going to say the following which I still have in notedpad
Im at a loss as to why a few people continue to see issues that either could be endpoints or something at the MSILs. There obviously are some people who do have a genuine problem and I'd tend to trust certain people (eg jelv) who would know how to rule out the basics.
TBH, if it were me, I would be taking a very close look at a chosen individuals line to see if they can see if they can pin point the issue. Im sure someone like jelv would be more than happy to assist with testing etc.
Plusnet wont/cant ever completely turn off the ellacoyas, but for testing purposes an EU could be put on 'God profile' which results in no shaping at all. iirc jelv is already on premium which is an elevated service on the BTw VPs and they should also ensure that their PN profile is set to maximum.
-
jelv... from a link on TBB I happen to notice this
http://aastatus.net/2103 which shows problems at Reading
21CN lines that connect through BRAS's 21CN-BRAS-RED1-MR-DH up to 21CN-BRAS-RED13-MR-DH
Just a note that its the MSILs at the Interconnects which connect the BRAS to the Core... suggesting that there is a probable issue with some of the MSILs at Reading. :(
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.kitz.co.uk%2Fadsl%2Fimages%2FWBMC_shared.png&hash=f199be0febeb29077839211ad474ad8edb05c238)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.kitz.co.uk%2Fadsl%2Fimages%2FIPSC.png&hash=ef9993bb8d3635b1c6cf97bbecc1a2ad709f9949)
-
if the elocayas are the issue a god mode profile wouldnt fix the issue, they would have to be routed to completely bypass them. As I expect a god mode profile would still be scanning the traffic but just nothing would be throttled.
-
It would at least eliminate incorrect configuration of a profile. I agree that wouldn't make any difference if the ellacoya/procera was overloaded.
Im not sure how the Proceras work, but surely if it was overloaded to the point of causing latency then surely it would affect every single line that was going through the gateway which the individual ellacoya/procera was attached... and in that case it would look like a specific gateway issue. It should also be much easier to spot.
-
Nothing wrong with that logic except it would appear only very small numbers, compared to total subscribers are being affected?
They don't terminate lines but going on our earlier assumption, they might well be terminating tunnels. Tunnel creation is probably a CPU as opposed to ASIC operation?
Tunnel creation or numbering of those tunnels or something equally inane could be the culprit. Or perhaps every 19th tunnel is having MSS/RWIN clamped. Or something is screwing with packet checksums or TCP sequencing so more packets in a flow are being examined under some undetermined circumstance. Or some other weird bug.
My limited experience of juniper is that they outperform cisco and are waay cheaper but documentation is sparse and bugs far more common than you'd like. TAC wants to investigate the bug you've reported? Cool. Where shall I put these 40k subscribers? :P
I bet PN support are looking at standard peak time load and under-utilisation with WTF style faces. ptn-ag2 was always flawless for me, if that helps.
Could be classic congestion and they're telling us porkies, though.
-
Because I was home tonight I've been doing several speedtests, but they have all been at full line speed flatline, so ptn-bng02 looks ok for me. :)
>> Or perhaps every 19th tunnel is having MSS/RWIN clamped. Or something is screwing with packet checksums or TCP sequencing so more packets in a flow are being examined under some undetermined circumstance. Or some other weird bug.
I had thought about MTU/RWIN etc because it throws up some really weird things. Ive had an RWIN issue myself that affected line rate throughput limiting me to 30Mb. It took me ages to sort and find out what it was.. the culprit was actually my nvidia driver which included a load of additional garbage I didnt need.
The full post is here (http://forum.kitz.co.uk/index.php/topic,13735.msg258720.html#msg258720).. but you can see what a difference it made.
This was with the full nVidea software which included NVStream
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F139575474730925936076.png&hash=bea42ace84a0ee2239a150cf57ad6cba9823272e)
This is without.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F139576216307525780960.png&hash=96a7bc9b42ba1da2bd0b6ee9c09c46b5649273d3)
Note the wavy line on the upstream too which I was talking about earlier. I cant recall the exact reason now, but its something to do with NVStream messing with the RWIN.. there was a massive thread on the nVidia forum about it.
-
AndyH is really getting my goat now!
Here's a post I've just made on the Community forums:
It is my firm belief that AndyH is a shill (http://en.wikipedia.org/wiki/Shill) - for Plusnet, BT Wholesale or OpenReach. He has demonstrated on numerous occasions that he has inside information on FTTC upgrade plans without ever posting a link to a public resource where we can look it up for ourselves.
The fact that Plusnet have not posted to this topic to confirm that what Anotherone, myself and several others are saying is correct makes me think that they are very happy to see this topic being derailed with all the FUD.
Lets make something very clear: all products should be delivered as specified by Plusnet even when they are no longer for sale. If they change the specification the customers MUST be notified. That is why details of all the old products are available in the Broadband Product Archive. A route is:
Help & Support
Support Pages
Under broadband: Broadband speed guide
In 6. Be aware of traffic management - there's a link Traffic management guide
Under rate limits - older broadband products
There's probably other routes to get to the same page - it lists all products sold since 4th April 2005
-
yeah as I said there is something odd about him, its as if he is been paid to spend 20 hours a day on the forums defending plusnet.
-
yeah as I said there is something odd about him, its as if he is been paid to spend 20 hours a day on the forums defending plusnet.
As someone has already said he /she even is a corporate shill , But reading through the plusnet thread, i see someone mentioned getting it exposed in the media presumably the likes of the register , it may get some kind of official response, i have taken my grievance to cisas as ISPA was a waste of time , all they do is ask your isp to respond to your issues , i can't say for certain that they even managed to do this , plusnet have had my formal complaint for nearly 1 mth and all they have done is end to end tests, before and after i reported a fault as advised , still no answer only that there appears to be nothing wrong with your connection result from testing , lol
-
Kitz, Chrys, Boost .............. can we speak in English please !! This is harder to understand than the Pinghua Chinese language :'( :'(.
;D ;D
-
If you are having problems imagine what the rest of us are like. ??? :'( ::)
<jk>
-
LOL ….. I'm as much as a novice as anyone from the Exchange MDF onwards …… or backwards …… whichever way you deem it to be ?? ;D
-
BS... If you like, I could point you to a site which may explain some of the terms that we are using.
:lol:
-
BS... If you like, I could point you to a site which may explain some of the terms that we are using.
:lol:
I'm washing my hair as it goes ........ but errm, thanks anyway. :)
Ha ha, appreciate the thought boss but my dwindling memory banks struggle to cope with stuff I need to know in my day-to-day activities, as it is. ;D
-
@jelv.
Did you happen to notice my post above re the Reading MSILs? I mentioned it because I recall that you have to go through Reading.
Its also been confirmed by Chris, that by gateway hopping, you could find yourself on a different MSIL depending upon the location of the gateway. I know you are on IPSC, but afaik they now also use the 21CN MSILs to hop on to the core.
-
Just to add my threeha'pence, after a needed reboot of my router after it lost sync (my exchange has been upgraded but still much work going on causing, I'm sure, occasional needs to reboot) I was down to about 1 Meg d/l speed. This was on pct-ag06. After a reconnect and onto ptw-bng01 I'm now back to my usual 10 Megs or thereabouts. My local cab has not been upgraded yet.
Tony
-
I'll look to see if gateway makes a difference.
Incidently, http://www.superfast-openreach.co.uk/where-and-when/ still says Exploring solutions but the cab is installed, the fibre is in, power is connected and today they are making the connections between the old cab (just refitted with a larger shell) and the FTTC cab so hopefully very shortly I won't be on IPSC!
-
Well after a few days of more or less full throughput at peak times here we are again same old same old (https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.thinkbroadband.com%2Fspeedtest%2Fbutton%2F142748887813851527935.png&hash=bc79c4f97624c23faef18336e922c69cd229414c)
and the jitter /latency is already building tonight BTW it ain't down to the football as that started some time ago, and such events shouldn't impact the service provided, or it wouldn't if there was spare bandwidth available
-
Chris from plusnet posted on tbb today that it is a deliberate policy to now withold the capacity upgrade information from customers, he will only say there has been upgrades but not how much, he also has yet to state why this new policy exists.
The only practical reason I can see for this policy is to hide a cut back, because given their current PR damage they can kill things dead by announcing the upgrade amount (if its at least as big as before).
So I guess the next best thing is for someone to check the plusnet customer count on the gateway graph from the date the last upgrade was announced, and then do a calculation of what bandwidth would have been added under their old policy and ask plusnet if they have added more or less then that amount.
Meanwhile andyh is still telling people their issues are local to them.
-
I bet we end up quoting Chris' reply to me in http://community.plus.net/forum/index.php/topic,135389.msg1216111.html#msg1216111 a few times!
@jelv absolutely any problem with your broadband connection is our responsibility to investigate and try and fix, it doesn’t matter to you whether the cause of that issue isn’t within our direct control and needs a third party (be that BTW, Openreach, LINX etc.) to be engaged to fix it, it’s up to us to arrange that and get it fixed.
-
@ericgripp
The fire in London impacted our resiliency rather than overall capacity.
Whats that all about... did I miss something. I had a quick skim, but couldnt see anything. Is this what they are blaming last Sunday night on?
-
Well yet again congestion , high latency and low throughput, some quite a few of the the gateways/endpoints that i hopped to where showing a hideous high amounts of base latency of 65+ ms at the 1st hop, whilst others where around 25+ms when they are at all other times between 11 and 13ms plusnet are a joke, regardless of where this problem lies if within their networking or BTW's why because they have done diddly squat about it so far , they have been relying on other isp's to chase their brethren (BT) or if within their side of things they either don't know their ass for their elbow or again their brethren are withholding opening the purse which i don't know, and am past caring anymore
-
@ericgripp
The fire in London impacted our resiliency rather than overall capacity.
Whats that all about... did I miss something. I had a quick skim, but couldnt see anything. Is this what they are blaming last Sunday night on?
I think this (http://www.bbc.co.uk/news/uk-england-london-32173689)is the fire meant.
Idon't think it could be the C17th one. :-\ ;D
-
Ahhh cheers, dont think it can be related to that then, as the problems started before that. Speeds were rubbish tonight 30Mbps... but Im taking the time to catch up on some site stuff that needed doing.
-
Well yet again congestion , high latency and low throughput, some quite a few of the the gateways/endpoints that i hopped to where showing a hideous high amounts of base latency of 65+ ms at the 1st hop, whilst others where around 25+ms when they are at all other times between 11 and 13ms plusnet are a joke, regardless of where this problem lies if within their networking or BTW's why because they have done diddly squat about it so far , they have been relying on other isp's to chase their brethren (BT) or if within their side of things they either don't know their ass for their elbow or again their brethren are withholding opening the purse which i don't know, and am past caring anymore
still waiting for you to migrate out then we will know quickly if its BTw or plusnet.
-
Outside of my other 'Problems' ;D
I had a situation where the PPP Session ground to a halt.
No data was coming down the line at all when attempting to navigate to pages in Firefox.
The DNS was resolving or had already resolved as the pages were already displayed but I was trying to move forward/back and getting nothing just a spinning cursor.
All the PC's etc in the house had the same issue.
In the end I disconnected the PPP session and re-connected at a new address, everything came back instantly. ???
DNS is OpenDNS on all machines and it has never had a problem in years. (Ususal 208.67.222.222 & 208.67.220.220)
This was about 8-9 pm a few days ago. (Sorry was distracted and did not record info)
-
I have officially been warned to get of andyh's back on the plusnet forum.
Make of that what you will.
-
I am not able to comment at this time, but understand so so well :)
Send from LG G3 via Tapatalk (Typos & bad formatting are free)
-
I asked oldjim (who sent me the pm) to show the posts I am apparently trolling.
lets see what happens, but since I wont change what I am doing on there I guess I will soon get banned.
-
You may not be the last
Time will tell ........ :)
Send from LG G3 via Tapatalk (Typos & bad formatting are free)
-
I might post to ask why there is no forum rule against shills (http://en.wikipedia.org/wiki/Shill)!
-
I might post to ask why there is no forum rule against shills (http://en.wikipedia.org/wiki/Shill)!
:lol: it would be interesting to see what replies you get, ;D
-
You want to join the 'Ban' Queue ?
:)
Send from LG G3 via Tapatalk (Typos & bad formatting are free)
-
I have officially been warned to get of andyh's back on the plusnet forum.
Make of that what you will.
Because you kick the ar5e out of a question, very rarely accept the answers given ..... and have your own idea of what is really happening and won't be budged on it ??? Just a quick guess. :-\
-
have I not been accepting your answers then black sheep? I thought I was.
for reference BS, this guy has been annoying our friend kitz as well and he has said information you gave us was wrong, I defended your information, as I dont think you know who he is.
-
It's a very frustrating position to be in and sometimes it feels like there is almost zero accountability for anything but having a pop at whoever, even if he is sitting on a throne in Sheffield with a PN flag flying behind him, is probably not going to help anyone.
(https://dl.dropboxusercontent.com/u/20271204/dslstats/thegame.jpg)
It does seem like PN could handle this entire thing better too. A blanket statement on blah is x and y and if you are z you have some other issue. The reality is, they have to literally battle with Openreach to get anything done.
I can't even begin to tell you how frustrating it is to read the words CLEARED AND CLOSED. To log the same issue four times and get nowhere. No co-op, no words of wisdom from the attending, boom, just closed. There are literally, cowboys, riding around in white vans, nicking pairs that currently supply ADSL2+ services or whatever and 're-provision' them for whatever job they're working on.
Then they close that job off and it's done.
You're left with a customer with no synch, a nice DIS IN NET or DIS IN EXCHANGE fault which you task out, gets cleared, so you can not raise another fault and even if you do, whoever nicked the pair has now effectively registered it to another address, so your new fault tickets are going to the wrong place. None of this is visible on Openreach's fault bookerer outerer platform. ORDIROBOT? Pah.
I think they've actually done a fantastic job on the FTTC stuff but MPF is just hilarious. Openreach, seriously, no one cares how well you are doing elsewhere when products like this make a mockery of you. It needs a serious look at.
God damn I've just had a rant!!! :lol: My bad! :o :D
Anyway, I think there was a point to my rant. Yes. Behind the scenes, people are probably fighting your corner. You may be getting the clipped, staid replies on your tickets but that is not necessarily a sign of complacency.
Anyway, I'm sorry your service is poor. I know what I'm like when my ping increases. I feel I should always get the ping the service could deliver for the known conditions.
I hope this hasn't come across as a judgey/preachy post. I just wanted to highlight that the sense of futility is not unique to the EU :)
-
have I not been accepting your answers then black sheep? I thought I was.
for reference BS, this guy has been annoying our friend kitz as well and he has said information you gave us was wrong, I defended your information, as I dont think you know who he is.
Ok, fair do's Chrysallis. I suppose you have been accepting of late, my bad. I don't frequent any other forum other than this, (I tried TBB but wasn't impressed) so you're right, I don't know Andy or what he's saying ?
-
thanks, I realise I wasnt friendly with you early on but I fully respect you now.
he didnt say a lot to kitz directly, but more so she has been annoyed with plusnet like myself and he has been playing down her problems.
-
That's very kind and noble of you to say, Chrysalis. Thank you. :-[ ;D
Moving on, there's one thing we all know about Kitz and that is ……. underestimate her knowledge and resolve, at one's peril !! No one individual knows everything about this in-depth science called DSL ….. but she comes a very close second !!
-
he is someone who says he is a plusnet customer and owns an isp (hence apparently having access to openreach confidential information), he is able to do repeated speedtests even tho he says he is out of the country, his username is andyh.
-
Hmmm ?? I'm no detective and wouldn't know how much of what he says holds water ??
But (as you are aware), OR engineers also have access to a plethora of commercially confidential information surrounding all aspects of trials and roll-outs of G.Technologies for both DSLAM vendors. Take for example the ECI Vectoring debate .... there's a lot going on and I very, very nearly came a cropper yesterday by posting up (or trying to post up ) a picture of an ECI DSLAM with in-situ VEC (Vectoring Engine Card) with a fully labelled lay-out of the design. Also, there was an associated write-up depicting what equipment was in use and how it all fits together.
I was half-way in when I noticed the, 'Commercially sensitive information - Not to be shown outside BT' logo at the bottom of each page. This warning is always at the top of the Word doc / Powerpoint presentation, but not this time and was in the main obscured due to my ageing eyes having to enlarge the page size. I would never knowingly flout my employers rules and regs, and my heart skipped a beat when I realised what I'd nearly done. :'(
The point I'm labouring to make is, Andyh may well have access to the same info as us, and be at liberty to present it on a public forum ?? But, I would doubt that, when you actually see the levels of information provided ??
You've asked me before, and I've answered before ...... I have no idea why some of the stuff is kept more secret than MI6's files, but I have to uphold the wishes of my company and if that means busting at the seams to keep shmuck, then so be it. :). It isn't worth my job.
What I do do though, is once the info is deemed fit for public consumption, I will post it here as soon as I possibly can. Whether it's still deemed relative at that stage is for the readership to decide ?? So why Andyh is saying the info I give here is wrong I have no idea ?? Strange. ??? :)
-
he is someone who says he is a plusnet customer and owns an isp (hence apparently having access to openreach confidential information), he is able to do repeated speedtests even tho he says he is out of the country, his username is andyh.
Has his geo location been validated , ie not simply using a proxy, VPN or tor ect to appear outside the uk ?
-
Take for example the ECI Vectoring debate .... there's a lot going on and I very, very nearly came a cropper yesterday by posting up (or trying to post up ) a picture of an ECI DSLAM with in-situ VEC (Vectoring Engine Card) with a fully labelled lay-out of the design. Also, there was an associated write-up depicting what equipment was in use and how it all fits together.
Google works fine to get that kinda information. (https://docs.google.com/viewerng/viewer?url=http://www.ecitele.com/OurOffering/Products/ProductsAssets/hi-focus-V41-vectoring-shelf.pdf)
Just FYI if Openreach haven't published it you probably are running the risk of coming a cropper. Unless you've been told you can release it you shouldn't be. When information is released to Openreach customers it's done under NDA. You are employed under an NDA. If Openreach want people to know about things they'll put them on their website.
Be careful, Sir.
While I'm thinking about it you claimed that vectoring is coming 'as we speak' to all DSLAMs. Did you actually read that or just find some information on the intranet regarding trials?
The decision as to how widely vectoring is going to be done hasn't been made yet. That's why the 100 DSLAM trial. Then after that assessing the economics of the ECI trials.
To deploy vectoring via Huawei is a VPE card, and in the case of multi-DSLAM nodes an optical cross-connect. To deploy via ECI is a chassis swap and VEC install. Given the company is going to be, very slowly as the hardware will barely be out of beta, deploying G.fast as of financial year 2016-17 not exactly a massive incentive to deploy vectoring to 61,000 cabinets, about 1/3rd of which need chassis swaps. Eircom's deployment was a fraction of this and all Huawei.
-
he is someone who says he is a plusnet customer and owns an isp (hence apparently having access to openreach confidential information), he is able to do repeated speedtests even tho he says he is out of the country, his username is andyh.
Andyh has never claimed to own an ISP, quite the opposite actually.
Try and keep the bitchiness factual.
-
:(
Just come home to see this :/ If people want to have a moan about their ISP then I can understand it, because I myself have seen the issues on numerous times. The lack of input from Plusnet has been frustrating for a lot of people. I've kept out of it a lot of the time because Im usually not around in the evenings, and may not get home until late... but when I am Ive seen signs of congestion and have always attempted to report it via their forums.
If I'd have seen mention that he had an ISP then I would have corrected it myself - you can see here (http://forum.kitz.co.uk/index.php/topic,14902.msg282490.html#msg282490) and here (http://forum.kitz.co.uk/index.php/topic,14902.msg282499.html#msg282499) that Ive attempted to be fair and I will correct things that I know are wrong. But unfortunately it is a fact that his manner does wind people up the wrong way and not just the odd one or two, its quite a lot of people. Sometimes people are wanting answers from Plusnet not excuses given by Andy for Plusnet... and they wonder who he is and how he gets his info.. thats only natural.
Its also natural if he has peed someone off then they will go and moan about it elsewhere.
We're generally a friendly lot here, we dont go in for the one upmanship you see on some other technical type forums and I know a lot of people visit and stay here because we dont either do the "I know more than you do", we just try and share what info we do have. If anyone does get anything wrong then Im always happy for it to be corrected... we all get things wrong and none of us are perfect.
>> I'm thinking about it you claimed that vectoring is coming 'as we speak' to all DSLAMs.
I must have missed that :hmm: I do recall this one (http://forum.kitz.co.uk/index.php/topic,15190.msg283178.html#msg283178) though from about 2 wks ago
I can confirm vectoring trials on ECI are happening, and I've even seen a photo (boring as it is) of the ECI vectoring engine shelf. For commercially sensitive purposes, I cannot post anything more. But, it's another step in the right direction for the ECI customers IMHO.
BTW, I've no idea of projected timescales regarding final trials to implementation ..... sorry.
...edit just done a search on vectoring and cant see anything :-\ Found another one from Dec but again only mentions trials
-
he is someone who says he is a plusnet customer and owns an isp (hence apparently having access to openreach confidential information), he is able to do repeated speedtests even tho he says he is out of the country, his username is andyh.
Andyh has never claimed to own an ISP, quite the opposite actually.
Try and keep the bitchiness factual.
I am afraid he has, but I am not going to bother looking for the posts now, I am keeping a rest from the issue and plusnet's site.
-
Nope closest he went to that was http://community.plus.net/forum/index.php/topic,135389.msg1213448.html#msg1213448
Not everyone who does business with BTW / OR is an ISP. In fact the vast majority of Wholesale's transactions aren't.
He doesn't 'claim' to be outside the UK - as a general rule he is. He has never claimed to own an ISP and, indeed, doesn't.
I would imagine a good reason why Andyh has access to the information he does and can discuss issues more freely with Plusnet staff is that he avoids approaching with belligerence. Something I know I could learn from.
This is, in any event, supposed to be a discussion on Plusnet, not a poster on a forum. We could all happily fill this thread for pages and pages and the result - you guys have just done exactly one of the things you complain about Andy doing, clouding the issues with irrelevance.
Repeating because it's awesome:
(https://dl.dropboxusercontent.com/u/20271204/dslstats/thegame.jpg)
-
Some refreshing honesty from Plusnet:
Hi all
Okay things haven’t gone quite as planned this week. The upgrade work on Tuesday on PTN-BNG01 went ahead. However the number of customers that are connecting to that gateway isn’t increasing at the rate that it should be meaning there was a lot of spare bandwidth on that device Tuesday and Wednesday nights.
We added an extra endpoint yesterday on another device which also had spare bandwidth last night but that should be fully in balance tonight. The IPSC (20CN) bandwidth that we added on Tuesday had to be disabled yesterday as it wasn’t working.
To summarise the balancing on the network isn’t perfect, but we’re working to improve it. As a result there’s spare bandwidth available on some endpoints where it couldn’t be used and some end points that are maxing out their bandwidth. Last night wasn’t as busy compared to Monday and Tuesday but we still saw high demand from people downloading iOS 8.3/OS X 10.10.3 and people watching the FA Cup on BT Sport.
As soon as we have further updates we'll let you guys know.
Matthew Wheeler
Plusnet Customer Relations Team
-
Wow, well done PN.
There you have it, I guess :)
-
honesty is the best policy, even tho they have come out with that info, it will do them good.
-
I hope you are not including all in that :(
For a start its not just on here and its not just members of this forum where this is happening. Theres plenty on PN forums and TBB who also have an issue so Im not quite sure why you brought it up on here. afaik theres nothing been said on here that hasnt been said on other forums.
He may not be belligerent to Plusnet but its the attitude to _their_ customers that is winding their customers up. I've kept out of it.. and its not limited to a couple of people here.. there are plenty more elsewhere
I hope you don't lump me in that belligerent category either, because I'm pretty placid and easy going.. until someone raises my heckles and then you will see a different side.
Generally speaking the people who visit here are a good crowd, that's not to say that there isn't the odd falling out or disagreement but on the whole the attitude on here is a lot friendlier than you will see elsewhere. In the whole history and 10yrs I think there's only ever been 2 bans ever placed. Dont think it means Im soft either because the regs will tell you I do pull people up and there's certain things that I wont tolerate.
So.... someone made a comment that they'd had a warning elsewhere.. and it kicked around for a bit between a couple of people. I didn't notice this thread until late at night, most of the regs here know why Im never around in the evenings and why I cant keep up with things as much as usual. I admit it was later than usual when I got home, but that was only because I stopped off to get some food shopping on the way home because I'd not eaten all day and had nothing in the house. Srsly there's people who have a go about me on other forums but I don't go round chasing them.. even though I know one of them is making absurd CT comments and the reason why they are doing it.. I've got far better things to worry about.
Im not even sure why BS has been dragged into this because he is one of the most helpful people you will come across and I've seen the snide comments. If he (or any of us) have made a mistake or something needs correcting then Im sure you will find he is most amenable if approached in the right way. :)
I'm also quite sure Andy doesn't need a bulldog. If Andy has an issue with a person of this forum over an incident that has happened on another forum then I suggest that they take it up amongst themselves.
-
Some refreshing honesty from Plusnet:
Good stuff... and thats the kind of feedback we need. I haven't checked out the forums there, so I'll go catch up later :)
-
Nice fancy words used to supposedly describe me?
I am always polite to people I do business with when contacting them formally, and on public forums I will also be polite, I only get angry when I am been given the runaround, but even with the case on the forums, I have generally stayed polite to plusnet staff and most users, the only user I have had debates with is the one guy who was telling people their issues are irrelevant if they can still browse web pages and that tbb was not a reliable way of confirming the issue, I took issue with how much effort he put into sidetracking the thread, for reasons we will never know.
As has been pointed out, generally the information related to trials and rollouts is classified, in addition business's that do business with BT wholesale that are not DSL related do not get access to the type of information he has been posting, this is why he has been by me put into question.
Andy would have done best to just stay out of that thread instead of trying to derail it.
Also for the benefit of others here, I never got a further reply of the moderator when I asked where I broke the rules.
-
I think for the sake of peace, (and taking the easy option when Im so tired) Im best locking this thread.
Feel free to start another about the speeds etc if you like.