Fascicle PlusNet traffic shaping again

So, remember when Fibre unlimited first came out and PlusNet tried for months to tell everyone that although there was traffic shaping it was for our own good and all our traffic would be treated as gold, no matter what it was you would be able to go full speed on any protocol but if and only if your _own_ line was being utilised for multiple usages, then that traffic would be shaped, therefore if someone was watching iPlayer and someone was downloading a torrent, the torrent would be slowed for the greater good of the iPlayer stream ..

Step forward 1 year, and a speed test will show full 78Mb speed tests, yet Usenet is less than 10Mb, torrent is 13Mb and an apple iOS upgrade is 22Mb .... switch back to a speedtest and boom 78Mb...


Why why why is this happening, no one else in the house, nothing else going on, line is obviously capable of achieving full speed as the speed test results show ...

So yet again the PlusNet traffic shaping that will *not* affect my traffic is indeed affecting my traffic.


The above was on gateway - pcl-bng01

I've now disconnected and reconnected to gateway ptw-bng01 - and all is fine everything is full speed .. but why am I having to jump gateways to find a good one?? Not good at all PlusNet not good....

something weird is currently going on, but not sure what yet tho.

Without a doubt is currently some bad endpoints but is unclear if the cause is plusnet or BTw.

Also before christmas, I found if single threaded tested fast, then it reflected real world performance, now I can speedtest at full speed (after hopping to get good endpoint) but certian types of usage are slower when they previously were not. However this could be down to peering/transit issues, never easy to diagnose without full info.

PSN has always been slow tho, I only get linespeed via a proxy. I think xbox live is also slow, but since moving to plusnet I have not done any large downloads on xbox live so am not sure on that one.

The fact that your speed is going back to normal after jumping gateway makes it *very* unlikely to be traffic management. Knowing how this is set on the Unlimited accounts, I'm confident that traffic management is not the cause of your issues.

I'm going to pass the information on about the gateways you were connected to through to our team here for more investigation.

investigation's into peak time issues that range from a visible increased latency & jitter on the ping monitors to packet loss and reduced throughput single threaded in particular,Have been ongoing for far too long and as yet no conclusive answer's i have seen single threads lower than 10mbps which is very poor, Why should any one have to repeatedly swap gateways ?

Edited by tommy45 (Wed 21-Jan-15 19:58:16)

Chris i disagree, it is network management that is the cause.

I'd suggest the overall gateway is congested, thus the overall gateway network management is having to apply shaping to certain protocols to ensure that there is sufficient bandwidth is available to things that need it.


If it was congestion without network management then *everything* would have been slow, but a speed test showing full speeds, whilst other services showing a slowdown (even http for usenet) shows that its network management causing this.

From outside and with no axe to grind in any direction my presumption is

1) If a gateway is at capacity or near, then priorities start to apply for specific traffic types
2) This can be viewed as good as will help to avoid time sensitive stuff having a very bad time
3) Unmanaged congestion can be a real pita

Hitting congestion sometimes is always inevitable, unless an ISP runs at 1:1 contention all the time e.g. presumes that every FTTC user will have the full 76 Mbps available to them.

Balancing this perfection against cost and user experience is a balancing game, and it might just be some gateways are just getting the balance a little wrong.

Its happened before, it will happen again.

The problem is that if a specific gateway is affected, then in theory it should impact all users on that gateway. This doesn't seem to be happening though.

I kinda agree Mr S.

Issue i have though, is that if there is congestion due to over-subscription of the user-base on the gateways, then managed contention should be allowed to come into force, so that everyone still has equal bandwidth allowances although may be lower than line speed at peak time. Quite happy to go from 78Mb to 50Mb for example but everything should still be 50Mb .. not some traffic types down into almost single figures.

