Speed above IP Profile

Can anyone suggest (in the linked thread) how this poster is repeatedly getting BTW speed test downloads greater than his IP Profile, even with his McAfee disabled?

It's not even impossible, I was was able to when the DLM was configured wrong for my line.

Sync of 18999, IP profile of 18.42Mbps. Probably 2 out of 5 tests would be around 18.60Mbps down, no bRAS mismatch. Kevin from BT care or Ed from ELC didn't know why it was happening.

It doesn't have to be him, try restarting the PPPoE connection.

I'm with BT not plusnet though... though this shouldn't have no impact on this.

Edited by deleted (Sat 27-Jul-13 06:57:27)

I wondered about this too. The really cool TBB speed test returns fairly steady 11Mbps, and yesterday 12Mbps, except during peak-time congestion when it sometimes falls to around 6Mbps. I quote stats just for interest, little idea what they all mean! I'm on BT and running KIS at all times.
Downstream 10,080 Kbps
Upstream 1,127 Kbps
VPI/VCI 0/38
Type PPPoA
Modulation G.992.5 Annex A
Latency type Interleaved
Noise margin (Down/Up) 6.0 dB / 6.3 dB
Line attenuation (Down/Up) 33.8 dB / 16.7 dB
Output power (Down/Up) 15.7 dBm / 1.7 dBm

Edited by Malwaremike (Sat 27-Jul-13 08:44:32)

Pass. What does an actual data transfer rate look like ? Something where the timing accuracy isn't going to introduce a significant error like downloading 1 Gbyte against a stopwatch.

I was getting the same sort of thing using speedtest.net (2Mb IP profile and recorded speeds above 2Mb). I raised this with their Tech Support and was pointed to this link.

In essence they break the speed test down into small chunks with a calculated speed for each chunk. They then use an algorithm to drop out the outlying chunks at the top and bottom of the speed range and average the rest. As they drop out 10% at the top end and 30% at the bottom end, it seems to me that this will have the effect of raising the average, perhaps to higher than the IP profile.

Maybe the BT test has the same sort of algorithm.

In reply to a post by GonePostal:

As they drop out 10% at the top end and 30% at the bottom end, it seems to me that this will have the effect of raising the average, perhaps to higher than the IP profile.

How?
Are you saying some chunks are above the IP Profile?
Surely, that's the question.

