Print

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

[Chrysalis]

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.

[Greybeard33]

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).

[boe323]

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.

[ryant704]

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?

[boe323]

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   
#

[ryant704]

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.

[boe323]

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.

[Chrysalis]

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.

[burakkucat]

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. 

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

One stale kitteh biscuit (slightly licked) has been dispatched to the Isle of Thanet, Kent. 

[Ronski]

One stale kitteh biscuit (slightly licked) has been dispatched to the Isle of Thanet, Kent. 

Thanks, I'll pass it on to the friendly neighbourhood cat 

[Greybeard33]

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. This page by the same author gives more detail about each plan. 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.

[Chrysalis]

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.

[kitz]

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.

[kitz]

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?

[ryant704]

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