Print

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

[loonylion]

Hi,

FTTC was installed in my house in November, ECI cab and modem. As it was the newer ECI, I soon replaced it with an older unlocked one so I could get the stats from it. Recently, I have been seeing absolutely appalling error rates, my speed has dropped all the way down to 28mbit from ~40mbit, and I now have an interleave delay of 1.7 seconds, and the modem doesn't seem to report SNR. Resyncs and modem reboots don't appear to make any difference.

Here are images showing the current stats and speed deterioration. (attenuation stats ripped from web ui source code as the interface code ECI 'borrowed' from D-Link can't seem to display the figures even though it has them).







Any suggestions as to what I can do to improve things? my ISP is Plusnet if that matters.

[Bald_Eagle1]

My 'guess' is that your connection has been quite severely affected by srosstalk as more users connect to your cabinet.

I saw a similar effect, dropping in clear but quite small steps from almost 30 Mbps sync speed to its current 19Mbps or so.

We had a brief power cut overnight & resync data was captured when power was resumed at 04:20.
I forced another resync at 07:23 as SNRM was incredibly low (0.7 dB DS).

SNRM reverted to around the target 6dB, but sync speeds took quite a hit:-

04/04/2014 04:20 - RESYNC detected (DS 24999 Kbps, US 4999 Kbps), AS = 88, Retrain Reason: 0
04/04/2014 07:23 - RESYNC detected (DS 19403 Kbps, US 4742 Kbps), AS = 14, Retrain Reason: 0

My assumption is that as the HG612 modem resyncs very quickly, it reconnected at a higher speed before any other modems/routers caught up.

By 07:23, when I forced a resync, other connections must have caught up & therefore my DS connection speed was quite a bit lower.



I reckon that users like you & I will have to wait until when/if Vectoring is introduced to offset some of the crosstalk issues, but as far as I am aware, ECI DSLAMS might lag behind for a while longer as they will need some sort of a hardware upgrade to be able to use Vectoring technology & I'm not at all sure that ECI/i & ECI/r modems are actually vectoring ready.

Also, some of the stats obtained via ECI modems need to be divided by 1000 to get the 'real' values & some need to be divided by 10 (or possibly by 100?).

 

[Ronski]

A good idea would be to get a Huawei HG612 3B off of Ebay, unlock it and that can be used for better stats monitoring. It may also give a slightly better connection speed with the latest firmware.

I'm still awaiting a power cut here, as my server, modem and router are all on a UPS and it would be very interesting to see what speeds/stats I can collect whilst the power is down.

[loonylion]

A good idea would be to get a Huawei HG612 3B off of Ebay, unlock it and that can be used for better stats monitoring. It may also give a slightly better connection speed with the latest firmware.

My understanding was mismatching modem and DSLAM could lead to problems or subpar performance, is that not correct?

[burakkucat]

My understanding was mismatching modem and DSLAM could lead to problems or subpar performance, is that not correct?

That is not necessarily so. There is no hard and fast rule. 

[custard]

I have noticed the FEC count been unnaturally high on the odd occasion with figures very similar to yours. That ~42,000,000,000 is most likely an error with the modem misreporting. Its almost the same as the threshold that the modem can report.

Here is what I get when I enter a counter  threshold command via telnet.

Code: [Select]

Alpha # echo "pmct1dg 0 0" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=15 nChannel=0 nDirection=0 nCodeViolations=4294967295 nFEC=4294967295

Minusing your figures from the threshold provides more realistic numbers.

4294967295-4294960605= 6690 FEC for 15mins
4294967295-4294946348= 20947 FEC for 24hrs
4294967295-4294967291= 4 ES for 24hrs
4294967295-4294967293= 2 SES for 24hrs

I listed some codes on the main fub/I thread. IIRC one of the codes will give you the snr margins via telnet. I can't test for it at the moment as my modem is not connected up.
http://forum.kitz.co.uk/index.php?topic=10635.msg259171#msg259171

[loonylion]

I have noticed the FEC count been unnaturally high on the odd occasion with figures very similar to yours. That ~42,000,000,000 is most likely an error with the modem misreporting. Its almost the same as the threshold that the modem can report.

Here is what I get when I enter a counter  threshold command via telnet.

Code: [Select]

Alpha # echo "pmct1dg 0 0" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=15 nChannel=0 nDirection=0 nCodeViolations=4294967295 nFEC=4294967295

Minusing your figures from the threshold provides more realistic numbers.

4294967295-4294960605= 6690 FEC for 15mins
4294967295-4294946348= 20947 FEC for 24hrs
4294967295-4294967291= 4 ES for 24hrs
4294967295-4294967293= 2 SES for 24hrs

I listed some codes on the main fub/I thread. IIRC one of the codes will give you the snr margins via telnet. I can't test for it at the moment as my modem is not connected up.
http://forum.kitz.co.uk/index.php?topic=10635.msg259171#msg259171

This isn't on the odd occasion, it's all the time pretty much except immediately after a modem reboot. looks like the firmware of these devices leaves a lot to be desired.

I have an unlocked huawei coming, will look at the firmware version when it arrives.

[custard]

You obviously have some issue with your line while mine is stable possibly explaining why you you see the odd figures most the time.

I agree that the firmware leaves a lot to be desired and your best bet to locate the cause of your issues is to harvest the data using the HG612.

[Ronski]

I have an ECI cabinet both at home and at work and use HG612's on both connections. I did try an ECI on my home connection and it had a lower sync.

My FEC error rate at work can be anywhere between 150,000 to 500,000 per minute, it normally hovers around the same area give or take the odd 50,000. I've seen it suddenly drop from being around 500,000 to 150,000 then stay there for weeks and then change again.

[loonylion]

so got a HG612 and installed it, attainable rate (d/s) went up by 5Mbps, actual rate went up by 1-2mbps, upstream more or less unchanged

I now have SNR figures, but no attenuation figures, so you win some you lose some 

also pretty graphs:






I know what bitloading is but everything else is meaningless to me. I'm guessing all this is going to show I have terrible crosstalk and that's why I'm only getting 30mbit instead of the 48 I apparently should be getting

[burakkucat]

so got a HG612 and installed it, attainable rate (d/s) went up by 5Mbps, actual rate went up by 1-2mbps, upstream more or less unchanged

<Cough!> If the attainable DS rate went up by 5 Mbps (five megabits per second) but the actual DS rate only went up by 1 - 2 mbps (one to two millibits per second) then something, somewhere is not quite right! 

I now have SNR figures, but no attenuation figures, so you win some you lose some 

Please take a look via the Telnet Data tab. You should find a sub-tab labelled Attenuation Log.

I know what bitloading is but everything else is meaningless to me. I'm guessing all this is going to show I have terrible crosstalk and that's why I'm only getting 30mbit instead of the 48 I apparently should be getting

<Cough!> (Another fur-ball.) "30 mbit" (30 millibit)? The pedantic b*cat suggests 30 Mbps . . .

As for understanding what DSLstats is reporting, I'll suggest that you should post both the pbParams & Connection Stats (from under the Telnet Data tab) and then wait for a passing Eagle (type Bald) to provide an analysis. 

[NewtronStar]

I know what bitloading is but everything else is meaningless to me. I'm guessing all this is going to show I have terrible crosstalk and that's why I'm only getting 30mbit instead of the 48 I apparently should be getting

You have some spare 4.0dB in the downstream SNRM which is good though it's not enough to take you to 48Mbps, you seem to have the same two RFI dips in SNRM as me in the tones of 1407 and 1677 to 1749 this is down to RFI (Radio Frequency Interference) from radio stations you will see this in the evenings it starts 1 hour before sunset and lasts upto 00:00am.

but tones 150 to 300 looks very bad 

[loonylion]

so got a HG612 and installed it, attainable rate (d/s) went up by 5Mbps, actual rate went up by 1-2mbps, upstream more or less unchanged

<Cough!> If the attainable DS rate went up by 5 Mbps (five megabits per second) but the actual DS rate only went up by 1 - 2 mbps (one to two millibits per second) then something, somewhere is not quite right! 

I now have SNR figures, but no attenuation figures, so you win some you lose some 

Please take a look via the Telnet Data tab. You should find a sub-tab labelled Attenuation Log.

Was referring to the webui, probably should have specified that.

I know what bitloading is but everything else is meaningless to me. I'm guessing all this is going to show I have terrible crosstalk and that's why I'm only getting 30mbit instead of the 48 I apparently should be getting

<Cough!> (Another fur-ball.) "30 mbit" (30 millibit)? The pedantic b*cat suggests 30 Mbps . . .

As for understanding what DSLstats is reporting, I'll suggest that you should post both the pbParams & Connection Stats (from under the Telnet Data tab) and then wait for a passing Eagle (type Bald) to provide an analysis. 

how about 117,187.5 kiloquads per second, does that make more sense?

here's the requested data:

Code: [Select]

xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 7784 Kbps, Downstream rate = 46832 Kbps
Path: 0, Upstream rate = 7752 Kbps, Downstream rate = 29996 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3971)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207)
DS: (32,859) (1216,1963)
       VDSL Port Details       Upstream        Downstream
