Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: AArdvark on March 17, 2015, 07:00:15 AM
-
I have just had a re-sync this morning and can confirm that G.INP works on the Zyxel VMG8324-B10A Firmware AAKL6b1.
I have PhyR US & DS enabled (SRA as well even though not supported yet) and it works !!!
Still got DLM 'having a laugh' but that is a seperate problem.
It appears to be according to users on MyDSLWebStats Huawei DSLAM's that are enabled at the moment. (Grand total of 8 ).
I await the next exciting changes from BT/OR/DLM ....... ;D ;D
-
Has it had much impact on your connection speed or max attainable rate?
-
I have just had a re-sync this morning and can confirm that G.INP works on the Zyxel VMG8324-B10A Firmware AAKL6b1.
I have PhyR US & DS enabled (SRA as well even though not supported yet) and it works !!!
Still got DLM 'having a laugh' but that is a seperate problem.
It appears to be according to users on MyDSLWebStats Huawei DSLAM's that are enabled at the moment. (Grand total of 8 ).
I await the next exciting changes from BT/OR/DLM ....... ;D ;D
Ten now (one is offline) but latest isn't uploading the Bits/Tone files so don't know cab but almost certainly Huw....
DLM has been nice to you actually, your sync jumped from 58 to 67 if you hadn't noticed :D ...
-
I wonder when or whether we will ever see an ECI enabled with G.INP, I have my doubts.
-
What should I look for in my VMG8324-B10A to see if G.INP has been turned on in my Huawei cab yet?
-
Ten now (one is offline) but latest isn't uploading the Bits/Tone files so don't know cab but almost certainly Huw....
DLM has been nice to you actually, your sync jumped from 58 to 67 if you hadn't noticed :D ...
tbailey2 & spudgun,
Yes there has been an improvement as you stated BUT I was in the middle of a DLM storm after an Engineer visit to fix a HR problem anyway.
My original sync was 79989/19999 kbps for the majority of the time I have been on Plusnet.
The engineer said I was testing at those speeds but I got 70000/19999 after the fix and have not recovered.
DLM has been bouncing my line about with 'mad' snrm and descending syncs.
So I am not overjoyed at the improvement as I was substantially slower than I should be to start with.
[rant over] ;D
I am still chasing Plusnet as the BTW Performance test was giving an error on the 3rd test and advising to log this via your ISP.
I am reluctant to test again as I have been having a problem at the same time where the PPP session does not re-establish after a fail.
I have needed to bounce the PPP session and/or the router itself many many times before eventually I get a new session.
It is this that has set DLM about my line with 'extreme prejudice'. :o ;D
-
...
G.inp coding now provides an improved retransmission-based error-handling mechanism for VDSL2 & VDSL2 Vectoring which results in significantly lower overheads. By replacing the traditional Forward Error Correction (FEC) mechanism, G.inp avoids the FEC-associated fixed overhead of about 12 percent in typical cases, and G.inp only kicks in when there’s actually an error to correct.
- See more at: http://www2.alcatel-lucent.com/techzine/vdsl2-vectoring-delivers-on-its-promise/#sthash.Gibov2ll.dpuf
...
What is new is the nationwide rollout and the possibility that some modems with older firmware may have problems obtaining internet access (sync but no PPP) if it has a G.INP profile applied by the DLM.
An example could be replacement of an ECI modem (which natively does not support PhyR) on a line that already has an INP profile applied by the DLM, may not be able to obtain PPP until its firmware has been updated.
I have just looked back at the G.INP/PhyR posts in kitz and noticed the above.
Could this be the problem I am having with not being able to get a new PPP session.
If so, what is a possible solution other than changing the router ?
Will replace if I have to but the Zyxel has been good on my line and is not very old. [On Plusnet for less than 8 months]
As an aside, it would appear to prove that the recent 'Planned BT Network Maintenance' on my exchange was enabling G.INP.
I get Service status emails from Plusnet which include the 'Planned BT Network Maintenance' emails issued by BT.
These list the exchanges and dates that the work is scheduled.
They might be useful to give a heads-up where the next G.INP enablements are, for anyone who is interested.
-
Hi
PPP is a different layer to the VDSL transport, so if your modem is sync'd then regardless of G.INP settings, it is unlikely that is causing an issue with the PPP connection.
Regards
Phil
-
man this really sucks been on a ECI dslam.
G.INP seems great.
-
Hi
PPP is a different layer to the VDSL transport, so if your modem is sync'd then regardless of G.INP settings, it is unlikely that is causing an issue with the PPP connection.
Regards
Phil
Phil,
I know and would agree with your comment totally based on my understanding.
BUT
....
An example could be replacement of an ECI modem (which natively does not support PhyR) on a line that already has an INP profile applied by the DLM, may not be able to obtain PPP until its firmware has been updated.
....
from the quote I included, disregarding the modem type, appears to imply that the switch from an existing INP to G.INP can fail & is manifest by the PPP failing to establish.
[If I am understanding it correctly]
I was on an existing INP as DLM was/is playing havoc on my line applying INP (amongst other things) where usually I was on 0/0.
Hence, I am wondering if the implementation of G.INP on the Zyxel is not 100% compatible with whatever BT/OR have implemented G.INP on, I might get the same effect as in the quote.
i.e. PPP does not work but as it is a possible mismatch of G.INP implementation it is not 100% failing 100% of the time.
Hence I can get a connection eventually.
Note: The Zyxel implements PhyR which is a 1st implemention of what became G.INP, if my background reading is correct.
The error I can see is an authentication error after DSL is up and running.
This is with a correct userID/Password that has previously worked.
It does work after many attempts.
In all attempts the DSL connection is made but the Internet light only lights IF the PPP session is established.
More than happy for someone more knowledgable to tell me I am wrong, as the problem is then somewhere else. ;D
-
If you search backwards through the forum threads, you will come across one by B*Sheep where he quoted the instructions that Openreach technicians should follow when an EU has an ECI B-FOCuS modem that is in synchronisation with the DSLAM but no PPPoE session is achievable.
-
burakkucat,
Many thanks, searching now !
-
Found it. :)
A thread with the subject line VDSL Re-Tx (http://forum.kitz.co.uk/index.php/topic,15099.msg280945.html). Quoting the fourth paragraph --
It may not be obvious that you’re carrying out a repair on a fibre ReTX enabled circuit with a retransmission profile applied. And it only becomes important if you have to replace a faulty Openreach modem. If the replacement modem is ECI (indicated on the box or base of the modem) it’s likely the firmware is incompatible with ReTX and a workaround needs to be applied.
An ECI modem with old firmware will appear to be in sync (the DSL light will be on) but the customer will not be able to access the internet and this will also be reflected in your GEA service test result:
For example “VDSL modem is not in sync”.
-
Yep the supposed symptoms are that you cant get PPP, although Ive no idea why or what it breaks.
The Zyxel is supposedly fully compliant with G.INP (G.998.4) even though they call it PhyR in the GUI.
The Huawei's also being a BCM based router would also natively support G.INP/PhyR. However, the ECI's weren't which is why they needed a f/w update.
I also find it a bit weirded why it will sometimes connect and sometimes not. From memory was there also an issue when you attempted to get the HG612 to connect as well?
-
Will replace if I have to but the Zyxel has been good on my line and is not very old.
From memory, your line previously seemed to perform better with the Zyxel, so certainly dont think of ditching it. I think what I would do in your situation is contact Zyxel support and tell them that you appear to have an issue with logins since the implementation of g.inp on your line. It may also be worth referencing the BT info to them. At least they should be able to check things are working as they should.
-
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
-
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
-
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 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.
-
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'. ???
-
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 (http://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 (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
-
~ 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:
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.