BT Infinity Option 2 (76mbps down / 19mbps up)

Can people on this package or any other package that has the same speeds post thier results in this thread for comparasion please.

Can you include what speeds were estimated on the BT speed checker and the actual results.

e.g.

Estimated: WBC FTTC Up to 61.8 Up to 20 -- Available

Actual: 57.99 Mbps

Speedtest link: http://www.thinkbroadband.com/speedtest/button/13686...

TIA!

Edited by Bobby_Valentino (Wed 15-May-13 10:09:42)

http://www.thinkbroadband.com/speedtest/button/13686...

sync is 66387/20000

estimated at 65.9/20

Edited by Chrysalis (Wed 15-May-13 10:11:44)

My original estimate was 55 Down & 19 Up

Actual is now 59.8 to 60.2 Down and about 18 Up

http://www.thinkbroadband.com/speedtest/button/13686...

My down speed was a little erratic at around 54 with up being 8, then down became even more erratic in the high 40s. When the Low upstream was cured and downstream stabilised back at low 50s, I changed from a Huawei HG612 modem to an ECI and the downstream went up to 60Mbps where it remains. Now need to work out why I have such a slow ramp up on my upstream especially as the attainable is around 26Mbps.

I was predicted 66Mb/s I think (it was over a year ago). I was initially connected at full speed but since autumn and especially over winter my line has worsened. I'm now connected at just under 66Mb/s and have interleaving in place.

So from memory I'm getting what was originally predicted but I'm still hopeful it will improve over the summer.

Most recent test:

http://www.thinkbroadband.com/speedtest/button/13684...

Edited by Andrue (Wed 15-May-13 10:44:07)

Original predicted speed was based on 40/10 product and I cant remember what it was anyway but when I do it now it predicts 63.3 down and upto 20 up.

Actual is usually between 74-76 down and 16 up.

Cabinet is about 100-150 metres away.

Speedtest Result

Estimate 58/20

Max available download sync usually around 82
Actual sync speed usually around 72
Speedtests just under 70

Real upload was around 17Mbps, up to 18.5Mbps when I disabled QoS.

~~~
Slower speeds just at the moment because of an unsuccessful experiment with HG622.
53 sync, 50 speedtests.
I expect this to repair fairly soon back to 72/70 speeds above.

Estimate was 61 down & 20 up

Actual sync is 79999/20000

In reply to a post by TheHorseman:

Estimate was 61 down & 20 up

Actual sync is 79999/20000

wow, pretty similar to mine but for some reason im getting 58mbps down and 8mbps up...bit weird? I wonder if it takes time for the speed to go up?

Would it be worth unlocking the modem to see what speed I'm syncing at and what the full potential is?

Estimate is 57/20

Currently 47/10, which is the highest I've been for a long time, highest I've ever had was 52/12. I was 42/10 for a long time.

Was first on the cabinet last August.

Bobby, it would be worth unlocking if you have the HG612, but it may well make no difference, my line is low for the distance of 450 meters and I got nowhere trying to sort out why.

Edited by R0NSKI (Wed 15-May-13 15:46:17)

In reply to a post by Bobby_Valentino:

wow, pretty similar to mine but for some reason im getting 58mbps down and 8mbps up...bit weird? I wonder if it takes time for the speed to go up?

Speed rarely goes up from the initial experience.

If a line is working OK, then the most significant impact is crosstalk from other subscribers. As take-up increases, crosstalk only tends to increase, so speeds only tend to go down.

Worse than that, the impact of crosstalk is quite random, as it depends on exactly which other subscribers have taken FTTC, and where their pair lies within the cable bundle relative to yours. That means the majority of the effect can come from just one or two other lines - and you're highly dependent on whether those lines do, or don't, take the service.

On a line of 400 metres, someone could initially experience a speed of 80 (with an attainable of 90), and find that it decreases to 70, 60 or even 50.

And that's if the line is working fine. If it isn't, then all bets are off.

In reply to a post by WWWombat:

If a line is working OK, then the most significant impact is crosstalk from other subscribers. As take-up increases, crosstalk only tends to increase, so speeds only tend to go down.

Yes, I seem to have a good line. My max attainable when I first changed to Infinity 2 was around 101/34, it has now fallen to around 90/34. Unfortunately I do not know how full my cab is so it may fall further. (though I hope not).

Better than the predicted and sync around 21000

WBC FTTC Up to 14.3 Up to 1 -- Available
WBC ADSL 2+ Up to 1 -- 1 to 3.5 Available
ADSL Max Up to 1 -- 0.75 to 2.5 Available
WBC Fixed Rate 0.5 -- -- Available
Fixed Rate 0.5 -- -- Available
Other Offerings
Fibre Multicast -- -- -- Available
BET Up to 2 -- -- Available


http://www.thinkbroadband.com/speedtest/button/13686...

