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 [2]

Author Topic: Zyxel VMG8324-B10A Firmware AAKL6b1 & G.INP  (Read 7549 times)

AArdvark

  • Kitizen
  • ****
  • Posts: 1008
Re: Zyxel VMG8324-B10A Firmware AAKL6b1 & G.INP
« Reply #15 on: March 18, 2015, 01:31:57 AM »

The HG612 connects quickly and every time but I get a lower sync.

I dare not play with the line any more or DLM will go ballistic  ;D

Logged

AArdvark

  • Kitizen
  • ****
  • Posts: 1008
Re: Zyxel VMG8324-B10A Firmware AAKL6b1 & G.INP
« Reply #16 on: March 18, 2015, 02:53:43 AM »

FYI

I have previously read about PhyR & G.INP and it was implied that they were not 100% the same.
I cannot remember where I found that information but just after a quick hunt using google I have found:

1.     An App Note from www.exfo.com (Top-two supplier in portable telecom testing). [Attached]
2.     Release Notes for Firmware Release A2pv6C038q and B2pvC038r1 (Cisco 800 Router) [Attached]
3.     An Introduction to G.998.4:Improved Impulse Noise Protection [Attached]
       
1st Two of these reference PhyR & G.INP as separate things.
3rd is reference material about G.998.4 (G.INP)

My understanding was that PhyR was a BroadCom vendor specific thing which was formalised as the Industry standard G.INP which may not be 100% the same but achieves the same end.

G.INP supports 4 framing types. (G.INP is a superset of PhyR ? ? ? perhaps)

Still not 100% sure but good info to read anyway.  :D ;D

« Last Edit: March 18, 2015, 02:57:24 AM by AArdvark »
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 30553
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Zyxel VMG8324-B10A Firmware AAKL6b1 & G.INP
« Reply #17 on: March 18, 2015, 08:50:54 PM »

My understanding was that PhyR was a BroadCom vendor specific thing which was formalised as the Industry standard G.INP which may not be 100% the same but achieves the same end.

That is exactly how I understand it.  ;)
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.

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 32548
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Zyxel VMG8324-B10A Firmware AAKL6b1 & G.INP
« Reply #18 on: March 19, 2015, 12:00:12 AM »

Thanks for the linkies -  tbh I havent read them yet, but I was thinking about what could cause the sync but no ppp whilst I was stuck in a queue of traffic... and anyhow these are my rambling thoughts.

---

afaik DMT based DSL has always supported 7 bearer channels (4 down, 3 up).  Each channel supports 2 paths (fast/interleaved) and each channel also supports 4 framing modes.

The one thing that we have observed with g.inp is that BT has allocated bearer 1.  I think the dslam is supposed to do something with DMT bearer channel traffic and convert it into ATM (and vice versa) depending on how it is configured.  I also think its entirely up to the CP how the configure their bearer channels as long as they meet the standard ANSI rules. 

Sync isnt concerned about overhead framing, but you'd need some sort of data flow (ATM/PPPoE or whatever) to set up PPP session. 
It is possible that g.inp uses a different type of framing overhead rate that isnt defined in 'normal adsl/adsl2/vdsl' standards, but I think the more obvious area would be something to do with the Interleaver process and Forward Error Correction algorithms.    If the dslam is set to send data scrambled in a different format  then this would be why they stop talking and unable to transmit throughput to establish the PPP session. 

Im out of my depth, but Im guessing that once the DLM has triggered g.inp then it instructs the modem to use bearer 1, interleaved path with an entirely different form of FEC (ReTx) as defined by G.998.4 -  rather than G99x.x. 
If the (old) router doesnt understand or hasnt been updated to know what the framing & interleaver parameters of G.998.4 should be.. then it wont be able to send any useful data that can be understood at the far end.. and will still be following the rules set out in G.993.2

So if this is the case then Bearer 0 is using G.993.2 rules, whilst Bearer 1 is using G.998.1 algorithms.

... and its also why I cant understand why sometimes Aardvark can connect.. and sometimes it cant.   It should OR shouldnt be able to understand G.998.4.   According to the specs the VMG8324 is fully compliant with G.998.4


