Poor data transfer rate in general, streaming issues in particular

[#1]

Ok, I really have just about had enough of this stupid bl**dy nonsense now  
Streaming performance had been somewhat better (although by no means consistently right) on the few occasions that I've tried to use it recently but everything was definitely back to absolutely dire and totally unusable again yesterday.  Whilst it definitely appeared that the general cap or rate-limit on data transfer between 1600+ and 0000- had in fact been removed earlier in the month, there has still been something "not quite right" (to say the very least )with iplayer traffic in general and tonight it very much looks to me that the totally unreasonable and completely indefensible 2Mb/s cap is well and truly back in place again.
TBH, I really can't help feeling that for around a year now ever since my enforced and unwanted so-called 'upgrade' to ASDL2,  PN have been *very* happy to regularly direct debit the cost of a high spec premium price product from my Bank A/C whilst regularly supplying me with what is quite clearly and regularly proven to be a minimum spec 'value' style product at best with all the associated additional usage restrictions that come along with such a package. I'm no lawyer but I would very much suggest to anyone who can be bothered to read this that invoicing for a premium price product when knowingly supplying something very more akin to a 'value' style product seems like a pretty d@mn good definition of fraud !!!
I do not know or care whether this is a 100% PN issue or an alleged issue with a chosen supplier or sub-contractor.  I similarly do not care how small the number of customers potentially also being affected is either.  What I most certainly do care about is always being one of the often alleged "very small number of customers" and that trying to get PN to even accept the possibility that there *might* be a problem for which they are 100% responsible for is always such a major battle. A battle usually necessitating many hours/days/weeks/months of effort on my part continually trying to find some way to demonstrate and prove that all is not well until the penny finally drops and PN eventually do something vaguely constructive to resolve an issue completely. I do not waste my valuable time going round looking for weirdo problems like this yet I stumble across many.  Neither am I an unpaid IT Consultant, Network Analyst or some other fault-finder under contract to PN.  In fact  quite the opposite, I am merely a customer who is paying PN to provide and maintain the contracted service. All I want is the service I pay handsomely for to work in accordance with the specifications as and when I wish to use it ... or if there is the expected but very occasional unforeseen problem, for it be addressed and fixed in a timely manner. Unfortunately, the reality appears to be that I am regularly finding some weird issue or another that is quite clearly a fundamental PN problem that PN apparently do not know about and/or seem quite happy to remain in complete denial about despite there usually being a significant amount of evidence to suggest they have customer affecting issues needing a proper and long-term resolution as a matter of urgency.
How can a "very small number of customers" and more importantly, ME in particular, somehow keep being mysteriously assigned an incorrect profile despite there being no A/C or other relevant changes ?  How can such an obvious albeit intermittent issue with (in this particular instance) iplayer only be affecting me or an alleged "very small number of customers" in any case ?  How can it possibly be that iplayer data is apparently being throttled to death somewhere other than on the PN network at certain times on certain occasions despite iplayer diagnostics sometimes showing no BW issues whatsoever ?  And finally, how exactly can this NOT be an issue that is 100% down to PN to investigate and resolve when the relatively simple act of terminating the PPP connection and re-establishing it via a different gateway quite often (but by no means always) resolves or at the very least significantly reduces the severity of the apparent issue in the short term ?
Here's some more evidence from last night somewhere around 2000 hours:


The netmeter graph above clearly shows a totally unacceptable and quite obviously throttled streaming data transfer rate that eventually resulted in an "insufficient bandwidth to stream this programme" error message meaning that playback at even the absolute minimum quality was totally impossible.  However,  what can also clearly be seen on this occasion is that a diagnostic test conducted immediately after the stream was terminated showed data was actually arriving at close to the maximum possible rate indicating that the connection would even theoretically support HD playback !
Repeated attempts to restart playback made no particular difference on this occasion. The data transfer rate was always exceptionally and quite unacceptably low meaning hiccups or buffering at best and termination with an error message at worst.  On various other occasions, pausing then restarting playback has led to the data stream restarting at a much more appropriate rate. However, terminating PPP and allowing playback to subsequently continue automatically just a few seconds later via a different gateway once again resolved the apparent issue in the very same way as it has been seen to do on several previous occasions.  This can clearly be seen in the following netmeter graph:


Despite the slightly poorer diagnostic test results on the new gateway, the data stream that had previously been terminated due to insufficient bandwidth restarted at a rate very much closer to what I would consider to be 'normal' for iplayer at this time of the day.

However, as for performance tonight, well it's even worse than yesterday I'm afraid. Despite still being connected to the very same gateway that was providing near-normal performance last night, I now appear to be having everything rate-limited to around 2Mb/s again ... i.e. right back to exactly as it was when I started this thread almost a month ago.  I have absolutely no idea whether it has been like this all evening or when this started regularly happening again but my connection was most definitely rate-limited between 2000 hours and midnight tonight after which a more 'normal' service resumed.


The netmeter graph above initially shows iplayer trying to stream data followed by the iplayer diagnostic test followed by a generic speed test. As can be seen, average data rate is ~2Mb/s and the connection is almost certainly being inappropriately and quite unreasonably rate-limited by PN again for reason or reasons various.  As was the case last month, there is no good or even remotely valid reason why restrictions of any kind should be in place.
In addition, here's the speed test results as further evidence of the back-to-square-one situation:


Sooooooooo ... I think I need to ask once again:  How on earth can this crazy on-going situation possibly not be an issue for which PN are in some way 100% responsible for ?   It's also interesting to note that just to make life even more interesting, there appears to be at least two fundamental problems here:  Firstly, data transfer is intermittently being rate-limited to ~2MB/s on various occasions and/or at various times of the day without there being any valid reason for doing so. Secondly, iplayer streaming data in particular is intermittently being quite unreasonably restricted to various seemingly random data transfer rates that are well below what is specified and should be expected for my A/C type when there is no line fault or equipment/network fault at my end of the line.  In short ... the service being supplied by PN is frequently not doing anything remotely like what it says on the tin and hasn't been for a VERY significant period of time.

PS: The iplayer streaming traffic always appears to be being consistently classed as $80 so this would not appear to be an obvious data classification issue.  
PPS: Unfortunately, the PSTN Cease Order was just another PN and/or BT c*ck up I'm afraid. Much as I would dearly love to have both PN and BT off my back and out of my life for good after 'enjoying' the often highly dubious quality service supplied at great expense for around 15 and 25 years respectively, it was regrettably nothing whatsoever to do with me. Quite how an unknown 3rd party can initiate the transfer of a line to alternative provider leading to all existing contracts, A/Cs and services in my name which had been paid for in advance ultimately being terminated by default is totally beyond me !! This is especially so when BT were apparently only able to talk to the A/C holder in person about the situation and persistently refused to even discuss the matter with someone calling them on my behalf (let alone do anything even remotely helpful to resolve the error) due to security, privacy and data protection issues needless to say  
PPPS: I'm reasonably certain now that I've finally twigged what's mostly likely to be going here and this would explain BOTH aspects of the apparent problem. If I'm even partially right then this is definitely not just affecting me at all but is very much more of a fundamental c*ck up problem affecting various other customers to a greater or lesser extent dependant on their A/C type, general pattern of usage and the time of month etc.  It will be *VERY* interesting indeed to see if the fully qualified experts who quite obviously should be residing in PN Towers (and who are of course ultimately on the receiving end of a significant part of my monthly subscription by way of a contribution to their monthly salary) eventually come to the same or a similar conclusion to that of a totally unpaid, untrained and unqualified customer following their own detailed investigations  Despite it being ridiculously difficult if not virtually impossible for me to prove almost beyond doubt exactly what's going on here, I am fully expecting to be able to provide some more info shortly when I've hopefully come up with way more than sufficient almost irrefutable evidence to get someone a d@mn good slap if they don't 'fess up about a known issue and/or get their a***e into gear and sort this before I make what I think is likely to be a way-too-close-for-comfort guess along with providing documentary evidence to support it  

[#2]

Have you tried asking them to give you the Pro add-on for free until they resolve the issue?

[#3]

A totally excellent browsing and streaming performance tonight ...


... NOT !!!  Nearly went rummaging for Ye Olde 1200 baud 56K Modem as it could perhaps have done a better job than my 8Mb/s broadband connection was managing.  Needless to say, it was pretty much like that ALL evening but everything was instantly back to 'normal' again at midnight of course.  Anyways, more info as promised below - very long and very boring so probably not worth reading any further unless you have a vested interest in this particular problem.

PLEASE NOTE that this very lengthy post may not be 100% correct or indeed in any way correct at all for that matter but it is my best guess as to what's going here based on what I believe is a reasonable amount of supporting evidence. However, the ONLY sensible and appropriate way to diagnose and resolve any weirdo issue like this is by someone who knows exactly what they're doing looking at things in detail at the PN end and then by having an intimate knowledge of what should be happening, compare that to what is actually happening. I quite obviously cannot do that in any respect, I don't even know what PN are trying to do let alone how they go about attempting to achieve it. The very best I can do is postulate a scenario that appears to explain exactly what is being experienced and then wait to see whether it results in a short delay followed by mucho embarrassed squirming or a swift, comprehensive and well justified denial.  My money is obviously on the former needless to say or I wouldn't be posting this at all but I obviously do fully accept that I may be completely wrong ... only time will tell and all that.
iplayer (in common with 4oD and ITVplayer etc.) does not rely solely on streaming it's own data from a single source when users request playback of a particular programme. The choice of source for a particular data stream is not only dynamic but generally (if not always) the service is provided by a 3rd party host such as Akamai or Limelight et al. The intention being to provide each and every user with the fastest possible data rate dependant on the characteristics of their specific connection, their location and of course, to load balance servers and so on to generally ensure that the best possible quality service is provided to all users.  iplayer (also in common with 4oD and ITVplayer etc.) does not rely solely on a single 3rd party to host the data and nor does it rely solely on streaming data in any one particular manner either. iplayer routinely uses both Akamai and Limelight (and maybe others) as 3rd party hosts and routinely streams real-time data using a variety of different protocols in addition to using the perhaps most common RTMP (Macromedia/Adobe Flash) protocol. iplayer (in common with 4oD and ITV player etc.) no doubt pay handsomely for 3rd parties to host their data and for attempting to provide all users with the best possible quality service. In contrast, PN have historically always done their very best to quite intentionally and often totally unreasonably throttle or otherwise control, manipulate and generally degrade the service provided by various 'big boy' content providers and/or 3rd party hosts thereby negating many (if not all) of the intended benefits to individual users that the service provider is actually paying the 3rd parties to provide their customers with.  PN have also historically been found to be screwing up bigtime in this respect on a fairly regular basis and they have to all intents and purposes previously been found to be preventing such services from working at all never mind just degrading performance to a low level as and when they see fit to do so.
iplayer appears to be streaming data using HTTP via Limelight on a very regular basis in addition to the perhaps more common method of RTMP via Akamai. I believe that it is this Limelight HTTP data in particular that is being totally screwed up by mis-management and/or mis-configuration of the PN Traffic Management system. It would appear to me that such data streams are being treated as plain old HTTP data (i.e. web traffic) as opposed to real-time streaming data. Whilst web traffic and streaming traffic are both generally classified as "gold" I would very strongly suspect that not all "gold" traffic is created equal !  Subsequent to the initial data classification, I think that I would expect to find "gold" web traffic being processed, queued, routed and/or otherwise further manipulated quite differently to "gold" streaming traffic from a very well known service such as iplayer, 4oD or ITVplayer.
I would suggest that the end result of this mis-management of iplayer data streams probably means that not only is a vast quantity of streaming data effectively swamping general web traffic on the PN network but such data is also being quite intentionally throttled to death by PN because it is being considered by them as being just routine data from a 3rd party host rather than being the real-time iplayer data stream that it actually is.  The effects of this are often a totally unusable streaming data, poor browsing performance in general and no doubt packet loss and/or errors galore due to grossly overloaded data queues and/or data pathways.
IN OTHER WORDS, EXACTLY WHAT IS BEING EXPERIENECD ON A REGULAR BASIS AND HAS BEEN INTERMITTENTLY FOR A VERY SIGNIFICANT PERIOD OF TIME.
All in all, with vast amounts of data in the 'wrong' place being sent down the 'wrong' path and generally being handled in the 'wrong' manner, nothing much works as it should do (no matter how much tweaking is done on the quiet) until such time as the amount of 'unexpected' traffic falls to an insignificant level compared to the traffic levels normally expected and/or the network in general is very quiet.  
In my experience, iplayer HTTP data streams never work particularly sensibly at all and especially not during peak times. They are always highly erratic and almost always throttled to an unacceptably low peak data rate. During peak times, the average data rate is often so low (or the stream contains such massive breaks, stalls or data errors) that the service is 100% unusable for long periods of time. Even when the data rate is high enough to actually support minimum quality playback, the breaks and general jitter in the data stream due to it not being prioritised appropriately mean that it is often virtually unwatchable. In addition to this, web browsing performance is often very poor as well with long(ish) delays or unexplained pauses in page loading, pages not loading completely, websites generally appearing to not be working properly and so on presumably due to network or data path loading issues and the associated packet loss, an indication of which can quite often be seen by remote monitoring. The effects can also often be seen even when performing a generic speed test despite the fact that PN almost certainly attempts to boost the priority of speed test data (or generally attempts to fiddle the results in some other way !) in order to try and mask any network loading issues there may be. What can usually be seen is the data rate is highly erratic, going up and down like a fiddler's elbow.
I WOULD IMAGINE THAT ALL OF THE ABOVE IS MOST LIKELY TO BE APPLICABLE TO ALMOST ALL USERS - iplayer HTTP streaming data does not appear to be being handled appropriately at all and this most likely applies to anyone who is unfortunate enough to want/need to use it. But don't forget that not all users are created equal of course !  Package type, connection speed/quality, gateway and location are all highly relevant not to mention again that the data type and source used by iplayer at the time of hitting the 'play' button is assigned dynamically.  Some users may not ever be seeing potentially problematic data streams and some users may not be experiencing problems when trying to view a problematic data steam in any case for any one or more of loads of different valid reasons. It's all a bit of a lottery really but that doesn't mean that the fundamental problem isn't there, just that it's not always 100% obvious at the time ... unless you're majorly unlucky as I very much appear to be on a very regular basis
In my specific case there would also appear to be a further problem just to compound what seems to be a general Traffic (Mis-)Management issue. At various times on various random days and/or at certain times of the month,  my service is apparently being quite obviously and totally unreasonably rate-limited to ~2Mb/s at best for no good or even vaguely valid reason.  Whatever method is being used to rate-limit, it's not very good to say the least either. Instantaneous data rate is highly erratic (sometimes zero for periods of time, sometimes near maximum) so almost always all over the place and yet always averaging out no matter what to ~2Mb/s and always returning to near 'normal' around midnight.  Apart from the very obvious issues that this causes, this intermittent yet persistent long-term problem effectively makes the general Traffic Management problem several orders of magnitude worse and can render my connection pretty much unusable for pretty much anything data intensive except during off-peak hours and/or at the quietest of times.  I cannot for one minute believe that this is just a highly unusual one-off random issue that is only affecting my service.  Apart from anything else it has been seen many times and always for no good reason and without any explanation being forthcoming from PN. It almost certainly has to be a general issue but it is probably only affecting other users with a similar A/C type to mine meaning only a small percentage of the userbase. However, whatever this additional problem actually is and however PN are managing to screw things up, one thing is for absolute certain. Recent examples are not isolated incidents, the problem definitely hasn't been fixed for good and it has been occurring at various times for more than a year now. There is quite simply no other plausible reason that I can think of to explain why data transfer rates in general can suddenly appear to be ~2Mb/s on average (whenever things don't feel right and I bother to investigate) no matter how erratic the data stream being examined is at the time and no matter what the IP profile(s) may be other than because PN are quite intentionally trying to rate-limit the connection in general to some unacceptably low level.  
In my book, "line speed" means exactly what it says on the tin - the fundamental unrestricted speed that the line is actually capable of supporting consistently and reliably. i.e. a function of synch speed taking into account all necessary transmission overheads and any relevant essential profiling.  It most certainly DOES NOT mean any seemingly random maximum data rate at which PN intentionally choose to rate-limit all data sent up/down the line. When the specification for my A/C clearly states streaming data is prioritised and supplied at Line Speed I expect to see data at or at least close to the maximum supported rate with minimal jitter and no significant breaks at all times other than when the source is clearly and quite intentionally sending data at some other lower rate or is experiencing fundamental server issues. In the case of the current iplayer issue and various similar 4oD issues previously, I obviously can't prove it but I would strongly suggest that it is almost without doubt that the data source would be quite capable of sending data at a much higher sustainable rate than my connection could actually support. If the speed issues were a server issue of just about any kind then not only would it have been dealt with by now but there would have been no end of other people (not just 1 or more PN customers) complaining about poor performance and/or an unusable iplayer service.
Finally, it should be noted that some iplayer traffic is without doubt being logged and presented via the portal usage page as web traffic. Apart from the (with hindsight) very obvious strange looking and inexplicable usage figures, several separate tests have now positively confirmed that a very significant quantity of iplayer streaming data is being logged as web traffic.  This doesn't seem in any way strange now considering it would appear that very significant quantities of iplayer streaming data is being delivered using HTTP and is apparently not being classified correctly by PN from a Traffic Management point of view either.  As I think I said very much earlier in this thread or perhaps in another very similar recent thread: Mr.Data was murdered in the Data Centre by Mr.Plusnet with an Ellacoya ... so I very much believe that I win this game of Cluedo hands down ... unless you know differently and can prove it of course  
I must say that I'm finding it incredibly hard to believe that all of this (assuming it's correct or at least somewhere remotely close to reality) isn't fairly obvious from just a quicky looky see at how things are performing in general at the PN end. Surely PN can see HTTP data from iplayer when perhaps HTTP data is not being expected ?  Surely PN can see large amounts of streaming data from unexpected sources if that's where the problem really lies ? Surely PN can see much higher than 'normal' amounts of HTTP traffic coincident with somewhat reduced amounts of RTMP traffic ?  Surely *some* form of network monitoring indicates that traffic levels or distribution of traffic in general is just looking way more than a bit odd to say the very least ?  I honestly believe that it ought to be pretty obvious that "something isn't quite as it should be" simply from taking a quick look at data logs, flows, queues and any other relevant network performance data that might be readily available in PN Towers.  So why am I as a mere customer who knows absolutely nothing about how PN actually perform their Traffic Management once again having to try to guess what might be going on and then attempt to find some way of justifying the theory simply to get PN to take reasonable notice of what looks to me to be almost irrefutable evidence of something definitely not quite right and it's almost certainly a problem on the PN network ?

PS: Can anyone imagine just how much 'fun' this would be if I'd raised a ticket and tried to get anyone to even begin to understand the issue    The last truly technical issue I raised by ticket went on for the best part of 9 months without getting anywhere even remotely close to any particularly sensible/relevant responses let alone a resolution so I just gave up in the end and came up with a workaround to mitigate the effect of PN/BT fundamental non-compliance issues.  

[#4]

Hi Mikeb,
We've identified an issue with Premier and Plus accounts where customers are being restricted during peak times due to an anomaly with usage reporting. This is because of daylight saving time changes. Originally it was thought that once a customer's account was fixed it wouldn't re-occur, or that this would be rectified on their next billing date. When we started to see this affect customers after their billing date, further investigation revealed that back end usage between midnight and 1am was being classed as 11pm-midnight and 4pm-5pm being classed as 3pm-4pm. As traffic management and VMBU usage are populated separately this meant that VMBU was showing the correct data and therefore made it harder to spot. Also, when customers reported slow speeds this tended to be during the following day, so traffic management profiles we not obvious as the culprit. It's not until after 4pm that the incorrect service offer is being applied, so during the day this will appear to be correct.
All that said, a fix is due to be rolled in the early hours of tomorrow morning, as part of our weekly roll-out of system improvements. If for some reason that wasn't to go ahead we can manually fix affected accounts.
Jojo

[#5]

Woah, that's a big post.  I'll try and read it.

[#6]

I'll précis it for you - Mike was right you are assigning the wrong profile.

[#7]

Quote from: mikeb

The very best I can do is postulate a scenario that appears to explain exactly what is being experienced and then wait to see whether it results in a short delay followed by mucho embarrassed squirming or a swift, comprehensive and well justified denial.  My money is obviously on the former needless to say or I wouldn't be posting this at all but I obviously do fully accept that I may be completely wrong ... only time will tell and all that.

I'd like to think we own up to our mistakes.   I'm not denying there is often some embarrassed squirming at the same time though...

Quote from: mikeb

In contrast, PN have historically always done their very best to quite intentionally and often totally unreasonably throttle or otherwise control, manipulate and generally degrade the service provided by various 'big boy' content providers and/or 3rd party hosts thereby negating many (if not all) of the intended benefits to individual users that the service provider is actually paying the 3rd parties to provide their customers with.

Er... we do?   Is that just you being disgruntled or do you actually believe it?   I feel that's a little unfair tbh.

Quote from: mikeb

PN have also historically been found to be screwing up bigtime in this respect on a fairly regular basis and they have to all intents and purposes previously been found to be preventing such services from working at all never mind just degrading performance to a low level as and when they see fit to do so.

Ditto.   The nature of what we do with Traffic Management does sometimes lead to cock ups (like the problem you are experiencing right now), but we believe it's worth it due to the good prices we can pass on because of it.  Also, we try and be responsive and apologetic when we do mess it up.  It's a shame you've still got this issue, and tbh, I'm quite unhappy we haven't resolved it yet as it's been on going for some time.

Quote from: mikeb

iplayer appears to be streaming data using HTTP via Limelight on a very regular basis in addition to the perhaps more common method of RTMP via Akamai. I believe that it is this Limelight HTTP data in particular that is being totally screwed up by mis-management and/or mis-configuration of the PN Traffic Management system. It would appear to me that such data streams are being treated as plain old HTTP data (i.e. web traffic) as opposed to real-time streaming data. Whilst web traffic and streaming traffic are both generally classified as "gold" I would very strongly suspect that not all "gold" traffic is created equal !  Subsequent to the initial data classification, I think that I would expect to find "gold" web traffic being processed, queued, routed and/or otherwise further manipulated quite differently to "gold" streaming traffic from a very well known service such as iplayer, 4oD or ITVplayer.

Gold is gold (unless it's Gold2, but there is hardly anything in there).   It's possible that some misidentification could result in some of your traffic going into a queue with a lower priority (after all this was exactly what was happening with your 4OD traffic earlier this year) but a wireshark capture will highlight that.  If you aren't seeing x80 in the wireshark, it's not in gold and could be being deprioritised.

Quote from: mikeb

I would suggest that the end result of this mis-management of iplayer data streams probably means that not only is a vast quantity of streaming data effectively swamping general web traffic on the PN network but such data is also being quite intentionally throttled to death by PN because it is being considered by them as being just routine data from a 3rd party host rather than being the real-time iplayer data stream that it actually is.  The effects of this are often a totally unusable streaming data, poor browsing performance in general and no doubt packet loss and/or errors galore due to grossly overloaded data queues and/or data pathways.

It's actually a good theory, but streaming and normal webtraffic is prioritised and treated the same way, so even if your sources are being identified as http instead of streaming (which I believe does happen a little, hence the difference in VMBU) you shouldn't see a problem.

Quote from: mikeb

In my experience, iplayer HTTP data streams never work particularly sensibly at all and especially not during peak times. They are always highly erratic and almost always throttled to an unacceptably low peak data rate. During peak times, the average data rate is often so low (or the stream contains such massive breaks, stalls or data errors) that the service is 100% unusable for long periods of time. Even when the data rate is high enough to actually support minimum quality playback, the breaks and general jitter in the data stream due to it not being prioritised appropriately mean that it is often virtually unwatchable. In addition to this, web browsing performance is often very poor as well with long(ish) delays or unexplained pauses in page loading, pages not loading completely, websites generally appearing to not be working properly and so on presumably due to network or data path loading issues and the associated packet loss, an indication of which can quite often be seen by remote monitoring. The effects can also often be seen even when performing a generic speed test despite the fact that PN almost certainly attempts to boost the priority of speed test data (or generally attempts to fiddle the results in some other way !) in order to try and mask any network loading issues there may be. What can usually be seen is the data rate is highly erratic, going up and down like a fiddler's elbow.

This is all really concerning.   Is this ALL THE TIME or just when you have these throtted patches as demonstrated in your graphs?  If so, then we really need to dig deeper here, as that is NOT what is represented by the rest of the customer base.   I'd appreciate it if any other readers of the thread could respond to this to verify?
FYI, speed tests are prioritised as gold, so they should come out with the same results as normal web traffic, giving you a good view of how congested we are.  We felt this was the fairest way of representing our performance.  The BT speedtester is an exception to this and prioritised as titanium so that the results are indicating what the line is performing at. This is so we can correctly use it in Fault Diagnostics.

Quote from: mikeb

I WOULD IMAGINE THAT ALL OF THE ABOVE IS MOST LIKELY TO BE APPLICABLE TO ALMOST ALL USERS - iplayer HTTP streaming data does not appear to be being handled appropriately at all and this most likely applies to anyone who is unfortunate enough to want/need to use it. But don't forget that not all users are created equal of course !  Package type, connection speed/quality, gateway and location are all highly relevant not to mention again that the data type and source used by iplayer at the time of hitting the 'play' button is assigned dynamically.  Some users may not ever be seeing potentially problematic data streams and some users may not be experiencing problems when trying to view a problematic data steam in any case for any one or more of loads of different valid reasons. It's all a bit of a lottery really but that doesn't mean that the fundamental problem isn't there, just that it's not always 100% obvious at the time ... unless you're majorly unlucky as I very much appear to be on a very regular basis

The way we identify traffic is the same across packages.  So Iplayer on Plus = iplayer on Extra etc.  Obviously there are differences in how we treated the identified traffic on a per package basis, but if you are seeing problems with iplayer on one package, you should see it on another package (Pro/Pro Addon being an exception here due to it putting everything in Titanium and Gold)

Quote from: mikeb

In my specific case there would also appear to be a further problem just to compound what seems to be a general Traffic (Mis-)Management issue. At various times on various random days and/or at certain times of the month,  my service is apparently being quite obviously and totally unreasonably rate-limited to ~2Mb/s at best for no good or even vaguely valid reason.  Whatever method is being used to rate-limit, it's not very good to say the least either. Instantaneous data rate is highly erratic (sometimes zero for periods of time, sometimes near maximum) so almost always all over the place and yet always averaging out no matter what to ~2Mb/s and always returning to near 'normal' around midnight.

I believe this is the problem we have with the DST stuff causing your management to be misapplied.

Quote from: mikeb

It almost certainly has to be a general issue but it is probably only affecting other users with a similar A/C type to mine meaning only a small percentage of the userbase. However, whatever this additional problem actually is and however PN are managing to screw things up, one thing is for absolute certain. Recent examples are not isolated incidents, the problem definitely hasn't been fixed for good and it has been occurring at various times for more than a year now. There is quite simply no other plausible reason that I can think of to explain why data transfer rates in general can suddenly appear to be ~2Mb/s on average (whenever things don't feel right and I bother to investigate) no matter how erratic the data stream being examined is at the time and no matter what the IP profile(s) may be other than because PN are quite intentionally trying to rate-limit the connection in general to some unacceptably low level.

It's definitely a general issue affecting Plus/Premier users.  We've seen a bunch of them complaining of it and hence have a fix.  It's been broken since our traffic management update roll out Mid February (this was the roll which caused your 4OD problems).  I'm not happy that it's taken us this long to identify and get a fix in place.  All being well, this should be sorted tomorrow.

Quote from: mikeb

In my book, "line speed" means exactly what it says on the tin - the fundamental unrestricted speed that the line is actually capable of supporting consistently and reliably. i.e. a function of synch speed taking into account all necessary transmission overheads and any relevant essential profiling.  It most certainly DOES NOT mean any seemingly random maximum data rate at which PN intentionally choose to rate-limit all data sent up/down the line. When the specification for my A/C clearly states streaming data is prioritised and supplied at Line Speed I expect to see data at or at least close to the maximum supported rate with minimal jitter and no significant breaks at all times other than when the source is clearly and quite intentionally sending data at some other lower rate or is experiencing fundamental server issues.

Yeah, I agree with that.  It we call it line speed, you should just see slow down from line max based on overheads and any contention in our gold queues.  I.e. right now we've got a platform imbalance (particularly on 20CN lines)  caused by a BT Wholesale outage on Saturday which means gold traffic is being contended.   Normally you shouldn't see much of this at all.

Quote from: mikeb

Finally, it should be noted that some iplayer traffic is without doubt being logged and presented via the portal usage page as web traffic. Apart from the (with hindsight) very obvious strange looking and inexplicable usage figures, several separate tests have now positively confirmed that a very significant quantity of iplayer streaming data is being logged as web traffic.  This doesn't seem in any way strange now considering it would appear that very significant quantities of iplayer streaming data is being delivered using HTTP and is apparently not being classified correctly by PN from a Traffic Management point of view either.  As I think I said very much earlier in this thread or perhaps in another very similar recent thread: Mr.Data was murdered in the Data Centre by Mr.Plusnet with an Ellacoya ... so I very much believe that I win this game of Cluedo hands down ... unless you know differently and can prove it of course

As indicated above, this could well be as you suspect, some streaming traffic being picked up as web traffic, but as they are treated identically in priority, it shouldn't result in any problems.

Quote from: mikeb

I must say that I'm finding it incredibly hard to believe that all of this (assuming it's correct or at least somewhere remotely close to reality) isn't fairly obvious from just a quicky looky see at how things are performing in general at the PN end. Surely PN can see HTTP data from iplayer when perhaps HTTP data is not being expected ?  Surely PN can see large amounts of streaming data from unexpected sources if that's where the problem really lies ? Surely PN can see much higher than 'normal' amounts of HTTP traffic coincident with somewhat reduced amounts of RTMP traffic ?  Surely *some* form of network monitoring indicates that traffic levels or distribution of traffic in general is just looking way more than a bit odd to say the very least ?

We can't go that deep into individual 'flows' of traffic with our current platform (without massive amounts of manual work).   Some of the new tech we've been look at allow us to see a "rating" of the quality of a flow though, so we'd be able to see this sort of thing exactly.  We can though see aggregates of traffic though, so when 4oD started playing up (and you let us know) we were able to correlate it against a falloff in the 4OD graph.

Quote from: mikeb

PS: Can anyone imagine just how much 'fun' this would be if I'd raised a ticket and tried to get anyone to even begin to understand the issue    The last truly technical issue I raised by ticket went on for the best part of 9 months without getting anywhere even remotely close to any particularly sensible/relevant responses let alone a resolution so I just gave up in the end and came up with a workaround to mitigate the effect of PN/BT fundamental non-compliance issues.

Tbh, it's probably best talking to us on Community about this sort of issue.  That way you get the attention of the people who are able to debug with knowledge of how the systems work.
(edit: fixing broken quoting)

[#8]

Hi Mikeb,
As I said earlier the fix is rolling overnight, but rather than you suffer for this evening we've manually changed your traffic management profile in advance of that.
Jojo

[#9]

Really sorry but I haven't read any responses since my last post as I just don't have any time at all to get involved in this today or tomorrow due to some urgent stuff (with a very non-negotiable deadline !) that I have to take care of at home.  However, I did want to provide a quicky update as someone has quite obviously been tweaking something somewhere
I don't know exactly what you've done as yet apart from reset my billing/usage several days early again like you did last month (even though usage was still somewhat within all relevant limits) but as of yesterday evening and esp this morning, there has been a *very* significant change in performance.  Even more so than there was last time you did much the same kinda thing.  
Despite no change in gateway, no apparent change in profile(s), no change in fundamental connection speed or quality and in fact no obvious visible or measurable differences whatsoever, web browsing is absolutely flying along  It was orders of magnitude better even during the busiest time yesterday. I almost can't remember the last time that browsing was quite so responsive and with an almost complete absence inexplicable pauses, odd delays or bits missing when loading some pages.  Nothing whatsoever has changed at this end - no updates of any kind and no resynch or restarted PPP, just the same old equipment booted as normal using the same old connection that was established several days/weeks ago and running exactly the same applications as always yet a significant immediately noticeable performance improvement when wandering around the same sites as I almost always do at very much the same sort of times virtually every day.  
However, it's not quite all good news. iplayer whilst initially performing reasonably OK yesterday (although still well below the way it used to be) gave up playing again later in the evening due to "insufficient bandwidth to stream the programme" and speed tests various indicated a significant slowdown although not to the extent that it should have affected iplayer so badly of course. The dip certainly wasn't quite as bad as has been regularly seen recently, didn't last as long and definitely didn't start at 1600(ish) and end at midnight either.  It was probably more like 2000 hours to 2200 hours or thereabouts. Unlike previously, upload speed wasn't being affected either.  iplayer diagnostics showed various problems mid evening mostly on an intermittent basis, sometimes performance not too bad, sometimes more than a bit grim and sometimes some of the individual tests wouldn't even run at all. Again, this all cleared after a couple of hours or so and after midnight as usual there were no visible issues whatsoever. When iplayer was struggling, RTMP data streams were generally speaking not brilliant although perfectly usable but HTTP data streams were almost always unusable. Performance tonight was similar if not slightly better than yesterday as HTTP streams did at least seem to play without ending up with an "insufficient bandwidth ..." error message.

I'll catch up  in a day or so but thanks to whoever for doing whatever seems to have helped  

[#10]

Hi Mike,
Glad to hear it's looking better. The dips of speed at peak time are still concerning though, would you be able to do a BT Speedtest during peak hours (around 10pm) and let us know when you've done that? The exchange isn't showing as contended at the moment but there may be issues somewhere causing the lower than expected speeds during the evening periods.

[#11]

Oh well, I guess Mrs.BT *really* didn't like me being quite so excited about not having any problems with web browsing so she fiddled around with the bl**dy wires to give me 151457 uncorrected errors in just a fraction of a second early this morning which resulted in a terminated PPP, multiple failed attempts to re-establish another one and finally a handful of reboots to eventually  get one of the much more typical not-quite-so-good connections instead of the one that was apparently working so well    Brilliant isn't it how some companies just seem to have p***ing off customers as their number 1 priority and it's generally one of the few measures of performance that they actually excel at as well  
Hmmmmm, OK, moving swiftly on cos I only popped in for a sneaky read while I'm supposed to be doing something else much more important.  Interesting stuff  ....and  me old mate Paul Carrack seems to be asking the most obvious question about the now confirmed profile/usage issue HERE and I'd very much like to know the 'official' answer to that one as well needless to say.  I guess it's been a persistent issue since the end of March and would have been until the end of October ... so we just need to know WHICH YEAR and all that
Plus I'd also very much like to know: What exactly is the difference between "Gold" traffic tagged $80 and "Gold" traffic tagged "$60" ? Presumably there just has to be some quite fundamental difference between the two that PN don't particularly want to talk about or you'd have probably used two completely different names !  It doesn't seem particularly sensible or indeed particularly likely that 2 of the not-very-many types of traffic classification available are used for exactly the same thing now does it ?
@Chris: I think you're right to be concerned. So am I.  I still don't think everything is quite as it should be but with BT moving the goalposts again and me not having time to b*gger around at the mo, any further investigating is just going to have to wait.

***** THIS POST HAS BEEN HERE ALMOST A WEEK AND STILL NEEDS SOME ANSWERS *****

[#12]

Anyone thinking (or perhaps hoping !) that "no news was good news" is about to be sadly disappointed I'm afraid ... esp so seeing as there are still no answers to the questions asked in my previous post from almost a week ago of course   But doubly so because there would appear to be even more fundamental problems (AKA c*ckups) on my A/C - problems that are almost certainly also affecting other customers with the same or a similar A/C type.  I honestly think it's well past the time to start getting *really* annoyed at the level of back-office incompetence and a complete lack of any effective testing and/or QA being demonstrated on a quite regular basis  
Despite the fact that I'm almost beginning to lose count now of just how many quite different and separately identifiable problems or whatever there actually are which appear to be directly affecting the service I pay handsomely for and the performance thereof, I seem to have stumbled across yet another previously unknown one with PN's name on it  More info and the customary irrefutable evidence coming a bit later when I've finished checking things out but suffice it to say for now that usage is definitely still not being counted correctly.  It's almost beginning to look like PN have basically been ripping me off in almost every way possible for some considerable time and have now well and truly been caught out. I'm stupidly paying PN £22/month for a mere 13GB of peak-time traffic and they're STILL trying to rip me off even more by not actually allowing me to use that meagre allowance !!
Firstly though, here's some irrefutable evidence that PN have been categorising iplayer traffic as something other than iplayer traffic and were consequently throttling it to death exactly as I expected to find they were doing.  Having had time to have a quick look at several 100MB of data collected during my investigations, it is quite obvious that some iplayer traffic was without doubt being intermittently tagged as $60 rather than $80 and therefore throttled to a ridiculous level.  As explained previously, this has almost certainly been affecting at least some other users (if not all users) and not just me. Here's a single packet from a block of streaming data captured on 13th May by way of an example:

Frame 3204 (1472 bytes on wire, 1472 bytes captured)
Arrival Time: May 13, 2012 23:59:43.825197000
Time delta from previous packet: 0.002408000 seconds
Time relative to first packet: 74.182044000 seconds
Frame Number: 3204
Packet Length: 1472 bytes
Capture Length: 1472 bytes
Ethernet II, Src: 00:50:7f:05:a9:08, Dst: 00:09:6b:11:c1:d2
Destination: 00:09:6b:11:c1:d2 (Ibm_11:c1:d2)
Source: 00:50:7f:05:a9:08 (Draytek_05:a9:08)
Type: IP (0x0800)
Internet Protocol, Src Addr: 88.221.94.166 (88.221.94.166), Dst Addr: 192.168.1.111 (192.168.1.111)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x60 (DSCP 0x18: Class Selector 3; ECN: 0x00)   <<----- ??????
0110 00.. = Differentiated Services Codepoint: Class Selector 3 (0x18)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 1458
Identification: 0x27d6
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 118
Protocol: TCP (0x06)
Header checksum: 0x5d75 (correct)
Source: 88.221.94.166 (88.221.94.166)
Destination: 192.168.1.111 (192.168.1.111)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1368 (1368), Seq: 1852707162, Ack: 152
Source port: http (80)
Destination port: 1368 (1368)
Sequence number: 1852707162
Next sequence number: 1852708580
Acknowledgement number: 1527010411
Header length: 20 bytes
Flags: 0x0010 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 65535
Checksum: 0xe1c6 (correct)
Hypertext Transfer Protocol
Data (1418 bytes)
0000 89 94 a2 e0 0a 80 04 dd 11 0e 2c 02 8a 89 10 14 ..........,.....
0010 08 13 84 85 2a 84 f2 b0 59 d0 a6 62 38 0f ef 3c ....*...Y..b8..<
0020 ef cc 0d 33 a7 27 b7 42 74 5d 32 aa 49 70 02 24 ...3.'.Bt]2.Ip.$
0030 c5 40 28 00 b4 44 42 b5 4a 72 b0 0a 82 40 00 50 .@(..DB.Jr...@.P
0040 00 70 00 00 00 ae 08 00 00 b4 00 90 4f 00 00 00 .p..........O...
0050 00 af 01 21 09 8d df ff ff ff f4 cc 14 f8 04 c4 ...!............
0060 44 41 02 10 44 49 05 2a 87 0e 01 9b 1d 49 50 2e DA..DI.*.....IP.
0070 8e fc 36 e5 1b 95 ce 50 ad 93 e2 e5 b5 d0 c4 46 ..6....P.......F
0080 ef d4 36 21 f1 a5 43 06 d5 83 e6 cb da f9 81 25 ..6!..C........%
0090 44 ed 76 d4 cc c0 22 d6 d4 69 f0 b5 80 86 56 39 D.v..."..i....V9
00a0 56 9b 76 dc 2e bd 0f 76 90 fc da 19 8d 1a 59 3f V.v....v......Y?
00b0 50 45 ee 16 a8 32 6c ec 82 da 84 cc db 34 fd bb PE...2l......4..
00c0 f3 4e b5 9a d0 9d 6a 16 48 3e c4 c0 0b 80 4d 58 .N....j.H>....MX
00d0 99 02 c0 28 84 08 23 01 91 00 a8 a4 09 7a 04 91 ...(..#......z..
00e0 4a b9 27 c1 fe 34 7a 69 6b 68 e9 5b 5f 06 54 a4 J.'..4zikh.[_.T.
00f0 34 f0 5f 06 7e fa be d9 02 89 0d 02 8b 04 40 0b 4._.~.........@.
0100 cc 08 26 05 b8 00 00 00 b4 09 00 08 04 00 90 60 ..&............`
0110 00 00 00 00 27 01 00 00 00 00 00 00 11 06 01 0c ....'...........
0120 00 3f 00 00 03 00 90 81 8c 80 00 00 08 80 00 00 .?..............
0130 07 e6 41 9a fd f8 04 5b ff ff ff ff ff ff f8 46 ..A....[.......F
0140 26 a7 32 9f 56 37 2a fc 2b bf fe bf 93 cc 32 23 &.2.V7*.+.....2#
0150 11 11 08 66 f5 87 95 0a cd d5 41 ea 11 11 08 de ...f......A.....
0160 5c d1 7c f1 f1 1f f8 33 ff 1b af 7f ff fd fe 2f \.|....3......./
0170 d6 98 42 ac a4 da 29 fe ff ff ff ff c4 ff f4 0b ..B...).........
0180 de bf 2e c2 47 81 4c dc 38 f2 bc 71 10 a7 9a 06 ....G.L.8..q....
0190 c5 9d 16 1e d4 bf 72 9a 1d 94 5a b8 b5 f0 12 df ......r...Z.....
01a0 ff ff f1 10 8e d8 68 c7 e3 9c 65 7d 6a c5 5d 6b ......h...e}j.]k
01b0 5b 3b 2d c6 f8 c3 cf 88 c4 eb 9f 5e 80 bb f1 7e [;-........^...~
01c0 41 bb 7e b8 ff ff 88 bd 99 3e 97 e3 aa 4a ac ad A.~......>...J..
01d0 75 a9 33 63 c5 2f 0e 17 e6 3d f8 53 62 b1 58 ac u.3c./...=.Sb.X.
01e0 56 2e 62 95 ef 26 ff f8 8a a4 c6 8d f4 7f 31 e7 V.b..&........1.
01f0 27 ee 66 22 56 7a d2 ff 88 2c 5f 7f 3f dc 9f fc '.f"Vz...,_.?...
0200 43 dc 60 bf 5b 79 d1 9e fb e9 e9 2a b4 b3 7e 72 C.`.[y.....*..~r
0210 02 8b 3b 9d 8d 0f de b1 11 9f 25 5b 55 d2 ca f8 ..;.......%[U...
0220 ff ff 9d f8 9f eb 05 9f 2c 67 fc e7 f1 65 56 37 ........,g...eV7
0230 d4 19 cb a8 ac 8b b1 2e 6d c5 df d8 53 b1 ae 7d ........m...S..}
0240 59 94 7c f4 0d 03 e3 99 3f ee 70 4a b1 90 ca e4 Y.|.....?.pJ....
0250 20 3d 83 22 f6 2f 90 93 f0 1f 2e 4d e4 3d 68 f2 =."./.....M.=h.
0260 bc 92 7c 84 13 79 e8 7f 7f c5 7f 3b c5 9a e8 4e ..|..y.....;...N
0270 55 18 18 f1 4e 25 5c 8f 30 40 80 d0 23 df 7d e5 U...N%\.0@..#.}.
0280 62 fd 58 c2 0a 8f 2f 61 7e 9e 57 60 9d 78 5c 46 b.X.../a~.W`.x\F
0290 bd 20 51 ae ab 52 a5 f2 d9 dc af ca 2b 7d 4e ca . Q..R......+}N.
02a0 fd e4 cb ff 86 17 b9 71 83 5f 1b c5 c6 85 6c 78 .......q._....lx
02b0 40 7f c6 a9 30 b0 15 bc 85 bc 8c f5 ed 7b 89 f5 @...0........{..
02c0 ac 2e 30 65 b5 6f 79 58 6d 36 f3 d1 df 0b e9 42 ..0e.oyXm6.....B
02d0 9a 10 cd c5 b7 84 2a 09 22 c6 5b ab 92 b1 d9 3f ......*.".[....?
02e0 e3 bb eb bb f7 c9 c8 f2 32 fd 7b d6 ae 11 e4 37 ........2.{....7
02f0 99 7b 13 b1 39 4e f7 c2 1b de f7 3f 7b 7e c1 c6 .{..9N.....?{~..
0300 b2 df fd fe 33 96 c9 4d 1a 36 5b 2f b2 ff 36 7a ....3..M.6[/..6z
0310 ff 43 dc 8a af 3e 2a f8 5f 50 9a f4 a2 76 ef 81 .C...>*._P...v..
0320 a0 82 78 ce b7 15 b5 21 0c 35 3e bf 8a 56 f7 35 ..x....!.5>..V.5
0330 59 e1 70 23 f9 0f e4 87 af 5b ba bd d2 f5 f7 fe Y.p#.....[......
0340 55 ef 38 b1 77 bb ef 5a f1 b4 f2 e5 fd 5d f8 fa U.8.w..Z.....]..
0350 b0 64 b6 50 71 8f 32 aa ff 19 bd dd dd ef 77 77 .d.Pq.2.......ww
0360 78 b7 10 f6 67 71 5f ff d4 68 a9 eb f4 39 58 25 x...gq_..h...9X%
0370 9b c1 bc 44 74 a8 56 67 88 74 09 8d 79 12 b3 8c ...Dt.Vg.t..y...
0380 fc ec 23 87 13 ee f7 dd f6 e2 c8 14 ac 5b f9 45 ..#..........[.E
0390 72 ec 14 74 8d 7e 1a a7 91 53 ce c2 ec 7d f2 e3 r..t.~...S...}..
03a0 be 99 61 ba df 3d 49 18 09 15 ea 7b 16 eb d9 df ..a..=I....{....
03b0 3b 97 ff 7f 8d e8 fa 54 ae 7c 4a fc 3e 2f e9 25 ;......T.|J.>/.%
03c0 de 4a 85 6c 5e 3f 4d 6c 75 8f c9 98 2b 2a 4c 0d .J.l^?Mlu...+*L.
03d0 18 ab f1 97 bb ed 04 da 87 be f4 3b ef f0 87 b7 ...........;....
03e0 a1 e3 47 00 58 8f 15 74 9c b2 b2 21 b0 57 bb cf ..G.X..t...!.W..
03f0 e7 e4 c5 64 97 6f 18 42 a0 41 d0 62 78 c5 0a 2f ...d.o.B.A.bx../
0400 48 bd c8 16 0f dd 5f 75 e8 f7 94 f9 3f 5e c1 78 H....._u....?^.x
0410 45 21 3c 43 98 6e 47 2b 93 13 b8 52 99 f9 eb bf E!<C.nG+...R....
0420 fb 03 37 e7 af d7 f8 26 eb 55 5f bd 71 6e df d8 ..7....&.U_.qn..
0430 b7 4f 49 f8 ac cc 58 e6 62 66 3e bd 54 4f cb f1 .OI...X.bf>.TO..
0440 3a d6 71 79 d9 9d 9c 69 31 9e 18 8b cd e5 61 01 :.qy...i1.....a.
0450 13 1f d0 d8 ca 13 34 26 6c 4d cd d0 a5 5e dd 76 ......4&lM...^.v
0460 de df ea db e1 59 42 94 35 c3 86 96 9e 40 73 f9 .....YB.5....@s.
0470 55 50 cd fa 4b b1 9e d6 c8 88 37 73 33 a6 5d 19 UP..K.....7s3.].
0480 18 30 38 41 a9 36 b1 fe a3 d9 6b d7 ef 52 05 01 .08A.6....k..R..
0490 3e ab 95 88 37 a6 3b d3 2d 3a 4a e6 b4 3e 9a 42 >...7.;.-:J..>.B
04a0 a8 cb ae a5 8b f4 2c 6f 3d 74 71 94 8e 9c b1 3b ......,o=tq....;
04b0 de f7 bf 42 be 06 1a f0 b5 55 54 cc 4e 93 f5 d0 ...B.....UT.N...
04c0 b7 6d b1 6e 65 3d df f2 93 f8 d8 21 22 16 10 ce .m.ne=.....!"...
04d0 e0 ff 97 12 2f c7 a9 78 81 fa f0 3b 74 4e 8e c7 ..../..x...;tN..
04e0 fc 3b d8 7c ea 79 17 00 d5 27 87 68 ba d7 f5 e7 .;.|.y...'.h....
04f0 af 4f fa e6 0f ff ec 66 c7 57 b7 d0 f2 7a 98 0c .O.....f.W...z..
0500 2a c1 28 91 20 ae 65 d7 5c dd a0 9d 95 a6 2e d8 *.(. .e.\.......
0510 c6 6e 8d c6 6a 72 79 07 5e a3 2c 6c b6 6b 1e 11 .n..jry.^.,l.k..
0520 ed fd cd 36 cd ce 7d af e1 1f 97 d5 bc 2c a0 ad ...6..}......,..
0530 41 c9 08 49 8d 59 bd 7d a3 a7 6f 36 cf 71 c6 e5 A..I.Y.}..o6.q..
0540 65 3e f9 50 80 86 df de e3 37 0b 77 89 02 28 d0 e>.P.....7.w..(.
0550 30 8b e9 85 05 53 6d df e6 0f 97 c3 d9 6a c7 05 0....Sm......j..
0560 82 00 b8 56 ac 28 d3 a1 84 4f 3d 2f 9a fd 7b 3b ...V.(...O=/..{;
0570 ac ef f1 1f c9 e2 fa 34 7a 34 72 7d 2b fd 63 31 .......4z4r}+.c1
0580 6f 98 f1 db 7f dd a7 df f9 26 o........&

It would appear to me that HTTP iplayer data via Akamai servers 88.221.94.135, 88.221.94.166 (and maybe others) in particular was being incorrectly tagged as $60 leading to a guaranteed completely unusable service due to the ridiculous restriction in data rate being applied to general Akamai traffic. This was quite clearly in addition to the general restriction in data rate on my specific service that had been erroneously and silently applied due to the usage accounting issue previously identified which has now allegedly been fixed.  RTMP data did not seem to be being affected and nor did HTTP data via Limelight although I could obviously only collect a limited amount of data at the time.  Because servers and data format are also assigned dynamically, the problem was quite clearly intermittent in general therefore it's not possible to be in any way certain that HTTP via Akamai was the only problem in existence at the time.

It's becoming very clear that someone without doubt deserves a bl**dy good slap for all this nonsense and way more than a bl**dy good slap for the additional usage collection problem that will be demonstrated shortly.  If PN/BT are going for the record in the maximum number of separate faults they can introduce on a single A/C at the very same time then please stop right now as apart from anything else, I'm getting way more than a bit p***ed off with wasting quite so much of my valuable time trying (and succeeding) to find them.  One of These Days I'm going to cut you into little pieces I'm going to jump on the Sheffield train that hopefully still trundles past the back of my place every day and deliver the slap(s) various personally !!!!

[#13]

Right then ... it's Screw my Usage ooooops, sorry, bit of a Freudian slip there, I mean VIEW my Usage accounting errors Part Deux and all that:
It would very much appear to me that usage is being categorised and accumulated quite incorrectly on my A/C and this is quite likely to also be affecting other users with the same or a similar A/C type.
This problem will also potentially lead to somewhat draconian restrictions being unreasonably placed on my service even though the previous timing issue elsewhere has allegedly been fixed.  So, in addition to the silent restrictions that PN had routinely been placing on my service for more than 50% of each month between March and October due to GMT/BST issues, it seems to me that other usage accounting issues will also lead to a similar restriction potentially being put in place and/or will generally prevent me from using a significant portion of the Peak-time allowance that I'm paying for.
Today, I have been making reasonable use of my service between approximately 1000 and 1600 hours in much the same way as is generally the case most days. Unfortunately for PN,  I also took a handy snapshot of the portal VMU pages before and after this period. There was no usage [##] for several hours prior to ~1000 hours when I first checked meaning that all previous usage was fully accounted for. Similarly, by ~1900 hours when I checked again, there had been no usage [##] for several hours meaning that all usage during the daytime period was also fully accounted for.  
Here's the breakdown of my usage first thing this morning:

Activity             Peak usage    Off-peak usage    Total usage
                     ----------    --------------    -----------
Web                   954.34MB         1.98GB           2.93GB
Email                  22.87MB        11.19MB          34.06MB
Broadband phonecalls   11.58KB          9.2KB          20.78KB
Gaming                  3.48KB         1.33KB           4.81KB
Streaming               1.54GB         6.42GB           7.96GB
PlusNet FTP           917.31KB        65.17KB         982.47KB
Peer-to-peer           19.34KB         2.98KB          22.32KB
Usenet                360.58KB            0KB         360.58KB
FTP (non PlusNet)          0KB         1.11KB           1.11KB
Other                  49.72MB        26.09MB          75.81MB
                     ----------    --------------    -----------
Total usage so far      2.57GB         8.43GB             11GB
                     ==========    ==============    ===========

And here's what it says this evening:

Activity             Peak usage    Off-peak usage    Total usage
                     ----------    --------------    -----------
Web                     1.11GB         1.98GB           3.09GB
Email                  25.18MB        11.19MB          36.37MB
Broadband phonecalls   12.04KB          9.2KB          21.24KB
Gaming                  3.48KB         1.33KB           4.81KB
Streaming               1.57GB         6.42GB           7.99GB
PlusNet FTP             1.04MB        65.17KB            1.1MB
Peer-to-peer           19.41KB         2.98KB          22.39KB
Usenet                432.52KB            0KB         432.52KB
FTP (non PlusNet)          0KB         1.11KB           1.11KB
Other                  54.51MB        26.09MB           80.6MB
                     ----------    --------------    -----------
Total usage so far      2.76GB         8.43GB           11.2GB
                     ==========    ==============    ===========

Soooooo ... spot the deliberate mistake time, answers on a postcard and all that  
[ HINT: My A/C is actually a Premier A/C (Peak-time: 1600 hours - midnight) just like it says at the very top of the VMU page but guess what's still happening to loads of my off-peak usage even though PN has apparently fixed the other problem that meant a different vast amount of off-peak usage was actually being counted as peak-time usage somewhere else  ]
All-in-all, these problems mean massive amounts of data each and every day being quite incorrectly counted as Peak-time usage and this has quite possibly been the case for some considerable period of time  The problem previously identified resulted in totally unreasonable restrictions being silently applied whereas this particular problem will prevent me from using my service in one way or another by falsely claiming that I have exceeded my allocated Peak-time usage.
Must say that I'm finding it very hard to believe that no one actually noticed this particular issue when they were checking things out trying to find the source of the previously found problem of incorrect accounting.  Me old mate Mr.Carrack also wants to know the 'official' answer to that very obvious question again needless to say although this time in relation to the fundamentally wrong Peak-time period being used in VMU rather than in relation to the DST issue that was discovered elsewhere  

Time for a musical interlude while a short pause followed by a li'l embarrassed squirming takes place methinks   ... now, what shall we have ... decisions, decisions ... so much good stuff to choose from and all that ... Ah yes, I reckon THIS probably fits the bill almost perfectly in so many ways !!!

[##] Excluding regular incoming email traffic, monitoring packets and any random unsolicited traffic there may have been.  This should have been accounted for under "email" and "other" categories of course and in any case would have been a totally insignificant amount of data.

[#14]

ROFL You think you have had troubles,  Ive not even started,  How about going back a few years as the speeds I have been getting was 0.9meg and thats DEAD slow 🙂  But now I have a better service and running at about 32-35meg and I think Ive  landed on some sort of mass broadband speed for a change,  Had my problem for 4 years despite forever telling people there was a problem, Nothing was ever done untill today when I went on the 80/20 trial and looking forward now.

[#15]

Oh, this thread is great!  I reported issues with streaming iPlayer and other VOD, and nothing came of it.  I really hope this gets resolved for you.