Estimate: 26.3DS 5.6US

First Sync 36DS 6US

Now 25.8DS 5.2US

BT estimate is 66 down 20 up.

Was getting 80/20 until local power problems with HT cables saw big drop in speed and erratic changes of interleave due to frequent power outages.

Put modem/router onto battery backed UPS and hey presto back to 80/20 and back on fastpath with <10,000 FEC errors a day.

the moral of the tale is that a dirty power supply can affect electrical equipment big time as well as line quality.

more likely to go down than up I am afraid, you might get lucky and openreach fix a fault somewhere which helps you, but more likely will go down with crosstalk.

I actually started on full sync but now get significantly lower.

My neighbour who managed to get a better pair now has crosstalk again, so his fix didnt last that long.

In reply to a post by Chrysalis:

My neighbour who managed to get a better pair now has crosstalk again, so his fix didnt last that long.

That's interesting.

Do you or your neighbour have any stats/graphs that demonstrate the changes between no crosstalk & then with crosstalk?

The QLN/SNR graphs are possibly the most likely to show something changing.

yes and I have posted mine before, but I cant do that animation thing you did.

Basically the difference is the QLN goes up, on my line it went up on D1 a lot, D2 a little and barely at all on D3 but of course D3 is the weakest part of the frequency. SNR went down a lot, most of the loss of SNR on D1, a bit on D2 and D3 not affected much. My SNR on D1 isnt much higher than D2 now, D1 has taken a battering.

Hlog stays the same as well as attenuation.

ok here is some I made, the SNR has 3 stages as it seems I have had further loss since the first time I got hit with crosstalk. So actually D2 was also badly affected although not so apparent on the snr.

qln crosstalk
snr crosstalk

Edited by Chrysalis (Fri 17-May-13 10:04:46)

Quite dramatic changes shown there (a bit too quick to view clearly for my eyes though)

Do you have any idea if that was caused by just one new user or by a batch of new users?

unfreez is brilliant for creating animated gifs. Small, stand alone, free. Also has a delay setting.

I was bored so here you go BE:

QLN-CT.gif
SNR-CT.gif

Initial estimate: 60.7 / 20
Current estimate: 62.9 / 20
Current Sync: 77678 / 20000

http://www.thinkbroadband.com/speedtest/button/13688...

Infinity2

EST (BT Checker)

WBC FTTC Up to 72.1 Down, Up to 20 Up
WBC ADSL 2+ Up to 3.5 Down, 2.5 to 4.5 Up
WBC ADSL 2+ Annex M Up to 3.5 Down, 2.5 to 4.5 Up
ADSL Max Up to 2.5 Down, 1.5 to 5 Up

Actual (reported from modem)

Attainable rate (kbit/s) 100028 33003
SNR margin (dB) 11.6 14.3
Line attenuation (dB) 0 0
Output power (dBmV) 13.5 -1.9

Speedlink

http://www.thinkbroadband.com/speedtest/results.html...

Upload is normily MUCH better then that report.

Hi

As is the case with ADSL, interference due to cross talk is going to be very low in the early days of deployment, and so this will likely see more people reporting better than the estimated speeds that will have been calculated to take into account cross talk.

The more people that join the service to a cabinet the more potential for cross talk and it is very likely sync speeds will have a tendency to drop over time.

I lot of people saw the same issue on ADSL2+, very noticeable to those getting >20Meg on ADSL2+ for being an early adopter, then seeing that continually drop bit by bit until they were on much less once the wider rollout of ADSL2+ services took place. A lot drove themselves mad fault reporting or fiddling with settings and wiring to blaming the ISP for slowing them down.

We just have to accept given we are still using decades old telephone wiring for part of the signal that estimated speeds from BT are always going to be just that, and that these cables will cause and allow themselves to be affected by interference and cross talk.

I expect those doing better than the estimate now, given a few more people signing up and sharing their cabinet will see their speeds fall to come ever closer or even below the estimate.

So don't drive yourself insane worrying about your sync speed being a bit less than an estimate and enjoy your connection which is considerably faster than the speeds of many.

Regards

Phil

In reply to a post by Croftie:

I was bored so here you go BE:

Haha! Thanks Croftie

the one with just 2 images animating is taken a week apart, that difference was all in one go so very likely just one customer, also the first image already had crosstalk, as it was taken on my 90/36 when I started off on 110/36.

the one with 3 images is the first 2 the same dates as the QLN, the 3rd is a more recent image,

Edited by Chrysalis (Sat 18-May-13 11:54:23)

there is no garuantuees of it been low early, its just more likely.

I was first on my cab but just 2 weeks later the affect on my posted image was there. Since then the next 6 months has much less crosstalk introduced but as can see with the 3rd image still some introduced, I was just unlucky a evil pair next to mine was made FTTC enabled so quick.

