Print

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

[mikeh]

I've recently moved to FTTC with Plusnet after my long line 2mb ASDL connection was loosing sync with incoming calls and heavy showers. I had a SFI engineer fault finding for a day but in the end the stability was no better and a line swap increased the attn from 55db to 67db. I was still in contract with Plusnet but we agreed a new 2year fibre contract. My fibre estimates were as below with a distance about 1.8km from the cab.

The first fibre connection, with the Hub One synced at 15200 and was stable for 6 days. The weather was fine and there was just a 1db dip in the DS snrm when a phone call ended. Throughput was about 14mb. After a week the line was loosing sync more often about once a day and the line stats as below.

3. Firmware version:Software version 4.7.5.1.83.8.217.1.1 Last updated Unknown
4. Board version:Plusnet Hub One
5. DSL uptime:0 days, 17:26:16
6. Data rate:1229 / 14150
7. Maximum data rate:1229 / 14612
8. Noise margin:6.1 / 6.8
9. Line attenuation:10.2 / 32.1
10. Signal attenuation:10.2 / 26.9

Yesterday I tried a Billion 8800nl router and was surprised to see it sync at 20000 so a 6mb gain but with line stats showing a high CRC error rate. There was no interleaving applied. I checked this morning and I now have interleaving, the connection had re-synced earlier this morning.

Stats recorded 29 May 2016 08:32:02

DSLAM/MSAN type:           BDCM:0xa48c / v0xa48c
Modem/router firmware:     AnnexA version - A2pv6F039g1.d24m
DSL mode:                  VDSL2 Profile 17a
Status:                    Showtime
Uptime:                    1 hours 50 min 19 sec
Resyncs:                   0 (since 29 May 2016 07:46:59)
         
            Downstream   Upstream
Line attenuation (dB):     30.9      0.0
Signal attenuation (dB):   Not monitored      
Connection speed (kbps):   21393      1165
SNR margin (dB):           6.9      6.6
Power (dBm):               10.8      10.5
Interleave depth:          8      1
INP:                       43.00      0
G.INP:                     Enabled      Not enabled
Vectoring status:          5 (VECT_UNCONFIGURED)      

RSCorr/RS (%):             0.0715      0.0000
RSUnCorr/RS (%):           0.0000      0.0000
ES/hour:                   0      0

 Any thoughts on using the Billion as opposed to the Hub One? and just one more query on the Tones graph gap between 150 and 250. Does that indicate a fault on the line?

[S.Stephenson]

The tones dropping down is due to them not wanting to kill the ADSL signals so they cutback the signal on FTTC.

You have G.INP which results in the inteleave depth 8 but it doesn't introduce a significant delay, and is perfect for a line of your length.

Basically IMO line is looking great you might want to force a resync when the Noise margin is at 6.9 as it may get you a tiny bit more speed.

[roseway]

I wouldn't advise forcing a resync before you know what the error rates are. Continue to monitor the connection with DSLstats to accumulate some data for 24 hours or more, and then have a look at the CRCs and errored seconds. Without that information, you would be risking the stability of the connection if you tried squeezing a bit more out.

[mikeh]

Thanks for your replies.

I don't need any more speed so I wouldn't be forcing a re-sync. I was just concerned the higher sync speed of the Billion would incur more errors, increase instability and make the DLM increase the TSNR etc as it used to do with ASDL. So far so good in daytime and good weather.

Since Link time = 3 hours 57 sec
FEC:            37724           0
CRC:            22              0
ES:             3               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
 

[WWWombat]

Welcome to the world of DLM on FTTC.

The intervention today was benign, turning on the latest error protection mechanism - retransmission aka G.INP.

Activation of retransmission also comes with very low levels of FEC protection and interleaving, giving your line 3 tools to help protect your data, but with a very small impact to bandwidth and latency. It is generally considered the best state for your line to be in.

That means the modem generates lots of stats while working, so it is worth following @roseway's recommendations.

The stats you give us in the latest post are fine. The FEC count is an indication that there is some noise on the line. The CRC count shows that between FEC, interleaving and retransmission, they are coping. DLM mostly cares about the ES rate - and 3 is low. Running at a few hundred per 24 hours will stay below thresholds.

The 8800NL likely did increase the error rate, but it also looks like it enabled G.INP activation - which is coping. A win-win.

[mikeh]

On checking the telnet data this morning many errors have been recorded overnight but no re-syncs have occurred. The throughput is just under 19mb so that's good. I will see how things develop.

Code: [Select]

Total time = 23 hours 2 min 17 sec
FEC:            3837516         0
CRC:            6501            1
ES:             1840            1
SES:            31              0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 15 minutes time = 2 min 17 sec
FEC:            194             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:            1390            0
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 1 day time = 23 hours 2 min 17 sec
FEC:            3837516         0
CRC:            6501            1
ES:             1840            1
SES:            31              0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0

                 G.INP