What I disagree with is that PN decide "oh its that traffic we will slow it" why am I sat waiting 24 minutes for iOS 8.1.2 update to download when it should be 3 minutes max just because plusnet have set those speed limits. If it is congestion then the overall "gold" traffic should be rate limited too so that everything still has same performance speeds, just lower than the off-peak line limits (i.e. contention!)

On Apple, they've moved most of their distribution over to their own CDN network. It might be related or unrelated, but Apple have a fair bit of work to do to catch up with Akamai. I've yet to be able to get fast updates (and this includes with another ISP in a different country).

Are the gateways segmented within themselves?

It could just be a bug in a bit of software too.

In reply to a post by Tam:

it is network management that is the cause.

It may well be network management - but network management by whom, and for what purpose? Not all network management comes down to the plusnet traffic shaping system (which is designed to place various limits on your connection, restricting individual protocol usage at various times of day).

The fact that shifting gateway can correct the problem does indeed suggest the problem does not come down to the traffic shaping system, but that the problem rests elsewhere.

I'd suggest the overall gateway is congested, thus the overall gateway network management is having to apply shaping to certain protocols to ensure that there is sufficient bandwidth is available to things that need it.

That could certainly be true - some leg/router is congested, and has started to employ congestion reduction techniques. That isn't shaping, in the same sense as shaping associated with your Plusnet account.

If it was congestion without network management then *everything* would have been slow,

Not necessarily. Weighted fair queuing techniques can affect long slow transfer more than short, fast ones.

Similarly, congestion detection avoidance techniques, such as RED (random early detection) can deliberately trigger early packet loss to slow down random TCP transfers; to the end user, it looks like some transfers are running slowly.

WRED can do the same, but with weighted traffic classes. The end-user experience will look very similar to traffic shaping, but is actually just plain network management and congestion prevention, although slightly more intelligent.

The kicker is that these impacts could be happening within the BTO and BTW domains, as well as within Plusnet. For one of the Plusnet users complaining about signs of congestion recently, the cause came down to congestion within certain BTW routes in Leeds.

Simply out of interest, reading this thread and checking the gateway I'm on, how can I be on a gateway that doesn't seem to exist on the 'Collated Users Online graph' displayImage.php

In reference to usertools.plus.net/@gateway/:

Which gateway You are currently connected to gateway ptn-ag02.

This is located in Telehouse North.

There is no ptn-ag02 ?

I think it's labelled as ptn-ag2 (no 0) on the graph.

Yes.

In reply to a post by WWWombat:

It may well be network management - but network management by whom, and for what purpose? Not all network management comes down to the plusnet traffic shaping system (which is designed to place various limits on your connection, restricting individual protocol usage at various times of day).

I think all the people reporting the problem are on the current products, which do not have any time of day parameters. Pure traffic type prioritisation.

I was disconnected around 8am along with a number of other users according to the useage graphs (looks on the graph as if there were at least 4 significant instances of drops in user connections since yesterday). I've been struggling to get off the 'bng' gateways where my latency was around 35ms. The speedtest graph also looked odd with initial surges and drops before settling down at an even 36-38Mbps.

I've finally got onto 'ptn-ag03' and my latency has dropped to 24ms and that initial 'bounce' on the speed test graph has been replaced with a steady rise and drop to a straight line still at 36-38Mbps.

In reply to a post by MrSaffron:

It could just be a bug in a bit of software too.

It is *slightly* reminiscent of an issue I had with IDNet which they eventually traced to a mis-configured LNS. I don't think this is the same thing though because in that case single threaded downloads had a more obvious cap whereas what I see when impacted on PN is single threaded speeds all over the shop.

To me it looks like congestion and my current theory is that something is throttling on a 'per stream' basis and multi-threading works around this because it uses multiple streams. So I am inclined to suspect the PN QoS system but why it should feel the need to kick in is a whole other question. My connection was fine last night and as far as I can tell from my TBBQM I'm still on the same gateway that I was on a week ago.

Edited by Andrue (Thu 22-Jan-15 15:54:55)

