Print

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

[waltergmw]

@ BS,

Studies have shown that engineers will connect their HHT (Testers) at the EU's premises and see a synch speed of lets say 50Meg, they would then visit the Cabinet and see the same 50Meg speeds. They were then requesting a 'Lift & Shift' take place.

That's a very interesting observation which I suspect happens because of an interaction between the HHT and the DSLAM.
Those unfortunates not provided with a HHT may discover modem speeds as recorded by a BT Speedtest do still vary with line distance / quality (as I have observed - but only once).

However, unless you have an inverter, I don't suppose you could try that experiment ?

Kind regards,
Walter

[Black Sheep]

Below is an extract of a brief we received about uneccessary 'Lift & Shifts'. Hope it adds to your understanding of VDSL ?


NGA DLM profiles CCT’s perform differently to other forms of ADSL, and this means that the full sync speed will not be achievable at the PCP.

For example, if a CCT is syncing at 29MB at the End User’s premises, and there were no issues on the D-side pair, you should only expect to achieve sync of something around 29MB at the PCP.

A ‘Lift and Shift’ would initially increase the sync speed at the PCP, but DLM would eventually return the speed back to 29MB, as this is the maximum that the D-side can support.

[guest]

Below is an extract of a brief we received about uneccessary 'Lift & Shifts'. Hope it adds to your understanding of VDSL ?


NGA DLM profiles CCT’s perform differently to other forms of ADSL, and this means that the full sync speed will not be achievable at the PCP.

For example, if a CCT is syncing at 29MB at the End User’s premises, and there were no issues on the D-side pair, you should only expect to achieve sync of something around 29MB at the PCP.

A ‘Lift and Shift’ would initially increase the sync speed at the PCP, but DLM would eventually return the speed back to 29MB, as this is the maximum that the D-side can support.

Is it me or is that "brief" just stating the bloody obvious?

* rizla wonders if he missed something 

[Black Sheep]

Far from it.

As an engineer, when working on ADSL on a fault free circuit, you could test at the EU's premises and get 10Meg, you could then test again at the Cabinet at get 15Meg. If you test on the MDF, you will get 24Meg. Conclusion, the nearer you move towards the Exchange from the EU's premises, the greater the speed will be.

Working on VDSL is as the 'briefing' laid out stipulates. On a fault free circuit, you could have 10Meg at the EU's premises. If you then went to the DP or an Underground Joint, or the actual Cabinet, you would still see 10Meg.

Because of this 'misunderstanding', new engineers are assuming the VDSL speed will increase the nearer the Cabinet they go, as would happen with ADSL. Because it doesn't, they are assuming the port has gone faulty and are requesting a 'Lift&Shift'. The new port comes to life at the full 40 or 80 Meg at the Cabinet, and the engineer assumes he's fixed the fault. However, DLM will reduce the circuits speed back to 10Meg over the course of the next few days.

[guest]

I'd assumed the DLM was per-port anyway and was a fixed profile so unless you changed the port or reset the profile nothing much would change. The sub-loop (D-side) isn't unbundled in any way so I'd expect the profile at the linecard to be ISP-independent.

With your last post I can see where the ambiguity kicks in. Going to be a fair few more gotchas like that I reckon...

[c6em]

I confess I'm having some difficulty with this one.....

This result of constant sync regardless of distance can only be because of some peculiar interaction between the testing equipment and the DLM.
Otherwise the logic of losses in copper transmission totally breaks down and you have in effect invented a constant loss copper conductor with distance - the goal of superconductor research everywhere

Say we have a moveable house(!).
You test at the cabinet and get 40Mbps
You test at the DP up the pole with the extra length (200m) of copper in the circuit and you still get 40Mbps.
You test at the house with another 50 yards of copper in and still get 40Mbps.
OK lets move the house 2Km down the road and extra 2Km of copper in the cct - you still get 40Mbps - really?
I've got a good idea.....
So why not move the house 25Km away from the cabinet - do you now still get 40Mbps?

The only logical explanation (non instrument interaction) I can think of for the same sync at a closer point is the the DLM has got the answer of say 10Mbps fixed in its brain as what the line is capable of - and no matter how much better the line is as you connect in your tester ever closer to the cabinet then it ignores this and still uses 10Mbps as the sync speed.
Perhaps this is the reason why VDSL lines which suddenly get "better" have to have a reset done whereas under ADSL2 the line would automatically sync higher when the fault was cleared.
It also emphasizes how the end user should keep the modem on the best socket and not move it to say a worse performing socket.  Because if they do move it back to say the master or better socket then the DLM will not make the sync better........but then again people on here have changed their arrangements around and got worse and then better syncs.....

