Plusnet may be restricting your speed

Plusnet have had a problem ongoing for many months which means users will not be getting the speeds they should be getting. What is happening is that when BT set a new IP Profile, Plusnet's systems may fail to reflect the change. For some reason it seems this seems for prevalent when speeds rise than when they fall (or maybe it's just more often reported).

How to check if you are affected:

1. Run a BT speed test at http://www.speedtester.bt.com/ in the information it gives will be your IP Profile.

2. Go to https://portal.plus.net/my.html?action=stable_rate and look to see what your current line speed is.

3. This depends upon whether you are on 20CN or 21CN. If you are on 20CN the BT speed test will have reported on the download only, on 21CN it reports on both download and upload.

21CN: The current line speed should match the IP Profile rounded down to the nearest 100.

20CN: See the table on this page to see how it should be set.

If your current line speed stays below the value it should be for more than 24 hours you need to contact Plusnet to have it corrected manually.

NB If you know you are on 21CN you can calculate your IP Profile which will be 88.2% of your sync speed.

My experience is that it drops when the IP profile drops but then does nothing when it rises again.
I have had to raise a ticket twice in the last couple of weeks to get it raised

Just to add to this, if you are an FTTC user rather than ADSL and your Plusnet profile says 20Mb, do not scream to get it changed, this is what it should be and it is not restricting your speed. Also, on FTTC, IP profile is 96.79% of sync speed, not 88.2%

Edited by kasg (Thu 05-Jul-12 11:24:01)

IP Profile for your line is - 13.46 Mbps

Current line speed:
13.4 Mb

I want my 0.06Mb!!!

I did say rounded down to the nearest 100 so yours is correct.

How long does it seem to be for Plusnet to update when your IP Profile changes by more than 100?

Not sure. My SNR is locked, so I don't think it does change. Sometimes if I reboot at night and it syncs higher, it can be immediate. Other times, not so.

Edited by camieabz (Thu 05-Jul-12 12:54:53)

My PN current linespeed is 9.6 but my IP Profile is 8.67. PN seem to have speeded me up!!

Meldrew.

Reading the title i wondered what dishonest thottling pn was up to as that is not like pn, should of guessed it was the elastic strecthing in the bras an ip profiles forgot what a pain it can be since moving to cable.

On fttc i thought the 20mb profile was just a adsl2 thing that would of been sorted by now since it has been out of trial long time. Is there a pn profile still running in background not visable in the member centre?

In reply to a post by ASBOdog:

On fttc i thought the 20mb profile was just a adsl2 thing that would of been sorted by now since it has been out of trial long time. Is there a pn profile still running in background not visable in the member centre?

I believe the PN line rate now properly reports the (rounded down) BTW IP Profile, except for those of us with it locked at 20Mbps.

The 20Mbps setting is recognised in the PN line management system as "unlimited/uncapped" wrt speed, and was originally applicable to ADSL2+ only.

When FTTC came along there was apparently a problem in getting the system to allow the 38717kbps BTW IP Profile, so people got throttled in error. Those of us who asked were therefore put on the 20Mbps setting, thus fooling the line management system into uncapping it.

Amusingly to me, an hour or so after mine was set to 20Mbps the bug was fixed.

In reply to a post by RobertoS:

I believe the PN line rate now properly reports the (rounded down) BTW IP Profile, except for those of us with it locked at 20Mbps.

Regrettably your belief is incorrect.
There is a major bug on ADSL2 where a rise in the BT IP profile isn't picked up by the Plusnet systems and needs to be manually changed either via a ticket or this thread http://community.plus.net/forum/index.php/topic,1015...

Sorry - crossed lines.

I was replying specifically to the FTTC side of it, as in the quote I gave, and why the 20Mbps setting is OK as pointed out in the OP.

I agree there is an intermittent bug whereby a rise in the BTW IP Profile doesn't always get picked up. I believe it does pick it up in most cases.

I would stress that the bug is almost certainly in the BTW notification system,(failing to issue the update to the ISP), not Plusnet's treatment of it. I say this because it used to be a frequent occurrence on Entanet connections in the days when there were large numbers of such. I think I recall it happening on AAISP as well.

As to the earlier comment by someone about the update failure only seeming to affect profile increases, my opinion is that is because it would be very unusual for anyone to check the PN line rate to see if it had followed a BTW drop,so it could very well be failing in the same way. Just no-one spots it.

Though again, I'm sure I've seen a few posts over the years where someone has done so, and had a line rate above both the sync and the BTW IP Profile.

My SNR is locked, so I don't think it does change

How did you manage that ? Used to be do-able on 20cn, but you are on 21.....