I don't believe they are segmented.

I suspect the issue will be somewhere between PN and the WMBC Shared handovers at Faraday/Colindale. This would make sense as you can reconnect on the same gateway, but end up on a different handover point or host link to that specific gateway.

The bng gateways are a load of rubbish. I always get poor performance on them.

Somehow I got onto one the other day without noticing, no re-sync), and after a couple of days of normal web pages taking 3-4 seconds to load instead of the normal under one second checked the latency and gateway. Latency was up at 20ms from a normal 12-14ms.

Speed tests however were unaffected.

After two attempts I got onto a non-bgn and everything returned to normal.

I find a disconnection of around a minute usually results in a gateway change. A few seconds doesn't.

I found that the BNGs gave me higher latency (6-9ms to bbc.co.uk) compared to the AGs (3-4ms to bbc.co.uk).

I've recently found though that sometimes I could land on a BNG and have the 3-4ms again. I came to the conclusion that it wasn't the gateways, but the links to them.

I'm really splitting hairs though when talking about a few ms - it makes no difference to me at the end of the day.

The very slow page loads was a pain.

In reply to a post by AndyHCZ:

I don't believe they are segmented.

I suspect the issue will be somewhere between PN and the WMBC Shared handovers at Faraday/Colindale. This would make sense as you can reconnect on the same gateway, but end up on a different handover point or host link to that specific gateway.

Based on my own experience it would seem reasonable to imagine that the BT Wholesale network is somewhat stressed on a few levels.

The issues affecting me were not at the exchange level but a layer deeper into the network, at the metro node, and the fix, while it has kinda worked, was very much a sticking plaster solution.

BT Wholesale have an ongoing programme to upgrade hardware at exchange, metro and core level, and EBD links. With the Christmas bandwidth spike and other things I suspect demand has overtaken those programmes somewhat.

I just disconnected/reconnected and went from bng01 (11ms ping to bbc) to ag02 (16ms ping).
Disconnected/reconnected again, back on bng01 and 11ms.
Opposite from what AndyHCZ saw; but probably his conclusion it isn't the gateways is correct.

I've never had better than 11ms on PlusNet: still much better than the 18-20ms on Infinity 2.

In reply to a post by StephenTodd:

I've never had better than 11ms on PlusNet: still much better than the 18-20ms on Infinity 2.

I'm usually interleaved (winter rain effect) so get 21ms minimum ping to bbc on any gateway :-/

Well the distinct absence of similar complaints from customers from other ISP's that use the very same BTwholesale products , and the same back-haul as plusnet It to me would appear to be a problem that is isolated to plusnet customers (being the issues that are still persistent ) as there where some problems on bt's side that where limited to certain areas ,which for the time being appear resolved, as has been suggested the problem could well lie with where plusnet's network meets bt's network feed, ie some of plusnets endpoints become overwelmed at peak times

As to the reasons ,that isn't paramount (diplomacy eh) but resolving this ASAP and providing updates as to what the problem is and how long before it will be resolved

Edited by tommy45 (Thu 22-Jan-15 20:51:03)

There are three bng01s. ptn, ptw and pcl.

In reply to a post by AndyHCZ:

On Apple, they've moved most of their distribution over to their own CDN network. It might be related or unrelated, but Apple have a fair bit of work to do to catch up with Akamai. I've yet to be able to get fast updates (and this includes with another ISP in a different country).

Always get fast Apple updates here. I just tested and got 72Mb/s average downloading iOS. I'm not on Plusnet or a foreign ISP, though.

Can you see where you're downloading from? Is it uklon5-vip-sx-002.aaplimg.com?

In reply to a post by AndyHCZ:

On Apple, they've moved most of their distribution over to their own CDN network. It might be related or unrelated, but Apple have a fair bit of work to do to catch up with Akamai. I've yet to be able to get fast updates (and this includes with another ISP in a different country).