Downstream Upstream
General
rtx_tx          191845          0               
rtx_c            127288          0               
rtx_uc          116542          0               
LEFTRS          6888            0               
minEFTR          21386            0               
errFreeBits      26996968        0               
Bearer 0
RxQueue          16              0               
TxQueue          8                0               
G.INP Framing    18              0               
G.INP Lookback  8                0               
RRC Bits        0                24             
Interleave depth 8                1               
INP              43.00            0.00           
INPRein          0.00            0.00           
Delay            0                0               
Bearer 1
Interleave depth 1                0               
INP              2.50            0.00           
INPRein          2.50            0.00           
Delay            0                0               

[Moderator edited to wrap all statistics blocks in [code][/code] tags.]

[NewtronStar]

Not very happy with your current 24 hour ES rate of 1840 are you sure G.INP is enabled on your line yes it shows all the stats that it is enabled but it's just not doing the job that it's supposed to 

[mikeh]

Here are the latest stats from DSLstats and it shows G.INP enabled.
Stats recorded 31 May 2016 09:06:41

Code: [Select]

DSLAM/MSAN type:        BDCM:0xa48c / v0xa48c
Modem/router firmware:  AnnexA version - A2pv6F039g1.d24m
DSL mode:                VDSL2 Profile 17a
Status:                  Showtime
Uptime:                  2 days 10 min 39 sec
Resyncs:                0 (since 31 May 2016 08:06:08)

Downstream Upstream
Line attenuation (dB):  30.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 21393 1165
SNR margin (dB):        6.9 7.0
Power (dBm):            10.8 10.5
Interleave depth:        8 1
INP:                    43.00 0
G.INP:                  Enabled Not enabled
Vectoring status:        5 (VECT_UNCONFIGURED)

RSCorr/RS (%):          0.4255 0.0000
RSUnCorr/RS (%):        0.0000 0.0000
ES/hour:                10.8 0

I had a laptop running DSLstats overnight showing the errors and snrm. The errors increase about 9pm and tail off about 4am. The connection has held. On ASDL the connection would drop at the start of incoming phone calls and during heavy showers where as with the fibre there is a 2db noise margin drop at the end of a call. Still a massive improvement as far as speed goes over the 2mb ASDL.

Code: [Select]

Previous 1 day time = 24 hours 0 sec
FEC:            4217824         0
CRC:            9997            17
ES:             1928            18
SES:            86              0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            2               0
Since Link time = 2 days 6 min 39 sec
FEC:            8094894         0
CRC:            16523           18
ES:             3771            19
SES:            117             0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            2               0

[Moderator edited to wrap all statistics blocks with [code][/code] blocks.]

[William Grimsley]

Yeah... That line is not in a good state...

Are you connected to the test socket and if so can you complete a line test (if you have not done so already)? Thanks.

[NewtronStar]

If we take the line length of 1.8Km into consideration then I suppose it's doing the best it can, hopefully i'll get my hands on a 8800NL and see if the ES rate does increase on my line which is 1Km at the moment using a HG612

[mikeh]

I'm not looking at any fault finding ATM just trying to understand more about how FTTC operates on my line. I am connected only by the master socket with no internal wiring. I am about 1.8km from the cab so my 19mb throughput is good though I am concerned more about stability and will see how the DLM will handle the errors.
 
I've started to look at the detailed info on this site so I'm picking up any relevant info about my particular circumstances. Interesting to read the HH5A suffers a downstream speed penalty with G.INP which matches what I have found with a 6mb gain in speed with the Billon 8800NL over the Plusnet Hub One. Now I'm reading about the DLM process.

[mikeh]

 I did read somewhere about a Billion 88ooNL syncing higher but with a higher error rate than an Openreach modem.

One thing which I've just read in ~ Data Analysis [Step 1]


"Each of the 96 bins are checked to see if there has been user activity and marked active or dormant. Any instability during inactive or dormant periods is ignored as the end-user will have been unlikely to have been affected by this."  Brilliant 

As the majority of the errors on my line occur between 9pm and 4am they should be ignored by the DLM because I only am online only in daytime and early evening. I will not be monitoring the line stats overnight now 

[NewtronStar]

As the majority of the errors on my line occur between 9pm and 4am

The noise level must be increasing during those times as shown by the SNRm gradually lowering could be RFI and also some shine getting through as well with sudden dips of SNRm values.

Your sitting around the standard DLM profile which would be red at the moment you will on the Speed profile which allows up to 2880 ES per a 24 hour period

[mikeh]

Thanks for that so if things stay as they are there should be no further DLM intervention as my daytime active use show a lot less ES.
Latest 1 day time = 9 hours 48 min 8 sec
FEC:            80422           0
CRC:            288             4
ES:             29              4
SES:            5               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0

[NewtronStar]

Mikeh the DLM as we know it works on a 24 hour period, it's the total errored seconds ranked up during that time if it's below 2880 then no DLM intervention