Trial of some sort. Whatever happens when I reboot the target SNR is 3.0dB. However, my line length means that if I reboot in quiet times the sync is around 16000k, but when things get busy (either the nation's networks or Plusnet's, I can't tell which) the line will drop and re-sync around 15500k. That seems to be my stable 3.0dB speed.

I can get 13 Meg between midnight and midday, but only 12.5 Meg between midday and midnight (line drop times vary).

No big deal though. 2.2 (ish) kms from the exchange.

Is this something Plusnet informed you of ? If not, then it will just be DLM recognising a nice stable circuit, and cranking the speed as high as poss. Usually come across these as faults when some businesses Cisco router just can't hang on at 3db.

My old 8128 circuit was hard pinned to a 6db fast path profile (have a friend in the know). I was glad I jumped from that to 40/10, as BTw up to 20 service is finicky, at best.

Setting the target SNRM isn't the same thing as having a fixed SNRM . The nearest thing to that is SRA, or the range mechanism in DMT. Or as Zarjaz said, it could be set higher than 6dB on IPStream. On WBC I think there is just standard, stable, and superstable.

You had Zarjaz and me confused there .

Edited by RobertoS (Sun 08-Jul-12 12:53:08)

In reply to a post by Zarjaz:

Is this something Plusnet informed you of?

Yes. The faults guy that helped me with my sync and snr monitoring was keen to lock at 6dB, but I pushed him that bit farther and jumped from 11.5 to 12.5 Meg.

Within the last few days they have made a change that seems to have significantly improved thins.

However...

A side affect is that speeds of users trialling the FTTC 80/20 service are being restricted to 40 Mbps!

Yike!
http://www.speedtest.net/result/2059895708.png

Tried the BT tester to check IP Profile but it doesn't actually upload anything, according to NetWorx, and hangs on the Testing page. So can't see the IP Profile. NetWorx showed the same speed as speedtest.net.

They've updated all the "Current Line Speed"s. I was on the fiddled 20Mbps, it's now 40Mbps.

Edited by RobertoS (Thu 12-Jul-12 18:02:22)

Raised in the Plusnet forums

In reply to a post by jelv:

A side affect is that speeds of users trialling the FTTC 80/20 service are being restricted to 40 Mbps!

Well, not all of them, mine has stayed as it should be, but it is certainly the major topic on the Fibre trials forum today!

Presumably you haven't had a resync with a slightly different speed - not that I recommend you try!

No, sync speed hasn't changed for 6 weeks, I'm leaving well alone!

I haven't had a resync either - 12/07/2012 21:50 57418 15015.

Anyway, on a 40,000 (39,997-9?) sync the Current line speed should be 38.7Mbps.

@Robertos

Yours should be corrected now, you may find that it changes to 40000 again though if we receive a delta report for your line.

We've identified how to fix it, and have coded, tested and are ready to roll the first stage (there are 4 or 5 steps for this so we don't impact the customers on the normal FTTC product too).

I am having a similar problem with http://speedtester.bt.com/. When I run the test it hangs on the upload part then eventually says "error".

