Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Author Topic: Monitored tones (again)  (Read 500 times)

Weaver

  • Kitizen
  • ****
  • Posts: 4151
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
Monitored tones (again)
« on: December 25, 2017, 08:04:29 AM »

Could someone help me with a recap on the what's-what with regard to monitored tones in modems? I know we have talked about this before.

The general pattern with my DLink DSL-320B-Z1 modems is a slow slide towards death: each modemís downstream (only[!]) SNRM goes down slowly over time until it has to drop the connection and resynch. The death slide takes about 4-10 days, very very roughly, and its duration is unpredictable.

Weird that it never is seen with upstream though.

I'm assuming that this is because of the DLink's presumed lack of support for monitored tones - as discussed earlier. Otherwise I find it very difficult to think up a reason why the SNR decline should be _monotonic_. It is completely unknown for the downstream SNR to ever improve temporarily, without a resynch.

Immediately after a resynch the reported downstream SNRM is a lot lower than the expected target SNRM. Every time, or almost so. Why this is, who knows. I'm assuming that it is a naughty tuning tweak in the modem possibly, to make them more aggressive and appear faster than the competition- a successful strategy.  Once again, this is not true for upstream: no such drop or gap/discrepancy.

I wonder about forcing a resynch every night at some time?
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 20605
  • Over the Rainbow
    • The ELRepo Project
Re: Monitored tones (again)
« Reply #1 on: December 25, 2017, 05:30:17 PM »

Two words:  "Bit swapping" . . . or the lack of it, within those DLink devices, for the DS band would give rise to the effect that you have noticed.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

ejs

  • Kitizen
  • ****
  • Posts: 1488
Re: Monitored tones (again)
« Reply #2 on: December 25, 2017, 06:23:17 PM »

Monitored tones refers to the ability of a modem to increase the bit loading of tones that were previously bit-swapped down to zero bits. Older ADSL modems/firmware did not do this, resulting in the gradual reduction in overall SNRM with the same total number of allocated bits being squeezed into an ever decreasing number of tones.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4151
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
Re: Monitored tones (again)
« Reply #3 on: December 26, 2017, 06:14:14 AM »

And the chipsets presumably plus firmware are fairly ancient in the Z1 variant. 2011 or earlier, iirc.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1488
Re: Monitored tones (again)
« Reply #4 on: December 26, 2017, 06:43:16 AM »

I don't think 2011 is that old as far as ADSL2+ hardware goes. The AR7 chipset can do monitored tones with a sufficiently recent DSL driver/firmware, but most manufacturers had abandoned updating their firmware for such devices before getting that far.

I meant old as in first generation ADSL2+ hardware.

The observed behaviour could be more to do with the connecting too fast to begin with than the possible lack of monitored tones.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4151
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
Re: Monitored tones (again)
« Reply #5 on: December 26, 2017, 06:57:03 AM »

Your point about connecting to fast to begin with is a good one indeed.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4151
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
Re: Monitored tones (again)
« Reply #6 on: December 26, 2017, 06:58:48 AM »

@burakkucat re bitswap - Agreed. Bitswap _is_ supposedly supported. I have hand-configured all my modems - including spares - to the following
   bitswap = ON  (default = off [!!!])
   mode = ADSL2_only (rather than 'auto'=ADSL2+/ADSL2/ADSL1)
   sra = ON (in hope but not expectation)

It is worrying though: Burakkucat's suggestion would require that the stupid modems don't do bitswap even when the option is turned in in the UI - I double checked that settingin every modem by using the web admin ui when I configured them all myself.

As mentioned some while back, Andrews and Arnold supplied the modems configured, and neglected to configure the bitswap setting correctly, it was still at its surprisingly stupid default of 'off'. An unlucky oversight, which I have complained about, but so far have got nowhere. (But then who would imagine that DLink would make a total cockup of their defaults?) I have tried once again tho - this time I went straight to the man himself and asked RevK if he'd be good enough to take a look at it, and he passed my request down to whoever.