As per my original post, disconnecting and re-connecting resulted in full line speed for all protocols to all sites..

In reply to a post by AndyHCZ:

Can you see where you're downloading from? Is it uklon5-vip-sx-002.aaplimg.com?

I tried about 10 downloads just now, they flipped between uklon5-vip-sx-001.aaplimg.com, uklon5-vip-sx-003.aaplimg.com and uklon5-vip-sx-005.aaplimg.com and all ran at 72-74Mb/s.

Just done a speed test on TBB and speed was usual 14.8 mbps down but latency was up from 40 to 78ms. Most of the sites I visited still took 2 - 3 seconds to display. No faster, no slower than usual.

Why in your case does a fraction of a second make a difference to pages loading?

I'm usually interleaved (winter rain effect) so get 21ms minimum ping to bbc on any gateway :-/

I used to switch a bit between interleaved and not (usually not); which brought me to 28ms pings on BT.

Soon after moving to PlusNet a neighbour's tree work brought down my line. Opereach replaced it all the way to the top of the house and down to the old junction box. My modem connection graphs have looked very boring since and I don't seem to have too much risk of interleaving. I am on PlusNet 40/20 with a sync speed of over 70Mbps; I wish I could increase my target SNR to make the line even more stable still; my attempts so far (unlocked HG612) have failed.

You can't alter the SNRM on FTTC with the Openreach modem for some reason. I had several goes when I first unlocked mine. You can technically change it, but it screws your connection. It doesn't work like it does on ADSLx.

The other make modem/routers seem to be able to do it. However, SIN 498 expressly says this should not be done.

Interesting, thanks for that.

In reply to a post by StephenTodd:

I'm usually interleaved (winter rain effect) so get 21ms minimum ping to bbc on any gateway :-/

I used to switch a bit between interleaved and not (usually not); which brought me to 28ms pings on BT.

I was pretty much always interleaved on BT as I was installed mid Sept, and it rained that week and so I was interleaved for 18months apart from the odd week. However when I joined plusnet they migrated me and reset everything so I started on 40/10 and support quickly kicked me onto the 80/20 profile which gives me 56 download and nearly 10up. I had 4 months of not being interleaved until the rain arrived, then it came and went, came and went, and eventually in Nov its stuck now. Maybe in the spring I'll get fast path back

The 40/20 option was new after I signed up, and wouldn't help me, as the openreach is still the 80/20 profile.

I am on PlusNet 40/20 with a sync speed of over 70Mbps; I wish I could increase my target SNR to make the line even more stable still; my attempts so far (unlocked HG612) have failed.

I wouldn't try - this isn't ADSL and you don't want the DSLAM in the cabinet applying a limited profile to your line.

You can achieve a similar effect by limiting the sync speed.

In reply to a post by BatBoy:

You can achieve a similar effect by limiting the sync speed.

You've probably mentioned that before; where you can tell the modem to limit the speed it will negotiate and the DSLAM accepts it as part of negotiation, so you get higher SNR margin and thus higher tolerances. Clever.

I dunno if I did but I believe the HG612 supports the appropriate command

1 - each gateway has multiple endpoints, so a single endpoint could get congested and other endpoints still ok so not entire gateway affected,

2 - having contention ratio higher than 1:1 does not mean congestion is inevitable.

In reply to a post by BatBoy:

You can achieve a similar effect by limiting the sync speed.

I had the same question as jchamier, how?
A google search on 'hg612 limit sync speed' comes up with
http://forum.kitz.co.uk/index.php?topic=14262.50;wap2

The new firmware performance of the vdsl/adsl side is the same as before. If you willing to manually limit the HG612 sync speed down to a value not a lot more than the speed you would get on interleaved the HG612 you should maintain fastpath in most cases. Using e.g. "xdslcmd configure --maxDataRate 64000 16000 100000" and aiming for a snrm of about 8-9 rather than 6 reduces my error rates by about a factor of 4-5.

