Print

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

[Dan]

I stumbled across this awesome site, did a lot of reading, tried a few things and now I'm out of ideas.

I had FTTC enabled a few weeks ago, ended up using a HG612 instead of using the HH5A supplied by my ISP. Internal wiring is through a NTE5A with a MK3 SSFP. I have tried going through the test socket to see if it would make a difference which it does but only by 2Mb.

Current sync is 38448/19658. I think I have a bit of a distance back to the Cab (400-500m), my estimated speed was 49.9Mb and 69.8Mb.

My line stats are up on MDWS under the user DanH.

Thanks in advance

[burakkucat]

Welcome to the Kitz forum. 

Just to clarify, do you have any extension sockets or wiring past the NTE5/A at all?

I am currently viewing five panes on MDWS which are displaying your --

• SNRM. That looks good. There is no cyclical variation over a 24 hour period.
• CRCs. One spike of 170 in the DS stands out.
• FECs. Two spikes, the first of 7159 and the second of 1360 corresponding to the CRC spike, above.
• QLN. Yuck. Significant noise and RF ingress.
• HLOG. Virtually perfect.

At the moment I will just say "watch and wait". Others will, in due course, give their interpretation of the other graphed statistics . . .

[Weaver]

Welcome Dan!

[Dan]

Welcome to the Kitz forum. 

Just to clarify, do you have any extension sockets or wiring past the NTE5/A at all?

I am currently viewing five panes on MDWS which are displaying your --

• SNRM. That looks good. There is no cyclical variation over a 24 hour period.
• CRCs. One spike of 170 in the DS stands out.
• FECs. Two spikes, the first of 7159 and the second of 1360 corresponding to the CRC spike, above.
• QLN. Yuck. Significant noise and RF ingress.
• HLOG. Virtually perfect.

At the moment I will just say "watch and wait". Others will, in due course, give their interpretation of the other graphed statistics . . .

Thanks for the welcome .

There is one extension which has the telephone connected to it upstairs. Originally the master socket was a LJU3 with the incoming and extension both punched down into the same slots. Before I had changed the master to an NTE5A I had already disconnected the ringer wire as I had some ADSL stability issues. This fixed those and gained me 3Mb.

Around a month before I had FTTC enabled the NTE5A was installed with a MK3 SSFP. This gained me a further 0.5Mb on my long line which was now at 8.5Mbps.

Going on the attenuation figures which I know are not always a given. I believe I should be seeing over 50Mbps downstream.

[burakkucat]

There is one extension which has the telephone connected to it upstairs. Originally the master socket was a LJU3 with the incoming and extension both punched down into the same slots. Before I had changed the master to an NTE5A I had already disconnected the ringer wire as I had some ADSL stability issues. . . .

Around a month before I had FTTC enabled the NTE5A was installed with a MK3 SSFP. . .

Note: correction in my first post - When I connected through the 'master' socket, I meant to say 'test' socket. The modem is on the master socket already.

Thank you for that further information. So your experiment via the test socket had temporarily removed the centralised filter and the telephony extension wiring from the circuit.

It is very difficult to predict the precise synchronisation speed for any circuit. What has to be remembered is that an xDSL service is very much a "best effort" service. There can be many factors which can affect the overall throughput.

At present your current actual DS synchronisation speed is greater than the maximum attainable (which is calculated during the "discovery phase" as the modem and DSLAM configure the circuit for use). It might be worthwhile to reboot the HG612 modem between 1100 - 1200 hours tomorrow (by a push on the reset button or by power cycling the device).

[Weaver]

Btw you can go back and change your earlier posts. Just locate the older post and click Modify.

[Ronski]

Weaver, you can only edit posts for a certain time, I think it's up to 12 hours.

What strikes me as odd is the OP has almost a full 20 Mbps up stream sync, yet only 38 Mbps down stream. Surely given the upstream you'd expect the down stream to be better.

[Weaver]

@ronski, are you sure about the time limit? I wouldn't know, I'm in no position to contradict you.

[tbailey2]

Weaver, you can only edit posts for a certain time, I think it's up to 12 hours.

It's at least seven days looking at my own posts...

[WWWombat]

If I compare the basic graphs for DanH against a line of similar attenuation, garypower, I can see:

• DanH's Hlog graph looks nice and smooth - so the basic copper circuit seems OK.
• DanH's Hlog graph drops slightly faster than garypower's, matching the slightly larger attenuation. It'll take a dB or two away from the bit-loading decisions, more at higher frequencies.
• DanH's QLN graph shows enough noise, but it isn't spectacularly wrong. Mine is much worse, and only 100m long!
• DanH's QLN graph is very similar to garypower's, generally a couple of dB noisier downstream. Upstream shows U2 to be 10dB quieter!
  I suspect this means that DanH is suffering crosstalk, but mostly from modems that are much further away from the cabinet, so they aren't using U2. Or perhaps they're TT customers, whose 2Mbps upstream isn't causing much impact.
• The SNR/tone graph shows the outcome you'd expect from adding the 2 previous graphs together: SNR slightly lower across the board downstream, but notably higher in U2.
• The bits/tone graph then matches the SNR/tone

In comparing those 2 lines, everything looks to be explainable, and reasonable. Just different to what I've seen before. I guess it goes to show that every line is different, and sits in a context of neighbouring lines that is different too.

It is notable the INP=0, delay=0 and interleaving is off, so DLM hasn't intervened. However, the graphs for FECs shows the downstream counter is running, so the modems have negotiated FEC protection to be turned on. That's a little unusual, if the package speed should be 80/20.

Getting the textual line stats might be good - either from the command line on the modem, or from the logging program. I might see something else from looking at them (the output from "--stats" and "--pbParams" specifically).

[burakkucat]

I see Dan had followed my suggestion and prompted the modem & DSLAM to resynchronise at 1153 hours this morning. It will be interesting to see how the circuit behaves over the following 24 hours.

[Dan]

If I compare the basic graphs for DanH against a line of similar attenuation, garypower, I can see:

• DanH's Hlog graph looks nice and smooth - so the basic copper circuit seems OK.
• DanH's Hlog graph drops slightly faster than garypower's, matching the slightly larger attenuation. It'll take a dB or two away from the bit-loading decisions, more at higher frequencies.
• DanH's QLN graph shows enough noise, but it isn't spectacularly wrong. Mine is much worse, and only 100m long!
• DanH's QLN graph is very similar to garypower's, generally a couple of dB noisier downstream. Upstream shows U2 to be 10dB quieter!
  I suspect this means that DanH is suffering crosstalk, but mostly from modems that are much further away from the cabinet, so they aren't using U2. Or perhaps they're TT customers, whose 2Mbps upstream isn't causing much impact.
• The SNR/tone graph shows the outcome you'd expect from adding the 2 previous graphs together: SNR slightly lower across the board downstream, but notably higher in U2.
• The bits/tone graph then matches the SNR/tone

In comparing those 2 lines, everything looks to be explainable, and reasonable. Just different to what I've seen before. I guess it goes to show that every line is different, and sits in a context of neighbouring lines that is different too.

It is notable the INP=0, delay=0 and interleaving is off, so DLM hasn't intervened. However, the graphs for FECs shows the downstream counter is running, so the modems have negotiated FEC protection to be turned on. That's a little unusual, if the package speed should be 80/20.

Getting the textual line stats might be good - either from the command line on the modem, or from the logging program. I might see something else from looking at them (the output from "--stats" and "--pbParams" specifically).

Should the DLM have intervened? What brought me to really ask about the line was that I have a decent upload and the download being quite far off the estimate (even though it is a best effort service)

I have added the --status and --pbParams info from the modem as of a few minutes ago.

Code: [Select]

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19361 Kbps, Downstream rate = 37696 Kbps
Bearer: 0, Upstream rate = 19342 Kbps, Downstream rate = 38040 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.3 6.7
Attn(dB): 19.9 0.0
Pwr(dBm): 12.5 7.6
VDSL2 framing
Bearer 0
MSGc: 18 19
B: 239 239
M: 1 1
T: 64 64
R: 14 14
S: 0.2008 0.3949
L: 10120 5146
D: 1 1
I: 254 127
N: 254 254
Counters
Bearer 0
OHF: 25099236 2191778
OHFErr: 509 20
RS: 1606331330 3929403
RSCorr: 3878 52
RSUnCorr: 2748 0