I'm scratching my head here..........maybe I'm misunderstanding all of this (Kitz, Asbo' the rest please help!)

[burakkucat]

As a scientist and techno-cat I must admit that the extract of the brief which Black Sheep posted, above, has resulted in a lot of head-fur scratching on my part. 

I would really like to see, verbatim, the briefing (as issued to Openreach staff) and the original information (origin Grimbledon Down, I presume), from which the briefing was created. It just does not make sense. 

[asbokid]

As the b*cat has pondered, the briefing must have been oversimplified, perhaps with the omission of an important "could do" or "may be".

Best guess for what it meant to say..

It's widely reported that DLM can, in the presence of adverse line conditions, force a 'banded profile' (as it has been dubbed). 

This is a configuration including a maximum net data rate. It is evidenced at the CPE by the reporting of very rounded figures for Actual Net Data Rates. Examples seen in the wild are 50,000kbps DS / 8,000kbps US.   The rounded nature of those data rates, rounded to the nearest 1,000kbps or even 10,000kbps, is the notable effect of a 'banded profile'.

The underlying effect of the banding is to keep the SNR high, ultimately giving greater stability with fewer resyncs.

That banding perhaps explains why the same data rates can *sometimes* be measured at the PCP and at the EU premises.   Just a guess though.

cheers, a

[waltergmw]

@ BS et Al,

I'd no idea my little comment would produce such a flurry.
Anyway thanks very much BS for telling us what you are being told, but I must admit the one experiment I observed seemed to follow what I'd expect the physics to be.

The thing we must however all remember is that DLM seems to react in the small hours a few days after a change has been made, always assuming that a DLM reset command was correctly processed. I suspect that what we might overlook are quite large noise bursts at let's say random times. In that case might I be correct to suggest that if a minor change to a line condition causes a minor speed increase that could be entirely swamped when the noise storm hits again and surely that must be a significant parameter in the DLM algorithm ?

I'd also guess that Grimbledon Down has considered some anomaly which is why the permanent cap is applied compared with auto-repairing ADSL2 logic.
I have taken my ultra-suspicious hat off as I can't believe that they are yet in desperate need to slug their traffic growth ??
The twisted pairs ought to do that for them with consumate ease !

Kind regards,
Walter

[Black Sheep]

Can't add much more, other than to say that what I have pasted was literally a couple of sentences less than the entire brief. I suspect Asbo and c6em have probably hit the nail on the head, in as much as the DLM 'bands' the profile, hence slight performance increases from socket to socket, but nothing drastic.
 
This is as opposed to ADSL that we know auto-corrects in line with attenuation.

Both scenario's are based upon fault-free circuits.

[Chrysalis]

Below is an extract of a brief we received about uneccessary 'Lift & Shifts'. Hope it adds to your understanding of VDSL ?


NGA DLM profiles CCT’s perform differently to other forms of ADSL, and this means that the full sync speed will not be achievable at the PCP.

For example, if a CCT is syncing at 29MB at the End User’s premises, and there were no issues on the D-side pair, you should only expect to achieve sync of something around 29MB at the PCP.

A ‘Lift and Shift’ would initially increase the sync speed at the PCP, but DLM would eventually return the speed back to 29MB, as this is the maximum that the D-side can support.

That brief confirms to be BT are drilling rubbish into their staff meaning when people like me get fobbed off the person telling me that truly believe it themselves.

What are you speaking of is probably line banding which the new DLM does instead of adjusting target noise margins (I assume so it cant be overriden by people tweaking the noise margin CPE side).

BT appear to have a policy on FTTC where there is pretty much no SLA/fault threshold, and that their DLM system can throttle without limits until things stabilise.  Combined with providing CPE's that hide information from the end user the result is the ability to lie to the end user.  On adsl there was eg. the FTR.

Also interesting is that line speed estimates clearly look hugely under estimated, they appear to be pretty much worse case scenarios meaning if someone has a line that matches their estimated speed whilst they may feel satisfied it probably means they either have a fault or high levels of crosstalk around the top of the percentile's expected but BT can pass it off as fine.

My personal case as an example.

Day 1 I had 80/20 sync.  Estimated 65.9/20 On HG modem, ECI dslam.
2 weeks later (if I remember right as was months ago now) I unlocked modem and the stats showed attainable of 110/36.
I noticed error rate was high considering how high my noise margin was and what others were reporting with short lines.  I was averaging around 300 crc errors a day and I did have occasional error bursts even when I had those stats.
24 hours after I unlocked modem attainable fell sharply to 90/36. so 2 weeks after install.
Week after that attainable fell again to 73/24.  With this sync speed and lost all my snr margin on the downstream I was now averaging 1200 crc errors a day, and the bursts now were serious when they occured causing me to be interleaved 3 times.

I probably would have got a better result if I at this point pushed the fault.  Openreach have a advisory that if the line drops 25% in a short time its a fault.  My problem was they look at 25% drop in visible speed.  Since everything above 80 is supposedbly invisible my drop was from 80 to 73 not from 110 to 73.  So I didnt report the fault.

Then later on 1-2 months later so about a month or so ago. I did report the fault as things started getting even worse, I had instability whilst interleaved, sync speeds falling below 60mbit, outages lasting multiple hours.  Initially when I escalated to the BT chairmans office the first guy @i had spoke to was very sympathetic and arranged the engineer.  But apaprently he was going on holday so someone else would be handling my case.  The new guy was nowhere near as sympathetic and when the engineer proved to be a fail, (basically he did basic jdsu tests, refused to do a pair swap and said because he couldnt find anything on his tests was nothing to be done.) he said if no more outages he will consider fault closed, my sync speed is above my estimate so thats that. (slightly above 66 sync 65.9 estimate).   I still at this point did not tell BT I had access to my stats instead I said I knew the line could do 110 as my install engineer showed me.  I was basically been fed information similiar to what bald eagle posted that its normal for a line to slow down after install as its by design.  the engineer visiting even claimed my initial 80 sync was impossible and thats on FTTP only. Welcome to BT fault resolution *sighs*.

Then I decided to let BT know I am a samknows tester, suddenly the guy decides I merit a new engineer so one is booked again.  He comes today, changes the cable from my pole and I think great someone who is motivated.  I also told this engineer I had the modem unlocked and I am not in the mood for fake information.

So my stats prior to the cable swap were 66/20 with 68/27 attainable.  My line is fast path still since the last engineer but on a banded profile capped to 74 down.  After the cable swap even with higher attenuation my attainable jumps to 97/39 yeah!! but with sync of 74mbit due to the banding.  fixed?  Sadly not.  BT in their wisdom decide even tho he has done the work to put in a new cable of the pole I had to be switched back to the dropwire that I was sharing with my neighbour in the above flat. SO I am back on my old lower sync.  I argued with a guy over the phone (I think his manager) for 20 minutes but the decision stands, back to shared dropwire.  The guy who booked the engineer from the chairmans office said he will get back to me, I said dont waste your time, get me quote for dedicated dropwire.  He said will ring me back tommorow.

Incidently after finding in BT's t&c's that they already breached my contract by refusing to fix previously I have already been offered a get out fo my entire contract without penalty and given 3 months free broadband, they have pretty much admitted the fault by their actions but refuse to fix it.

[Bald_Eagle1]

Working on VDSL is as the 'briefing' laid out stipulates. On a fault free circuit, you could have 10Meg at the EU's premises. If you then went to the DP or an Underground Joint, or the actual Cabinet, you would still see 10Meg.

An engineer visited today to 'investigate' my current speed having reduced to more than 25% less than my estimated speed.

He told me that DS speed is 27Mb at the cabinet yet his Exfo reported only 18845/5449 Kbps at my master socket.
He said that was normal & due to it travelling around 1300m from the cabinet & that sync speed at my home looked about right for a line of that length.

My HG612 was reporting sync speeds of 20764/4859 Kbps immediately before he unplugged it to plug in his Exfo.

Just before he left, my HG612 connected & reported sync speeds of 20667/4774 Kbps.


Could the engineer have been mistaken or does this suggest the line isn't actually as error-free as his PQT & Eclipse tests suggest?

When I also mentioned that Interleaving had recently been unexpectedly turned off, he said that's how VDSL2 connections always run i.e. on Fastpath.

Hmmm.........................................

[ryant704]

Eagle, all tests should be done with FastPath on though that isn't what he said but it could of been what he meant.

[asbokid]

He told me that DS speed is 27Mb at the cabinet yet his Exfo reported only 18845/5449 Kbps at my master socket.  He said that was normal & due to it travelling around 1300m from the cabinet & that sync speed at my home looked about right for a line of that length.

I bet it was 27,400Kbps!  That's the maximum downstream bit rate used in a handful of the ~200 banded* channel-profiles [1] that Openreach can bind to a VDSL2 subscriber port.

In a sense, the problem is self-acknowledged. Insofar as you might expect closer to 27,400Kbps than 18,845Kbps.   Given that there are intermediate channel-profiles with maximum downstream bit rates closer to the one at which you currently sync.  Why wasn't your port bound to one of those lower speed profiles?  Because the DLM algorithm observed higher rates on your line in the past?

Have you given the ECI a try?  Aside the non-existent web user interface,  it is otherwise quite impressive in performance.

cheers, a

* in a sense, every channel-profile is "banded", even the 80/20, 40/10 and 40/2 profiles.  Those are the maximum possible bit rates in the "banding".   In many cases, the line could sync at a higher speed than that offered in the end-user contract.  In those cases, the maximum downstream rate is still capped or "banded" to 80/20, 40/10 or 40/2.

In your case, the maximum downstream bit rate (that's the upper edge of the "banding") of your latest fastpath channel-profile appears to be 27,400Kbps.  And that was the speed the engineer witnessed with his Exfo at the DSLAM.

[1] see attached

[burakkucat]

A thoroughly confused b*cat goes to find his bed.