Broadband Related > FTTC and FTTP Issues

Plusnet change impacting performance

(1/2) > >>

ccarmock:
Originally I had Plusnet's up to 40 Mb/s FTTC service.   Which was adequate since my line is estimated to achieve a max of 41 Mb/s anyway, but I still elected to got for their 80 Mb/s service since at the time they offered a paltry 2 Mb/s upload.  That has changed now I know.

Anyway they did make some changes but seemed to move me to a 40/10 service in error but I didn't notice as the upload speed increaed to between 7 & 8 Mb/s and down remained much the same.

Anyway they have spotted their error which affects multiple customers and will refund the incorrectly billed amounts and have now moved me to the 80/20 service.

This has caused a DLM reset and performance now is worse than it was previously as I was on Fastpath both up & down with G.INP active.

Now I have ended up on Interleave down, Fastpath up with no G.INP and a growing number FECS - 185,000 in 8 hours.

The service has been table for over 220 hours according to my Draytek 2860, until yesterday when a power cut reset it.  So based on these counters it's about 1 ES per hour

It seems like G.INP isn't coming back any time soon.

Following other treads here some people have suggested using Draytek's option to modify target SNR margin - will that likely help?

I am syncing between 5-6 Mb/s lower now after this change which in theory might have got an extra 1-2 Mb/s!    Progress this isn't!

Details from the Draytek:-

DrayTek> vdsl status
  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
   Running Mode            :      17A       State                : SHOWTIME
   DS Actual Rate          : 33562000 bps   US Actual Rate       :  8063000 bps
   DS Attainable Rate      : 40829960 bps   US Attainable Rate   :  8063000 bps
   DS Path Mode            :  Interleave    US Path Mode         :        Fast
   DS Interleave Depth     :      489       US Interleave Depth  :        1
   NE Current Attenuation  :       26 dB    Cur SNR Margin       :        6  dB
   DS actual PSD           :     5. 7 dB    US actual PSD        :    11. 6  dB
   NE CRC Count            :       76       FE CRC Count         :    81431
   NE ES Count             :       23       FE  ES Count         :    66006
   Xdsl Reset Times        :        0       Xdsl Link  Times     :        2
   ITU Version[0]          : 00000000       ITU Version[1]       : 00000000
   VDSL Firmware Version   : 05-07-06-0D-01-07   [with Vectoring support]
   Power Management Mode   : DSL_G997_PMS_L0
   Test Mode               : DISABLE
  -------------------------------- ATU-C Info ---------------------------------
   Far Current Attenuation :       29 dB    Far SNR Margin       :        5  dB
   CO ITU Version[0]       : b5004244       CO ITU Version[1]    : 434da48c
   DSLAM CHIPSET VENDOR    : < BDCM >
DrayTek>
                     
Trellis     ON     ON
Bitswap     ON     ON
ReTx     0    0   
SNR Margin   6dB   5dB
Attenuation   26dB   29dB
CRC           76   81435
FECS           15078145  47243
                                     

gt94sss2:
I would advise you not to alter the SNR margin or to cap the line.

g.inp will eventually come back on the line itself and your speed will improve when it does.

Don't worry about FEC errors - they are actually 'good' in that they reflect errors avoided rather than having to be retransmitted.

ccarmock:
Thanks for that.   I assume a growing number of FEC errors will not prevent DLM from switching from Interleave to Fastpath with G.INP?

gt94sss2:
It will make no difference..

Ixel:
G.INP may take a little while to return, but it should eventually return. You could increase the SNRM offset for your downstream (e.g. vdsl snr 30 would increase it by 3.0 dB, making it 9 dB instead of 6 dB), given you're on a DrayTek device, so that your connection appears even more stable to 'DLM' but I imagine for now just be patient and hope DLM takes positive steps without you trying to encourage it. As I'm on an ECI DSLAM I do the SNRM offset anyway, as I'd rather keep fastpath at a slower sync rate instead of traditional interleaving at a slower sync rate and higher latency. Fortunately I'll be getting FTTP very soon so I won't have this problem anymore.

Navigation

[0] Message Index

[#] Next page