Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Hi kitizens, I want to convert from sync rate (ADSL1 20CN) PPPoE to IP PDU throughput, that is the amount of bytes transmitted including IP headers and payload.

I think this means something like 2000/2272 from the speed rungs BT use in 20CN = 0.88.

Does this sound vaguely right? (Just ATM cell overheads alone gives 48/53 = 0.906 so a more accurate conservative figure has to be below that.)

[guest]

I have a figure I remember from those days (on BT infrastructure in 2002) of 0.882 efficiency if the TCP/AAL packets were perfectly aligned in "normal usage".

Do bear in mind that was a long time ago - you'd probably do better asking RevK as ISTR he reduced the packet size on the AAISP L2TP tunnel to optimise this back in the day

[Weaver]

The reason is that you are supposed to tell a Firebrick router what the maximum speed of the payload in each upstream pipe is. The figures in use for specifying this are, I assume, the bit rate of PPPoE payload into the modem. (Which is approx the same as the bitrate of IP TPUs.)

I'm assuming it works like this as the router can't know how much overhead is generated by the modem, so I reason that the only units that the router can understand are the bit rate into the modem, plus or minus any essential overhead that may always be present regardless of modem type.

So I'm trying to work out what this payload data rate is given a particular u/s sync speed as reported by the modem. (20CN adsl1)

Luckily, the u/s speed values reported by the modems don't seem to vary often. One modem recently went up quite a lot, from 350 to 416. But it doesn't happen too often. It's a pain having to do this, what would happen if you only had one line? You underestimate, the line is unnecessarily slow, overestimate and the line oscillates or settles down and shows steady packet loss. If you have several lines perhaps it's all about getting the ratios right between the amounts of traffic going up each pipe.

I have been taking a look at the detailed graphs for upstream performance and buffering given by the excellent thinkbroadband speed tester in order to see if I'm pushing it too hard.

[burakkucat]

Wouldn't A&A be able to advise you how to estimate (or calculate) the parameters needed? 

[Weaver]

@burakkucat - that's a good point. ( Not thinking straight this week. Have been completely out of it most days. ) ISPs that use Firebricks presumably have this problem, but in reverse - that is, in relation to the downstream side.

A second point occurs to me. I'm still lacking a solution for the problem of where to get the raw numbers for u/s sync rate from, never mind the fudge factor which was the original subject of my post. Inspecting the modems manually every so often isn't really an intelligent solution. I wish there were standards for these things, obtaining modem stats via a sub-protocol that plugs into PPPoE would be nice.

[waltergmw]

@ Weaver,

There is a limited amount of data here:-

http://support.aa.net.uk/Category:FireBrick

I too have a starving Ewhurstian with 3 ADSL2 lines 

[Weaver]

From exhaustive performance tests, 0.8800 seems to be the magic number for upstream "sync". It seems to be ridiculously sensitive to slight tolerances, for god only knows what reason. If I reduce the fudge factor a bit below 2000/2272, then performance starts to wilt, but on the other hand if I increase the fudge factor slightly above 0.8800 then the result is a sharp high peak in initial throughput, followed by waves of instability and performance crippling droops. This is as shown on the time vs throughput graphs shown by the thinkbroadband speed tester. The speedof.me dslreports and ookla speedtesters were all used too for cross checking.

The overall initial 5 s (approx) throughput avg shown by speedof.me is 0.91 Mbps for three lines combined.

Either the time behaviour and fudge factor sensitivity are due to the performance of TCP to the particular speedtesters or to the behaviour of the Firebrick's traffic-shaper algorithm, or both.

[Weaver]

(Update: Since the previous post I've changed to 21CN and ADSL2. When I was so upgraded, I gained about 1.25  Mbps downstream, to 7.7 Mbps (measured effective total TCP throughput, using combined three lines). In the last six months or so, I've lost a lot of speed in both downstream and upstream directions. This is possibly due to increased crosstalk, the idea behind this theory being that a fair few new houses have been built recently. At one point I was getting over 1.1 Mbps effective total upstream throughput, but now it's down to ~0.9 Mbps. Again, reasons not known for certain. This is only 77% of the expected ideal combined total obtained by taking sync rates and converting them down to IP PDU throughput, done by multiplying sync rate by a fudge factor of 0.87 for ATM overhead, a figure that doesn't allow for IP headers, possible TCP headers, other lower-level protocol headers, which won't be that much assuming full length packets, but nor does that allow for DSL overheads such as FEC etc. Mind you, when comparing upstream with downstream, that fudge factor seems to work for downstream though, when converting downstream sync rates to true measured total TCP payload throughput)

Anyway -

As things stand, right now for some reason I now seem to get the same upstream performance without fine-tuning of the Firebrick upstream PPPoE bandwidth parameters. If I just simply set every line to a very high arbitrary upstream bandwidth figure, then it just seems to do the right thing, no worse than if you just tweaked it to be ‘right’. I don't know what this means, apart from probably indicating that I had or have gone mad and I've been seeing things. This is just simply what you would expect it to do, to just do the right thing and make the best use of the lines, whose speeds are for some reason nowhere near equal, line #1 being 25% faster than either of the other two. I must definitely be losing it.

[aesmith]

The Firebrick could be simply assigning each outbound packet to the interface whose egress queue is shortest, measured in bits rather than packets. 

[ejs]

but nor does that allow for DSL overheads such as FEC etc.

It does not need to. Any DSL level overheads have already been taken into account to give the "sync speed", technically known as the "net data rate".

[Weaver]

@ejs - that's good to know. I never knew exactly what it was that the various systems was reporting.

I retested this yet again and noticed something odd, if I run upstream at just under 0.87 * sync rate, the downstream throughput improves slightly. I repeated the test several times. This is something to do with the Firebrick being in charge of the upstream rather than the modems.