----------

Ermm Im rambling.  -  Short version:-

~ BT's DSLAM is configured to be able to send or receive ReTX data using bearer channel 1 & standard FEC using bearer channel 0
~ A G.INP enabled line is set by the DLM to use Bearer 1 to transmit data.

~ An old spec router cant understand & interpret the interleaved data its been sent down Bearer 1 channel nor decypher the ReTX algorithm.
~ The dslam cant understand FEC send by the modem as its attempting to de-interleave using a different algorithm.

~ Updating the router firmware tells the modem the new reTX algorithms and allows it to communicate correctly with the dslam.. and also better BER. 

 
« Last Edit: March 19, 2015, 12:27:19 AM by kitz »
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

AArdvark

  • Kitizen
  • ****
  • Posts: 1008
Re: Zyxel VMG8324-B10A Firmware AAKL6b1 & G.INP
« Reply #19 on: March 19, 2015, 12:57:38 AM »

My understanding was that PhyR was a BroadCom vendor specific thing which was formalised as the Industry standard G.INP which may not be 100% the same but achieves the same end.

That is exactly how I understand it.  ;)

Thanks, was begining to think I had mis-remembered it and was having a 'Senior moment'.  ???
Logged

AArdvark

  • Kitizen
  • ****
  • Posts: 1008
Re: Zyxel VMG8324-B10A Firmware AAKL6b1 & G.INP
« Reply #20 on: March 19, 2015, 03:16:58 AM »

afaik DMT based DSL has always supported 7 bearer channels (4 down, 3 up).  Each channel supports 2 paths (fast/interleaved) and each channel also supports 4 framing modes.

...


Ermm Im rambling.  -  Short version:-

~ BT's DSLAM is configured to be able to send or receive ReTX data using bearer channel 1 & standard FEC using bearer channel 0
~ A G.INP enabled line is set by the DLM to use Bearer 1 to transmit data.

~ An old spec router cant understand & interpret the interleaved data its been sent down Bearer 1 channel nor decypher the ReTX algorithm.
~ The dslam cant understand FEC send by the modem as its attempting to de-interleave using a different algorithm.

~ Updating the router firmware tells the modem the new reTX algorithms and allows it to communicate correctly with the dslam.. and also better BER.

Re:Short version: Yes what I basically understood.

FYI:
See Page 101 for Differences between G.INP & PhyR [Basically, Framing at the DTU level]:
ftp://ftp.zyxel-tech.de/2.new_mirror/VES1724-56/user_guide/VES1724-56_Users%20Guide_1.pdf
new link
https://www.dropbox.com/s/g0zcyb09dbo9x8n/VES1724-56_Users%20Guide_1.pdf?dl=0


Latest available pdf of G.998.4 from ITU [Approved in 2010-06. Newer 2015-01 not published yet]:
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.998.4-201006-S!!PDF-E&type=items



admin - updated link
« Last Edit: September 27, 2015, 10:08:13 PM by kitz »
Logged

roseway

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 39660
  • Penguins CAN fly
    • DSLstats
Re: Zyxel VMG8324-B10A Firmware AAKL6b1 & G.INP
« Reply #21 on: March 19, 2015, 07:33:50 AM »

Quote
~ BT's DSLAM is configured to be able to send or receive ReTX data using bearer channel 1 & standard FEC using bearer channel 0
~ A G.INP enabled line is set by the DLM to use Bearer 1 to transmit data.

One thing which is apparent from the data received from G.INP-enabled modems is that, although the use of Bearer 1 seems to be an indicator of G.INP enablement, most of the actual data is still transmitted via Bearer 0. For example:

Code: [Select]
Max:   Upstream rate = 32465 Kbps, Downstream rate = 83036 Kbps
Bearer:   0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer:   1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps

I'm totally out of my depth here, and probably talking nonsense, but it looks to me as though both Bearer 0 and Bearer 1 are being used in some combination on G.INP enabled connections.
Logged
  Eric
Pages: 1 [2]
 

anything