Upgraded package (Fibre Unlimited to Fibre Unlimited Extra) yet no difference in speeds.

[#1]

Thanks for getting back to us @ErTnEc

I'd recommend monitoring it further to see if DLM eventually removes interleaving

[#2]

Looks like last night, DLM was doing some 4dB tests on the line, as I can see some slight fluctuations between 2am and 3am where the SNR is wobbling, as well as the attainable rate for downstream having some flutter too.  It settled back down to 5dB afterwards, so I guess it's doing something.

Holding steady so far.  I've had 5 CRC errors in the past 24 hours, FECS still climbing, but again not crazily.

Currently doing some testing to reduce buffer bloat by setting the bandwidth limits on a traffic scheduler to approx 95% of the current sync speeds, and updating it hourly.  I'll do some latency & ping loss tests later, but it seems to be working out OK.  It seems to have reduced some ping loss so far from what I've seen, and I've also noticed that the actual transfer rate has bumped up from 45Mbit/s to over 48Mbit/s, which is in line to what is currently being set (49.723 Mbit/s D/S, 18.839 Mbit/s U/S).

[#3]

Hi @ErTnEc,

DLM seems to be making positive changes to your service, let us know how you get on with the latency tests later.

Thank you.

[#4]

Yeah I agree with that, it does seem to be holding steady now at 5dB.  Had 10 CRC's again over the past 24 hours, with 2 ES faults as well, but it doesn't seem to have dropped from what I can see.

  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
                  Near End        Far End    Note
 Trellis      :      1               1
 Bitswap      :      1               1
 ReTxEnable   :      0               0
 VirtualNoise :      0               0
 20BitSupport :      0               0
 LatencyPath  :      0               0
 LOS          :      0               0
 LOF          :      0               0
 LPR          :      0               0
 LOM          :      0               0
 SosSuccess   :      0               0
 NCD          :      0               0
 LCD          :      0               0
 FECS         :   377315            994721 (seconds)
 ES           :      2            347202 (seconds)
 SES          :      0              42 (seconds)
 LOSS         :      0               0 (seconds)
 UAS          :     31            24010 (seconds)
 HECError     :      0               0
 CRC          :     10            385104
 RsCorrection :      0               0
 INP          :      0              15 (symbols)
 InterleaveDelay :      0             800 (1/100 ms)
 NFEC         :    254              85
 RFEC         :     16              16
 LSYMB        :   5374            16341
 INTLVBLOCK   :    127              85
 AELEM        :      0            ----

Quick update on bufferbloat, I'm having to compensate more on the DS side of things to overcome contention, even though I'm syncing at 52mbps, I seem to be holding steady at around 47 to 48 useable bandwidth.  So I've updated the process I'm using to manage this directly, and set the values for FQ_CODEL schedulers every 15 minutes.  This is based on setting the US bandwidth to 95% of total US SYNC, and DS to 90% of total DS SYNC:

Average rate for past 15 minutes:
  Downstream: 52807000bps
  Upstream  : 19999000bps
Calculated Values for Codel Scheduler:
  Downstream: 47526300bps (90% of DS SYNC)
  Upstream  : 18999050bps (95% of US SYNC)
Setting via 'ipfw'...
Sending Metrics to Influx...
Done!
Output from `ipfw sched show`
00003:  47.526 Mbit/s    0 ms burst 0
q65539  50 sl. 0 flows (1 buckets) sched 3 weight 0 lmax 0 pri 0 droptail
 sched 3 type FQ_CODEL flags 0x0 0 buckets 1 active
 FQ_CODEL target 5ms interval 100ms quantum 300 limit 10240 flows 10240 NoECN
   Children flowsets: 1
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 ip           0.0.0.0/0             0.0.0.0/0       12    14058  0    0   0
00004:  18.999 Mbit/s    0 ms burst 0
q65540  50 sl. 0 flows (1 buckets) sched 4 weight 0 lmax 0 pri 0 droptail
 sched 4 type FQ_CODEL flags 0x0 0 buckets 1 active
 FQ_CODEL target 5ms interval 100ms quantum 300 limit 10240 flows 10240 NoECN
   Children flowsets: 2
  0 ip           0.0.0.0/0             0.0.0.0/0        1       40  0    0   0

Although this does give me a slight performance hit on total available speed, it has pretty much eliminated ping timeouts as well as bufferbloat in general:

I think for now I need to really keep an eye on these CRC errors, as something is still obviously not right for this to happen, whether it's the line or the (so far) dodgy new master socket, I guess that's still to be determined...

[#5]

Hi there @ErTnEc

Glad to see things have improved.

As you mentioned above, keep an eye on things and let us know if there's any further problems.

[#6]

Just out of curiosity, what is deemed an 'acceptable level' of CRC's on the line?  I've had 4 more on the line since 10:30 last night...

[#7]

Hi @ErTnEc 

There isn't really an 

 'acceptable level' of CRC's 

Many CRC errors in a short period of time will show a noticeable reduction in throughput speed, 4 on the line in a (roughly) 12 hour period doesn't look too high at all if I am honest. 

How has the line looked in the past 24hrs since your last post?

Thanks, 

MoR 

[#8]

Past 24 hours:

Sync speeds seem to be holding steady at 52Mbps down, 20Mbps up.  I tried adjusting the Delta yesterday for an hour so the SNR was 3dB, this resulted in a DS Sync of 59.9Mbps, however the maximum download rate I am seeing appears to be capped at 45Mbps, so I'm assuming the speed profile either didn't update or is locked at this regardless of sync speeds?  It also seems that the closer I go to this limit, the more affected I an with higher latency and bufferbloat (hence why I'm using the FQ_Codel scheduler to overcome this and setting an upper bandwidth limit), and it does reduce ping timeouts and latency spikes reliably enough to keep things running if something is downloading (for instance my Sky box pulling down some on-demand content).

Then an odd one yesterday at 17:35 and 19:08 where the SNR margin jumped up to 8, and the attainable values also peaked at 72Mbps.  Wondering if this was DLM doing something at that time?  Didn't notice my connection go down or any other issues from it, and the spikes lasted about a minute or 2 each time.

Regarding the speed profile though, as this appears to be seperate to the Sync speed of the modem (from my post previously where downloads were being capped at 20Mbps even though I was syncing at over 50Mbps), what factors go in determining this value, and how often does it update?

[#9]

Hi @ErTnEc

Thanks for the update.

I'm afraid we don't know the finer points of how a speed profile is reached or how often this is updated - this function is performed by our suppliers equipment and we don't have access to that level of detail.

By all means, continue to monitor your connection and if things take a turn for the worse, let us know.

Best wishes

Dave

[#10]

Yeah there is a lot of conflicting info & nothing overly clear on how profiles are set...  Well, 24 hours on, no CRC's this time round.  Line profile seems to be stuck though & not moving, I'm hoping the bRAS hasn't stuck as it's still syncing 8mpbs below attainable, and speeds still only hitting 45Mbps throughput.

I'm going to try something though over the next 24 hours, I've just dropped the SNR to 4dB (previously 5dB), which has bumped attainable to 67Mbps and sync to 57.9Mbps.  I'm hoping the speed profile updates to reflect this, so will see how that fairs.

Still wish the engineer had requested a DLM reset, as if bRAS is stuck, this would have sorted that out...  I'd have much preferred a few days while the line retrains from scratch instead of slowly adjusting...

[#11]

Thanks for getting back to us.

While we've no control over the IP/BRAS profile of the line unless there are other signs of a fault or your speeds are restricted by banding, I can see that the connection profile on your account is set at 50.8mbps since the 7th June.

I can also see there is no banding on the line so a DLM reset would have little value:

"0.128M-80M Downstream, Interleaving Low - 0.128M-20M Upstream, Error Protection Off"

As you've got a static IP due to the way your connection routes across our network as your sync speeds are above the connection profile on your account, this would be capping your throughput. I've nudged it up as far as it can go.

Can you reboot your router or do a single disconnect/reconnect of the PPP session letting us know how it goes?

[#12]

Cheers @Gandalf. . I've kicked the modem and it's resynced back at 57.8Mbps, SNR has settled at 3dB also (I've manually set the delta for a -2dB margin).

  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
   Running Mode            :      17A       State                : SHOWTIME
   DS Actual Rate          : 57810000 bps   US Actual Rate       : 19999000 bps
   DS Attainable Rate      : 66778488 bps   US Attainable Rate   : 22672000 bps
   DS Path Mode            :  Interleave    US Path Mode         :        Fast
   DS Interleave Depth     :      842       US Interleave Depth  :        1
   NE Current Attenuation  :       17 dB    Cur SNR Margin       :        3  dB
   DS actual PSD           :     7. 2 dB    US actual PSD        :    12. 8  dB
   NE CRC Count            :        0       FE CRC Count         :   386517
   NE ES Count             :        0       FE  ES Count         :   348529
   Xdsl Reset Times        :        0       Xdsl Link  Times     :        1
   ITU Version[0]          : fe004452       ITU Version[1]       : 41590000
   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 :       21 dB    Far SNR Margin       :        7  dB
   CO ITU Version[0]       : b5004244       CO ITU Version[1]    : 434da48c
   DSLAM CHIPSET VENDOR    : < BDCM >
  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
                  Near End        Far End    Note
 Trellis      :      1               1
 Bitswap      :      1               1
 ReTxEnable   :      0               0
 VirtualNoise :      0               0
 20BitSupport :      0               0
 LatencyPath  :      0               0
 LOS          :      0               0
 LOF          :      0               0
 LPR          :      0               0
 LOM          :      0               0
 SosSuccess   :      0               0
 NCD          :      0               0
 LCD          :      0               0
 FECS         :   42957            998436 (seconds)
 ES           :      0            348530 (seconds)
 SES          :      0              42 (seconds)
 LOSS         :      0               0 (seconds)
 UAS          :     30            24691 (seconds)
 HECError     :      0               0
 CRC          :      0            386518
 RsCorrection :      0               0
 INP          :      0              15 (symbols)
 InterleaveDelay :      0             800 (1/100 ms)
 NFEC         :    254              85
 RFEC         :     16              16
 LSYMB        :   5374            17889
 INTLVBLOCK   :    127              85
 AELEM        :      0            ----

Download speeds have also increased to around the 49Mbps mark, previously actual throughput was around 45Mbps, and anything more would cause some massive latency spikes (over 200ms in some cases).  The fq_codel limiter has adjusted max throughput for downstream to 52Mbps, and latency/bufferbloat is holding steady at the new speeds:

2019-06-11 16:34:40 Testing against netperf.bufferbloat.net (ipv4) with 5 simultaneous sessions while pinging gstatic.com (60 seconds in each direction)
.............................................................
 Download:  48.92 Mbps
  Latency: (in msec, 61 pings, 0.00% packet loss)
      Min: 17.900
    10pct: 18.200
   Median: 20.400
      Avg: 21.033
    90pct: 22.800
      Max: 39.300
..............................................................
   Upload:  18.11 Mbps
  Latency: (in msec, 62 pings, 0.00% packet loss)
      Min: 18.400
    10pct: 19.200
   Median: 22.400
      Avg: 22.992
    90pct: 27.300
      Max: 30.000

I'll leave the delta as it is for now at -2dB, and see how the profiles span out over the next few days.

[#13]

Cheers for the update.

Keep us posted on how things go.

[#14]

Well, 48 hours in since setting the delta at -2dB, and these are the current stats:

  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
   Running Mode            :      17A       State                : SHOWTIME
   DS Actual Rate          : 57810000 bps   US Actual Rate       : 19999000 bps
   DS Attainable Rate      : 66754584 bps   US Attainable Rate   : 22687000 bps
   DS Path Mode            :  Interleave    US Path Mode         :        Fast
   DS Interleave Depth     :      842       US Interleave Depth  :        1
   NE Current Attenuation  :       17 dB    Cur SNR Margin       :        3  dB
   DS actual PSD           :     7. 2 dB    US actual PSD        :    12. 8  dB
   NE CRC Count            :       26       FE CRC Count         :   387223
   NE ES Count             :       11       FE  ES Count         :   349213
   Xdsl Reset Times        :        0       Xdsl Link  Times     :        1
   ITU Version[0]          : fe004452       ITU Version[1]       : 41590000
   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 :       21 dB    Far SNR Margin       :        7  dB
   CO ITU Version[0]       : b5004244       CO ITU Version[1]    : 434da48c
   DSLAM CHIPSET VENDOR    : < BDCM >
  ---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
                  Near End        Far End    Note
 Trellis      :      1               1
 Bitswap      :      1               1
 ReTxEnable   :      0               0
 VirtualNoise :      0               0
 20BitSupport :      0               0
 LatencyPath  :      0               0
 LOS          :      0               0
 LOF          :      0               0
 LPR          :      0               0
 LOM          :      0               0
 SosSuccess   :      0               0
 NCD          :      0               0
 LCD          :      0               0
 FECS         :   15205594            1000766 (seconds)
 ES           :     11            349213 (seconds)
 SES          :      0              42 (seconds)
 LOSS         :      0               0 (seconds)
 UAS          :     30            24691 (seconds)
 HECError     :      0               0
 CRC          :     26            387223
 RsCorrection :      0               0
 INP          :      0              15 (symbols)
 InterleaveDelay :      0             800 (1/100 ms)
 NFEC         :    254              85
 RFEC         :     16              16
 LSYMB        :   5374            17889
 INTLVBLOCK   :    127              85
 AELEM        :      0            ----

Level of CRC & ES faults seem low still I hope for a 2 day period.  There is no real pattern as to when they occur.

Codel scheduler is holding steady too at 52/19 to keep bufferbloat to a minimum, it's not adjusted over the past 2 days to overcompensate for any latency spikes.  I may look at scaling back the minimum compensation percentage for downstream from 20% and let it rebalance, but for now it's still set at 20%/10%.

00003:  52.029 Mbit/s    0 ms burst 0
q65539  50 sl. 0 flows (1 buckets) sched 3 weight 0 lmax 0 pri 0 droptail
 sched 3 type FQ_CODEL flags 0x0 0 buckets 1 active
 FQ_CODEL target 5ms interval 100ms quantum 300 limit 10240 flows 10240 NoECN
   Children flowsets: 1
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  0 ip           0.0.0.0/0             0.0.0.0/0       18     1337  0    0   0
00004:  18.999 Mbit/s    0 ms burst 0
q65540  50 sl. 0 flows (1 buckets) sched 4 weight 0 lmax 0 pri 0 droptail
 sched 4 type FQ_CODEL flags 0x0 0 buckets 1 active
 FQ_CODEL target 5ms interval 100ms quantum 300 limit 10240 flows 10240 NoECN
   Children flowsets: 2
  0 ip           0.0.0.0/0             0.0.0.0/0       22     1708  0    0   0

Actual throughput is hovering still around 47 to 50Mbps.

[#15]

Thanks for the update @ErTnEc

It's certainly looking like its holding. Keep us posted if this changes.