I haven't time to check this out right now (weather too nice outside, and tax forms to fill in) but looks promising.

Post deleted by vimto_girl

uklon5-vip-sx-001.aaplimg.com through uklon5-vip-sx-006.aaplimg.com all downloaded at avg 72-74Mb/s between 8-9pm yesterday (Friday), confirming my general experience

I know you said "I've yet to be able to get fast updates" from Apple on your Plusnet connection.

Can I ask what speeds you see? Are you going to report it to Plusnet?

Just tried "xdslcmd configure --maxDataRate 50000 20000 70000" and save
Rebooted HG612 by unplugging and replugging; still pretty much the same connection speed

Down            Up
max:            74984          22405
path:           74985          19999
SNR (dB):        6.3             7.1

So either it is ignored, or my save didn't work, or ...???
Can anyone tell me the correct way to save configuration, and to reboot/reset or whatever is needed to make it actually happen?

In reply to a post by vimto_girl:

uklon5-vip-sx-001.aaplimg.com through uklon5-vip-sx-006.aaplimg.com all downloaded at avg 72-74Mb/s between 8-9pm yesterday (Friday), confirming my general experience

I know you said "I've yet to be able to get fast updates" from Apple on your Plusnet connection.

Can I ask what speeds you see? Are you going to report it to Plusnet?

I updated about 20 devices with large updates last year, but I've not had anything to update recently. So I cannot really comment now. I was looking for something hosted on one of those CDNs to try as a test, but I couldn't find any links unfortunately.

It's been widely reported about the teething problems of Apple's CDN. It's a huge amount of traffic they need to distribute when they have iOS/OSX updates.

I would hope things are better now - I just need to find something large to test (App store downloads were going through Akamai for me for some reason).

In reply to a post by StephenTodd:

Just tried "xdslcmd configure --maxDataRate 50000 20000 70000" and save
Rebooted HG612 by unplugging and replugging; still pretty much the same connection speed

Down            Up
max:            74984          22405
path:           74985          19999
SNR (dB):        6.3             7.1

So either it is ignored, or my save didn't work, or ...???
Can anyone tell me the correct way to save configuration, and to reboot/reset or whatever is needed to make it actually happen?

Reason: stop mess around with your modem tweak! I believe that FTTC DSLAM had blocked any tweaking. This is why u seeing the same sync rate (no change)

Edited by adslmax (Sat 24-Jan-15 14:43:49)

In reply to a post by adslmax:

Reason: stop mess around with your modem tweak! I believe that FTTC DSLAM had blocked any tweaking. This is why u seeing the same sync rate (no change)

That seems quite likely: it certainly seems to be the case with attempts at SNR tweaks.

I can see various reasons why they want to prevent people using extreme settings that would make things less stable, it seems a shame to prevent conservative settings that would make things more stable.

keep disconnecting/reconnecting the modem so dlm throws a hissy fit and makes your connectoing more stable, unusable but stable anyway this talk of modems ect is diverting us off topic

Edited by tommy45 (Sat 24-Jan-15 15:02:14)

I don't see a Save command.

I do see xdslcmd profile --save

Also with options --show and --restore

I suggest you do a --show and save the listing to a text file first.

The first thing DLM would do would be to turn on interleaving and add 8ms to his latency. He doesn't want either of those effects. He just wants to bring the sync down from 70+Mbps as he's on a 40Mbps (ISP-router capped) package.

Edited by RobertoS (Sat 24-Jan-15 15:13:18)

Then he could ask to be put on a 40/10 product, that would give plenty of spare SNR instead of the 80/20 capped at 40 one he is one now

Edited by tommy45 (Sat 24-Jan-15 16:12:13)

In reply to a post by tommy45:

Then he could ask to be put on a 40/10 product, that would give plenty of spare SNR instead of the 80/20 capped at 40 one he is one now

That would rob him of 10mbps of upload speed. The problem is Openreach don't offer a 40/20 sync profile, and they should.