Attainable Net Data Rate:       7784 kbps         46832 kbps
Actual Aggregate Tx Power:    -   0.9 dBm          12.4 dBm
============================================================================
  VDSL Band Status U0 U1 U2 U3 D1 D2 D3
  Line Attenuation(dB): 7.8 41.8 N/A N/A 18.8 51.5 80.0
Signal Attenuation(dB): 7.8 41.0 N/A N/A 18.8 51.5 N/A
        SNR Margin(dB): 5.9 6.0 N/A N/A 11.3 10.8 N/A
         TX Power(dBm): -12.2 -1.2 N/A N/A 10.5 7.8 N/A


Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 7732 Kbps, Downstream rate = 46080 Kbps
Path: 0, Upstream rate = 7752 Kbps, Downstream rate = 29996 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 10.7 6.0
Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 -0.9
VDSL2 framing
Path 0
B: 47 239
M: 1 1
T: 64 41
R: 16 0
S: 0.0509 0.9836
L: 10064 1952
D: 1273 1
I: 64 120
N: 64 240
Counters
Path 0
OHF: 4480396 1453168
OHFErr: 31 21
RS: 1146904408 3712849
RSCorr: 177165 0
RSUnCorr: 3217 0

Path 0
HEC: 825 0
OCD: 34 0
LCD: 34 0
Total Cells: 843882914 0
Data Cells: 5484221 0
Drop Cells: 0
Bit Errors: 0 0

