When I first got FTTC (10 months ago) the max attainable rate was around 136000 downstream and 36000 upstream, which is now down to around 90000 and 30000 (from memory). Would bald_eagle be interested in seeing some graphs and stats from the HG612 (I haven't done anything to the ECI modem)?
When I first got FTTC (10 months ago) the max attainable rate was around 136000 downstream and 36000 upstream, which is now down to around 90000 and 30000 (from memory).
Yes, I would indeed be interested, especially if you have any from when attainable rates were higher to compare against what they have been more recently.
An excellent speed but still quite a dramatic drop. Presumably accounted for by crosstalk eating into your sync speed, as more households sign up for VDSL2 from your cabinet. It also provides a rationale for clobbering the maximum actual rate to 80/20, as Openreach has done via the BRAS profile. In effect, that profile has introduced a margin to play with. The high syncing end-users can afford to lose that margin before the degradation becomes evident in their actual surfing experience.
cheers, a
It was wise of you taking note of the sync speeds at the time of installation. Many people have valid arguments of a developing line fault, but without physical evidence to prove that - such as screenshots or graphs, it can get difficult.I lost the original stats like I said, but at least I have some high speed (thanks Dropbox) ones just in case.
cheers, a
Yes, I would indeed be interested, especially if you have any from when attainable rates were higher to compare against what they have been more recently.
I called Sky complaining of a speed fault after it had got to the point of the upload hitting 10000. I was happy when the upload went down to around 15000 but getting under 10Mb/s just bugged me (when I had seen the max attainable speeds on install). I basically had to argue with the Sky Fibre Team lady, at one point she said it must be the router, which it obviously can't be (when I can see my sync, shh), she did three line tests, the first and third had shown that the line was fine but the second had shown a fault, it ended in me saying I'll pay for the engineer and then she put me on hold and spoke with her manager (I think), once she came back she said are you available tomorrow, I was, and he came the next day, at about 12 I think. I never got billed for it, rightly so as the fault wasn't past the Demarcation Point.
An Openreach engineer was here for about two hours, he looked at the line and eventually came to the conclusion that a 'lift and shift' was required, so he contacted someone to do the 'lift and shift' (who came from the exchange, I think). The DSL light was off for at least half an hour. The DSL light eventually game back on and he came back a few minutes later, ran some tests, I think the line length said something like 263 metres on his JDSU (the Openreach engineer who originally installed the faceplate didn't have a JDSU).
I'd also like to mention I may of had around 46000 max upload on day 1, not 36000.
Just for information purposes. A) A 'Lift & Shift' does not require anybody to "Come from the Exchange", it will be done there and then by the same engineer who visits the premises. Initially, when FTTC first came to market, it could take up to 3hrs to get a new 'Port' at the Cabinet. It now takes approx 30-45mins to achieve.
B) A lot of FTTC 'Lift & Shifts', have been found to have been not necessary. 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.
This shouldn't happen, as unlike ADSL, where the closer to the cabinet/Exchange you test for speeds, the higher the said speed will be. VDSL's DLM speed remains static wherever you test in the network from Cabinet to Premises.
Comms have been put out to those who need to know and this should remove the many 'L&S' being submitted.
Thought it worth pointing out as Splash may be under the impression his 'fault' was cured. In the interests of balance, his circuit could well indeed have had a faulty port, and a 'L&S' was necessary ??
I had to upload the file to Dropbox because the size was too large for an attachment on here.
This shouldn't happen, as unlike ADSL, where the closer to the cabinet/Exchange you test for speeds, the higher the said speed will be. VDSL's DLM speed remains static wherever you test in the network from Cabinet to Premises.
Comms have been put out to those who need to know and this should remove the many 'L&S' being submitted.
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.
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.
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.
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.
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.
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.
A thoroughly confused b*catMe too, but I think this is a very important discussion that we're starting here about the FTTC DLM.
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.IIUI right, this means that there are ~200 variations on a capped IP profile (of one kind or another, i.e. the parameters involved are not just restricted to max line sync rate). Is there a list of them with the max sync rates anywhere? From BE's and my own experience (and I'm sure Chrysalis could add to this too) between us we have (it seems) observed in DS 80, 67, 54, 35, and 27 (I will ignore US for the moment).
I have observed two quite different situations almost as if the DLM has a blacklist of performance criteria,I'm sure both BE and I (and a lot of others no doubt) would like to know what those performance criteria are that leaves us both unshakeably capped - and in BE's case it seems worse than that, in that it appears that he has a max capped value of 27 but still syncs >25% lower than that, which after 14 days, is by BTOR's definition a fault worthy of invesigation.
A "Good" line will adjust around a set of different sync speeds presumably as line conditions vary with every power-reset.
A "bad" line, usually due to some execrable installation procedures remains capped
Have you given the ECI a try?No, but I do have one to hand. However do you seriously think that its potentially better performance will cause the DLM to remove the blacklisting? I'd be willing to try it, and if it worked (which I have to say I would doubt), then I would quite happily send mine to BE to let him try to, if he wants. Even now, if he wants - I can wait till later.
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).To some extent I believe that this is so, but not entirely, as BE has also had fastpath removed. But is that a temporary or a permanent change e.g. have BTOR updated the profiles recently? :shrug2: I don't know but it is suspicious.
I don't have my current Profile Name from Plusnet, but this is how they reported it at one point - before the physical line problems were finally repaired during May 2012:-
Profile Name 13.7M-27.4M Downstream, Interleaving High - 0.128M-0.8M Upstream, Interleaving On
Time Stamp 2011-07-28T12:44:35
It would perhaps have been more helpful if the engineer had mentioned my PROFILE band rather than sync speed at the cabinet.
As you say, I suspect my profile is currently similarly banded, but with Interleaving OFF.
MA5616(config)#vdsl channel-profile modify 999
Start modifying profile 999. New setting will take effect automatically after the modification succeeds
Press 'Q' to quit the current configuration and new configuration will be neglected
> Data path mode 1-ATM, 2-PTM, 3-Both (1~3) [2]:
> Will you set the minimum impulse noise protection? (y/n) [n]:y
> Minimum impulse noise protection downstream:
> 1-noProtection 2-halfSymbol 3-singleSymbol 4-twoSymbols
> 5-threeSymbols 6-fourSymbols 7-fiveSymbols 8-sixSymbols
> 9-sevenSymbols 10-eightSymbols 11-nineSymbols 12-tenSymbols
> 13-elevenSymbols 14-twelveSymbols 15-thirteenSymbols 16-fourteenSymbols
> 17-fifteenSymbols 18-sixteenSymbols
> Please select (1~18) [1]:
> Minimum impulse noise protection upstream:
> 1-noProtection 2-halfSymbol 3-singleSymbol 4-twoSymbols
> 5-threeSymbols 6-fourSymbols 7-fiveSymbols 8-sixSymbols
> 9-sevenSymbols 10-eightSymbols 11-nineSymbols 12-tenSymbols
> 13-elevenSymbols 14-twelveSymbols 15-thirteenSymbols 16-fourteenSymbols
> 17-fifteenSymbols 18-sixteenSymbols
> Please select (1~18) [1]:
> Will you set interleaving delay parameters? (y/n) [n]:y
> Maximum interleaving delay downstream (0~200 ms) [0]:
> Maximum interleaving delay upstream (0~200 ms) [0]:
> Will you set parameters for rate? (y/n) [n]:y
> Minimum transmit rate downstream (32~200000 Kbps) [13700]:
> Minimum reserved transmit rate downstream (13700~200000 Kbps) [13700]:
> Maximum transmit rate downstream (13700~200000 Kbps) [27400]:
> Minimum transmit rate upstream (32~200000 Kbps) [128]:
> Minimum reserved transmit rate upstream (128~200000 Kbps) [128]:
> Maximum transmit rate upstream (128~200000 Kbps) [800]:
> Will you set rate thresholds? (y/n) [n]:y
> Rate threshold downshift downstream (0~200000 Kbps) [0]:
> Rate threshold upshift downstream (0~200000 Kbps) [0]:
> Rate threshold downshift upstream (0~200000 Kbps) [0]:
> Rate threshold upshift upstream (0~200000 Kbps) [0]:
> Will you set PHY-R function? (y/n) [n]:n
> Will you set erasure decoding? (y/n) [n]:n
> Will you set SOS bit rate? (y/n) [n]:
> Will you set the G.998.4 retransmission function? (y/n) [n]:
> Will you set channel initialization policy selection? (y/n) [n]:
Modify profile 999 successfully, and new setting is taking effect now
The flow for the profile to take effect is complete
MA5616(config)#
So, is it still likely that actual speed at the cabinet has negotiated downward to what my line can achieve i.e. identical to the actual speed I am seeing at home (still within the banded profile)?
Openreach can just define new channel-profiles with new parameters, whenever needed.that's what worries the hell out of me! :o I'm off to plusnet to ask for the name of mine ....
Such is the beauty of a bespoke, centrally-controlled DLM algorithm.Possibly, but only in the hands of people who understand what they are doing. :( While there may well be teflon-heads at Martlesham who might, I suspect that the 'portfolio' of profiles available are as likely as much to have been 'influenced' by the marketing department as the technologists. (OR are no different from anybody else in that respect :))
since SNRm does not appear to form a direct part of the profile, I guess DLM must have to calculate a rough SNRm to achieve the desired max rate once it knows from the training period what the likely bit loadings would otherwise be? :(
The same system has three levels of Interleaving shown to us a '1'- No Interleaving, '1'- Low Interleaving, '1'- High Interleaving.
Just for info ......... there are 36 levels of banding that can be applied by Rambo, from 0.125Kbps up to 80Meg.
The same system has three levels of Interleaving shown to us a '1'- No Interleaving, '1'- Low Interleaving, '1'- High Interleaving.
Cheers.
Just for info ......... there are 36 levels of banding that can be applied by Rambo, from 0.125Kbps up to 80Meg.That seems to correspond to something I've seen elsewhere, where (it is said) that the ISP can request on behalf of the EU one of 3 VDSL profiles Gaming (No interleaving?), Standard (Low), and Stable(High). :)
The same system has three levels of Interleaving shown to us a '1'- No Interleaving, '1'- Low Interleaving, '1'- High Interleaving.
there are 36 levels of banding that can be applied by Rambo, from 0.125Kbps up to 80Meg.You must be refering to DS then? Are these tabulated anywhere (like here in Kitz perhaps? ;)) in a form like the ones quoted by PlusNet? Does every DS band have a fixed corresponding US band? If not, are we talking 36 DS x ?? US combinations? ???
Ha ha, you would think, wouldn't you ?? It may be just how the 'Override' system is laid out at 'our' end and could quite possibly present itself as 1,2,4,8 ...... etc etc, or 0,1,2 ...... when you guys look at the Modems ??
But, it is as I quoted above.
So the combinations are:What I'm wondering :hmm: is whether ATM they are only really using (some) of the first in the DLM, and none of the rest, and that is possibly the change that a lot of people are reporting. So as BE says, he has seen different interleaving depths in the past, but all of a sudden he's on fastpath but with a restrictive banding?
- 36 transmission rate bands (an extendable? range of max and min down- and upstream rates);
- 3 choices of maximum interleaved-delay (no=0ms, low=8ms and high=16ms) in the downstream;
- 2 levels of max interleaved-delay (0ms and 8ms) in the upstream; and
- 7 levels of INP protection (from no protection to 10 symbols)
I don't have my current Profile Name from Plusnet, but this is how they reported it at one point - before the physical line problems were finally repaired during May 2012:-
Profile Name 13.7M-27.4M Downstream, Interleaving High - 0.128M-0.8M Upstream, Interleaving On
Time Stamp 2011-07-28T12:44:35
It would perhaps have been more helpful if the engineer had mentioned my PROFILE band rather than sync speed at the cabinet.
Plusnet did disclose your channel-profile in so many words. There are just a couple of channel-profile parameters absent from its report: the exact interleaving delays, down and up, and the INP levels, down and up (and the reserved transmission rates).
Unless your D-side was zero centimetres long, the sync speed measured at home will always be lower than the sync speed measured at the cabinet, with one big caveat.
The only time that the sync speed at home will match the speed at the cabinet is when it has hit the maximum transmission rate/s defined in the channel-profile.
If the sync speeds would otherwise exceed those maximums then the line will be banded or capped to those maximum rates (e.g. 27400/13700 in your case).
And that is the circumstance when the speeds measured at home are identical to those measured at the cabinet, as per the engineers' note from Openreach, posted by BlackSheep.
Maybe it was a 20M-40M Profile & the speed loss over 100m to 1300m line length brought it down to 30Mb at my home.I think getting and understanding that is part of the key here. On the one the quoted to me today for my line, you can see that I am clearly maxing out their banding, and frankly would probably also max out a 67-80Mb band too, so why won't the DLM back off to that? I can't see anything to prevent it? Not now anyway. :( However, it is certainly coincidental if not suspicious that that banding is closer to their 69Mb prediction rather than the reality. :(
Just for info ......... there are 36 levels of banding that can be applied by Rambo, from 0.125Kbps up to 80Meg.That seems to correspond to something I've seen elsewhere, where (it is said) that the ISP can request on behalf of the EU one of 3 VDSL profiles Gaming (No interleaving?), Standard (Low), and Stable(High). :)
The same system has three levels of Interleaving shown to us a '1'- No Interleaving, '1'- Low Interleaving, '1'- High Interleaving.
there are 36 levels of banding that can be applied by Rambo, from 0.125Kbps up to 80Meg.You must be refering to DS then? Are these tabulated anywhere (like here in Kitz perhaps? ;)) in a form like the ones quoted by PlusNet? Does every DS band have a fixed corresponding US band? If not, are we talking 36 DS x ?? US combinations? ???
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......................................... ???
[EDIT] Chrysalis observed earlier in the threadQuoteWhat 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).To some extent I believe that this is so, but not entirely, as BE has also had fastpath removed. But is that a temporary or a permanent change e.g. have BTOR updated the profiles recently? :shrug2: I don't know but it is suspicious.
Simply using banded profiles with max sync rates like that is a very crude way of managing line conditions, but if they were doing that it might explain some things we are seeing e.g. reduced profile maxes while DLM still apparrently believes there is no need for either interleaving or INP.
The cynic in me wonders if BTOR are quietly banding everyone at the next nearest profile to the official BTOR 'Estimate'? :o
[EDIT] Chrysalis observed earlier in the threadQuoteWhat 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).To some extent I believe that this is so, but not entirely, as BE has also had fastpath removed. But is that a temporary or a permanent change e.g. have BTOR updated the profiles recently? :shrug2: I don't know but it is suspicious.
Simply using banded profiles with max sync rates like that is a very crude way of managing line conditions, but if they were doing that it might explain some things we are seeing e.g. reduced profile maxes while DLM still apparrently believes there is no need for either interleaving or INP.
The cynic in me wonders if BTOR are quietly banding everyone at the next nearest profile to the official BTOR 'Estimate'? :o
Ironically its a way to claw out of BT infinity contract without penalty.
BT state "We wont slow you down"
Banding does exactly that. (interleaving does also). i have already tested it, I was given a copout of my contract simply because DLM "slowed me down". If they had to keep it legal, then everyone would have a max banded profile, interleaving would probably have to be able to be reset on user request also.
question how can a cabinet only get 27mbit sync? its a effective 0m length? or at least the length between PCP and FTTC cab. Or is the line banded at 27mbit?Of course it's banded (i.e. a profile with max/min sync rates has been applied by DLM)
@ Colin,Yes, I remember it well. So was mine until somebody fidgetted around in the cabinet on 08/04/2013. >:(
Here is one we prepared earlier (Thanks as usual to to Eagles, pussies and naughty children !)
A newly commissioned service under 200 m from the FTTC had a sync speed of 90.41 Mbps on 15 January 2013 but after the training period it adjusted to the channel profile and is now 79.997 Mbps.
Oh what a lucky chap !
You're not the only one !
http://www.ewhurst-broadband.org.uk/?p=3528&cpage=1#comment-730
You're not the only one !
http://www.ewhurst-broadband.org.uk/?p=3528&cpage=1#comment-730
No doubt, but what has happened to me and others is not remotely similar to that report (other than experiencing a reduction). There was no progressive reduction over time, just the immediate application of a lower banded profile in the face of a transient disturbance to the line.
IMO in my case it has nothing at all to do with FEXT or DPBO. It is just a flaw in DLM which, for reasons we would all like to know, is simply refusing to back off on a perfectly respectable line with a BER currently estimated between 5*10^-11 and 2*10^-8, either of which are way above the alleged 10^-7 BER of a good line.
In other words, the profile is 'stuck' maxing out the profile max sync, while still only on an RCO of 73%. It appears that both BlackSheep and Ryant704 were also stuck until their lines were reset, when their sync rose to the level their lines were capable of. IMO, no one should be stuck on a profile which they max out, other than the current 80/20 exception.
While the product is sold as 80/20, I don't have any argument with a profile banding that results in a 79.997 actual sync on those lines that are capable of it.
given I have no fault I couldn't really expect one to come out just to reset DLM on my line without being charged a hefty fee.In all honesty I don't think they would do it even if you offered to pay them, as if it did 'fix' a stuck profile, it would open them up to the not-entirely-unjustified accusation that a 'stuck' profile was in fact the only thing wrong with the line. ::)
given I have no fault I couldn't really expect one to come out just to reset DLM on my line without being charged a hefty fee.In all honesty I don't think they would do it even if you offered to pay them, as if it did 'fix' a stuck profile, it would open them up to the not-entirely-unjustified accusation that a 'stuck' profile was in fact the only thing wrong with the line. ::)
It seems the perverse response to solving the 'up to xMb/s' complaints is to manage expectations downwards through the use of 'estimates'. But why stop there, eh? Why leave your estimate at 60/20, when they could make it 15/2? after all there's about as much justification given for either. That would make life a lot easier for some people, but then it might just be open to a complaint that an 'up to 80/20' service was equally misleading.
And as you will find on other threads, there has indeed been a fair degree of 're-estimating' downward going on recently.
The DLM can only sync to maximum rate of the band that has been applied (This is what the NGA Helpdesk told the engineer). My line had a profile assigned called TR03 (301) which was incorrect for my line, it was then applying a 7Mbps - 19Mbps band. It would keep syncing to the exact same sync (19Mbps with a 18.42 bRAS Profile) and band after full DLM resets, this went on for around 2 months. The NGA helpdesk then said it assigned a different profile (Shame they didn't tell me the name, was Kevin from BT care that did before and I was moved on to the ELC Team), the 7Mbps - 19Mbps band was no longer being used. This leading to my speed returning to the 25/27Mbps mark. Though 2 days later a 15Mbps cap was applied to my line from Wholesale... that's going off-topic though!
[EDIT] Chrysalis observed earlier in the threadQuoteWhat 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).To some extent I believe that this is so, but not entirely, as BE has also had fastpath removed. But is that a temporary or a permanent change e.g. have BTOR updated the profiles recently? :shrug2: I don't know but it is suspicious.
Simply using banded profiles with max sync rates like that is a very crude way of managing line conditions, but if they were doing that it might explain some things we are seeing e.g. reduced profile maxes while DLM still apparrently believes there is no need for either interleaving or INP.
The cynic in me wonders if BTOR are quietly banding everyone at the next nearest profile to the official BTOR 'Estimate'? :o
Ironically its a way to claw out of BT infinity contract without penalty.
BT state "We wont slow you down"
Banding does exactly that. (interleaving does also). i have already tested it, I was given a copout of my contract simply because DLM "slowed me down". If they had to keep it legal, then everyone would have a max banded profile, interleaving would probably have to be able to be reset on user request also.
I've always agreed on this, I've asked BT this question. Here is the response (partly)...
"As you’ve mentioned, we can change the preference between Standard, Stable and Speed but in practice this will have little impact on the sync rate."
Then when the engineer was talking to the NGA helpdesk I got him to ask a couple of questions for me on the DLM (he was interested as well). He said there are many profiles that ISP use, none uses the default ones offered by Openreach, each ISP modifies the ones that Openreach offer though the default ones from Openreach will do exactly as they sound. He then mentioned you could see a speed difference of around 5Mbps if you're on the Speed profile instead of the Stable profile (note he wasn't talking about my line).
He then proceeded to talk on about Crosstalk, he stated if all people were on the "Speed" profile the service would degrade to a slower standard than if it was on a managed service. He said because everyone would be on "FastPath" there would be a higher number of errors this leading to more crosstalk? (First I've ever heard of this, I'm not sure if it's true as it wouldn't be the first time I've been lied to). Then proceeds to tell me that this would degrade the service to a slower rate if it wasn't managed the way it is.
errors themselves do not cause crosstalk, what causes crosstalk is the signal itself when it collides with another signal. There are mechanisms to reduce crosstalk BT probably use such as twisting the pairs, and reducing dsl signal power, I expect they also vary the power pattern on adjacent lines to also minimise crosstalk. Capping line speeds will only reduce crosstalk if the signal power is also reduced. So eg. banding a line but leaving it on full power with a high snrm wont reduce crosstalk. asbokid or someone else might correct me if I am wrong, but I think I am right.
When I last spoke to Azzaka probably around last Christmas he said quite categorically that the ONLY way of resetting a banded profile was to request a BT O site visit and that, provided the VDSL service passed all the line tests, that engineer was then able to request a reset, but NOT before. This particular conversation happened whilst I was supervising a Zen upgrade from 2 / 40 to 10 / 40.Hi Walter. Yes, I understand the points you are making. :)
Incidentally that Zen service is now sitting with another fixed Sync speed of 25.003 Mbps whilst another service two doors away from the same DP also on a single span drop is only running at 18.576 Mbps on a BT Retail service.
As you will expect that Zen user does not want to tempt the oracles by requesting yet another reset !
Sadly no, as both are ECI modems on to an ECI DSLAM.Sure, no problems. I was just curious.
I've not yet been brave enough to try a different extraction method.
I might be able to persuade the faster one to let me disturb his connection with an unlocked Huawei, but he won't thank me for screwing up his quite reasonable connection for this line length.
what concerns me is the amount of crosstalk that 'appears' to be picking up as more and more VDSL connections go live - it kinda makes me hope we DONT get FTTC if all ive got too look forward to is watching my 40Mb connection slowly dwindle away to 'slightly better' than top ADSL2+ speeds... :no:
If there is no modulated data on a tone, does an unmodulated carrier signal by itself contribute to crosstalk?
When I last spoke to Azzaka probably around last Christmas he said quite categorically that the ONLY way of resetting a banded profile was to request a BT O site visit and that, provided the VDSL service passed all the line tests, that engineer was then able to request a reset, but NOT before.
what concerns me is the amount of crosstalk that 'appears' to be picking up as more and more VDSL connections go live - it kinda makes me hope we DONT get FTTC if all ive got too look forward to is watching my 40Mb connection slowly dwindle away to 'slightly better' than top ADSL2+ speeds... :no:
My DS connection speed has reduced from around a sustainable 30Mbps (after my line was finally repaired) to less than 21Mbps - strongly suspected to be as a result of increased crosstalk.
Although that is very disappointing, due to distance (from the exchange for ADSL connections), it is still far better than the 1Mbps that my connection managed on ADSL.
When I last spoke to Azzaka probably around last Christmas he said quite categorically that the ONLY way of resetting a banded profile was to request a BT O site visit and that, provided the VDSL service passed all the line tests, that engineer was then able to request a reset, but NOT before.
Hi Walter,
That must be down to BT's rules-and-regs, rather than any technical limitation? The DLM software runs centrally at some NOC (Martlesham?).
Every DSLAM has an inband management interface. The DSLAM, and each of its subscriber ports, are configured and re-profiled through SNMP by the (Java-based?) DLM application.
So a DLM reset is all software-controlled, and requires no "truck roll".
Wonder why BT opted primarily for site visits, and the great cost they entail?
cheers, a
what concerns me is the amount of crosstalk that 'appears' to be picking up as more and more VDSL connections go live - it kinda makes me hope we DONT get FTTC if all ive got too look forward to is watching my 40Mb connection slowly dwindle away to 'slightly better' than top ADSL2+ speeds... :no:
My DS connection speed has reduced from around a sustainable 30Mbps (after my line was finally repaired) to less than 21Mbps - strongly suspected to be as a result of increased crosstalk.
Although that is very disappointing, due to distance (from the exchange for ADSL connections), it is still far better than the 1Mbps that my connection managed on ADSL.
very true - but its still a worrying trend - will my ADSL connection be affected also? (from others signing up to VDSL when its available) sounds like it will, but not as much as VDSL
I wonder if its going to get to the point where crosstalk impacts VDSL so badly (once all/most connections in a bundle are VDSL 'live') that speeds are well below par for whats classed acceptable for VDSL (just how bad can it get?) - any news on vectoring?
@ les-70 - I had a 'Split-Pair' last year and my connection dropped from 18Mb to 9-10Mb, QLN noise was really bad as noise cancellation could not work properly, I suppose it depends on the length of the "split pair" as to how bad an effect it has.
@ Chrysalis - I see, so if 40% of your speed is lost you get about 22Mbps on a 40Mb connection, and theres also the possibility that could get worse - like you say that is fine if before you had a really slow ADSL service, but for me getting 15-16Mbps throughput on ADSL, signing up to 40Mbps then seeing it dwindle away to 22Mbps would be very annoying as I would be paying a premium for something that was 1.5 times faster than what I was getting before, but has gone down to being 0.5 times faster than my old ADSL connection, not so much worth paying the extra for compared to someone who was say getting 3Mb ADSL - which initially a 40Mb connection would be 13 times faster then the ADSL connection, and when it dwindled to 22Mb its still 7.5 times faster than the old ADSL connection... so your paying premium to have internet 7.5 times faster than you had it before = worth it, but high speed ADSL connections = not so.
Gentlefolk,
Does anyone know whether it's possible to discover the DP number either internally for a BT Openreach engineer or for Joe public ?
The reason for this question is that on longer downstream of the DP lines there can be many pole top boxes which appear not to classed as DPs and not marked as such either. I assume that all BT 66 boxes are never classed as DPs ?
Kind regards,
Walter