Openreach should offer the end user a lot of things, such as the option to have DLM disabled should an end user want that but they don't why they didn't supply unlocked modems is another stupid idea

option of no dlm and manual parameter config would be better

Edited by tommy45 (Sat 24-Jan-15 17:13:17)

In reply to a post by tommy45:

Openreach should offer the end user a lot of things, such as the option to have DLM disabled should an end user want that but they don't why they didn't supply unlocked modems is another stupid idea

Wires only will solve that, no Openreach modem, use any VDSL router you like. Downside is lots of different modems in use for the DSLAM to manage could mean everyone gets lower speeds.

option of no dlm and manual parameter config would be better

With VDSL being more of a cooperation than ADSL its likely that would mean everyone loses speed. No thanks.

Openreach should have enforced their modem, and supported a basic web interface/display of statistics, and forced all ISPs to use it. Then it would have been similar to the VirginMedia cable modem - and the router manufacturers could concentrate on making good routers with ethernet ports.

Thanks for those helpful comments. It turns out that xdslcmd profile --show does not show very much,
but xdslcmd info --cfg shows the state of the configuration and confirms that my earlier configuration attempt was not saved.

And profile --save gives

# xdslcmd profile --save
xdslcmd --save is only supported from Linux404 on ward

The save that did something was one level higher, to the ATP prompt. However, it didn't seem to save the xdslcmd configuration.

# exit
ATP>save
Successed in saving config datas

I'm giving up for now. My line doesn't seem to be in significant danger of getting interleaved (unless I play with the modem too much); but it does seem a shame not to be able to reduce that danger considerably more.

I can't see how or why speeds would drop because of having different modems as long as those modems comply with the relevant spec's then i don't see this causing problems for anyone else should some choose to buy their own modem, and i can't see how disabling dlm would affect speeds for anyone than the end users who choose to have it disabled manual configs would be fastpath or interleave, increase in SNR or allow hard capping of sync speeds,

Edited by tommy45 (Sat 24-Jan-15 17:47:21)

I'm amazed you aren't CEO of a major ISP Tommy . You are obviously an ace at xDSLx system design and marketing.

Which ISP are you with at the moment?

All I'm talking about is Openreach allowing ISP's = end users some control over connections because DLM simply doesn't work well for some infact there was some talk regarding this happening some time ago but so far that's all it was talk
Openreach do allow use of other modems already with wires only FTTC installs I a few years time it's likely that FTTC won't be much different than ADSL except for the boost in speeds of course

by rebooting you lost the setting, it isnt stored.

when you run the command it will initiate a new sync at those settings, but only last for one connection.

In reply to a post by Chrysalis:

by rebooting you lost the setting, it isnt stored.

when you run the command it will initiate a new sync at those settings, but only last for one connection.

Thank you very much.

xdslcmd configure --maxDataRate 50000 25000 75000 didn't seem to force a resync by itself.
But xdslcmd start --up --maxDataRate 50000 25000 75000 did the trick.

I am now seeing a 14.5 SNR, which should be pretty robust against most fluctuations and reduce risk of getting put on interleaving.
As I expected, speedtests are unchanged. http://www.thinkbroadband.com/speedtest/results.html...
BT wholesale showing 48.4/20 profile, 38.25/17.38 speedtests.

Down            Up
max:            75080          22355
path:           49999          19999
SNR (dB):        14.5            7.1

R:              16              16
N:              254             254
I:              254             127

INP:            0.00            0.00
D:              1               1
delay:          0               0

Well done .

Thank you Roberto and thankyou everyone who has helped here. I have been trying this on and off for a few months now since joining PlusNet. It is a uniquely PlusNet issue because of their curious 40/20 package. I will be posting on the forum there soon as well in case it helps anyone else.

I think this is a good example where forum collaboration really helps. Partly because of lack of HG612 CLI documentation it would have been a very long time before any one of us alone had come up with an answer.

