Print

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

[les-70]

Cure for stats and interleaving OCD

   I thought it might be of interest to report the results of my recent speed capping tests.

  The CAB is ECI, modem HG612 and the ISP TalkTalk Business who are unclear over whether they provision on stable or standard profiles, I have been advised of both!.  Definitely not the fast profile.  I believe the profile is stable as DLM hits have been 100% consistent with stable.  Interleaving has been produced about 7 times (once for no obvious reason) and always by odd events which mean that when it is applied it often would not otherwise be re-invoked for another month or so!!  The line has always recovered fast path.

 I am able to cap the speed down with the transmitted power remaining fixed. However when the upstream speed is capped the transmit power can also drops.  More annoying is that a cap from 20 to 15 or 10 gives no benefit but a SNRM of 6 and large power drops. Maximums in the upstream SNRM and benefit occur at caps of about 16Mb/s and 11Mb/s

   With no speed cap the line runs at about 71Mb/s down and just makes 20 Mb/s up. Should interleaving be applied the speeds become 63Mb/s and 18Mb/s.

  The average error rates Downstream on fast path are:

   No speed cap 71Mb/s ES/hour ~20    CRC/ES   ~10  SES/hour ~0.5 SNRM ~6db

   Capped to 64Mb/s     ES/hour ~10    CRC/ES   ~5   SES/hour ~0.2  SNRM ~9db

   Capped to 56Mb/s     ES/hour ~2     CRC/ES  ~1.5  SES/hour ~0.0  SNRM ~12 db

   capped to 48Mb/s     ES/hour ~0.5   CRC/ES  ~1.0  SES/hour ~0.0  SNRM ~15 db

  The line suffers from odd error bursts and in spite of the acceptable average error rates, With no speed cap, it seems that roughly once month the ES limit of 1440/day or 720/day is exceeded.  With the speed cap of 64 the ES limit has been exceed twice in 18 months.  I suspect the ES limit won't ever be exceeded with a cap of 56 or less. The ratio of CRC/ES shows that many of the ES when uncapped are due to large bursts of CRC.  If I use a 63168 chipset based modem these error rates go up by a factor of 2 or 3, the increase in errors is not uniform hour by hour but rather the 63168 chipset seems to respond very badly just to the large bursts of CRC and gives overall CRC/ES rates of about 30.

   The average error rates Upstream on fast path are:

  No speed cap 20Mb/s  ES/hour ~3      CRC/ES ~1.1   SNRm ~6db

   Capped to 16Mb/s     ES/hour ~1.0    CRC/ES ~1     SNRM ~9db

   capped to 11Mb/s     ES/hour ~0.1    CRC/ES ~1     SNRM ~12db

  Upstream does not seem to seem to have the same odd error bursts as downstream but has had instead steady high CRC rates of 1-5 CRC/min for several hours some evenings. These events have got very close to error limits. So far this has not caused a DLM response but some evenings I have powered the modem down for the night when the upstream daily count has exceeded about 500ES.

   My noisy line looks as though it needs to be capped to something like 56/12 or less to be close to 100% unlikely to ever be hit by an error burst and then go interleaved the next day. With a higher speed cap of 64/16 interleaving events are not common but as noted have occurred.  If I change ISP and have a fast DLM profile then either a much more modest speed cap or no speed cap should be OK. 

   The good news is that whilst I notice interleaving I do not notice any impact of these speed caps  --- except of course in a speed test! (I am of course fortunate to start with 71/20 uncapped.)  On a line like mine totally getting rid of any possibility of interleaving seems to cost up to 25% of the sync. Interleaving itself would cost 10% of the sync plus higher pings.  Running at the speed that interleaving would give. i.e. roughly 64/16 in my case makes interleaving unlikely but not impossible.
 

   I have made this post in case anyone on an ECI with no G.INP and who hates interleaving would be interested in an example of the exact impacts of capping. 

 

[burakkucat]

For the benefit of others, in the future, this post deserves to be made "sticky".

[les-70]

Since the above post has been made sticky I thought it worth adding information on implementing the speed cap. 

   The speed cap only works for FTTC vdsl connections.  It works on most but not all recent Broadcom based modems.  e.g. the HG612 with the latest firmware and the  more recent Billion and Zyxel devices such as the 8800NL and VMG8324.   It does not work with a TalkTalk HG635 as of firmware 1.06.  The status of the command on a Netgear D7000 has not been reported yet.

   For an HG612 the command is e.g.             xdslcmd configure --maxDataRate 60000 15000 100000

  This would limit the speeds to 60000 down and 15000 up. the third number should simply be equal to or greater than the sum of the other two speeds.  The third value can just be left at 100000 is all cases.
   On a Billion or Zyxel the command would be              adsl configure --maxDataRate 60000 15000 100000.


   A speed cap does not seem to be possible for adsl connections and with adsl conections the commands seem to be  ignored.

  The command is made over telnet after logging in  or once via custom commands in dsl stats. The command will cause an immediate resync.
If you wish avoid any possible DLM impact either only apply the command once or twice in a day or 1. Power off. 2. Disconnect the modem lead. 3. Power on and apply the command and lastly 4. After 30 minutes reconnect the modem lead.

   The setting will survive a resync caused by e.g. the DLM but it does not survive a modem reboot or power on and off.
On the HG612 or Billion vdsl can be disabled on the GUI and then the modem will wait for a command after a reboot.

  i.e.   xdslcmd configure --mod v --maxDataRate 60000 1500 100000       would then both enable vdsl and the speed cap.

   The speed cap will only reduce the sync speeds and thus raise the SNRM and reduce errors.