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

Login with username, password and session length
Advanced search  

News:

Author Topic: Modems and monitored tones  (Read 3492 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Modems and monitored tones
« on: February 09, 2017, 01:59:24 PM »

We have recently discussed the subject of modems that cease using a particular tone or bin, assigning zero bits to it after it's SNR deteriorates too far. I am told that some modems then give up on that bin for good, they never go back to exploiting it again. This seems to me to be a major design weakness and very unfortunate.

How does this work? Speculation: Perhaps the receiving modem doesn't actually look at SNR but at error rates on that bin, so that if there is no data coming in then there is no _free-lunch_ method of monitoring that bin's quality. If this is true then the modem would have to have more code or perhaps even more hardware to monitor noise on unused bins, and the more of these buns there are the greater the implementation cost in terms of processor load or additional hardware elements. I don't know, just guesswork.

Does anyone know about which modems do / don't support this good behaviour? Do we ever see hints about this in specs?

If I could find a good modem that also has this feature then all other things being equal I would switch to it in a flash. As you know, I'm always on the look-out for good ADSL2 modems, and although we've gone over this ground before, new suggestions are always extremely welcome.

Logged

PhilipD

  • Reg Member
  • ***
  • Posts: 591
Re: Modems and monitored tones
« Reply #1 on: February 10, 2017, 01:57:01 PM »

Hi

Practically it would make very little difference to anything, as what you are gaining or losing is so small you will see no real world difference in speeds.

Bad tones are bad tones, only the flaky ones are turned off that by definition were never carrying much data anyway, and the bits move to better tones so the speed doesn't slow down anyway. 

Millions or more of pounds of R&D around the world went into ADSL, I'm sure they thought about it, and what we were given was for a reason.

You are looking for faster speeds in the wrong places I'm afraid.  Is there no option for 4G where you are?  What about satellite?

Regards

Phil


Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Modems and monitored tones
« Reply #2 on: February 11, 2017, 09:43:26 AM »

I dont consider it a weakness, unless you obsessed with gaining every tiny bit of speed as possible. But even then it doesnt reduce your speed (unless SRA is in use).

A few things to consider.

1 - The tones are used again on a new sync event if available, so "for good" is a bit misleading.
2 - Its more stable to turn the tones off if they not able to maintain minimum bitloading, as otherwise overall error rate would be higher, usually the bits get moved to the strongest tones which tend to be more stable.

ADSL2 made changes so the minimum bitloading is lower, on ADSL2 a tone can be just one bit (I think has to be at least two bits on ADSL1).

As Phil said if you really want more speed then you need an alternative delivery of which I think satellite is your best bet or 4G if available.  I know you dont like the idea of not using aaisp, but it is what it is really.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Modems and monitored tones
« Reply #3 on: February 11, 2017, 05:52:07 PM »

Monitored tones are not about getting extra bandwidth, they're about long-term stability.

Without monitored tones, you can't continue indefinitely squeezing the same total number of bits into an ever decreasing number of tones. The good tones were, of course, already loaded with a suitable number of bits at the start, adding extra bits to them later is not going to make those tones more stable. Eventually you won't be able to put any more bits into the remaining tones, and the modem will have to drop the connection.

In general, newer modems will do monitored tones and older ones won't.

It is possible to take an interest in how things like this work. Not everything has to be about getting the most speed.
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Modems and monitored tones
« Reply #4 on: February 15, 2017, 04:01:31 AM »

ejs understands. I'm not asking for advice, I'm trying to understand how things work and what the cost of implementing this feature vs not implementing it. I wouldn't mind some extra speed, but that isn't the point of the original post. Presumably bins go bad and then could sometimes recover, because noise distribution may be transient or cyclic, so writing them off for eternity is, it seems to me, a really bad idea.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Modems and monitored tones
« Reply #5 on: February 15, 2017, 07:33:50 AM »

I expect the factors are having it behave properly, and the fact now adsl is considered obsolete as far as development goes.

Back when adsl was the latest craze I would think they decided because its simply more stable to heavily load up stronger tones than to even use weaker tones lighter, I know for sure that was the case on my line.  The higher tones would be wiped out at night whilst the lower tones didnt even have an affect at all at night. So the strong tones could effectively be stable at 1db snrm but the weaker ones would need a much higher margin due to fluctuations.  For that reason having bitswapping shift bits to stronger tones shouldnt be a problem.  It would only affect speed if the line uses SRA, as the sync speed is static during a sync otherwise.

So i guess i am saying I disagree with ejs, my opinion is bitswapping moving bits away from unstable tones to stable tones will on a overall level increase stability.  Trust me when I say a world without bitswapping is not a good one, massive instability occurs.
« Last Edit: February 15, 2017, 07:37:31 AM by Chrysalis »
Logged

PhilipD

  • Reg Member
  • ***
  • Posts: 591
Re: Modems and monitored tones
« Reply #6 on: February 15, 2017, 08:20:46 AM »

Hi

ejs understands. I'm not asking for advice, I'm trying to understand how things work and what the cost of implementing this feature vs not implementing it. I wouldn't mind some extra speed, but that isn't the point of the original post. Presumably bins go bad and then could sometimes recover, because noise distribution may be transient or cyclic, so writing them off for eternity is, it seems to me, a really bad idea.

The bins that go bad though are almost always those that were only carrying a small amount of data and were already borderline, it's the modem giving it a go on a wishful thinking basis.  You could find a modem that monitors and re-instates and bit-swaps back to weak tones only to find it's not as good as finding them in the first place during the initial sync, so you don't get them at all.  The difference it would make overall is easily lost in the general variation of how different modems can perform.

As Chrysalis points out, stability is better with fewer errors, the modem has given the tones a chance, it's not worked out, so the bits are swapped to more reliable tones.  This may have the affect of reducing the SNR margin over time prior to the next resync, but it is a margin and that's why it syncs with one to allow for this sort of thing.

As for SRA, I had that for a time on a PlusNet LLU connection (via Tiscali it was back then), and my sync speed changed dynamically without a resync, however overall the line was less stable than not having it, it was hard to see what was gained, but what was lost was sync speed during the evening and night in my case with extra full re-syncs I didn't have if I disabled SRA.  My point is, whilst these things seem like a good idea and we wonder why they haven't been implemented, generally they haven't been widely adopted for good reason.

Regards

Phil

« Last Edit: February 15, 2017, 08:25:31 AM by PhilipD »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Modems and monitored tones
« Reply #7 on: February 15, 2017, 08:46:39 AM »

For me SRA was brilliant however I think the issue with these sort of technologies is they not reliably implemented from vendor to vendor, on ukonline it only worked properly if at all by using a certain model of a billion router, no other vendors worked and not even newer variants of the billion router worked.  BE tried SRA but they had a bad experience like you had so never rolled it out.  The downside of SRA tho even if it works properly is that when tones get disabled the speed does drop but I accepted that for the increased stability I had.  Over the life on the sync the drop amounted to about half a mbit. From an overall 6.4mbit.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Modems and monitored tones
« Reply #8 on: February 15, 2017, 03:52:45 PM »

Please remember that the SNRM is defined in terms of the error rate. The SNRM is technically defined as the maximum increase in noise power for which the modem could meet the configured bit error ratio (usually 1 bit error in 107 bits). So the lower the SNRM gets, the higher the error rate gets. And squeezing more bits into the already highly loaded tones is only going to reduce the SNRM.

Of course the modem will be doing the bit-swaps in the first place to keep the error rate down. And it would only be swapping them back based on its assessment of the current conditions.
Also remember that at the start, the modem would have assigned as many bits as suitable to each tone in order to maximize bandwidth. And the maximum bits per tone is 15, so the really good tones might be fully loaded with 15 bits from the start.

My point is, whilst these things seem like a good idea and we wonder why they haven't been implemented, generally they haven't been widely adopted for good reason.

But monitored tones have been widely implemented on most modern DSL modems. You can see "monitorTone: On" listed in the output of the xdslcmd command.

Since we haven't seen any bitloading data from Weaver's modems, we don't actually know if the lack of support for monitored tones is the reason for the sharp drop in and staying low SNRM. It's a plausible explanation for the behaviour, but it may actually be due to something else.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Modems and monitored tones
« Reply #9 on: February 26, 2017, 07:19:24 AM »

I only learned of the term "monitored tones" relatively recently, when looking through the Netgear open-source code released for the DG934G (Sky's version of the DG834Gv3). Within that source code was version 8.2.2 of the AR7 DSL driver, the changelog comments in some of the files indicating things to do with monitored tones had been added.

The last Netgear firmware for the DG834Gv3 contains the AR7 DSL driver and firmware 7.3.1, which does not support monitored tones. As an experiment, I extracted a newer DSL driver binary and firmware from a firmware image for the Actiontec PK5000, and uploaded it into the RAM of my Netgear. There's no ftp or tftp or wget or any other command to transfer files to the Netgear, so they had to be uploaded using an expect script based on exe2hex, to type out the files over telnet.

Before:
Code: [Select]
ATM Driver version:[7.03.01.00]
DSL HAL version: [7.03.01.00]
DSP Datapump version: [7.03.01.66] Annex A
SAR HAL version: [01.07.2c]
PDSP Firmware version:[0.54]
Chipset ID: [Ohio250(7200/7100A2)]

After:
Code: [Select]
ATM Driver version:[8.01.00.112]
DSL HAL version: [8.01.00.00]
DSP Datapump version: [8.01.00.112] Annex A
SAR HAL version: [01.07.2c]
PDSP Firmware version:[0.54]
Chipset ID: [Ohio250(7200/7100A2)]

The new DSL driver/firmware does support monitored tones, plus there are a few extra stats reported, and even some QLN data. It doesn't really make a huge difference. The SNRM behaviour is perhaps more normal, falling and rising, rather than the previous behaviour of generally falling, then flatlining for a while, then gradually creeping lower and lower.
Logged