Print

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

[Greybeard33]

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

[Chrysalis]

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.

[Bald_Eagle1]

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.

[burakkucat]

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.

[Greybeard33]

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 

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.

[kitz]

  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?

[burakkucat]

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

Code: [Select]

# xdslcmd profile --show
xdslcmd: invalid command
#

HG612

Code: [Select]

# 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

Code: [Select]

# 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
#


[burakkucat]

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]

Its stats from the ECI modem that Greybeard33 linked to regarding the testing that Asbo did.

[Greybeard33]

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.

[kitz]

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

[burakkucat]

Ah I see. Thank you, both.

However I can't offer any explanation for the observation. 

[Chrysalis]

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.

[ryant704]

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!

[Bald_Eagle1]

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.