My Firewall shows a large amount of traffic during the download part and none at all during the upload part. (Note all other traffic flows both ways and it is not the firewall.

speedtest.net / London / Nmaesco gives. 21 ms, 23.68 Mbps Down and 15.56Mbps Up, which I would have thought was far too low on an 80/20 connection . Since joining the trial, my download speeds have either been about the same, or they may actually have reduced a little. My upload speeds have definitely increased.

I am on the Value Fibre tariff should I be contacting plusnet?

Thanks Chris, it is indeed now 20Mbps setting. (Scratches head - a bit of (fairly elementary) detective work there Chris? Or was I the only one left)?

No bother anyway . Things are good on Plusnet.

I'm on Value Fibre as well. That's not the issue. Your 23Mbps speed looks very strange though, given the earlier one in your sig.

Have you tried a different speedtest.net server? If so, I'd say you have a problem specific to you somewhere, probably best raised in a dedicated thread.

In reply to a post by philippercival:

speedtest.net / London / Nmaesco gives. 21 ms, 23.68 Mbps Down and 15.56Mbps Up, which I would have thought was far too low on an 80/20 connection . Since joining the trial, my download speeds have either been about the same, or they may actually have reduced a little. My upload speeds have definitely increased.

I am on the Value Fibre tariff should I be contacting plusnet?

If you were only getting around 23-24Mbps download speeds before joining the trial, you won't see any improvement from 80/20, except for the upload speed. You need to have been on the maximum sync on the 40Mbps product to benefit. If you want to contact Plusnet your best bet is to post on the 80/20 trials thread here.

In reply to a post by RobertoS:

Your 23Mbps speed looks very strange though, given the earlier one in your sig.

Ah, hadn't spotted that - Entanet, not Plusnet, from May. Not sure how that relates to the question.

Edited by kasg (Fri 13-Jul-12 13:56:50)

In reply to a post by kasg:

In reply to a post by RobertoS:

Your 23Mbps speed looks very strange though, given the earlier one in your sig.

Ah, hadn't spotted that - Entanet, not Plusnet, from May. Not sure how that relates to the question.

Because the stats in it indicate an Entanet Fibre connection (I hadn't missed the ISP ), unless it was a wild upload figure on speedtest.net. I think only downloads get the silly results though.

Entanet fibre is WBC just like PN.

Edit - and they use copy IP Profiles .

Edited by RobertoS (Fri 13-Jul-12 14:38:25)

Philip? How did that high speed result in your sig come about? What service were you on with Entanet?

I'm just that good

Thanks, The value in my sig is on another connection. There seems to be little difference in the speedtest servers.

Edit: I have now read further responses. My Enta connection is also 80/20 and that is a typical speed on a good day with that.

Edited by philippercival (Fri 13-Jul-12 16:26:18)

An update:

This issue is still affecting many users. Today I've just seen a post on their community forums by a Plusnet rep. which included the following.

At the moment we're looking at any reported examples of where the profile hasn't updated and in each case we're needing to check at which level the issue lies (i.e is the delta report being issued correctly when the line resynchs and if so is our system processing it).

This isn't something that seems to affect everyone but we do acknowledge that it is impacting some of you and I'm certain we'll push things further forward with this if a single clear cause for such problems can be identified.

The implication of the final paragraph as it is worded is that if they identify more than one cause they are going to do nothing. I somehow suspect that isn't what he meant!

Backhaul, contention, routing, load balancing : I doubt it will be a simple fix.

This is nothing to do with any of those; it's the failure of the PN profile to keep in step with the BT profile.

It seems to be the opposite of petrol prices: very quick to go down when the BT profile goes down, but slow (or never) to rise when the BT profile goes up!

The profile keeps in step for me, but the (stable) sync can be anything from 15,000 to 15,500 and one of the reasons I listed is causing the sync issues.

Shouldn't we look at what causes sync to change to prevent profile changes, rather than fix the profile issues?

In reply to a post by jelv:

This is nothing to do with any of those; it's the failure of the PN profile to keep in step with the BT profile.

That's one of the issues, in quite a number of cases we're not actually able to download the BT profile as it hasn't generated.

In reply to a post by chrisparr:

... in quite a number of cases we're not actually able to download the BT profile as it hasn't generated ...

... in the place it is sent to you from. It is usually active on the line itself and in BT speed test results. That's how we spot yours is wrong. (And I have many times posted here that I believe the problem is within BT Wholesale - not sending the update, so I'm not getting at you).

It's got worse/more frequent for my maaf connection on 20CN, rarely used to be bothered before with the PN profile not matching the BT profile.

Had to reboot the router at lunch time in the hope to get the PN profile to match BTs, fortunately for me that did the trick.

PN need to get this mismatching debacle fixed ASAP as it seems to be getting worse from what I'm experiencing of late.

My current BT profile for my line is

Download speedachieved during the test was - 38.22 Mbps
For your connection, the acceptable range of speedsis 12 Mbps-44.99 Mbps .
Additional Information:
IP Profile for your line is - 44.99 Mbps


info from Plusnet

Estimated line speed:
44Mb (Accurate to within +/- 1Mbit) - Checked on 2012-08-26 00:49:43
Current line speed:
39.4 Mb

Lisa

Rebooting the router doesn't change the profile on our side though?

All I can think of that's happened is that the reboot has forced a resync, which has generated a new line report that was then picked up.

In reply to a post by lisaj:

My current BT profile for my line is

Download speedachieved during the test was - 38.22 Mbps
For your connection, the acceptable range of speedsis 12 Mbps-44.99 Mbps .
Additional Information:
IP Profile for your line is - 44.99 Mbps


info from Plusnet

Estimated line speed:
44Mb (Accurate to within +/- 1Mbit) - Checked on 2012-08-26 00:49:43
Current line speed:
39.4 Mb

That's interesting - I thought all "line speeds" on the Plusnet side were set to 20Mb, 40Mb or 80Mb for FTTC connections (all of them basically meaning unrestricted) but I see mine is now set to 69.2Mb, which is actually correct (same as my IP profile) but I see yours isn't.

That was changed when the 80/20 product ceased to be a trial and now it is supposed to work the same as ADSL2+

Thanks, I hadn't spotted that. I suppose I'd better keep an eye on it now!

In reply to a post by chrisparr:

Rebooting the router doesn't change the profile on our side though?

All I can think of that's happened is that the reboot has forced a resync, which has generated a new line report that was then picked up.

OK, so if the IP profile from the BT performance tester says 3.5Mbps what's stopping the throughput increasing after the rise in IP profile? (it increases OK after a reboot with the same 4Meg sync speed)

You are saying/suggesting a new line report could be the issue, why wasn't the increase in IP profile picked up when it increased from whatever it was previously (2.5Meg?) to 3.5Meg as it used to happen automatically and what or whose equipment/systems is not picking it up?

This is being discussed ad nauseum in the Plusnet forums and many of us are suffering.
There doesn't appear to be a single reason but the end result is that the Delta reports from BT are not working as they should and, in my opinion it could be the problem of having two different profile generating systems in BT and they are not producing a correct result.
In my case when I was on 20CN for a small drop in speed it changed the IP profile almost immediately but a small increase in speed took up to 3 days to take effect. This is as it was supposed to operate.
Now I am on 21CN the IP profile I see from a BT speedtest changes immediately (up or down) but the Delta reports seem to follow the old timing - immediate for a drop and 2-3 days for an increase.
In addition when I compared my connection speed changes with the ones received by Plusnet from BT not only had they missed a chunk of them but had even added a spurious one as well.
So it has all the hallmarks of a right mess but fortunately my sync speed only changes by about 300kbps (best to worst) so I can live with it.

It has luckily never affected madasafish customers hence why I am still not swapping to a plusnet tariff.on my adsl2 line

Edited by deleted (Sun 09-Sep-12 09:13:20)

In reply to a post by camieabz:

The profile keeps in step for me, but the (stable) sync can be anything from 15,000 to 15,500 and one of the reasons I listed is causing the sync issues.

Shouldn't we look at what causes sync to change to prevent profile changes, rather than fix the profile issues?

No. The OP is discussing a specific issue which highlights a quite disconcerting issue with Plusnet's traffic management system.

That may or may not be the case but the fact that MAAF customers can't see their profile on the MAAF website may have something to do with it.

They do not iomplement thier mirroring of the ip profile on the maaf system so each time my ip profile is updated on the bt system speed tests show instant rise or fall in throughput.

That is interesting as posts on the Plusnet forums implied the opposite http://community.plus.net/forum/index.php/topic,8514... as does this http://forums.thinkbroadband.com/plusnet/t/4155036-r...
Of course one possible explanation may be that your profile is stuck at a high value as no Delta reports are being received

Edited by deleted (Sun 09-Sep-12 11:53:19)

It has luckily never affected madasafish customers

It has for my connection (20CN)

If you are on 20CN then the current debacle hasn't affected you - you are still on the "BT will drop the IP profile immediately but will think about it for 3 days before raising it system"

In reply to a post by Oldjim:

If you are on 20CN then the current debacle hasn't affected you - you are still on the "BT will drop the IP profile immediately but will think about it for 3 days before raising it system"

It's not BT's profiling that's causing the issue, it moves up OK after a sync increase but the throughput doesn't it still remains as though it was on the previous/lower BT IP profile.

So are you saying that PN doesn't have their own IP profiling for 20CN connections?

No I am not. The current problem with the Plusnet profile not updating is 21CN specific.
The 20CN is still working as it always has - Plusnet updating within 12 hours of the BT profile changing

Ok that's fine, I'll just have to keep a written note of changes in case I'm not giving BT's system the full 72 hours it needs after a higher sync rate + new higher IP profile to then increase the actual throughput.

In reply to a post by Oldjim:

If you are on 20CN then the current debacle hasn't affected you - you are still on the "BT will drop the IP profile immediately but will think about it for 3 days before raising it system"

That was replaced by 4 hours to 5 days in August 2008, see this page.

See my reply to Oldjim a few seconds ago.

In reply to a post by Oldjim:

The 20CN is still working as it always has - Plusnet updating within 12 hours of the BT profile changing

It has always had this occasional failure.

and my experience and that of many others is the new system didn't work as advertised

Now that's a confusing post . What are you talking about? The BT IP Profiling system or the communication of its changes to Plusnet's copy system?

The BT IP Profiling post-August 2008 works fine. The issue being discussed here is the failure of the BT system communicating the profile changes to PN, wherever the fault for that lies.

The 3-day system stopped in August 2008, Fact! Two of you this evening have posted as though it was still in existence and as I'm sure you agree the perpetuation of incorrect "facts", i.e. internet myths, is to be deplored. It certainly doesn't help the discussion in this thread, either for those participating or any later readers.

I can personally vouch for the system that was introduced at that time working as advertised. I was with Newnet, with a slightly unstable line, and when I had a small drop in sync, losing me one or two profile steps, it would take 4-5 days instead of the previous three for the IP Profile to rise again. However it was easy to fool the system.

Just before going to bed, a few of us when in this position would tweak our noise margin extremely high for a few minutes to force a very low sync/profile. Then tweak the margin to something like 3dB, (bearing in mind that's where it would have been at that time of night for many of us). That gave the sync expected from a standard daytime 6dB margin sync, and bingo - come the morning the profile was up to the right place.

The key is to have a high percentage increase in sync. A doubling of sync didn't rate as high . IIRC that gave around the old three days. The further above 100% increase the more rapid the adjustment.
_{Edit - typo as pointed out by ian72}

Edited by RobertoS (Tue 11-Sep-12 09:33:22)

The 3-day system stopped in August 2000, Fact!

Are you sure - this is before they even introduced variable speed products. Think that is a little mistype

In reply to a post by RobertoS:

The BT IP Profiling post-August 2008 works fine.

In my experience and that of quite a few others it didn't

In reply to a post by Oldjim:

In reply to a post by RobertoS:

The BT IP Profiling post-August 2008 works fine.

In my experience and that of quite a few others it didn't

I repeat! Do you mean the BT/Plusnet copying system? That is nothing whatsoever to do with the underlying profile set and applied by the 20CN DLM.

I think I'm right in saying it even cured the historic 2000kbps stuck profile problem.

If my room does not become light when the sun is due to rise, it doesn't mean the sun hasn't risen. It is because the blind-opening mechanism has failed.

It's my impression that that works absolutely fine. Where the sync speed doesn't rise it's because of other factors like another low sync event or the user getting impatient and rebooting the router to try and increase the speed.

Confusing the issue is that most frequently posters give the result of a speed test which doesn't increase because of the delay/non-update of the PN profile instead of checking the IP profile reported by a speed test.

Also complicating this is the DLM which does take a long time to lower the target noise margin, but that is a different issue to the IP Profile updating to reflect the current sync speed.

The final complication is that half the time the BT speed test wouldn't run so users couldn't find out what their IP Profile was anyway - although that seems a bit better these days.

To clarify - al;though I thought I was being very clear
The BT system - also called adaptive max logic - in my experience didn't work as advertised.
I see no point in continuing this discussion as obviously my memory/experience must be faulty

I haven't seen an example of this reported on the Community forums for a user on 20CN for a very long time.

As an example of how this is working on FTTC, my modem resynced slightly higher, from 71491 to 72203 on Sunday, so I rebooted the router to increase my IP profile from 69.2 to 69.89. 24 hours later the Plusnet profile still said 69.2 but it has updated to 69.8 this morning. So it seems to work but it's a bit sluggish.

http://speedtest.net/result/2186494347.png

Edited by kasg (Tue 18-Sep-12 09:20:16)

So the reboot of the router was probably irrelevant?

In reply to a post by RobertoS:

So the reboot of the router was probably irrelevant?

Not at all - the IP profile would not have increased had I not rebooted the router.

Are you saying that until you reboot the router the results of a BT speed test don't show the changed IP Profile?

That's right, you need to disconnect and reconnect the session to get a new profile and a "spontaneous" modem resync will not normally do that. It's the same if it resyncs lower, you can get. an IP profile higher than the sync speed.

?
On OR DLM with WBC IP Profiling generated from it, (and in fact on WBC ADSL2+), the BT IP Profile changes immediately the modem sync's at a different speed.

Your reboot of the router has no effect on that. I thought you meant the PPP disconnection from rebooting the router would cause the PN system to refresh immediately from the BT profile, but it seems it didn't.

There is the bit we are still only guessing at, which is what BT database also gets updated with the WBC IP Profile, and when, as it is the feed from that database that updates the PN copy. It's somewhere in the WBC >> unknown >> PN feed >> PN update path the problem lies. So maybe the PN line rate was refreshed from the unknown, but that hadn't updated at that stage.

... if it resyncs lower, you can get. an IP profile higher than the sync speed.

That was the case on the original 20CN DLM, and earlier versions of the WC one, as they took up to 75 minutes to register the sync change. Normally they took far less than that.

The current WBC DLM reacts immediately in either direction.

Whatever is going on behind the scenes, the reported BT IP profile, and I don't mean Plusnet's copy, does not change until you disconnect and reconnect the session and this has been documented several times here.

Does this apply to FTTC which is what is being referred to.
I must admit that this is the first time I have seen this reported

I've not seen that, here or elsewhere, unless I'm having a serious senior moment. Proving it either way isn't made easier by the current malfunctioning of the BT Wholesale speed test though.

Ahhh, I might have an explanation, but t'other half has just stirred upstairs, so time to take us both tea in bed.

Yes, I'm talking about FTTC and I've experienced it and seen it reported several times, I'll have a search later on when I get home, unless someone beats me to it (please!)

Well a quick search hasn't revealed anything that wasn't written by me but I'm pretty certain I've seen it reported by others. Perhaps it's my "senior moment!" I can't be certain that I checked the IP profile before and after rebooting the router, if it happens again I'll have to be more methodical.

This is what I was thinking of:-

CPs should be aware that the mechanism for reporting the downstream and upstream line rates relies on a line re-train causing the CP, or the CPE, to initiate a new PPP session or a new DHCP request. The success of this method of line rate reporting is down to the CP's choice of timers used around PPP/DHCP handling.

If the PPP/DHCP survives a re-train, then the CP will be unaware of any change in the line rate and will not be able to shape appropriately.

The line re-train time for VDSL2 can be anywhere between 10 and 60 seconds, with typical values in the 20-30 second range. As DHCP typically uses lease timeouts in the order of days rather than seconds, CPs intending to use DHCP are advised to consider the impact of downstream line rate changes on their service and any strategies they could adopt if they wish to shape downstream traffic in close relationship to the active line rate.

I'm wondering if the WBC IP Profile can fail to be updated if the re-sync is faster than the Plusnet setting for killing the PPP session. This used to, (still does?), happen on ADSL2x with many ISPs, where the user had resync's he (a) witnessed, and (b) could often show in router logs, but the ISP was not aware of any line drops.

If that means the OR DLM does not report to the WBC one that the speed has changed, the WBC IP Profile will be unchanged. The situation presumably being corrected within 24 hours, as just happened to you, by the following mechanism.

Where Openreach have provided and are managing the Modem, daily status reports will be generated and transmitted consisting of no more than 8k Bytes (64k bits) of data upstream at full line rate.

I expect the WBC DLM reacts to that as well as passing it on to the ISP.

If you have a line that is re-sync'ing very quickly, this could be happening, and your rebooting the router would of course cause a long PPP drop, sufficient to trigger the update.

Or my thoughts could be garbage. They do at least provide a possible explanation.

Thanks - that was it!

In reply to a post by RobertoS:

...This used to, (still does?), happen on ADSL2x with many ISPs, where the user had resync's he (a) witnessed, and (b) could often show in router logs, but the ISP was not aware of any line drops...

That was definitely the case late last year when I had problems with DSL dropping for a few seconds due to a line fault and PN were not aware of a loss of connection (session?) at their end - that was ADSL MAX though and I don't think it had any effect on the IP Profile (or whatever they called it) as displayed on the PN web site when I logged-in to my account.

Well my profile was stuck at 13.2 Meg for a few weeks and reported it to Plusnet and they tweaked it up to 13.8 Meg in next to no time. After a couple of reboots over the weekend, it's down to 13.3 Meg.

As far as I'm concerned, Plusnet are not putting any priority into the upward adjustment of profiles. If you phone them, no problem, but you'll need to phone them, it seems.

The reason for the re-boots were due to speeds and profiles not matching, and I was getting confusing info. Speed tests were jagged until the phone call, then they were good. Add to that, once the speeds were fine, the gateway I was on was of a higher ping than other gateways, so I re-booted to get a better ping. It seems I can't get a good ping and a high sync, which I find completely strange.

Frankly, their internal systems are hit and miss. I haven't nailed it completely, but it's either a lack of balancing / routing issues, or some of their kit is less up to the job as others, and users are re-booting to get the better gateways (or that's how it comes across).

I think a lot of it is also that the FTTC growth is side-lining non-FTTC connections.


For what it's worth, see these trace tests, last hop ping shown, 20 samples (with slowest hop in brackets):

bbc.co.uk/news (11 hops) - 24ms (link12-central10.ptw-gw02.plus.net : 47ms)

fast.co.uk (9 hops) - 23ms (link11-central10.ptw-gw01.plus.net : 34ms : 5% packet loss)

aa.net.uk (8 hops) - 24ms (link7-central10.ptw-gw01.plus.net : 31ms)

idnet.net (8 hops) - 23ms (lo0-central10.ptw-ag04.plus.net : 46ms)

plus.net (9 hops) - 36ms (vlan2658.ptp-elb02.plus.net : 38ms)

forums.thinkbroadband.com (7 hops) - 23ms (link14-central10.ptw-gw02.plus.net : 31ms)

In all cases the slowest hop in the chain is a plusnet hop. In fairness, the majority of the hops in a tracert are plusnet. However, given that I'm on the plusnet network, one would think the trace to the plusnet website would be as fast or faster than the other sites. This suggests internal issues (capacity or routing though?).

Make of that what you can. Something else that's occurred to me. The Plusnet DNS servers I use are both 23ms. I've never considered it before, but is a tracert minimum ping dictated by the ping to the DNS server? (i.e. my best ping to any site is never lower than my best ping to a DNS server).

In all cases the slowest hop in the chain is a plusnet hop. In fairness, the majority of the hops in a tracert are plusnet

That doesn't actually mean anything. All most tracert intermediate lines really show, if higher than the final line, is how quickly that router responded to a ping when it is handling throughput from thousands of genuine data routing tasks. Simple multiple pings to the target are generally more useful.

Where tracert is useful is when there is a step jump within it which is maintained and/or exceeded for all subsequent hops. Thus showing the bottleneck.

Make of that what you can. Something else that's occurred to me. The Plusnet DNS servers I use are both 23ms. I've never considered it before, but is a tracert minimum ping dictated by the ping to the DNS server? (i.e. my best ping to any site is never lower than my best ping to a DNS server)

I would expect DNS servers to be particularly loath to respond to pings, for exactly the reason you surmise, they are a primary factor in any real response times. Though if you have no pings ever better than them, that is interesting.

What happens when you use IP addresses in pings/tracerts rather than URLs?

In reply to a post by RobertoS:

That doesn't actually mean anything. All most tracert intermediate lines really show, if higher than the final line, is how quickly that router responded to a ping when it is handling throughput from thousands of genuine data routing tasks. Simple multiple pings to the target are generally more useful.

In reply to a post by RobertoS:

What happens when you use IP addresses in pings/tracerts rather than URLs?

>ping www.plus.net -n 20

Pinging portal.plus.net [212.159.9.2] with 32 bytes of data:
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=33ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=33ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=72ms TTL=247
Reply from 212.159.9.2: bytes=32 time=46ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247

Ping statistics for 212.159.9.2:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 72ms, Average = 34ms


>ping 212.159.9.2 -n 20

Pinging 212.159.9.2 with 32 bytes of data:
Reply from 212.159.9.2: bytes=32 time=33ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=79ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247
Reply from 212.159.9.2: bytes=32 time=30ms TTL=247
Reply from 212.159.9.2: bytes=32 time=32ms TTL=247
Reply from 212.159.9.2: bytes=32 time=31ms TTL=247

Ping statistics for 212.159.9.2:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 30ms, Maximum = 79ms, Average = 33ms


>ping www.aa.net.uk -n 20

Pinging www-server.co.uk [81.187.30.81] with 32 bytes of data:
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=26ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=33ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57

Ping statistics for 81.187.30.81:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 33ms, Average = 25ms


>ping 81.187.30.81 -n 20

Pinging 81.187.30.81 with 32 bytes of data:
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=26ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=25ms TTL=57
Reply from 81.187.30.81: bytes=32 time=24ms TTL=57

Ping statistics for 81.187.30.81:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 26ms, Average = 24ms


That's using dos. Previous traces were using Pingplotter. Using pingplotter I get no difference with pure IPs.

So to sum up, ping or trace, pingplotter or tracert, I get similar results.

FWIW, I have spent quite a few hours studying FTTC connection stats etc. (not just my own).

I have mentioned quite a few times that BT's IP Profile (also known as BRAS Rate) is not usually updated unless a new PPP session is initiated.

Before my line was eventually physically repaired, I saw many "on the fly" resyncs, logged by the unlocked HG612 MODEM as typically taking around 16 seconds.

Plusnet couldn't see these frequent resyncs as they were too quick for their timers & thus a new PPP session that would have updated the IP profile was not iniatiated.
On that basis, Plusnet initially kept claiming that my connection was stable.
It took quite a while to convince them that these resyncs actually happened frequently & that my connection was nowhere near as stable as they believed it to be.

I saw resyncs that caused both upward & downward sync speeds & ALWAYS had to force the Netgear ROUTER to initiate a new PPP session to update the IP profile.

On occasions I was left with a higher IP Profile than sync speed & on other occasions the speeds achievable from an increased sync speed were not delivered as IP Profile was still shown as the lower value.

This must have caused quite some confusion for many users who reported high IP profiles yet were only seeing low throughput speeds.

Certain Plusnet staff members are aware of this "issue", but I'm not convinced that all CS staff are aware of it from various comments I have read from time-to-time.

A MODEM reboot (not resync) ALWAYS initiates a new PPP session as it takes substantially longer & is therefore detected accordingly.

The above relates purely to my extensive observations of FTTC (VDSL2) connections. It may or may not apply to ADSL connections, that "usually" use combined modem/routers.

Edited by deleted (Tue 18-Sep-12 18:43:57)

That's good.

It ties in exactly with what I was saying about those BT SIN quotes. Clearly PN have their timing set to too high a figure for the Openreach modem. The question is, have they got to have it like that for some other reason, or could they lower it?

In reply to a post by RobertoS:

That's good.

It ties in exactly with what I was saying about those BT SIN quotes.

SIN 498, if memory serves.

Clearly PN have their timing set to too high a figure for the Openreach modem. The question is, have they got to have it like that for some other reason, or could they lower it?

I did ask the question many moons ago, but didn't get a response from Plusnet.
Being aware of it though, it doesn't really matter to me personally, but it may have been useful for others for it to actually work as intended.

Just as examples:-

"On the fly" - 16 seconds:-
2012-9-7 20:8:33 Notice 104500 DSL activate succeed
2012-9-7 20:8:17 Notice 104500 DSL deactivate


Reboot (also needing the MODEM's clock to be reset) - 25 seconds:-
2000-1-1 0:0:25 Notice 104500 DSL activate succeed
2000-1-1 0:0:18 Debug 104500 LAN1 up
2000-1-1 0:0:16 Debug 104500 LAN2 up
2000-1-1 0:0:16 Notice 1 System up
2000-1-1 0:0:3 Warning 10400 KLOB Pool 1 Initialized: 1048576 bytes <0x80300000 ... 0x80400000>
2012-9-8 14:1:7 Warning 104001 System reboot


EDIT:

I see the SIN was updated in July:-

http://www1.btwebworld.com/sinet/498v4p0.pdf

Edited by deleted (Tue 18-Sep-12 19:41:12)

Yes re the update. They added all the stuff about the requirements for wires only installation, so ISPs can start lining up end user equipment to replace the OR modem.

Plus they added the warning that the noise margin and sync rates should not be tampered with .

Just to nail this once and for all, I find that my modem has re-synced this morning at 65802 (down from 72203 after my longest ever period at the higher speed without interleaving - it will probably take over a month to increase again, if it ever does).

I have checked my BT IP profile (not Plusnet's) and it is still 69.89Mbps. Obviously the Plusnet profile is still 69.8 as it cannot have received a delta report for something that hasn't happened. I'm just going to leave it and see what happens, I won't be rebooting the router.

Speed tests show pings doubled (not surprisingly) and download speeds reduced by about 6Mbps. I hate Openreach's DLM!

Edited by kasg (Thu 20-Sep-12 09:40:52)

(My) Theory says the IP Profile will correct within 24 hours.

The problem is either the WBC DLM or Plusnet not detecting the re-sync. The Openreach DLM has nothing to do with it if the re-sync is quicker than the CPs' settings detect - it's their problem for ignoring the tech docs they have, for whatever reason.

I imagine most people, certainly me, like the shortest time to sync as is possible.

In reply to a post by RobertoS:

(My) Theory says the IP Profile will correct within 24 hours.

My experience is that the IP Profile doesn't correct itself unless a new PPP session is initiated.

I tested it for a few days once over, just to prove the point that some (maybe all) ISPs aren't always aware of quick "on the fly" resyncs that indicate instability.

We wouldn't have a leg to stand on in arguing that a connection was unstable (needing repair work) if the HG612 was still unlockable.

In reply to a post by Bald_Eagle1:

In reply to a post by RobertoS:

(My) Theory says the IP Profile will correct within 24 hours.

My experience is that the IP Profile doesn't correct itself unless a new PPP session is initiated.

Well, 24 hours later the IP profile has corrected itself to 63.69Mbps, so one point to Bob
The Plusnet profile, however, is still 69.8 and I expect that to take another 24 hours to change.

Edited by kasg (Fri 21-Sep-12 09:49:22)

I thought recently one of the reps said they receive delta reports three times a day, but whether that is pushed to them for all changes, or pulled by them for those they are aware of having had session drops, I haven't a clue.

We receive delta reports whenever there is an PPP/sync disconenction/reconenction, and if there is a change in sync speed then your profile will be updated.

Not quite Chris. They should be *generated* each time there is a resync that changes the sync speed, however we only poll them a few times a day.

Well I'll let you know when mine catches up! Not a problem at the moment as it's higher than my sync speed.

And to both of you, , the recent discussion has been about possible reasons the delta reporting sometimes fails on FTTC. In particular, the failure of the PN system to detect the resync, as it completes before the PPP session is dropped.

In particular, have a read of this post if you missed it earlier .

On further thought, there may be such a mechanism in the BT Wholesale DLMs as well when controlling ADSLx. Maybe this is the cause of the IP Profile/line rate imbalances you sometimes have to run a check to find, followed by a manual reset. It isn't inconceivable that some ADSLx modem/routers are occasioanally resync'ing too quickly for the Plusnet system. It may just need a tweak downwards of a couple of milliseconds in the PPP/DHCP settings, as per the Openreach quote earlier, to fix both problems.

In reply to a post by kasg:

Well, 24 hours later the IP profile has corrected itself to 63.69Mbps, so one point to Bob

Well, that's interesting/surprising; & is there definitely no evidence of a new PPP session reported by the router at the same time?

I think the second quote in this post is what has caused it.

The question now is will the PN line rate adjust to match. I have my doubts, but it is possible. Depending on precisely how the delta report operates.

In reply to a post by Bald_Eagle1:

Well, that's interesting/surprising; & is there definitely no evidence of a new PPP session reported by the router at the same time?

I just checked the log and it's showing a new session started at 5.30 this morning. (It wasn't me, I was in bed!)

Meanwhile, Plusnet profile is still 69.8 so that hasn't been updated.

In reply to a post by kasg:

I just checked the log and it's showing a new session started at 5.30 this morning. (It wasn't me, I was in bed!)

My experience is that the IP Profile doesn't correct itself unless a new PPP session is initiated.

Can I have half a point then?

So, it does appear that initiation of a new PPP session is the essential trigger for updating IP Profiles.

However, the new PPP session may be initiated manually, instantly updating IP Profiles or by the OR managed modem feeding daily info to DLM that deals with it "in due course".

As we are all using the same unlocked firmware version for the HG612, I can't see why my connection always seems to need manual intervention to update IP Profiles.
I shall look at that more closely the next time my connection resyncs (upward or downward), just to see if it does eventually update without manual intervention.

Edited by deleted (Fri 21-Sep-12 21:21:53)

Post deleted by RobertoS

In reply to a post by RobertoS:

The question now is will the PN line rate adjust to match. I have my doubts, but it is possible. Depending on precisely how the delta report operates.

Still not updated, so either the delta report hasn't been produced or it hasn't been processed, well over 24 hours after the BT profile changed. When it last went up it took about 24 hours, this is a change down and it is taking longer. Better that way than the other!

You'd think a PN rep would be able to comment on the theory, seeing as the problem on ADSLx has existed for years and the techies haven't fixed it. I wonder if the techies have looked at the timing q of the BT profile change. Also it would be interesting to know whether the delta report is a pull or push, and whether it is blanket or selective based on known PPP reconnects.

From the failure of your PN line rate to drop the implication is that it is selective.

Unless the techies have checked these things out they could be highly relevant.

A week later, the Plusnet profile still hasn't changed to match the BT profile. As it's higher, I still don't care!

Which seems to mean that the delta report only gets info for those that have a new PPP session initiated since the previous report.

There is a tiny drawback in the PN line rate being higher than your IP Profile. You could be getting a fair number of dropped packets at the DSLAM, which I'm fairly sure will be counted towards your allowance.

Edited by RobertoS (Fri 28-Sep-12 12:42:40)

In reply to a post by RobertoS:

You could be getting a fair number of dropped packets at the DSLAM, which I'm fairly sure will be counted towards your allowance.

There is absolutely no danger of getting anywhere near my 250GB allowance, so that shouldn't be a problem!

LOL. Like me. I use less than 8GB, and never use P2P. We are subsidising the rest of them .

Well earlier this afternoon I had to reboot the router due to a loss of internet connection (a very rare event) so we'll see if that triggers an update (it hasn't yet). I don't know whether this was connected with Plusnet problem 72818.

I use more than you but am still only getting through 40-50GB a month so plenty of headroom.

What's the BT IP Profile done?

Still 63.69, unchanged, as the sync speed hasn't changed (65802). PN profile still 69.8, which corresponds to the old IP profile of 69.89.

FYI, still not updated, two days after router reboot.