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:

Pages: 1 ... 4 5 [6]

Author Topic: FTTC Attenuation  (Read 27830 times)

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 33756
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC Attenuation
« Reply #75 on: July 21, 2012, 08:36:35 PM »

Latest update on the Retain Reason codes observed --

Code: [Select]
[b*cat@Duo2 tmp]$ grep -iR reason modem* | awk -F: '{ print $2":", $3 }' | sort | uniq
Retrain Reason: 0
Retrain Reason: 1
Retrain Reason: 2
Retrain Reason: 8000
[b*cat@Duo2 tmp]$
« Last Edit: July 21, 2012, 08:40:06 PM by burakkucat »
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.

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: FTTC Attenuation
« Reply #76 on: July 22, 2012, 09:34:29 AM »

Oh God. Don't rely on me  ???

A recursive grep of the (full) source code tree for the DG834, another Broadcom 63xx-based router, uncovered no obvious references to Retrain Reason 8000.

 Hmm..

Perhaps "8000" isn't defined explicitly in the source. Elsewhere in other code, Broadcom uses offsets or bitwise shifts to define constants. e.g. retrainCode could be stored as (1<<15) or as (0x7000 + 0x1000), or maybe the retrain reason code 8000 is not hexadecimal, but base10 like the reason codes up to 17. etc..   It does seem a strange number, not in keeping with other reason codes. Perhaps it's more of a flag (bit 15 set).

The search continues :)

cheers, a

Kindly pointed to this debate by B*K, as I too am very interested in it.  Although open to correction, it seems to me that all the retrain codes quoted are clearly (combinations of) powers of 2.  Therefore IMHO it seems a reasonable presumption that they are indeed flags, and that (perhaps) it is possible for more than one flag to be set, thereby explaining reason 8800.  :-\

Using that hypothesis, I now need to go and look at the list and see what I think that interpretation is trying to tell me.
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: FTTC Attenuation
« Reply #77 on: July 22, 2012, 09:45:12 AM »

If Asbo's 'flag hypothesis' holds,
then 0=LOS
       1=RDI ? (ATM VP/VC)
       2=Negative margin (presumably srnM)
       2000=Dsl Start Physical Layer Cmd
       8000=G992 failure
       8800=G992 failure, Tone ordering exception
       
Does any of this make any sense?  :-\
« Last Edit: July 22, 2012, 10:52:10 AM by ColinS »
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: FTTC Attenuation
« Reply #78 on: July 22, 2012, 10:00:12 AM »

For those, like me, who didn't know what RDI was  ???

How the ATM Interface Handles RDI Cells [1]

RDI cells received from the remote endpoint of the VP/VC indicate an interruption in the cell transfer capability of the VP/VC. For example, the remote endpoint of a VC receives an F5 AIS cell, enters the AIS state, and transmits F5 RDI cells for the duration of the AIS condition. On receipt of a configurable number of F4 or F5 RDI cells, the ATM interface declares an RDI state but does not generate OAM fault management cells in response to the condition. The ATM interface leaves the RDI condition when no RDI cells have been received for a configurable time period.

The OAM VC status field of show atm vc atm shows whether the circuit is in RDI state.


[1] http://www.juniper.net/techpubs/en_US/junose10.0/information-products/topic-collections/swconfig-link/how-the-atm-interface-handles-rdi-cells.html
[2] http://www.juniper.net/techpubs/software/erx/junose93/swconfig-link/operations-administration-and-management-of-atm-interfaces.html
« Last Edit: July 22, 2012, 10:07:05 AM by ColinS »
Logged

ColinS

  • Reg Member
  • ***
  • Posts: 529
Re: FTTC Attenuation
« Reply #79 on: July 22, 2012, 10:44:55 AM »

or Tone Ordering  ???

Tone ordering [1]
A DMT time-domain signal has a high peak-to-average ratio (its amplitude distribution is almost Gaussian), and large values may be clipped by the D/A-converter. The error signal caused by clipping can be considered as an additive negative impulse for the time sample that was clipped. The clipping error power is almost equally distributed across all tones in the symbol in which clipping occurs. Clipping is therefore most likely to cause errors on those tones that have been assigned the largest number of bits (and therefore have the densest constellation). These occasional errors can be reliably corrected by the FEC coding if the tones with the largest number of bits have been assigned to the interleave buffer.

The number of bits and the relative gains to be used for every tone are calculated in the ATU-R receiver, and send back to the ATU-C. The pairs of numbers are typically stored, in ascending order of frequency or tone number , in a bit and gain table.

The ``tone-ordered'' encoding assigns the first  bytes (8  bits) from the symbol buffer to the tones with the smallest number of bits assigned to them, and the remaining  bytes (8  bits) to the remaining tones.

[1] http://www.cs.tut.fi/tlt/stuff/adsl/node13.html
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4850
Re: FTTC Attenuation
« Reply #80 on: July 26, 2012, 11:32:50 PM »

With Lan cable from HH3 going to HG612 (port 2) I have noticed the HH3 will not go into low power mode until I remove Lan cable from port 2 !
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: FTTC Attenuation
« Reply #81 on: July 27, 2012, 12:01:53 AM »

If Asbo's 'flag hypothesis' holds,
then 0=LOS
       1=RDI ? (ATM VP/VC)
       2=Negative margin (presumably srnM)
       2000=Dsl Start Physical Layer Cmd
       8000=G992 failure
       8800=G992 failure, Tone ordering exception
       
Does any of this make any sense?  :-\

Interesting find, ColinS!  The definitive answer must be somewhere in that 9MB of C source code for the Broadcom drivers!

cheers, a
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 33756
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: FTTC Attenuation
« Reply #82 on: July 27, 2012, 12:09:49 AM »

With Lan cable from HH3 going to HG612 (port 2) I have noticed the HH3 will not go into low power mode until I remove Lan cable from port 2 !

 :hmm:  Hmm . . . An interesting observation. Perhaps the router, the BT HH3, "sees" the HG612 as an active device and thus will not transition into low power mode.

For datum point completeness, are you referring to a HH3.0A or a HH3.0B?
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.

NewtronStar

  • Kitizen
  • ****
  • Posts: 4850
Re: FTTC Attenuation
« Reply #83 on: July 27, 2012, 01:04:28 PM »

I have the HH3.0A Buakkucat only noticed it last week, with all computers and port 2 unpluged the HH3 will go into power save until I plug it back into port 2, Yeah the HH3 see's the Hg612 as a device !
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4850
Re: FTTC Attenuation
« Reply #84 on: July 28, 2012, 07:41:34 PM »

Since doing HG612 Graph stats a month or two I did notice alot of HD disc thrashing every 1 minute ,and as the log is getting larger the accessing became worse.

My solution was to uninstall NSI2012 then reinstall the Stats program and install NIS2012 this has solved it, its still logging but its silent  ;D 
Logged
Pages: 1 ... 4 5 [6]