Bearer 0
HEC: 2270 0
OCD: 110 0
LCD: 110 0
Total Cells: 1621917588 0
Data Cells: 33160015 0
Drop Cells: 0
Bit Errors: 0 0

ES: 350 20
SES: 0 0
UAS: 26 26
AS: 80953

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 3.22 6.34
OR: 59.53 31.53
AgR: 38099.99 19373.77

Bitswap: 26538/26538 326/326

Total time = 22 hours 29 min 39 sec
FEC: 3878 52
CRC: 509 20
ES: 350 20
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 14 min 39 sec
FEC: 57 0
CRC: 5 0
ES: 5 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: 9 0
CRC: 2 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 22 hours 29 min 39 sec
FEC: 3878 52
CRC: 509 20
ES: 350 20
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 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
Since Link time = 22 hours 29 min 13 sec
FEC: 3878 52
CRC: 509 20
ES: 350 20
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0



Code: [Select]

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19361 Kbps, Downstream rate = 37868 Kbps
Bearer: 0, Upstream rate = 19342 Kbps, Downstream rate = 38040 Kbps

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3755)
  VDSL Port Details   Upstream   Downstream
Attainable Net Data Rate:     19361 kbps     37868 kbps
Actual Aggregate Tx Power:        7.6 dBm      12.5 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2   D3
  Line Attenuation(dB): 7.4 31.2 46.6   N/A   N/A 14.7 38.0 60.1
Signal Attenuation(dB): 7.4 30.5 45.3   N/A   N/A 21.6 37.7 60.2
SNR Margin(dB): 7.0 6.7 6.7   N/A   N/A 6.4 6.4 6.4
TX Power(dBm): 0.3 -11.5 6.5   N/A   N/A 9.4 7.8 4.6

I see Dan had followed my suggestion and prompted the modem & DSLAM to resynchronise at 1153 hours this morning. It will be interesting to see how the circuit behaves over the following 24 hours.

Yes I did, I got jut before 12 so gave it a go.

[Bald_Eagle1]

I have reformatted your pbParams data into columns to make it a little easier to view

Code: [Select]

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19361 Kbps, Downstream rate = 37868 Kbps
Bearer: 0, Upstream rate = 19342 Kbps, Downstream rate = 38040 Kbps

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3755)
  VDSL Port Details   Upstream   Downstream
Attainable Net Data Rate:     19361 kbps     37868 kbps
Actual Aggregate Tx Power:        7.6 dBm      12.5 dBm
====================================================================================
  VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
  Line Attenuation(dB): 7.4 31.2 46.6   N/A   N/A 14.7 38.0 60.1
Signal Attenuation(dB): 7.4 30.5 45.3   N/A   N/A 21.6 37.7 60.2
SNR Margin(dB): 7.0 6.7 6.7   N/A   N/A 6.4 6.4 6.4
TX Power(dBm): 0.3 -11.5 6.5   N/A   N/A 9.4 7.8 4.6

I can see that your Signal Attenuation in the D1 band is quite a bit higher than Line Attenuation.

I'm not sure that any of us know why that should be the case, but we do tend to see worse Signal Attenuation on longer lines (maybe due to power mask cut backs to avoid swamping weaker ADSL signals, especially when, as in my case, the cabinet is over 5km from the exchange?).

e.g. This is from my 1100m or so line:-

Code: [Select]

xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 4718 Kbps, Downstream rate = 21812 Kbps
Bearer: 0, Upstream rate = 4516 Kbps, Downstream rate = 22399 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
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,1196)
DS: (33,859) (1216,1720)
  VDSL Port Details   Upstream   Downstream
Attainable Net Data Rate:      4718 kbps     21812 kbps
Actual Aggregate Tx Power:        6.8 dBm      12.6 dBm
 =========================================================================================
  VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
  Line Attenuation(dB): 8.1 53.8   N/A   N/A   N/A 21.8 66.1   N/A
Signal Attenuation(dB): 8.1 52.6   N/A   N/A   N/A 30.6 65.9   N/A
SNR Margin(dB): 6.6 6.8   N/A   N/A   N/A 6.2 6.1   N/A
TX Power(dBm): -0.7 6.0   N/A   N/A   N/A 11.5 6.0   N/A


Do you know how far your cabinet is from the exchange itself?