Does the sync speed change automatically on FTTC or does the modem have to reboot for a change of sync?

The cabinet->modem sync changes automatically. DLM forces a modem resync (without reboot) when it thinks the time appropriate.
Usually in the middle of the night to minimize user disruption.

BUT the IP/BRAS profile is derived from the sync speed on PPPoE connection; between the router and the exchange at a higher level.
Sometimes (often in my experience) the modem resync is so quick that the PPPoE connection is not dropped, so no new connection made, so the IP Profile is stale.
If you have any reason to think that there may be a low level sync improvement, it is worth disconnecting and reconnecting the HomeHub (or other router).
So after a sudden drop in speed, disconnect/reconnect first thing each morning in case there was a sync improvement overnight.

If you have an unlocked modem, you can see the sync improvement so no need for daily trial and error reconnect of router.
Just reconnect when the sync rises but the profile doesn't.

~~~
Improvements to latency will happen automatically on low level resync, no need for router to match.

Openreach has configured a vdsl line-profile in which the upstream and downstream transmission rates are adapted at start-up only. After line activation, the transmission rates cannot change. Any change to the transmission rates requires the retraining of the line.

Openreach disables the feature, but the Huawei MA56xx DSLAMs can also dynamically adapt transmission rates at runtime (i.e. during showtime). If enabled, this does not require the retraining of the line.

cheers, a

Shhhh! Don't let Chrysalis read that .

In reply to a post by asbokid:

Openreach has configured a vdsl line-profile in which the upstream and downstream transmission rates are adapted at start-up only. After line activation, the transmission rates cannot change. Any change to the transmission rates requires the retraining of the line.

Openreach disables the feature, but the Huawei MA56xx DSLAMs can also dynamically adapt transmission rates at runtime (i.e. during showtime). If enabled, this does not require the retraining of the line.

cheers, a

SRA?

I read it , but obviously openreach have their reasons for not utilising it. Most likely hard to get proper CPE compatability.

Actually another little think I am guessing the IP profile system is a reason why they turn it off, currently if the speed changes it needs a resync and mostly also a ppp recconect which establishes a new IP profile. Put SRA into the mix and IP profile would never update as both sync and ppp wouldnt drop.

Edited by Chrysalis (Sun 19-May-13 06:38:33)

BE trialled SRA (obviously not for VDSL) some time ago, and decided not to go ahead; I don't know the reason. It looks excellent on paper, but I assume there are enough technical issues that the actual gains didn't make up for the pains.

I can't recall where I saw this, but it was a document on a variety of DLM/DSM techniques...

The impression I got for SRA was that it worked well on an individual line (ie DSM level 1 activities), but wasn't very good in terms of spectrum efficiency to other users (ie DSM level 2). Something where it effectively caused everyone to run at highest power, and therefore increase crosstalk.

I'll try to find it.

Edited by deleted (Sun 19-May-13 12:29:17)

The issues on ukonline is it only worked with a very small amount of equipment, typically the older billion 7402s. But when it did work it was a complete transformation for poor lines. On good stable lines probably not so much a benefit as I dont really miss it on FTTC, but on my adsl service it was a complete game changer, I went from 3 to 100 or more drops a week to having sync uptimes around a year (on 6db margin, fast path).

In reply to a post by Chrysalis:

In reply to a post by asbokid:

Openreach disables the feature, but the Huawei MA56xx DSLAMs can also dynamically adapt transmission rates at runtime (i.e. during showtime). If enabled, this does not require the retraining of the line.

SRA?

Yes, Seamless Rate Adaptation.

Although what Openreach does implement for dynamic rate adaptation is a theoretically superior method, any way.

By opting for a bespoke centrally-controlled DSM Level 1 / DLM algorithm, the network operator isn't stuck with the vagaries of a vendor-specific DSLAM-based solution. The algorithm can be updated or even replaced altogether at any time. And, fundamentally, it can tweak a range of parameters in the channel-profile, not just the data rates.

The SRA is limited to tweaking the minimum and maximum data rates (banding), but the Openreach DLM algorithm can also modify the interleaving delays and impulse noise protection levels (and theoretically the TSNRM too). And by centrally logging that line data on an individual basis, long-term trends for a line can be discovered heuristically by the algorithm, too.

When a subscriber port is initially activated at the DSLAM, a line-template is bound to the port. That template comprises three components: a line-profile, a channel-profile (and an alarm-profile).

The line-profile is configured identically on all lines across Britain since much of it is stipulated in regulations. For example, the line-profile defines the VDSl2 profile (17a), the PSD class mask (B8-11), the DPBO and UPBO PSD masks, as well as the target SNRM (6dB) and the rate adaptation method (set at startup), etc.

However, there is just that one, solitary line-profile in use in the copper access network.