Edited by StephenTodd (Mon 26-Jan-15 11:13:59)

In reply to a post by StephenTodd:

Thank you very much.

xdslcmd configure --maxDataRate 50000 25000 75000 didn't seem to force a resync by itself.
But xdslcmd start --up --maxDataRate 50000 25000 75000 did the trick.

I am now seeing a 14.5 SNR, which should be pretty robust against most fluctuations and reduce risk of getting put on interleaving.
As I expected, speedtests are unchanged. http://www.thinkbroadband.com/speedtest/results.html...
BT wholesale showing 48.4/20 profile, 38.25/17.38 speedtests.

Down            Up
max:            75080          22355
path:           49999          19999
SNR (dB):        14.5            7.1

R:              16              16
N:              254             254
I:              254             127

INP:            0.00            0.00
D:              1               1
delay:          0               0

I was very surprise this tweak does work in your favour! But it a question of time that DLM might adjusted it back to where they used to be in due course!

In reply to a post by adslmax:

I was very surprise this tweak does work in your favour! But it a question of time that DLM might adjusted it back to where they used to be in due course!

It will be interesting to see.

From Chrysalis' comment the configuration settings will certainly get lost if the modem reboots.
I suspect that the xdslcmd configure --maxDataRate 50000 25000 75000 part means it will use those figures for resyncing until then.

It may be that DLM will decide I can go faster, and so schedule early morning resyncs.
However, as it looks as if that configuration of the modem will mean that the resyncs still sync at the modem limited speed.
I don't think any of knows enough about the system that we feel we could give reliable predictions about how it will behave.

In ADSLx days I found unsaveable SNRM tweaks survived re-syncs from any cause, but not reboots.

yes if the resync is not initiated by the modem it may survive I am just not sure, defenitly wont survive a reboot.

This thread highlights why I think a 40/10 wholesale package is better for those who only want 40mbit, as it grants extra stability.

Edited by Chrysalis (Thu 29-Jan-15 17:34:23)

In reply to a post by Chrysalis:

This thread highlights why I think a 40/10 wholesale package is better for those who only want 40mbit, as it grants extra stability.

That's what DLM is supposed to be for. I'm sure PN did their trials and they indicated that this kind of thing is the exception rather than the rule.

In reply to a post by Chrysalis:

This thread highlights why I think a 40/10 wholesale package is better for those who only want 40mbit, as it grants extra stability.

who only want 40mbit download and only want 20mbps upload.

It looks as if my change is sticking, so far at least. Downstream errored seconds are down for around 100 per day to around 10 per day. Though I must admit that my line appeared to be perfectly stable even at the 70Mbps 6dbSNR setting.

except stability via a nice snrm buffer is preferable to added artificial latency.

I didn't notice at first that you were replying to an earlier post and not my more recent one. Still, most of what I say here still applies.

In reply to a post by Chrysalis:

except stability via a nice snrm buffer is preferable to added artificial latency.

Exactly why I wanted (and finally managed) to change my sync speed; so that it syncs with higher SNR. This did not have any immediate effect on latency, but reduced the risk of the kind of errors that could cause DLM to step in and add interleaving and thus increase latency.

My attempts to change it the other way around (configuring higher target SNR thus forcing lower sync speed) did not work; that is why I tried configuring lower sync (thus forcing higher SNR), which eventually did work. I agree that having the 40/10 option at the lower BT (retail, openreach, never quite sure) level would have had the same effect (more permanently) on download, but it would have seriously compromised my upload.

Summary:
For anyone who cannot get or does not want more than 10 upload, the 40/10 option is the way to go.
For people who are happy with the PlusNet 40/20 and do use >10 upload, the configuration changes others helped me find are the way to go (till someone suggests better).

Edited by StephenTodd (Fri 30-Jan-15 11:15:15)

Plusnet doesn't have (officially) a currently orderable 40/10 option. Few will rule it out because of that .