(I'm also using PPPoEoA RFC 2684 _VC-MUX_, rather than the wasteful LLC, having woken up to the fact that it's ok with BT, after having had delusions to the contrary for years for reasons I can't remember. - Another hand-applied change.)
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4151
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
Re: Monitored tones (again)
« Reply #7 on: December 26, 2017, 07:03:41 AM »

A horrible thought, thanks to Burakkucat's point :- What if there is a bug in the UI text ? - the web design people who did the admin http server ui and the core dev people with A-levels got their wires crossed talking together and they
    got it backwards [!] in the ui
ie. the text in the web admin ui is backwards and should read "disable bitswap". That would explain the seemingly insane default and the slide down towards death.

So if this is right, I've caused a problem not fixed one, and if this idea is right then I've just lead AA astray now too.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4151
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
Re: Monitored tones (again)
« Reply #8 on: December 26, 2017, 07:17:13 AM »

So I need to test this properly. Somehow.

I can compare devices side by side, but they will be in different lines and the linesí performance characteristics are quite different. line cwcc@a.3 - BBEUIDxxx055 is the slowest in both directions, its upstream rate is 440kbps versus 500 and 560 for the other two lines (cwcc@a.4 and cwcc@a.1 respectively). And it is slightly slower, maybe 100kbps lower d/s sync too. And the reported numbers are always in that one ranking order, an ordering which is true for the upstream and downstream both. iirc line cwcc@a.3 - BBEUIDxxx055 was the second ordered and I think it's just a second pair in the first drop cable. Pair @a.1 is the aboriginal and @a.4 the third installed and in a second drop cable.

I also need to warn AA. Perhaps they would agree to do the testing for me.

Otherwise is there anyone willing to volunteer who knows what they're doing and can make a definitive verdict on the bitswap on/off thing? I can ship any such noble soul a modem, as I have three or four spares at all times.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1488
Re: Monitored tones (again)
« Reply #9 on: December 26, 2017, 09:18:22 AM »

ie. the text in the web admin ui is backwards and should read "disable bitswap". That would explain the seemingly insane default and the slide down towards death.

I'm not sure bit swapping being totally disabled would explain the observed behaviour. Why would a lack of bit swapping cause the SNRM to only creep lower and lower, and never go back up? If the modem couldn't change the bit allocation, then the SNRM would vary down or up as the noise levels change, as it would anyway, but the modem wouldn't be able to adapt to noise level changes on particular tones, presumably leading to a higher error rate or having to re-sync.

Actually, without monitored tones, I think disabling bit swapping might actually solve the problem - since without any bit swapping, there wouldn't be a gradual reduction in the number of available tones as tones get swapped down to zero then cannot be used re-used until a re-sync.

I think the only way to see what's going on is going to be to find a way to monitor the bit allocation data from the modem. It might turn out that the checkbox in the UI does nothing.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 20605
  • Over the Rainbow
    • The ELRepo Project
Re: Monitored tones (again)
« Reply #10 on: December 26, 2017, 03:24:02 PM »

Hmm . . . A number of things to ponder.  ???

Surely a fairly simple experiment will give some meaningful results for consideration --
  • Select one DLink device out of the three and configure it via the GUI to have bit-swapping disabled.
  • Select a second DLink device out of the remaining two, configured via the GUI with bit-swapping enabled, to be the partner to the one above.
  • Watch and record the SNRM for the two devices over a period of a week.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Kitizen
  • ****
  • Posts: 4151
  • Retd sw dev; A&A; 3 ◊ 7km ADSL2; IPv6; Firebrick
Re: Monitored tones (again)
« Reply #11 on: December 27, 2017, 03:31:00 AM »

@Burakkucat - will indeed do so

ejs wrote:
> I'm not sure bit swapping being totally disabled would explain the observed behaviour.

That's very helpful. Appreciate the guidance on this. It will be a relief if this crazy reverse-ui supposition is laid to rest.
Logged
 

anything