In addition to the line-profile, Openreach uses nearly 200 different definitions of channel-profile. These channel profiles specify the minimum upstream and downstream bit rates (that's the banding part of the profile), the minimum reserved bit rates, the interleaving depths, and the minimum INP levels, etc.

During its daily iterations, the centrally-controlled DLM algorithm processes all of the individual line data that has been retrieved (by ANCP/SNMP) from DSLAMs under its control. This data is examined to discover the number of coding violations and the number of (downward) re-trains on a given line. The algorithm then classifies the line under one of those 200 different channel profiles. This could see, for example, the interleaving and INP levels raised and/or the introduction of fixed maximum and minimum data rates to increase stability. Or, ideally, the channel-profile will be left completely unchanged.

cheers, a

edit: here are the Huawei docs for configuring a TR129 VDSL Channel Profile [1]. The docs illustrate the range of parameters that can potentially be tweaked by the DLM algorithm.

[1] http://pdfcast.org/pdf/tr129-vdsl-channel-profile-ad...

Edited by deleted (Sun 19-May-13 22:29:30)

well which is superior I guess depends on what way you score it.

I look at outages and affect on latency.

The DLM system requires an outage to make an adjustment, SRA does not. SRA doesnt touch latency, and I consider a loss of speed superior to a bump on base latency, especially as interleaving tends to reduce speed on top of the bump on latency. Plus I think that DLM simply can go too far, not go far enough, act too late etc.

eg. if we think back to my previous issues on my FTTC line I had a 2 hour occurance in the early hours of the morning of noise on my line of some sort. DLM did nothing whilst that was ongoing, but then some time later after it stopped it applies interleaving to my line affecting the line performance when there is no longer a problem. Whilst SRA would (when it works) react near enough instantly to any problems.

I think unless one has suffered from a very bad line they cannot appreciate how good SRA is. On my old ADSL line DLM was near enough useless. Isp tech's consistently berate DLM as well saying when they compare they find bad lines perform better without DLM.

I am less fussed now as I no longer am suffering like I did on my adsl line. But I still find DLM annoying, makes me scared to do anything with my modem incase I upset DLM.

Edited by Chrysalis (Sun 19-May-13 19:40:48)

makes me scared to do anything with my modem in case I upset DLM. All part of their devious plan.

I found my references.

The thing that seemed to work worst on external effects - labelled "zap your neighbour first" in one paper [1] - was called "Virtual Noise". It causes DSL to end up like everyone shouting at a party.

SRA wasn't so bad [2]. It seems to be aimed at SLOW changes to the noise picture, not fast ones. The negatives were that it still gave a problem to power control of the line - As the line adapts down, it used less power, but as it adapts up, the power goes up too.

I think that prospect is probably the killer when DLM propagates to level 2 - when the aim is to manage the power level of all the lines, so spectrum (power and frequency) gets shared more equitably. It doesn't work in a predictable way if the lines are then "randomly" altering their power settings.

In the meantime, we've definitely shifted from the AMA style of DLM to TRA [3].

[1] http://www.stanford.edu/~achowdhe/Papers/Inderscienc...
[2] http://www.broadband-forum.org/technical/download/TR...
[3] http://www.niccstandards.org.uk/files/current/NICC%2...

I think it was designed to deal with gradual changes like daytime to nightime, however on my adsl line it did also work pretty well in dealing with large sudden noise bursts,which without SRA would have either left the modem holding onto sync but with unusueable internet or a resync. It was able to make instant large % swings to sync speeds without downtime eg. from 6400kbit to 4500kbit in one split second when a noise burst started.

However with that said, the SRA utilised on ukonline wouldnt have helped my FTTC fault, because that SRA worked by making the snrm stick like glue to the target snrm. So if eg. the snrm fell to 5db the sync speed was reduced to peg the snrm back to 6db. On my FTTC fault, the snrm did not change, I just had a burst of errors but no change in noise margin. But there is a 2nd type of SRA which monitors error rate and adjusts sync speed independent of the current snr based on error rate, that 'may' have helped my FTTC fault.

Edited by Chrysalis (Tue 21-May-13 17:16:55)

Hi

SRA is really the next step up from bit-swapping. When bit-swapping runs out SRA can "sell back" some sync speed for SNR and have room again to bit-swap, then when SNR improves it trades it back for sync speed. This can happen in almost real-time without the line needing a full retrain and so no disruption for the user.

While BT may have some complicated algorithms going on, they can't react in real-time and any changes only take effect after a retrain. SRA is designed to avoid the retrain in the first place.

The problem with SRA generally is compatibility between equipment and that for the vast majority bit-swapping and interleaving was enough to give a stable line without the need for SRA. For those still having problems the SNR just got upped!

Regards

Phil

estimate FTTC 80 down/20 up, actual 76 down/18.5 up