I'm on 14 down and 0.9 up and I'm more than happy with my speeds.

I'm on adsl and get 13M.

Mostly i use my vpn, my throughput varies from 35k to 75k on the 1Gb test file on this site

if I do not use my vpn I get 1.4Mb.

Congestion would throttle both equally.

It could be the vpn provider, and have tried other countries but the all have the same speed. To be honest every time there is a slight issue the provider informs people in advance, or if that is not possible, at the time.

While I am not against the principle of traffic management as it enables fairer sharing of bandwidth, i am not in favour of being cut off and letting someone else have all of my bandwidth.

I must say p2p downloads for me seem to be much slower since just before christmas I think. I'm on fibre unlimited and use to get around 7MB/s - 8MB/s but for a while now it's more like 3MB/s at most.

Chrome seems to be very slow and unresponsive as well but I think that's chrome fault since the update. Can't find a way to downgrade that though unfortunately.

Try a different browser?

Yes, like I say I think there is an issue with the latest version of Chrome.

But as I mentioned p2p has been slower for a while like the OP stated which is a different issue.

I was wondering if there are two problems though. Some slowdown as before, but much worse since the Chrome update. That's why I suggested trying a different one. Just to see.

It's two different issues as firefox is fine, just annoys me that chrome has gone pair shaped with the update and can't get the old one back.

When you say Firefox is fine, do you mean the 7-8MBps you used to have, or lower but still well above the Chrome 3MBps?

Crossed wires, the 7MB-8MB I was talking about was for p2p (uTorrent) not the browser which seems to have plummeted over the last month which I think is due to a change in the traffic management.

The chrome issue I feel is different, it seems slow to respond but I've just done a test download using the files on here (the 512mb file) which averaged at around 3MB/s - 4MB/s not the usual 8MB/s.

I don't know if this is related to p2p aspects (seems unlikely), but a suggestion on Chrome slowness is to remove the Hardware Acceleration option.
http://www.cnet.com/uk/how-to/a-quick-fix-for-your-s...

My Chrome was still pretty snappy anyway (new machine recently after 6 years), but I think this may have helped a tiny bit.
Seems pretty odd, but several others claim it helped, so worth a try ....

Thanks but that setting is already off.

I think it probably is unrelated I just wasn't sure.

I saw RobertoS mention something about the gateway's bnc (i think) not being very good, I've managed to reconnect to pcl-ag04 so I will see how that goes for a while for p2p.

bgn gateways don't do IPv6, which is madness seeing as all the older ones did and these are new. They also seem to be low performance/throughput.

Some of the older ones are better on pings and BQM, but recently may be slow on browsing. My norm is 12-14ms, currently on pcl-ag06 with 20ms BQM and 22ms to bbc.co.uk, with snappy browsing. as opposed to a recent "ptn-ag01 12ms (V laggy)". ptn-ag01 between 20 and 29 October gave me the same 12ms but was fast browsing. That "V laggy" was several seconds for normal page loads.

Tried this, Stephen, but it made no difference. Just in the past few days whilst some websiites seem to load at usual speed some are ssslllooowww - in fact with the revolving doughnut going anti-clockwise!
Odd, but I want to stick with GC rather than IE11

apparently ipv6 does work on them but they dont dish out the ip via dhcpv6. This is according to andyH on the plusnet forums.

LOL
I haven't seen that, (not been looking), but doesn't that mean they don't work on IPv6?

Ah!

But what if I take the IP address I assigned to the BQM and fix it in my router? Is that covered wherever you are quoting from?
...
Just done that but landed on ptw-ag03. Will try another gateway change in a minute.

Edit - now on ptn-bng02. Let's see how it goes!

Nah ! IP address showing in the relevant fields but only got the IPv4 connection now. Hugely improved ping! 20ms >> 11ms.

Edited by RobertoS (Fri 06-Feb-15 00:12:21)