ES: 4 21
SES: 0 0
UAS: 19 19
AS: 14645

Path 0
INP: 8.00 0.00
PER: 3.25 10.08
delay: 16.00 0.00
OR: 78.62 25.39

Bitswap: 3081 270

Total time = 4 hours 4 min 27 sec
FEC: 177165 0
CRC: 31 21
ES: 4 21
SES: 0 0
UAS: 19 19
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 4 min 27 sec
FEC: 2308 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 10554 0
CRC: 26 2
ES: 3 2
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 4 hours 4 min 27 sec
FEC: 177165 0
CRC: 31 21
ES: 4 21
SES: 0 0
UAS: 19 19
LOS: 0 0
LOF: 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
Since Link time = 4 hours 4 min 5 sec
FEC: 177165 0
CRC: 31 21
ES: 4 21
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0


[burakkucat]

Thank you for posting that data. Now I just need to "whistle up" an Eagle to analyse it . . .

[kitz]

I know what bitloading is but everything else is meaningless to me. I'm guessing all this is going to show I have terrible crosstalk and that's why I'm only getting 30mbit instead of the 48 I apparently should be getting

You have some spare 4.0dB in the downstream SNRM which is good though it's not enough to take you to 48Mbps, you seem to have the same two RFI dips in SNRM as me in the tones of 1407 and 1677 to 1749 this is down to RFI (Radio Frequency Interference) from radio stations you will see this in the evenings it starts 1 hour before sunset and lasts upto 00:00am.

but tones 150 to 300 looks very bad 

Agreed - the spare SNRM is noted.

attainable rate (d/s) went up by 5Mbps, actual rate went up by 1-2mbps,

Since the attainable went up more...  and the BToR DLM controls lines by interleaving and banding (rather than SNR margins and interleaving) it could be possible that the line has been banded to keep the speeds lower than the attainable.   I cant recall the banding profiles so it could be a moot point.   We also have insufficient knowledge from that one graph as to how much the SNR is shifting over the course of the day.

The hlog looks rather nice - unlike the QLN and the SNRM,  lots of noise coming from somewhere :/

<Cough!> (Another fur-ball.) "30 mbit" (30 millibit)? The pedantic b*cat suggests 30 Mbps . . .

Chucks mega bits of cold fish at the kitteh.  Does that help clear the furball?