Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Greybeard33 on September 19, 2013, 12:27:20 AM
-
Recently I noticed a resync in my modem log that looked different from a DLM-triggered on-the-fly one - off line for over 7 minutes from 03:07am. So I took a snapshot of the modem stats for the first time for a couple of months (the line had been boringly stable - nearly 5 months since the last resync).
Comparing the before and after stats (attached), I noticed a slight change in the Discovery Phase Band Plan. The uppermost tone in the D3 band has changed from 3959 to 3971. (My line is too long to use the D3 band, so there was no change to the Medley Phase tones.) Also the DSLAM has now started reporting the US QLN, HLog and SNR to the modem - I had understood only ECI DSLAMs supported this?
I suspect that the interruption in service was for my DSLAM to receive a firmware upgrade that included these changes. Does anyone know if BTOR is rolling out such an upgrade to its Huawei DSLAMs? Just curious.
Since the change, my DS sync and max attainable rates seem to have decreased slightly while the US rates have increased slightly. Consequence or coincidence?
-
Sorry I cant answer your question as theres no huawei dslams around here and Ive not really seen many stats from them and therefore wasnt aware of the differences.
Perhaps someone like BE or Colin who have been on fftc longer than I have may be able to say more.
-
Comparing the before and after stats (attached), I noticed a slight change in the Discovery Phase Band Plan. The uppermost tone in the D3 band has changed from 3959 to 3971. (My line is too long to use the D3 band, so there was no change to the Medley Phase tones.) Also the DSLAM has now started reporting the US QLN, HLog and SNR to the modem - I had understood only ECI DSLAMs supported this?
That's an interesting observation, especially the reporting of US data.
I too can't use the D3 band due to line length, but I'm quite interested in seeing my US data.
As you mentioned, that was NEVER available from a Huawei DSLAM previously.
I haven't read of anyone else seeing this band plan change, yet & mine is still showing 3959 as the highest available tone.
Your U2 QLN graph looks 'interestingly' & disproportionally 'noisy'.
Hence nothing showing in the Hlog or SNR graphs.
I'd be interested to see the Plink log for those graphs, just in case I have missed anything in plotting the data US when obtained via a Huawei DSLAM.
Could you possibly zip it & post it here?
Just for curiosity, do you know your line length from the cabinet?
-
Comparing the before and after stats (attached), I noticed a slight change in the Discovery Phase Band Plan. The uppermost tone in the D3 band has changed from 3959 to 3971. (My line is too long to use the D3 band, so there was no change to the Medley Phase tones.) Also the DSLAM has now started reporting the US QLN, HLog and SNR to the modem - I had understood only ECI DSLAMs supported this?
That's an interesting observation, especially the reporting of US data.
I too can't use the D3 band due to line length, but I'm quite interested in seeing my US data.
As you mentioned, that was NEVER available from a Huawei DSLAM previously.
I haven't read of anyone else seeing this band plan change, yet & mine is still showing 3959 as the highest available tone.
Your U2 QLN graph looks 'interestingly' & disproportionally 'noisy'.
Hence nothing showing in the Hlog or SNR graphs.
I'd be interested to see the Plink log for those graphs, just in case I have missed anything in plotting the data US when obtained via a Huawei DSLAM.
Could you possibly zip it & post it here?
Just for curiosity, do you know your line length from the cabinet?
Plinks attached, zipped together with the related plots. I have added a more recent one taken after another resync at a "quieter" time of day. I am not sure the U1 QLN looks disproportionate, but the U2 curve is again way out of line with the D2 & D3 bands and again U2 does not appear on the Hlog plot (would not be expected to appear on the SNR plot, since the band is not in use?) I notice also that the shared band between U0 and D1 is not plotted on either the QLN or the Hlog graphs - is this the same as with an ECI DSLAM?
The September snapshots were taken with the v1.1 release of your program, whereas the July one would I think have been with v1.0. As a check I did try taking a recent snapshot with the batch file version from last year, and that gave similar plots of the US QLN, Hlog and SNR graphs.
The distance by road to the cabinet is 0.98km measured by the Google Maps pedometer, but I do not know how much the underground wiggles add to this. I believe it must be copper cable to give such good speeds.
-
I notice also that the shared band between U1 and D1 is not plotted on either the QLN or the Hlog graphs - is this the same as with an ECI DSLAM?
Yes, it's the same with the ECI DSLAM.
If you zoom in, you can just see a tiny bit of blue shared band between U0 & D1 in the QLN & Hlog graphs.
That's the way the Huawei modem reports the raw data, but I don't know if is a modem glitch or not.
The distance by road to the cabinet is 0.98km measured by the Google Maps pedometer, but I do not know how much the underground wiggles add to this. I believe it must be copper cable to give such good speeds.
I am a similar distance from the cabinet, but your connection performs much better than mine.
Mine was O.K. at around 30 Mbps when it was repaired in May 2012.
It stayed like that until January 2013 when it started dropping in stages to its current 20 Mbps.
This speed reduction is being put down to crosstalk as other users have been connected, although a number of visiting engineers couldn't actually prove it as such.
Roll on Vectoring that seems to be my only hope of seeing higher speeds again.
-
I notice also that the shared band between U0 and D1 is not plotted on either the QLN or the Hlog graphs - is this the same as with an ECI DSLAM?
Yes, it's the same with the ECI DSLAM.
If you zoom in, you can just see a tiny bit of blue shared band between U0 & D1 in the QLN & Hlog graphs.
That's the way the Huawei modem reports the raw data, but I don't know if is a modem glitch or not.
Oh yes, I see it now. The U0 band looks a bit peculiar too. (Sorry - I was muddling the upstream band numbers in my previous post - will correct it.)
Mine was O.K. at around 30 Mbps when it was repaired in May 2012.
It stayed like that until January 2013 when it started dropping in stages to its current 20 Mbps.
This speed reduction is being put down to crosstalk as other users have been connected, although a number of visiting engineers couldn't actually prove it as such.
Roll on Vectoring that seems to be my only hope of seeing higher speeds again.
Crosstalk seems to affect some lines much more than others. I was an early adopter of FTTC, yet the performance of my line has (touch wood!) changed very little over two years. I guess it is "the luck of the draw" as to how the cables lie in the ducts (except where crosstalk might be being cited as the "catch-all" excuse to avoid expensive investigations of poor performance!)
-
I guess it is "the luck of the draw" as to how the cables lie in the ducts (except where crosstalk might be being cited as the "catch-all" excuse to avoid expensive investigations of poor performance!)
I think the cross-talk is more to do with the amount of users within the cable, rather than how they lie separately within a duct. But with the major factor being FEXT, actually at the FTTC DSLAM. I've seen images taken by thermal cameras that show the difference to a DSLAM with vectoring applied. It's far from being a 'Catch all' excuse, although I will admit some engineers may wittingly or unwittingly make this statement when faulting a circuit. Poor training and knowledge share being the main culprits. :)
-
I think the cross-talk is more to do with the amount of users within the cable, rather than how they lie separately within a duct. But with the major factor being FEXT, actually at the FTTC DSLAM. I've seen images taken by thermal cameras that show the difference to a DSLAM with vectoring applied.
Yes, of course you are right that that it is the proximity of pairs within the same cable that affects the severity of Far End X-Talk. From a bit of googling I gather that it is short lines, which use the highest tones, that are the worst affected by crosstalk and so benefit most from vectoring, whereas the effects are proportionately much less on lines that are too long to use the D3 and U2 bands.
Which might explain why my long line has not been much affected by FEXT, and also suggests that BE might be over-optimistic in hoping for a big improvement from vectoring on his long line.
-
Again, my bad, I meant to type 'NEXT' .......... not 'FEXT'. So hopefully BE will see noticeable changes ??
-
Again, my bad, I meant to type 'NEXT' .......... not 'FEXT'. So hopefully BE will see noticeable changes ??
Hmm. I am no expert, but from what I have read vectoring is intended to reduce FEXT not NEXT. Near End X-Talk can be mitigated by band-pass filtering in the DSLAM and modem to attenuate interference between the upstream and downstream tone frequencies - I presume this is already implemented?
-
I presume this is already implemented?
I think vectoring is wee bit behind schedule if my link is correct ?
http://www.ispreview.co.uk/index.php/2013/08/bt-make-final-adjustments-for-faster-fttc-broadband-vectoring-trial.html
-
I think vectoring is wee bit behind schedule if my link is correct ?
http://www.ispreview.co.uk/index.php/2013/08/bt-make-final-adjustments-for-faster-fttc-broadband-vectoring-trial.html
Looking at that link, I am amused to see a hard-hat (with chin strap fastened) and safety spectacles being worn by the Engineer 'attending to' (or 'posing in front of') that Huawei cabinet.
. . . preparations have apparently taken slightly longer than expected. The good news is that Openreach have now finished installing the necessary DSLAM hardware into six street cabinets around Barnet (London) and Braintree (Essex) in England.
So those six cabinets have now been fitted with their Huawei MA5603 subracks.
-
Again, my bad, I meant to type 'NEXT' .......... not 'FEXT'. So hopefully BE will see noticeable changes ??
Hmm. I am no expert, but from what I have read vectoring is intended to reduce FEXT not NEXT. Near End X-Talk can be mitigated by band-pass filtering in the DSLAM and modem to attenuate interference between the upstream and downstream tone frequencies - I presume this is already implemented?
I've no idea with vectoring, tbh. I keep seeing the odd snippet of info but can't be bothered with getting 'in deep' with it, until it's implemented. Having seen the pictures of the DSLAM thermal imaging, before and after vectoring was applied, i assumed that it eradicated NEXT as much as FEXT, but you've informed me otherwise now, so I'm a little bit more educated in it all.
The only bits I know are, 'aliens' or 'disturbers' are completely counter-productive to vectoring, well anything over 5 'aliens' that is. Therefore, from what I gather, all CP's will have to agree to have their lines vectored ?? Even our testers will have to have some kind of update, or different module to attach in order not to become a 'disturber' whilst we carry out faulting techniques.
The graphs that I have seen show that short to medium lines gain massive improvement, but that longer lines also show some improvement as well.
That is about as much as I know at this moment in time. I get to know more info on here, than I do from official work-streams !! ;) :)
-
on my line if the issue is crosstalk the tones affected the most are D1 and D2, D1 the worst. D3 barely affected at all.
When I had a 90mbit attainable my D1 had higher snr then D2 as one would expect and also higher bitloading, now crosstalk has made D1 and D2 almost equal. Its D1 and to a lesser extenct D2 where my sync speed has been lost.
I think when people say crosstalk affects short lines more they rather mean crosstalk is the biggest issue for short lines as when attenuation is low external interferience has less affect. I would expect vectoring to help all lines not just short lines but shorter lines will see bigger speed increases due to the fact they use more tones.
eg. even tho Greybeard33 has a longer line than me and cannot even use D3, his snr on D1 is comparable to mine as crosstalk has trashed my D1 signal. But my D2 is higher than his D2 and I have a D3.
-
on my line if the issue is crosstalk the tones affected the most are D1 and D2, D1 the worst. D3 barely affected at all.
When I had a 90mbit attainable my D1 had higher snr then D2 as one would expect and also higher bitloading, now crosstalk has made D1 and D2 almost equal. Its D1 and to a lesser extenct D2 where my sync speed has been lost.
I think when people say crosstalk affects short lines more they rather mean crosstalk is the biggest issue for short lines as when attenuation is low external interferience has less affect. I would expect vectoring to help all lines not just short lines but shorter lines will see bigger speed increases due to the fact they use more tones.
eg. even tho Greybeard33 has a longer line than me and cannot even use D3, his snr on D1 is comparable to mine as crosstalk has trashed my D1 signal. But my D2 is higher than his D2 and I have a D3.
I have not seen your stats, but are you sure the issue you have in D1 is caused by crosstalk from other VDSL2 lines, not just the power mask applied to your line at the DSLAM, up to Tone 512, to protect adjacent long ADSL2+ lines from crosstalk? Theory says that crosstalk increases with frequency, so the D3 band should be the worst affected if the source is another VDSL2 line.
My cabinet is actually closer to the exchange than to my house, so adjacent ADSL2+ lines presumably have a fairly strong signal and so the power cutback needed on my line may be less than on yours. I used to get 18Mb/s sync when I was ADSL2+ myself.
-
Bumping this thread because the band plan has changed again, concurrent with a modem firmware update - see this post: http://forum.kitz.co.uk/index.php/topic,13041.msg246175.html#msg246175 (http://forum.kitz.co.uk/index.php/topic,13041.msg246175.html#msg246175) .
-
Thank you. Every little bit of information helps. :)
-
on my line if the issue is crosstalk the tones affected the most are D1 and D2, D1 the worst. D3 barely affected at all.
When I had a 90mbit attainable my D1 had higher snr then D2 as one would expect and also higher bitloading, now crosstalk has made D1 and D2 almost equal. Its D1 and to a lesser extenct D2 where my sync speed has been lost.
I think when people say crosstalk affects short lines more they rather mean crosstalk is the biggest issue for short lines as when attenuation is low external interferience has less affect. I would expect vectoring to help all lines not just short lines but shorter lines will see bigger speed increases due to the fact they use more tones.
eg. even tho Greybeard33 has a longer line than me and cannot even use D3, his snr on D1 is comparable to mine as crosstalk has trashed my D1 signal. But my D2 is higher than his D2 and I have a D3.
I have not seen your stats, but are you sure the issue you have in D1 is caused by crosstalk from other VDSL2 lines, not just the power mask applied to your line at the DSLAM, up to Tone 512, to protect adjacent long ADSL2+ lines from crosstalk? Theory says that crosstalk increases with frequency, so the D3 band should be the worst affected if the source is another VDSL2 line.
My cabinet is actually closer to the exchange than to my house, so adjacent ADSL2+ lines presumably have a fairly strong signal and so the power cutback needed on my line may be less than on yours. I used to get 18Mb/s sync when I was ADSL2+ myself.
I am talking about the part of D1 that is outside the adsl1 frequency range, in my area the cutback isnt applied above 256. I do have graphs from before my crosstalk and after. So I can see the affect it has had, both graphs have the cutback for adsl, but the cutback isnt the entire D1 range, its just a part of it. The cutback tones on my line are actually almost 0 bitloading, it drops the signal a hell of a lot more than making it equal with D2 :p
-
how do you know what dslam your using, I always thought mine wasn't eci because of not having the eci modem. This is what I have foe dslam on my stats,
DSLAM/MSAN type: BDCM:0xa415 / v0xa415
DSL mode: VDSL2
Status: Showtime
Uptime: 20 hours 22 min 31 sec
is that eci or the other one?
I think bandplan as been changed
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
Oh yes of course, my dslam is Broadcom, not eci, DOH
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
-
how do you know what dslam your using, I always thought mine wasn't eci because of not having the eci modem. This is what I have foe dslam on my stats,
DSLAM/MSAN type: BDCM:0xa415 / v0xa415
DSL mode: VDSL2
Status: Showtime
Uptime: 20 hours 22 min 31 sec
is that eci or the other one?
I think bandplan as been changed
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
Oh yes of course, my dslam is Broadcom, not eci, DOH
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
Yes, that is a Huawei DSLAM.
Your band plan is the same as mine was after the first change last month, which prompted me to start this thread. Since the second change last Friday morning, it is now:
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
The big change is to the U0 band, which has shrunk and no longer overlaps the D1 band. The other changes only affect a handful of tones at the boundaries of the other bands.
I experienced a drop in DS Max Attainable Rate and SNRM after the first change; since the second one (and concurrent modem update) they are back up to where they were originally. However, this could just be coincidence. My long line is somewhat noisy (capped at 40M, Trellis on, Interleaving ~700, INP 3, Delay 8ms) and there have been previous occasions when there has been a gradual loss of Max Attainable and SNRM, only for them to recover after a resync.
I think it will take weeks rather than days to judge the effect, if any, of these changes. Pure guesswork, but one possibility might be that they are in preparation for the introduction of vectoring?
-
Ah, sounds like my line, im pretty far from my can also, nearly the limit i think, im only expected to recieve 30meg, but my attainable rate is 61, sync rate 52, so im lucky. Does that mean then i should expect another change to the dslam?.
-
greybeard which changes are big depends on the line.
On my line those handful of tones you speak of account for about 4.8mbit of my sync speed on D3.
Whilst the D1 changes due to adsl power cutback I expect will gain me 2-3 mbit at the most. Its also possible the D1 changes have no gain, as with it been shared it may already be used by downstream. I expect on lines unable to get 20mbit upstream sync the shared is used by upstream, on lines that can get 20mbit upstream without its used by downstream.
-
greybeard which changes are big depends on the line.
On my line those handful of tones you speak of account for about 4.8mbit of my sync speed on D3.
Whilst the D1 changes due to adsl power cutback I expect will gain me 2-3 mbit at the most. Its also possible the D1 changes have no gain, as with it been shared it may already be used by downstream. I expect on lines unable to get 20mbit upstream sync the shared is used by upstream, on lines that can get 20mbit upstream without its used by downstream.
You should count yourself lucky! In the first change D3 gained 12 tones, in the second it lost two and D2 lost two, so that is still a net gain of 8. In my case I have just lost the top two tones of D2 (admittedly only carrying one bit each), without any gain. My US sync has only dropped by about 0.2M, despite U0 losing 7 tones and U1 5, so I suspect the shared tones were being used for DS anyway.
-
DSLAM/MSAN type: BDCM:0xa415 / v0xa415
BDCM == Broadcom, which implies a Huawei SmartAX MA5616 MSAN. ;)
-
greybeard which changes are big depends on the line.
On my line those handful of tones you speak of account for about 4.8mbit of my sync speed on D3.
Whilst the D1 changes due to adsl power cutback I expect will gain me 2-3 mbit at the most. Its also possible the D1 changes have no gain, as with it been shared it may already be used by downstream. I expect on lines unable to get 20mbit upstream sync the shared is used by upstream, on lines that can get 20mbit upstream without its used by downstream.
You should count yourself lucky! In the first change D3 gained 12 tones, in the second it lost two and D2 lost two, so that is still a net gain of 8. In my case I have just lost the top two tones of D2 (admittedly only carrying one bit each), without any gain. My US sync has only dropped by about 0.2M, despite U0 losing 7 tones and U1 5, so I suspect the shared tones were being used for DS anyway.
remember the before and after stats you posted?
the before stats had the same sync speed but a very low snr margin.
the after stats you had the same sync speed but a snr margin above 6db (meaning you gained 3db worth of snr from the change) and your attainable jumped by 7mbit.
I think you just looked at your sync speed and ignored the rest.
-
Since my bandplan change my DS snr is terrible, I could drop right down to 3db from 6.5 in evenings now, as before the change my snr would hardly bugde, maybe drop 1.5db.
-
remember the before and after stats you posted?
the before stats had the same sync speed but a very low snr margin.
the after stats you had the same sync speed but a snr margin above 6db (meaning you gained 3db worth of snr from the change) and your attainable jumped by 7mbit.
I think you just looked at your sync speed and ignored the rest.
Humph! Well, since then there has been another resync (at 8am on Sunday morning!). Retrain Reason 1, RDI Detector (Remote Defect Indication), which I have never seen before. INP has gone up from 3 to 8, Delay from 8 to 16 and Interleaving Depth from 701 to 1557, while DS sync has dropped from 39998 to 37126. These are about the worst stats I have ever seen, except when I had trouble with REIN last Christmas. Although US sync has actually increased from 7752 to 7832, so perhaps I should be grateful for small mercies!
The DS daily error rates do seem to have got much worse, so DLM seems just to be doing its job. I suppose it is possible the line has suddenly got noisier, but it seems rather a coincidence that this should happen just after the DSLAM and modem changes....
Edit: Having just looked again at the "Broadcom retrain codes" thread, Retrain Reason 1 becomes LOS Detector (Loss Of Signal), if you buy Asbokid's "bitwise left shift" interpretation of the codes, i.e. 2^0=1.
-
Since my bandplan change my DS snr is terrible, I could drop right down to 3db from 6.5 in evenings now, as before the change my snr would hardly bugde, maybe drop 1.5db.
same here it was steady at 6db in the evening but now going below 4.4db and thats since the firmware update on modem and my interleaving Depth has gone from 455 before update last friday to 1215 so what is this new BandPlan and what is it for and it's not working and it's making things worse for me anyway.....
-
greybeard I will post my bitloading so you can see how bad my adsl power cutback is, yours seems mild in comparison. Also note how weak my D1 is. Which considering your line is longer is odd. I also found a line on the btcare forums, that guy has almost no power cutback at all, barely a dent in his D1.
here is the link.
Also I now posted how my bits and snr looked in dec 2012. Even back then the power cutback was removing approx 15mbit of attainable sync. Some people seem to be barely losing 5mbit from the cutback. Also if you remember my earlier comment ref crosstalk, you can see my D3 is least affected by it.
http://community.bt.com/t5/BT-Infinity/Compare-Graph-stats-please/m-p/1044242/highlight/true#M113165
-
Since my bandplan change my DS snr is terrible, I could drop right down to 3db from 6.5 in evenings now, as before the change my snr would hardly bugde, maybe drop 1.5db.
same here it was steady at 6db in the evening but now going below 4.4db and thats since the firmware update on modem and my interleaving Depth has gone from 455 before update last friday to 1215 so what is this new BandPlan and what is it for and it's not working and it's making things worse for me anyway.....
Am I starting to see a pattern here, our connection at work has also deteriorated since the modem update, interleaving now being at 1429. See my thread here (http://forum.kitz.co.uk/index.php/topic,13061.0.html). Things turned bad yesterday, but the modem updated towards the end of last week.
-
Since my bandplan change my DS snr is terrible, I could drop right down to 3db from 6.5 in evenings now, as before the change my snr would hardly bugde, maybe drop 1.5db.
same here it was steady at 6db in the evening but now going below 4.4db and thats since the firmware update on modem and my interleaving Depth has gone from 455 before update last friday to 1215 so what is this new BandPlan and what is it for and it's not working and it's making things worse for me anyway.....
Am I starting to see a pattern here, our connection at work has also deteriorated since the modem update, interleaving now being at 1429. See my thread here (http://forum.kitz.co.uk/index.php/topic,13061.0.html). Things turned bad yesterday, but the modem updated towards the end of last week.
yeah after I noticed the tone reductions on all 3 bands I disabled my tr069 again I will keep the older firmware. The update looks worse to me on the band plan, and I have seen more than you 2 guys complain about performance/stability.
-
greybeard I will post my bitloading so you can see how bad my adsl power cutback is, yours seems mild in comparison. Also note how weak my D1 is. Which considering your line is longer is odd. I also found a line on the btcare forums, that guy has almost no power cutback at all, barely a dent in his D1.
here is the link.
Also I now posted how my bits and snr looked in dec 2012. Even back then the power cutback was removing approx 15mbit of attainable sync. Some people seem to be barely losing 5mbit from the cutback. Also if you remember my earlier comment ref crosstalk, you can see my D3 is least affected by it.
http://community.bt.com/t5/BT-Infinity/Compare-Graph-stats-please/m-p/1044242/highlight/true#M113165
Hmm, puzzling. As far as the ADSL power cutback is concerned, I think it depends mainly on the length of the line on the E-side of the cabinet. The further the cabinet is from the exchange, the weaker the ADSL DS signals are by the time they get there, so the more the VDSL power has to be cut back to avoid swamping them with crosstalk. My cab is only about 800m from the exchange; I suspect yours is further away whereas the guy whose stats you linked has a cab that is very close to the exchange.
However, as you say, that has nothing to do with the D2 band, or the D1 above the ADSL frequencies. You certainly seem to have had a loss of SNR in both bands, resulting in reduced bitloading. Whereas SNR and bitloading have actually improved at the top of the D3 band. I still do not think this can be caused by crosstalk from other VDSL lines, or you would be seeing the opposite effect - the biggest loss at the top of D3, reducing at lower frequencies. Also your graphs are quite smooth, without much of the jagged, notched, profile I see on mine from some tones being worse affected by noise than others. So if your problem is interference, it must be some sort of "white noise" source spread across the frequency spectrum - no idea what that could be.
Another explanation might be that a power cutback has been applied to the D2 & upper D1 bands, but I have no idea why that should be either.
-
yeah after I noticed the tone reductions on all 3 bands I disabled my tr069 again I will keep the older firmware. The update looks worse to me on the band plan, and I have seen more than you 2 guys complain about performance/stability.
4 days on after update & bandplan changed the only thing I see thats changed is 2.5X more interleaving has been added but will wait to see if that changes in the next 2 weeks if not I am stuck with it, the other is US seems consitantly better, my DS even with Interleaving depth of 1215 it's still giving me a Path: of 28632 Kbps which is odd as the last time with High Interleaving (before firmware update and BandPlan change) it was 24500 Kbps.
TBH I am still in observation mode since the change's and it's not as bad as I first thought when looking deeper into old stats and the one's I am seeing to-day :-\
-
Could you post a zipped Plink log since the changes or email it to me for a closer look?
-
Yep no problem ! BE1 -> plink uploaded
-
yeah after I noticed the tone reductions on all 3 bands I disabled my tr069 again I will keep the older firmware. The update looks worse to me on the band plan, and I have seen more than you 2 guys complain about performance/stability.
Please take care, for the BT Agent != TR-069. ;)
It is via her own proprietary busy-body, the BT Agent, that Beattie pushes out the firmware updates, whilst it seems that the CPE and line performance is monitored by TR-069. Until such time that someone de-compiles (and then reverse engineers) the BT Agent, its behaviour is still a big unknown. :(
-
Yep no problem ! BE1 -> plink uploaded
This is what it looks like:-
The text formatting still needs sorting out for the pbParams data.
-
greybeard I will post my bitloading so you can see how bad my adsl power cutback is, yours seems mild in comparison. Also note how weak my D1 is. Which considering your line is longer is odd. I also found a line on the btcare forums, that guy has almost no power cutback at all, barely a dent in his D1.
here is the link.
Also I now posted how my bits and snr looked in dec 2012. Even back then the power cutback was removing approx 15mbit of attainable sync. Some people seem to be barely losing 5mbit from the cutback. Also if you remember my earlier comment ref crosstalk, you can see my D3 is least affected by it.
http://community.bt.com/t5/BT-Infinity/Compare-Graph-stats-please/m-p/1044242/highlight/true#M113165
Hmm, puzzling. As far as the ADSL power cutback is concerned, I think it depends mainly on the length of the line on the E-side of the cabinet. The further the cabinet is from the exchange, the weaker the ADSL DS signals are by the time they get there, so the more the VDSL power has to be cut back to avoid swamping them with crosstalk. My cab is only about 800m from the exchange; I suspect yours is further away whereas the guy whose stats you linked has a cab that is very close to the exchange.
However, as you say, that has nothing to do with the D2 band, or the D1 above the ADSL frequencies. You certainly seem to have had a loss of SNR in both bands, resulting in reduced bitloading. Whereas SNR and bitloading have actually improved at the top of the D3 band. I still do not think this can be caused by crosstalk from other VDSL lines, or you would be seeing the opposite effect - the biggest loss at the top of D3, reducing at lower frequencies. Also your graphs are quite smooth, without much of the jagged, notched, profile I see on mine from some tones being worse affected by noise than others. So if your problem is interference, it must be some sort of "white noise" source spread across the frequency spectrum - no idea what that could be.
Another explanation might be that a power cutback has been applied to the D2 & upper D1 bands, but I have no idea why that should be either.
yep I am far from the exchange, or rather my line routing is long as its very indirect. So when people say distance from exchange has zilch affect on vdsl, it does actually have an affect as the power cutback is worse on longer E sides.
I wont argue with you much on the crosstalk because I cant say for sure what it is, I can only guess, my gut feeling is it is crosstalk, the cause is between the PCP and FTTC cabinet an engineer diagnosed it the other week, the cause is affecting many pairs between the 2 cabinets, but as far as I know no rectification work has been done yet. My install engineer insists its crosstalk. Because it happened when there was installations.
Your theory is crosstalk has more impact where the signal is weaker?
My theory is/was the disturber lines are not using D3 perhaps they too long or something so thats why that is barely affected.
I also have considered the dslam been faulty eg. incorrect power masking been applied cutting back too much, of course if it is that I think it would never get fixed as these cabinets once installed cant be accessed by regional engineers.
I also had some weird behaviour before as well. I had for a while my sync speed jumping between 73 attainable and nearly 90mbit 86-88 range, it was mostly at 83 tho, but would randomly jump up for short periods of time. At the same time this was occuring I did have a fault affecting my stability at night which I reported to BT and a engineer came out, the engineer said he found nothing wrong and closed the fault. But something was changed as the night time instability stopped and the sync speed jumping up to nearly 90mbit also stopped.
-
yeah after I noticed the tone reductions on all 3 bands I disabled my tr069 again I will keep the older firmware. The update looks worse to me on the band plan, and I have seen more than you 2 guys complain about performance/stability.
Please take care, for the BT Agent != TR-069. ;)
It is via her own proprietary busy-body, the BT Agent, that Beattie pushes out the firmware updates, whilst it seems that the CPE and line performance is monitored by TR-069. Until such time that someone de-compiles (and then reverse engineers) the BT Agent, its behaviour is still a big unknown. :(
whats the reccomended way to kill btagent?
-
This is what it looks like:-
The text formatting still needs sorting out for the pbParams data.
Your Current Stat's BE works fine, what I noticed in the Profile is the Attn (db): is now showing 24.9 in the down were as the old (before BandPlan & firmware update) showed 0.0
-
whats the reccomended way to kill btagent?
Establish a telnet connection to the HG612, invoke the busybox shell and issue a killall -KILL start btagent command.
A power-cycle or reboot of the device will turn Beattie's busybody back on.
-
quick reply @ greybeard.
Its my understanding too that crosstalk impacts most on the shorter lines and that its the higher frequencies that are affected most.
However, I dont know if the following info helps, but when on adsl2+ I was one of the first (if not the 1st) people to go on a shiny new BE MSAN. At first I could get a full 24Mb, over time this deteriorated to 21Mbps.. most remarkably so when the MSAN started to fill up with o2 users.
The place where I noticed crosstalk had the most impact though was across the 6,7,8,9,10 Mbps range. By that I mean the max tones in use by anyone syncing at say 8Mbps would be using. After tones 260 both my SNR and bit loading started to increase. At about tone 300 my SNR was better than say tone 130. It was all a nice smooth dip bit like a shallow bowl. Somewhere around tone 255 (8Mb) was my lowest SNR... until tone 460 ish.
This saucer shape meant that I could never get full bit loading over the 128 -288 region when in the early days I could.
Obviously the more users that synced at x speed then the worse impact it would have on my snr and bit loading across those tones. There must have been far fewer people syncing at over 14Mbp, which is why my own SNR was good there and least impacted by other users and would start to rise again.
Hope you get the gist of what Im trying to say.. I possibly have a DMTtool graph from about 2008ish when you could see this happening quite clearly, but its on an old drive that I need to hook up to the network sometime to transfer some data from. :/
-
whats the reccomended way to kill btagent?
Establish a telnet connection to the HG612, invoke the busybox shell and issue a killall -KILL start btagent command.
A power-cycle or reboot of the device will turn Beattie's busybody back on.
At first I wasnt going to bother and thought that the separation in tones may actually be a good thing as far as crosstalk goes, and I was going to let it happen as im not too bothered about the webgui as long as I can still telnet into the router.
However now Im not too sure if some are saying that they are being left without any access and that the algorithms may not be as good causing some SNR instability. Obviously this will impact on errors which in turn could invoke the DLM. I have spare SNR, but this pair Im on now doesnt have as much spare, and Im actually seeing more variance on the downstream SNRm than the old pair.
I think I'll turn the BTAgent off.
btw.. it can be done in dslstats too. I saw eric post a screenshot earlier.
-
b*cat (or someone else) please :)
Can you confirm whether there should be a response from the modem when you issue that command?
See my telnet session.
----
Edited to add
Just answered my own question.. If I attempt to do it again then I get
# killall -KIll start btagent
killall: start: no process killed
killall: btagent: no process killed
-
Looking at the image, I can see that the command line was successful. :thumbs:
The expected response is just another busybox shell prompt (#).
Another command you might like to note is ps, which lists all the processes. When your HG612 has been rebooted (reboot from the busybox shell, for example) or power-cycled, you might like to issue the following three commands which will show the effect of the killall command line --
ps
killall -KILL start btagent
ps
;)
-
Thank you for that b*cat.
I was just a bit surprised that there was nothing to indicate the command was successful, hence the query.
Since it moaned at me the second time I attempted it, I then sussed that the first attempt must have been accepted.
That is useful information and could do perhaps with being recorded somewhere permanent. Not tonight though as Ive realised its way past my bed time and due to the fact I have to be up and out tomorrow, I guess Im not going to get many zeds now.
-
I can confirm b*cat's information. It's fairly common practice with Linux commands to give no response when they're successful. Often there will be an optional -v or --verbose parameter which will cause it to return a "success" response. The "no process killed" response is quite normal and benign, and in this case simply indicates that the processes in question were already not running at the time the command was issued.
(Incidentally, the -v or --verbose parameter doesn't appear to be recognised in the implementation of the killall command in this router)
-
quick reply @ greybeard.
Its my understanding too that crosstalk impacts most on the shorter lines and that its the higher frequencies that are affected most.
However, I dont know if the following info helps, but when on adsl2+ I was one of the first (if not the 1st) people to go on a shiny new BE MSAN. At first I could get a full 24Mb, over time this deteriorated to 21Mbps.. most remarkably so when the MSAN started to fill up with o2 users.
The place where I noticed crosstalk had the most impact though was across the 6,7,8,9,10 Mbps range. By that I mean the max tones in use by anyone syncing at say 8Mbps would be using. After tones 260 both my SNR and bit loading started to increase. At about tone 300 my SNR was better than say tone 130. It was all a nice smooth dip bit like a shallow bowl. Somewhere around tone 255 (8Mb) was my lowest SNR... until tone 460 ish.
This saucer shape meant that I could never get full bit loading over the 128 -288 region when in the early days I could.
Obviously the more users that synced at x speed then the worse impact it would have on my snr and bit loading across those tones. There must have been far fewer people syncing at over 14Mbp, which is why my own SNR was good there and least impacted by other users and would start to rise again.
Hope you get the gist of what Im trying to say.. I possibly have a DMTtool graph from about 2008ish when you could see this happening quite clearly, but its on an old drive that I need to hook up to the network sometime to transfer some data from. :/
thats a big point kitz.
given most people are on 40/10 not 80/20 then those people probably only use the D1 and D2. When tones arent needed on sync then the power output is disabled, as seen with the medley phase vs the discovery phase. So I think its quite plausible my issue is crosstalk, but I respect the possibility of it been external noise also. However my line did recover when the engineer the other week moved cables around, meaning I was temporarily away from my disturber, at the moment more evidence seems to be pointing to crosstalk.
More weirdness?
At 5am today my attainable dropped by another 4mbit. No loss of sync, so either DLM changed something without requiring a resync or some interference changed at 5am. I cant generate new graphs, the modem stats script is hanging after ***********11
ok attaching before and after bit/snr graphs, the after is from the new modem stats tool (I finally upgraded after this problem). On the new graph the snr declines smoothly whilst on the old was dips, but it doesnt look obvious to me where the signal has been lost.
My loop loss on D1 is under 10db I think the snr really should be around 60db.
-
whats the reccomended way to kill btagent?
Establish a telnet connection to the HG612, invoke the busybox shell and issue a killall -KILL start btagent command.
A power-cycle or reboot of the device will turn Beattie's busybody back on.
thanks, since I probably forget about this I added the command to auto run whenever I login to the telnet.
so with tr069 on BT can collect performance stats but they need btagent to make remote changes?
-
Right gonna ask the Big question :no: Will the GUI be back after the new firmware has been modded ? I know it's to early to ask that question but any thoughts or inside info would be nice ;)
-
so with tr069 on BT can collect performance stats but they need btagent to make remote changes?
Well, that's not quite what I believe to be the case. Here follows my speculation, as a result of tingles received in my whiskers . . .
The BT Agent calls home to the Evil Empire (once at boot? periodically? -- probably the latter) and establishes a secure connection to a dedicated server. Many functions can then occur. One function is to compare the current version of the firmware on the CPE with the latest available and if there is a difference, upload the latest image and reboot the device.
TR-069 is a defined means for communication between the device and a remote system. It is capable of being used for data gathering, configuration changes and other functions -- of which firmware upgrades are but one.
Perversely, some might say typically, Beattie appears to have decided to 'do her own thing' by embedding proprietary code into the CPE. Very little is publicly known about her busy-body, the BT Agent, but it does seem highly likely that it is identical across the entire spectrum of CPE devices that she provides to end users.
-
Right gonna ask the Big question :no: Will the GUI be back after the new firmware has been modded ? I know it's to early to ask that question but any thoughts or inside info would be nice ;)
How long is a piece of string? ::)
The question that you are really asking is "Has the GUI just been disabled or has its code been removed from the latest firmware?" and that can only be answered when someone has managed to obtain a copy of the firmware image for inspection . . . :-\
-
quick reply @ greybeard.
Its my understanding too that crosstalk impacts most on the shorter lines and that its the higher frequencies that are affected most.
However, I dont know if the following info helps, but when on adsl2+ I was one of the first (if not the 1st) people to go on a shiny new BE MSAN. At first I could get a full 24Mb, over time this deteriorated to 21Mbps.. most remarkably so when the MSAN started to fill up with o2 users.
The place where I noticed crosstalk had the most impact though was across the 6,7,8,9,10 Mbps range. By that I mean the max tones in use by anyone syncing at say 8Mbps would be using. After tones 260 both my SNR and bit loading started to increase. At about tone 300 my SNR was better than say tone 130. It was all a nice smooth dip bit like a shallow bowl. Somewhere around tone 255 (8Mb) was my lowest SNR... until tone 460 ish.
This saucer shape meant that I could never get full bit loading over the 128 -288 region when in the early days I could.
Obviously the more users that synced at x speed then the worse impact it would have on my snr and bit loading across those tones. There must have been far fewer people syncing at over 14Mbp, which is why my own SNR was good there and least impacted by other users and would start to rise again.
Hope you get the gist of what Im trying to say.. I possibly have a DMTtool graph from about 2008ish when you could see this happening quite clearly, but its on an old drive that I need to hook up to the network sometime to transfer some data from. :/
Yes, I see now that I was wrong to say that the highest tones will always be affected worst. I should have qualified it by "if other things are equal" - i.e. if the crosstalk is between lines of similar length, all with uncapped profiles. Clearly that is not always the case, particularly when the crosstalk is between pairs in the cable between the FTTC cab and the PCP. A long line with no D3 signal cannot degrade the D3 of an adjacent short line. Nevertheless, Chrysalis seems to have suffered approx 15dB loss of SNR throughout the D2 band and the D1 band above the ADSL cutback, and I doubt that there are many FTTC lines that are so long that they do not at least make full use of the D1 band. FEXT cross-coupling is mainly capacitive, which increases with increasing frequency, so it is puzzling that Chrysalis' noise does not seem to have this characteristic.
-
Right gonna ask the Big question :no: Will the GUI be back after the new firmware has been modded ? I know it's to early to ask that question but any thoughts or inside info would be nice ;)
How long is a piece of string? ::)
The question that you are really asking is "Has the GUI just been disabled or has its code been removed from the latest firmware?" and that can only be answered when someone has managed to obtain a copy of the firmware image for inspection . . . :-\
;D Yeah BC thats is the Question and Answer we are looking for Disabled or Removed ? I guess once we know, then we will know which direction the HG612stats software is going as I am sure it used the GUI were as DSLstats used Telnet i could be wrong ?
-
Right gonna ask the Big question :no: Will the GUI be back after the new firmware has been modded ? I know it's to early to ask that question but any thoughts or inside info would be nice ;)
How long is a piece of string? ::)
The question that you are really asking is "Has the GUI just been disabled or has its code been removed from the latest firmware?" and that can only be answered when someone has managed to obtain a copy of the firmware image for inspection . . . :-\
Attached is a listing of the directory where the webimg and webidx files were to be found in the old firmware. A reasonably thorough hunt through the rest of the root file system failed to reveal them. Of course, that is not to say that one of our hacker friends might not be able to build them back in again....
I believe the current version of HG612_stats uses only the Telnet interface.
-
Attached is a listing of the directory where the webimg and webidx files were to be found in the old firmware. A reasonably thorough hunt through the rest of the root file system failed to reveal them. Of course, that is not to say that one of our hacker friends might not be able to build them back in again....
I believe the current version of HG612_stats uses only the Telnet interface.
So it looks like it has been removed, you would need some spare space on that Eprom /Flash memory if the GUI was to be re-built and by the looks of it there is no spare memory left after update.
-
I guess once we know, then we will know which direction the HG612stats software is going as I am sure it used the GUI <snip> i could be wrong ?
I can quite definitely say that you are . . . wrong! ;) Sorry, but knowing who wrote the original code that 'kick-started' the Baldy bird's project, I can definitely say that it does use TCP port 23.
I have a stale kitteh biscuit as a prize for the first person to correctly identify the initial writer of the code which inspired No-feathers. :angel:
<snip> by the looks of it there is no spare memory left after update.
Do you have a reference (or link) please? I would be very surprised, unless something else, very significant in size, has been added to the new image. :-\
-
Attached is a listing of the directory where the webimg and webidx files were to be found in the old firmware. A reasonably thorough hunt through the rest of the root file system failed to reveal them. Of course, that is not to say that one of our hacker friends might not be able to build them back in again....
Thank you GB. I shall, in a short while, scrutinise your file.
I believe the current version of HG612_stats uses only the Telnet interface.
:thumbs:
-
I can quite definitely say that you are . . . wrong! ;) Sorry, but knowing who wrote the original code that 'kick-started' the Baldy bird's project, I can definitely say that it does use TCP port 23.
Yes, I can confirm that the GUI's URL is not used for obtaining any stats for the HG612 Modem Stats package of compiled programs.
It was indeed used in the original batch file versions, but even then, I eventually switched to purely telnet obtained stats as some of the data presented to the GUI was clearly 'wrong'.
-
I have a stale kitteh biscuit as a prize for the first person to correctly identify the initial writer of the code which inspired No-feathers. :angel:
IIRC it was your good self running on Linux and BE converted it to Windows, I'll let you keep the biscuit though if I'm correct ;D
-
quick reply @ greybeard.
Its my understanding too that crosstalk impacts most on the shorter lines and that its the higher frequencies that are affected most.
However, I dont know if the following info helps, but when on adsl2+ I was one of the first (if not the 1st) people to go on a shiny new BE MSAN. At first I could get a full 24Mb, over time this deteriorated to 21Mbps.. most remarkably so when the MSAN started to fill up with o2 users.
The place where I noticed crosstalk had the most impact though was across the 6,7,8,9,10 Mbps range. By that I mean the max tones in use by anyone syncing at say 8Mbps would be using. After tones 260 both my SNR and bit loading started to increase. At about tone 300 my SNR was better than say tone 130. It was all a nice smooth dip bit like a shallow bowl. Somewhere around tone 255 (8Mb) was my lowest SNR... until tone 460 ish.
This saucer shape meant that I could never get full bit loading over the 128 -288 region when in the early days I could.
Obviously the more users that synced at x speed then the worse impact it would have on my snr and bit loading across those tones. There must have been far fewer people syncing at over 14Mbp, which is why my own SNR was good there and least impacted by other users and would start to rise again.
Hope you get the gist of what Im trying to say.. I possibly have a DMTtool graph from about 2008ish when you could see this happening quite clearly, but its on an old drive that I need to hook up to the network sometime to transfer some data from. :/
Yes, I see now that I was wrong to say that the highest tones will always be affected worst. I should have qualified it by "if other things are equal" - i.e. if the crosstalk is between lines of similar length, all with uncapped profiles. Clearly that is not always the case, particularly when the crosstalk is between pairs in the cable between the FTTC cab and the PCP. A long line with no D3 signal cannot degrade the D3 of an adjacent short line. Nevertheless, Chrysalis seems to have suffered approx 15dB loss of SNR throughout the D2 band and the D1 band above the ADSL cutback, and I doubt that there are many FTTC lines that are so long that they do not at least make full use of the D1 band. FEXT cross-coupling is mainly capacitive, which increases with increasing frequency, so it is puzzling that Chrysalis' noise does not seem to have this characteristic.
by the way thank you for the time you have spent diagnosing my line, I do appreciate it.
Whats interesting is the morning after I enabled tr069, my power masking got adjusted (thats what I think happened) this occured with no loss of sync and now my snr looks a more normal pattern ie. it slopes. But of course still imo at least 10db of snr down on D1 what it should be. However this change as I mentioned knocked 4mbit of my attainable speed, I was synced at 68mbit with 72 attainable so had a 7+ db margin, now the attainable is matching my sync speed so about 5.9-6db margin and my crc error rate went from 300 in 24 hours to 1300 in 24 hours. Yes a 1.5db of snrm seems to have the impact to increase errors by 400%.
Nothing changed this morning.
-
Whats interesting is the morning after I enabled tr069, my power masking got adjusted (thats what I think happened) this occured with no loss of sync and now my snr looks a more normal pattern ie. it slopes. But of course still imo at least 10db of snr down on D1 what it should be. However this change as I mentioned knocked 4mbit of my attainable speed, I was synced at 68mbit with 72 attainable so had a 7+ db margin, now the attainable is matching my sync speed so about 5.9-6db margin and my crc error rate went from 300 in 24 hours to 1300 in 24 hours. Yes a 1.5db of snrm seems to have the impact to increase errors by 400%.
Nothing changed this morning.
Hmmm. Have you checked the reported Tx Pwr for D1 & D2 in pbParams to see if there have in fact been any changes since last year? (The text formatting has gone awry with the new firmware, because a placeholder has been added for a U4 band, but the figures are all still there).
-
My snr as gone crazy since update, its now goes up at night and drops during the day lol, I to have lost attainable rate for up and down gici=ving me a lower sync speed and pooh loads of ES and CRC errors. I don't think ill be keeping this update, I have to wait a week anyway before I can flash old firmware back, so i'm hoping it will settle.
-
I manually restarted my modem an hour ago to perform a test and I have this...
Retrain Reason: 2
Apparently it was the DLM, maybe the DLM is using the killswitch now in the modem (If it wasn't before)? Any others get DLM intervention rather than a 0 like before?
-
you will get the retrain 2 if manually reseting or restarting(using telnet restart/reboot) only way to stop that is pull the power to reset, you will go back to retrain 0, can someone look at my stats, mainly the crc and es, thers seems to be to many for the time its been up.
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8597 Kbps, Downstream rate = 59396 Kbps
Bearer: 0, Upstream rate = 8449 Kbps, Downstream rate = 51368 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.5 6.5
Attn(dB): 21.7 0.0
Pwr(dBm): 12.0 6.1
VDSL2 framing
Bearer 0
MSGc: 18 56
B: 51 237
M: 1 1
T: 64 33
R: 12 16
S: 0.0322 0.8944
L: 15896 2272
D: 1005 1
I: 64 127
N: 64 254
Counters
Bearer 0
OHF: 60887145 580366
OHFErr: 773 378
RS: 2702084808 845505
RSCorr: 2665126 667
RSUnCorr: 34792 0
Bearer 0
HEC: 7213 0
OCD: 256 0
LCD: 256 0
Total Cells: 3854960972 0
Data Cells: 39391071 0
Drop Cells: 0
Bit Errors: 0 0
ES: 201 316
SES: 0 0
UAS: 24 24
AS: 126004
Bearer 0
INP: 3.00 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 2.06 14.81
OR: 92.77 33.48
AgR: 51460.98 8482.39
Bitswap: 95895/95895 15616/15656
Total time = 1 days 11 hours 28 sec
FEC: 2665126 667
CRC: 773 378
ES: 201 316
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 28 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 7524 23
CRC: 5 7
ES: 1 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 11 hours 28 sec
FEC: 590764 194
CRC: 134 113
ES: 36 85
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 2074362 473
CRC: 639 265
ES: 165 231
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 11 hours 3 sec
FEC: 2665126 667
CRC: 773 378
ES: 201 316
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2506)
DS: (33,859) (1216,1961) (2793,3938)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 8594 kbps 59392 kbps
Actual Aggregate Tx Power: 6.1 dBm 12.0 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 6.2 35.5 53.4 N/A N/A 16.5 43.7 67.0
Signal Attenuation(dB): 6.2 34.7 51.4 N/A N/A 19.6 43.4 67.6
SNR Margin(dB): 6.5 6.7 6.6 N/A N/A 6.5 6.4 6.4
TX Power(dBm): 0.7 -7.2 4.4 N/A N/A 8.1 7.9 5.2
#
-
you will get the retrain 2 if manually reseting or restarting, only way to stop that is pull the power to reset, you will go back to retrain 0, can someone look at my stats, mainly the crc and es, thers seems to be to many for the time its been up.
You will not get 2 upon a manual reset, 2 is DLM Intervention (the broadcom retrain code 2 is for a negative margin, but I don't believe that to be true (for OR) and my margins were far from negative as well! :) ). That's my whole point, I pulled the power of my modem, this normally leading to a Retrain 0 like all the other countless times I had to do it in the past.
-
Ok then, go to telnet, and reboot using telnet, unless all the lights go out on the modem, it will give you retrain2, I didn't know you meant manually resetting by pulling the power, that is odd, should give you retrain 0, unless it synced and then dlm kicked in and resynced again. Ive added telnet restart/reboot to my previous post to make it a bit more clear to what I was on about.
-
Whats interesting is the morning after I enabled tr069, my power masking got adjusted (thats what I think happened) this occured with no loss of sync and now my snr looks a more normal pattern ie. it slopes. But of course still imo at least 10db of snr down on D1 what it should be. However this change as I mentioned knocked 4mbit of my attainable speed, I was synced at 68mbit with 72 attainable so had a 7+ db margin, now the attainable is matching my sync speed so about 5.9-6db margin and my crc error rate went from 300 in 24 hours to 1300 in 24 hours. Yes a 1.5db of snrm seems to have the impact to increase errors by 400%.
Nothing changed this morning.
Hmmm. Have you checked the reported Tx Pwr for D1 & D2 in pbParams to see if there have in fact been any changes since last year? (The text formatting has gone awry with the new firmware, because a placeholder has been added for a U4 band, but the figures are all still there).
no worries I am still on the old firmware anyway.
so as was before.
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.2 14.8 29.0 N/A 9.8 23.8 39.5
Signal Attenuation(dB): 0.2 14.7 28.8 N/A 9.8 23.8 39.5
SNR Margin(dB): 8.8 9.2 10.2 N/A 6.8 6.8 7.0
TX Power(dBm): -5.0 -27.2 4.8 N/A 10.6 7.4 7.4
and now
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.2 14.8 29.0 N/A 9.8 23.8 39.5
Signal Attenuation(dB): 0.2 14.7 28.8 N/A 9.8 23.8 39.5
SNR Margin(dB): 9.1 9.9 9.2 N/A 5.7 5.8 5.8
TX Power(dBm): -5.0 -27.2 4.8 N/A 10.6 7.4 7.4
so looks same on the tx power readings.
-
I have a stale kitteh biscuit as a prize for the first person to correctly identify the initial writer of the code which inspired No-feathers. :angel:
IIRC it was your good self running on Linux and BE converted it to Windows, I'll let you keep the biscuit though if I'm correct ;D
One stale kitteh biscuit (slightly licked) has been dispatched to the Isle of Thanet, Kent. :D
-
One stale kitteh biscuit (slightly licked) has been dispatched to the Isle of Thanet, Kent. :D
Thanks, I'll pass it on to the friendly neighbourhood cat :P
-
A Google search turned up this interesting paper about the various G.993.2 band plans for VDSL2: http://www.joepeesoft.com/Public/DSL_Corner/Docs/Publications/PUB_2009_10_TNO35092_SpM_VDSL2_FreqAllocations.pdf (http://www.joepeesoft.com/Public/DSL_Corner/Docs/Publications/PUB_2009_10_TNO35092_SpM_VDSL2_FreqAllocations.pdf). This page by the same author gives more detail about each plan. http://www.joepeesoft.com/Public/DSL_Corner/DSL_Spectra_VDSL2.html#dummy (http://www.joepeesoft.com/Public/DSL_Corner/DSL_Spectra_VDSL2.html#dummy).
The current UK plan for Profile 17a is variant B8-11, from the overall band plan "998" for Region B (Europe). The recent changes we have seen, and the differences between the Huawei and ECI cabinets, are just minor variations to the band boundaries within this plan.
It has been rumoured, although I have not seen any confirmation, that BTOR is planning to move to Profile 30a in order to increase speeds to over 100Mb/s for short lines. In this case I would guess that the new band plan is likely to be B8-13. The U0, U1, U2, D1 & D2 bands would remain as is. A new U3 band would take over the bottom part of the current D3, up to 14MHz, while the top of D3 would move up from 17.664 to 21.45MHz. There would then be a U4 from 21.45 to 24.89MHz and above that a D4 up to 30MHz.
One of the changes in the new HG612 firmware is that the xdslcmd info --pbParams command now yields placeholders for a U4 band, in addition to those for U3 that were there in the old firmware. However, there are no D4 placeholders. "Building castles in the air", I would speculate that one reason for the firmware rollout might be to prepare for the profile switch - maybe the old firmware does not properly support the B8-13 band plan? The absence of D4 perhaps suggests that this band will not be implemented initially - it would only benefit those closest to the cabinet. So upload speeds might increase much more than download ones.
If the old firmware is incompatible with Profile 30a, BTOR might be forced to physically replace those HG612's that they do not succeed in re-flashing remotely.
-
I think that change wouldnt work well for my line greybeard, but I think you are right, the U4 seems evidence of a profile 30 rollout in the works, and given BT's history I am not surprised as profile 30 is far cheaper to rollout than vectoring.
What I prefer to see is openreach make changes that make interleaving a much less common occurence as I think interleaving is an abomination. eg. vectoring to decrease crosstalk noise, DLM changes to favour banding (increasing snrm) over FEC, and a new fault policy that decides that if a line has been interleaved its classed as faulty and as such the interleaving is a temporary workaround not a permanent fix.
-
The BT Agent calls home to the Evil Empire (once at boot? periodically? -- probably the latter) and establishes a secure connection to a dedicated server.
This had me puzzled too.. why install both TR069 and a BTAgent, when TR069 is capable of both?
Remote management can be done either via CWMP or SNMP. TR069 uses the CWMP protocol and was supposedly designed to be more secure than SNMP.
Since weve found out that turning off CWMP doesnt stop this latest update then it goes to say that its the BTAgent that is wholey responsible for the management of firmware update. I strongly suspect that they installed TR069 for BT retail helpdesk purposes leaving the BTAgent to do other things. I have also wondered in the past if the BTAgent could also be responsible for BTFon (wifi) settings as Im not certain if TR069 encompasses something such as BTFon within its remit. I dont know for sure though on that point so cant rule it out entirely.
These updates are interesting? in that how they are being rolled out. Normally you'd expect firmware upgrades to roll out en-mass. ie the does a simple check of its f/w against the latest and if its not then it would install.
From comments in this thread it appears theres something more to the BT f/w rollout its possibly geographic to co-incide with the DSLAM updates, so our modems are obviously giving away our location regardless or not if we are a BTr customer.
-
It has been rumoured, although I have not seen any confirmation, that BTOR is planning to move to Profile 30a in order to increase speeds to over 100Mb/s for short lines.
Yes Ive heard this too. Actually Im not sure now but I think BS may have mentioned that it was in the pipeline?
-
I done the same research as well Greybeard, but as there wasn't a D4 in the pbParams I thought I was barking up the wrong tree as I was very tired so I left it! With the new MK2 filter supporting up to 30MHz, I think we could see some areas be replaced.
I think that change wouldnt work well for my line greybeard, but I think you are right, the U4 seems evidence of a profile 30 roll out in the works, and given BT's history I am not surprised as profile 30 is far cheaper to roll out than vectoring.
I don't think vectoring is getting abandoned (at least I don't think it should be I also doubt it is as well), though there is one thing BT SIN 498 currently states... "The modem shall support 17MHz Vectoring as defined in G.993.5[7].
This requires the modem to be “vector ready”." [1]
Obviously the move to 30MHz hasn't been completed but by this I was always under the impression they wanted vectoring to be rolled out before 30 MHz but maybe they have made some serious progression in both fields.
[1] http://www.sinet.bt.com/498v5p1.pdf R.VDSL2.12
-
I done the same research as well Greybeard, but as there wasn't a D4 in the pbParams I thought I was barking up the wrong tree as I was very tired so I left it! With the new MK2 filter supporting up to 30MHz, I think we could see some areas be replaced.
I think that change wouldnt work well for my line greybeard, but I think you are right, the U4 seems evidence of a profile 30 roll out in the works, and given BT's history I am not surprised as profile 30 is far cheaper to roll out than vectoring.
I don't think vectoring is getting abandoned (at least I don't think it should be I also doubt it is as well), though there is one thing BT SIN 498 currently states... "The modem shall support 17MHz Vectoring as defined in G.993.5[7].
This requires the modem to be “vector ready”." [1]
Obviously the move to 30MHz hasn't been completed but by this I was always under the impression they wanted vectoring to be rolled out before 30 MHz but maybe they have made some serious progression in both fields.
[1] http://www.sinet.bt.com/498v5p1.pdf R.VDSL2.12
Not sure we should read too much into the SIN not specifying 30a - after all they can always reissue it. Vectoring is a bit different in that the trial is already in the public domain. If the SIN had required modems to support 30a, the press would have immediately jumped to the conclusion that it is going to happen, when a final decision might not have been made.
As Chrysalis says, lines of a similar length to his might lose downstream speed on the 30a band plan, and many home users would not be mollified by the faster upstream speed. If vectoring were rolled out at the same time, it might "sugar the pill".
-
I done the same research as well Greybeard, but as there wasn't a D4 in the pbParams I thought I was barking up the wrong tree as I was very tired so I left it! With the new MK2 filter supporting up to 30MHz, I think we could see some areas be replaced.
I think that change wouldnt work well for my line greybeard, but I think you are right, the U4 seems evidence of a profile 30 roll out in the works, and given BT's history I am not surprised as profile 30 is far cheaper to roll out than vectoring.
I don't think vectoring is getting abandoned (at least I don't think it should be I also doubt it is as well), though there is one thing BT SIN 498 currently states... "The modem shall support 17MHz Vectoring as defined in G.993.5[7].
This requires the modem to be “vector ready”." [1]
Obviously the move to 30MHz hasn't been completed but by this I was always under the impression they wanted vectoring to be rolled out before 30 MHz but maybe they have made some serious progression in both fields.
[1] http://www.sinet.bt.com/498v5p1.pdf R.VDSL2.12
yeah I think it will come eventually but I think rather its not coming soon and it seems BT dont want to sit on their bums until then so profile 30 looks next. Especially now with these MK2 faceplates as well where profile 30 is mentioned.
-
What I prefer to see is openreach make changes that make interleaving a much less common occurence as I think interleaving is an abomination. eg. vectoring to decrease crosstalk noise, DLM changes to favour banding (increasing snrm) over FEC, and a new fault policy that decides that if a line has been interleaved its classed as faulty and as such the interleaving is a temporary workaround not a permanent fix.
I would like to see the facility for ISPs to lower target SNRM to say 3dB rather than fix it at 6dB.
My 'longer' connection is extremely stable at an overall SNRM 6dB & I believe it could sustain reliability at alower value, thus increasing sync & throughput speeds.
-
I seem to recall that some of Asbokid's research and analysis showed that Profile 30a would be a 'profile too far' for the BCM6368 chip in the Huawei HG612. Somewhere (and I can't put my paws on it, at the moment) he showed that the BCM6368 was only just coping with Profile 17a (with a little bit left 'in reserve').
Both his attempts to get a HG612 to synchronise with a MA5616 using Profile 30a and my attempts to get a HG612 to synchronise with a Planet VC-230N (operating in CO mode) using Profile 30a failed. :(
My feeling is, therefore, that if/when Profile 30a is 'rolled out' a new CPE device will be required.
-
I seem to recall that some of Asbokid's research and analysis showed that Profile 30a would be a 'profile too far' for the BCM6368 chip in the Huawei HG612. Somewhere (and I can't put my paws on it, at the moment) he showed that the BCM6368 was only just coping with Profile 17a (with a little bit left 'in reserve').
Both his attempts to get a HG612 to synchronise with a MA5616 using Profile 30a and my attempts to get a HG612 to synchronise with a Planet VC-230N (operating in CO mode) using Profile 30a failed. :(
My feeling is, therefore, that if/when Profile 30a is 'rolled out' a new CPE device will be required.
Yes, this post by Asbokid on Thinkbroadband may be what you recollected?
http://forums.thinkbroadband.com/dslrouter/4238694-hg612-fttc-modem.html#Post4239196 (http://forums.thinkbroadband.com/dslrouter/4238694-hg612-fttc-modem.html#Post4239196)
Though he does say that the BCM6368 "reportedly supports Profile 30a" - maybe (pawing at straws) the new BLOB might enable that support?
Asbokid's 30a testing was with band plan B8-16, which has U3 above D3 and no U4 or D4. He did get the ECI vg3503j to sync using Profile 30a.
-
DS1 band:
Signal attenuation(dB) : 15.6
Line attenuation(dB) : 15.6
Line SNR margin(dB) : 25.9
US1 band:
Signal attenuation(dB) : 0.0
Line attenuation(dB) : 0.0
Line SNR margin(dB) : 8.9
DS2 band:
Signal attenuation(dB) : 8.9
Line attenuation(dB) : 8.8
Line SNR margin(dB) : 25.9
US2 band:
Signal attenuation(dB) : 0.0
Line attenuation(dB) : 0.0
Line SNR margin(dB) : 8.8
DS3 band:
Signal attenuation(dB) : 0.2
Line attenuation(dB) : 0.2
Line SNR margin(dB) : 25.2
US3 band:
Signal attenuation(dB) : 1.4
Line attenuation(dB) : 0.3
Line SNR margin(dB) : 8.8
Is it me - have I missed something, but those figures look a bit strange.
Why is DS1 more attenuated than DS3 are they transposed?
-
Thank you for being my memory bank GB. ;)
Though he does say that the BCM6368 "reportedly supports Profile 30a"
A HG612 will make that claim, if appropriately interrogated. The relevant output from the three HG6xx devices now follows --
HG610
# xdslcmd profile --show
xdslcmd: invalid command
#
HG612
# xdslcmd profile --show
Modulations:
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled
VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
30a Enabled
US0 Enabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra Off
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) Off/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: On
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)
#
HG622
# xdslcmd profile --show
Modulations:
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra Off
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) Off/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: Off
SOS: On
Training Margin(Q4 in dB): 67
#
-
Is it me - have I missed something, but those figures look a bit strange.
Why is DS1 more attenuated than DS3 are they transposed?
Sorry Kitz but I do not recognise the format of the data that you have shown. Perhaps our avian colleague could assist with an explanation? :-\
-
Its stats from the ECI modem that Greybeard33 linked to regarding the testing that Asbo did.
-
Is it me - have I missed something, but those figures look a bit strange.
Why is DS1 more attenuated than DS3 are they transposed?
Sorry Kitz but I do not recognise the format of the data that you have shown. Perhaps our avian colleague could assist with an explanation? :-\
Kitz' quote is from Asbokid's post I linked above. It is an extract of his test results of the ECI vg3503j synced to the MA5616 at 115Mb/s using Profile 30a. The strange attenuation figures possibly result from the artificial test conditions with zero loop length?
Edit: sorry Kitz - this crossed with your own explanation.
-
>> The strange attenuation figures possibly result from the artificial test conditions with zero loop length?
I had considered that... but it wouldnt make sense. No cable is going to be entirely perfect and if anything was going to be attenuated, then surely it would be the higher frequencies that showed any attenuation first? Id even considered powercut back which could perhaps explain it for the SNRm, but that doesnt seem right either. Upstream looks ok.
But look at how D1 & D2 are more attenuated than U1 and even U2. Thats not right. Order of attenuation should follow the same order as the banding.
(unless that line is suffering from severe FEXT... but thats a 1-1 connection?)
Even if those DS figures have been transposed theres still something weird going on.
-
Ah I see. Thank you, both.
However I can't offer any explanation for the observation. :no:
-
my couple of points.
I remember in some tests asbokid artifically messed up the attentuation as an experiment, its possible those figures were the result of that.
Also in terms of his assessment of profile 30a he wasnt using this new firmware, and firmware versions can entirely change behaviour and capability of devices.
-
Ok, I've had 3 re-syncs since the new firmware update and of course this forces the PPPoE connection to drop. Though up on re-syncing it appears I still have the same IP now, anyone else have this? I suppose could checking if disconnecting the PPPoE connection manually will assign me a new IP!
-
It seems to depend on which type of resync has occurred.
Most times, Retrain Reason 2 resyncs allow the PPPoE session to survive as they are so quick.
Thus the IP Profile is usually maintained at possibly too high or low a value, perhaps explaining some users' confusion regarding large differences between sync speed & IP Profile.
If I'm not mistaken, you have previously mentioned that as a problem with Plusnet but not BT connections.
It appears that Retrain Reason 0 resyncs ALWAYS cause a new PPPoE session to be initiated (or at least they used to with the original firmware).
In my experience, it is wise to force a new PPPoE session via the ROUTER following a Retrain Reason 2 resync, just to make sure the relevant IP Profile is being used.
-
It seems to depend on which type of resync has occurred.
Most times, Retrain Reason 2 resyncs allow the PPPoE session to survive as they are so quick.
I've had both and it's maintained the same IP, router shows the PPPoE has dropped and re-initiated.
Thus the IP Profile is usually maintained at possibly too high or low a value, perhaps explaining some users' confusion regarding large differences between sync speed & IP Profile.
bRAS mismatch
If I'm not mistaken, you have previously mentioned that as a problem with Plusnet but not BT connections.
It appears that Retrain Reason 0 resyncs ALWAYS cause a new PPPoE session to be initiated (or at least they used to with the original firmware).
In my experience, it is wise to force a new PPPoE session via the ROUTER following a Retrain Reason 2 resync, just to make sure the relevant IP Profile is being used.
Doesn't really matter at the minute about speed as I'm banded at 20Mbps and have been for the last 40 days.
-
As anyone noticed the fixed ip address?, I had the same ip now(from leeds when im no where near it lol) since the first update to the dlm, wont change on reboot/reset, Ive disconnected and connected numerous times and still get the same ip.
-
As anyone noticed the fixed ip address?, I had the same ip now(from leeds when im no where near it lol) since the first update to the dlm, wont change on reboot/reset, Ive disconnected and connected numerous times and still get the same ip.
I have the same, mention'd this yesterday somewhere but not sure where now...
Edit: Was this thread, page 6.
-
Hmmm. That's unusual.
I'm with Plusnet who are you fellas with?
Mt modem's firmware was updated 17th October, sync speeds:-
Bearer: 0, Upstream rate = 4586 Kbps, Downstream rate = 20256 Kbps (Retrain Reason 0).
Using the 96.79% ratio, I calculated the IP Profile to be 19.61 Mbps (rounded up from 19605.7824).
Just for fun, I disconnected/reconnected the ROUTER yesterday afternoon.
The IP Address changed & then I ran a BT speed test.
As expected, the reported IP Profile was indeed 19.61 Mbps (see attached).
The modem has still not resynced since the firmware update.
Prior to the firmware update, my PPPoE session was always maintained via Retrain Reason 2 resyncs, but was always renewed via Reason 0 resyncs.
I wonder if you have somehow been allocated a fixed IP Address?
Are you 100% sure that your IP Profile does NOT equate to 96.79% of sync speed?
Your earlier post mentions that your connection maintained the same IP.
Did that relate to IP Profile or IP Address (or both???)
-
I'm with BT, my IP did change today but that was with a disconnection 5/10 mins while the engineer here was here.
My IP has remained before on Retrain 0 an 2.
-
I'm with BT, my IP did change today but that was with a disconnection 5/10 mins while the engineer here was here.
My IP has remained before on Retrain 0 an 2.
Just for the purpose of clarity, do you refer to IP Address or IP Profile (or both)?
-
IP Address.
-
IP Address.
Is your IP Profile now at 96.79% of sync speed (or thereabouts)?
-
Yes.
25.899, IP Profile is 25.9Mbps
-
Not sure if you ment me or not so, yes I was referring to ip address, my ip profile still changes, ip address is stuck at leeds, I would say a month now at least. Do you remember the old master socket with the screw holders instead of IDC(I think that's what you call them), well I changed mine back to the screw connectors to give a good stable connection in the master socket, sync speed shot up loads, I couldn't believe it, those idc connectors are pants, just not tight enough to get a good connection, im not breaking the law either as my main line terminates 2inchs coming out of the wall, followed by my cat6 that BT connected.