I can also see that you are connected to a Huawei cabinet & that your Available DS tones at Discovery Phase are different to mine.
Yours end at tone 3959 & mine end at 3970.

That is probably due to different DSLAM chipset versions.

This is from my connection, using the telnet command xdslcmd info --vendor:-

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   0
Last initialization procedure status:   0
Max:   Upstream rate = 4718 Kbps, Downstream rate = 21812 Kbps
Bearer:   0, Upstream rate = 4516 Kbps, Downstream rate = 22399 Kbps
Bearer:   1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
ChipSet Vendor Id:   BDCM:0xa459
ChipSet VersionNumber:   0xa459
ChipSet SerialNumber:   



I have G.INP applied on my DS, whereas you haven't.

The lack of G.INP on your connection might be down to the chipset version (there does seem to be a bit of a pattern).

For curiosity, could you please post the output from the telnet command xdslcmd info --vendor for your connection?



None of the above might actually be relevant to the query as to why you have such a low DS Attainable rate & sync speed against such a high US attainable rate & sync speed.


The answer is probably tucked away somewhere within the raw stats, but I can't see it yet.

If it was all due to aluminium cabling, I would have also expected to see lower US speeds.

[Dan]

I have reformatted your pbParams data into columns to make it a little easier to view

Thanks

Do you know how far your cabinet is from the exchange itself?

Quite a long way. 4km or so. My ADSL estimates were 2-4Mbps but I actually achieved 8Mbps with a Broadcom based modem/router and cleaning up my internal wiring.

I can also see that you are connected to a Huawei cabinet & that your Available DS tones at Discovery Phase are different to mine.
Yours end at tone 3959 & mine end at 3970.

That is probably due to different DSLAM chipset versions.

This is from my connection, using the telnet command xdslcmd info --vendor:-

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   0
Last initialization procedure status:   0
Max:   Upstream rate = 4718 Kbps, Downstream rate = 21812 Kbps
Bearer:   0, Upstream rate = 4516 Kbps, Downstream rate = 22399 Kbps
Bearer:   1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
ChipSet Vendor Id:   BDCM:0xa459
ChipSet VersionNumber:   0xa459
ChipSet SerialNumber:   



I have G.INP applied on my DS, whereas you haven't.

The lack of G.INP on your connection might be down to the chipset version (there does seem to be a bit of a pattern).

For curiosity, could you please post the output from the telnet command xdslcmd info --vendor for your connection?

Here is mine:

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   0
Last initialization procedure status:   0
Max:   Upstream rate = 19361 Kbps, Downstream rate = 37696 Kbps
Bearer:   0, Upstream rate = 19342 Kbps, Downstream rate = 38040 Kbps

ChipSet Vendor Id:   BDCM:0xa48c
ChipSet VersionNumber:   0xa48c
ChipSet SerialNumber:   

None of the above might actually be relevant to the query as to why you have such a low DS Attainable rate & sync speed against such a high US attainable rate & sync speed.


The answer is probably tucked away somewhere within the raw stats, but I can't see it yet.

If it was all due to aluminium cabling, I would have also expected to see lower US speeds.

The house was built mid 90's, part of a large development. The PCP is at the top of the road but the run takes the internal route underground along the estate. I believe I have read aluminium was installed in the 70's/80's era due to copper costs.

[Bald_Eagle1]

Your chipset version explains the fewer tones at Discovery phase matter.

Searching through this forum, I have seen other connections actually on G.INP that use that particular chipset.

However, I can't explain your unusual attainable & sync speeds.

Your DS attainable/sync rate would usually go with a much lower US attainable rate, say around 7 or 8 Mbps.

Alternatively, your US attainable/sync rate would usually go with a higher DS rate, say around 60 Mbps or so.

The only thing that really draws my eye at all is your fairly poor QLN at the lower frequency D1 & D2 bands.


Compare your QLN against mine.

I'm 1100m or so from the cabinet & have been hit by crosstalk to the tune of around 30% of my DS sync speed.

If your current sync speed is similarly 30% down on what it could have achieved without crosstalk or all the 'other' noise, it could have been around 54 Mbps.
Or if it is as much as 40% down, it could have achieved around 63 Mbps.

You could just be incredibly unfortunate to have a serious crosstalk disturber pair very close to yours in the bundle coming from the cabinet.