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)