Using the btspeedtest diagnostics page, I too get reported speeds faster than my up/down profiles (but timing test file downloads doesn't reflect this) - even though I have been stuck on a 4mb cap for months:

http://linicks.net/stuff/btspeedtest.png

I really think it must be a glitch in the way the thing works.

Nick

What a pity everyone has replied here, rather than in the thread as requested, where the OP and future readers may have found it useful.

In the link in my post speedtest.net state:

"Since we are measuring data transported over HTTP (via Flash), there are the following factors that can affect speed: potential protocol overhead, buffering due to the many layers between our application and the raw data transfer, and throughput bursting due primarily to CPU usage. These factors lead us to drop the top 10% and bottom 10% of our slices as outliers.

Additionally, we keep the default test length short for user experience. Because the test is shorter, the ramp-up period can take a significant part of the beginning of the test, leading us to drop another 20% of the bottom result slices."

I am not as technically expert as many users here but I take that to mean that things like buffering can actually make it seem as if some chunks are being transmitted at slower than the actual rate and some faster. This is presumably why they drop the outliers. If the local circumstances are such that there are still outliers beyond the IP profile even after application of the algorithm then I can see how the report could show a speed higher than the IP profile even though that is not what was actually achieved. If that is not the case, I will be quite happy to be corrected.

I can't see how taking an average of a set of results will give a figure higher than the peak result.

Line is underperforming. Should be getting about 13 Meg.

In reply to a post by RobertoS:

What a pity everyone has replied here

it was too subtle, I only saw that after your comment.

In reality you can't have an average higher than the peak.

However, I don't think you are seeing the point about what the speed test is actually registering while it is hard at work. The point is that the rate recorded by the speedtest program may be higher than the actual rate achieved in practice because of the factors that the speedtest.net link identifies. It may well be that there are two consecutive chunks where the download rate is a consistent 1.8Mbps. However, because of buffering etc. only the bandwidth equivalent to a download rate of 1.4Mbps is acknowledged by the speedtest program for the first chunk. Things catch up in the next chunk so it "registers" 2.2Mbps. The 1.4Mbps may then fall into the 30% of slow chunks that are ignored while the 2.2Mbps may not fall into the 10% of fast chunks that are similarly ignored.

You will then get a skewed result and potentially even an average higher than the IP profile. It is all explained far better than I can lay it out in the link I attached to my first posting.

Sorry, I can't see how it would catch up at 2.2Mbps unless the actual speed was at least 2.2Mbps. And then given the top 10% results are discarded, the actual speed would have to be higher than 2.2Mbps anyway.

Buffering on the client machine(s) between the client modem and the program calculating the received speed is the most likely cause of speeds being recorded above the IP Profile. You probably remember how useless speedtest.net used to be when people were using Kaspersky and Avira - giving speeds double or more than the sync speed.

The reason I posted was because the particular user has McAfee and had got the same effect with it disabled.

That's assuming McAfee really does disable itself when it says it has done . Awful stuff.

Looks ok to me though

In reply to a post by LEEEVANS69:

and now today 16 th July

Download speedachieved during the test was - 37.87 Mbps
IP Profile for your line is - 41.6 Mbps

Unless I'm looking at the wrong thing

Well my reply to you was on the issue then being discussed as to how speed tests can record a higher speed than the maximum on the line - giving reasons quite independent of the sampling methods used that was being argued about.

But in reply to your latest, you didn't follow the link in the opening post of this thread .

http://forums.thinkbroadband.com/plusnet/t/4254596-p...
http://forums.thinkbroadband.com/plusnet/t/4254668-p...

he posted several, most are sensible a few have recorded speed slightly above IP profile.

Always helps to look at these things in terms of percentage errors.

AFAIK the IP profile is updated by the router being reset, so it's easy to get a profile mismatch.

The IP Profile controls the throughput speed from the MSAN/DSLAM. End of.

On 20CN it does not update immediately, remember? Only on the latest version of the WBC DLM. That can fail if the re-sync of the modem occurs before the PPP session has been dropped, as no signal is then sent to the BRAS with the new sync.

In the case of an 8Mbps sync and a 0.75kbps IP Profile, the router has clearly been reset since the 0.75kbps profile was established..

In reply to a post by RobertoS:

The IP Profile controls the throughput speed from the MSAN/DSLAM. End of.

in which direction ? I would have said that the IP profile limits the amount of data sent to the MSAN / DSLAM from the ISP, but I often look at these things differently

so the reported value on the speedtest may not be the prevailing value ?

I think the IP profile is related to the BRAS not the DSLAM.

I think with Plusnet there are potentially 3 different profile speeds in addition to the sync speed.

Actually Phil the IP Profile does seem to be held in more than one place, and an imbalance can occur.

There is some test that shows this, which PlusNet run when all else fails to make sense. IIRC it amounts to there being a database for access by the BTW speed tester and the value from there is what feeds through to PlusNet and other ISPs that hold copies, and then there is the live figure in the BRAS itself controlling the line speed via the DSLAM/MSAN. (Not via the ISP).

That makes sense - separating an operational database from an informational one. Or at least in did when the system was designed, when database servers were far less powerful than now.

Those two values held by BTW can get out of step, and so far as I know the test referred to above is the only way an ISP can find out if that has happened.

yep, it restricts how much data can be sent to the DSLAM post at the BRAS.

the BRAS IP profile limits how much data can be thrown at a DSLAM port, to be no more than what it can pass down the line to the CPE if its working. The ISP can mirror the value in order to limit how much it throws at the BRAS in order to avoid the policing coming into effect.

I don't know if the speedtester returns a live look-up or a historical value which may be out of date. To get a speed test result greater than the reported IP profile means either the test is overstating the speed, the IP profile is reported incorrectly, or the BRAS isn't doing its job.

In reply to a post by yarwell:

I don't know if the speedtester returns a live look-up or a historical value which may be out of date.

It isn't an historical value, but apparently can fail to update.

To get a speed test result greater than the reported IP profile means either the test is overstating the speed, the IP profile is reported incorrectly, or the BRAS isn't doing its job.

First and second agreed. As for the third, I'm not aware of any suspicion of that since I came here. The second is the immediate discussion.

Post deleted by GonePostal

Let's try a simplistic example to show how the numbers work.

In the house you have a tap discharging into a sink. There is no plug in the sink and the sink discharges into the outlet pipe for the house. The plughole is bigger than the pipe to the tap so that the sink can clear away more water than the tap can put in.

The pipe to the tap has a nominal flow capacity of 2 unite per second but the internal resistance in the pipe means that only 1.8 units per second can physically flow through the pipe. In the house there are also people showering, taking baths etc and the dishwasher and washing machine are also pushing water into the main outlet pipe.

We know that the sink will normally discharge 1.8 units per second. However, the dishwasher starts pumping out so the main outlet is already full of water when the discharge from the sink gets there. Let's assume that only half of the water coming out of the sink can actually be taken away by the outlet because of the other flow. The flow out of the sink is then 0.9 units per second and the sink starts filling at 0.9 units per second. Once the dishwasher has finished pumping, the outlet pipe dries up and the sink can stop backing up and get rid off the water that has collected. Let's assume that this happens in the same amount of time that the backing up happened. The outlet rate from the sink will then be 2.7 units per second.

Now suppose we want to measure the flow of water from the pipe through the sink and into the outlet using the speedtest.net model and measuring the rate of our particular flow through the outlet pipe. We'll assume there are 20 chunks of time in the sample and that there are 6 dishwasher type events during that period. That means there will be 6 chunks at 0.9 units per second, 6 chunks at 2.7 units per second and 8 chunks at 1.8 units per second. The speedtest.net model drops the lowest 30% (6 x 0.9 units per second) and the top 10% (2 x 2.7 units per second) leaving 8 x 1.8 units per second and 4 x 2.7 units per second. This gives an average of 2.1 units per second. We know this is impossible because in ideal circumstances the inlet can only handle 2 units per second, but it is what the algorithm produces.

Now replace the inlet pipe with your internet connection, the sink with your buffer or internal memory and the outlet pipe as the flow of work through the CPU and I hope you can see how a clearly impossible result can be achieved through statistical manipulation.

Edited by GonePostal (Sun 28-Jul-13 09:38:35)

In reply to a post by RobertoS:

It isn't an historical value, but apparently can fail to update.

To me that's a contradiction, if it needs "updating" it has to be historical, shirley ? ie it's a stored historical value from the last time it was updated, rather than a real time "ask the BRAS what the IP profile is right now" thing.

It makes sense to have a historical / buffered / <insert other name> record for a better response time. The speedtest can be ponderous enough as it is.

My OS tells me the instantaneous transfer rate through the network interface, why not sample that through the duration of a fixed period of streaming data and record the average - no influence of buffering ?

In reply to a post by GonePostal:

(1) The pipe to the tap has a nominal flow capacity of 2 unite per second but the internal resistance in the pipe means that only 1.8 units per second can physically flow through the pipe.

(2) The outlet rate from the sink will then be 2.7 units per second.

How can (2) ever happen when (1) says only 1.8 units can physically flow?

In reply to a post by BatBoy:

How can (2) ever happen when (1) says only 1.8 units can physically flow?

1.8 can flow in to the sink, 2 can flow out.

In = Out + Accumulation

negative accumulation = emptying the sink at the same time as water is running in.

Not a great analogy TBH.

If only 2 can flow out, how can 2.7 flow out?

Edited by deleted (Sun 28-Jul-13 10:33:14)

only 2 can flow in - 2 is the limit to the tap, not from the sink

What's the limit from the sink?

he didn't specify a limit on the outlet from from the sink ?

Maybe it's totally unlimited?

Post deleted by GonePostal

usually laws of hydraulics apply

but why measure downstream of a buffer ?

No idea. I was just trying to visualise what the information in the speedtest.net link actually represented.

No, it's not a contradiction so long as we ignore the milliseconds between the two updates. In effect it is a real-time update, so the value is not historical in the system design sense.

I accept that if the update fails, it could be argued that it is an historical figure but I feel the argument would be spurious.

In particular, we don't even know, at least I don't, which updates first. They may both update from feeds from the same source, not one from the other.

This argument in itself is fairly pointless and silly, distracting from the thread discussion. As I said before, it seems the two can get out of step, thus potentially causing apparently impossible speed test results.

if it can get out of step it's not a real time value, so comparing a historical record of a limit against the current value of a speedtest doesn't tell us anything of significance.

The title should be be "Speed above alleged IP profile" or "Speed above historical record of IP profile"

If the speed test doesn't report the value prevailing in the BRAS at the time the test was executed, it's historical.

Sorry Officer, I was within the speed limit that I recall was in operation last Thursday