Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: roseway on March 03, 2015, 07:34:21 AM
-
I need to inject a small note of caution for anyone considering the purchase of this model. It doesn't currently support G.INP, and a recent thread asking about it on the Billion forum has got no response from the company.
http://www.billion.uk.com/forum/viewtopic.php?f=19&t=3522
Recently a new firmware version was released, which claims to be "more compatible with newer exchanges" (whatever that means) but it was quickly withdrawn because of other issues.
So at this stage we don't know what the position is.
-
The spec on the website makes no mention of G.vector support, but Billion have confirmed that this is supported. Given this, and that the BCM63168 chipset in the 8800NL clearly supports G.INP, isn't it likely that the 8800NL will have support. As G.INP isn't yet available on my line, I can't confirm this but perhaps someone out there who does have it enabled can tell us?
-
My assumption is that it's a firmware issue, which will presumably be resolved. But until Billion confirm it we can't be certain.
-
Well as Billion seem to have scrapped the new firmware permanently, it could be a long wait!! :)
-
It will be a xDSL front-end f/w issue.
Broadcomm f/w comes in various different images & most manufacturers take the default image which doesn't support g.INP.
In theory you ought to be able to use the relevant Broadcomm f/w image to flash the xDSL front-end yourself but from memory the f/w images aren't that easy to get hold of. Been a long time since I looked though.
-
my opinion is vectoring is not currently supported as well.
note its an opinion.
is a shame they quickly withdrawn the firmware.
wow check out this response regarding the new broadcom firmware, I wont be recommending the 8800nl anymore.
I don't think we are going to release this new DMT code, as there is issues with our hardware
The firmware also doesn't work in bridge mode,
So even tho its a newer chipset than the hg612, it seems it has less future proofing due to billion.
I also just checked billion's .au site as they make many au firmwares but not much uk, when I used my older billion devices I often used .au firmwares, but seems the 8800nl isnt even sold over there which might explain the lack of post launch support.
-
As BT sell the 8800NL you would hope/think any issues will get sorted...
http://www.shop.bt.com/products/billion-8800nl-wireless-n-vdsl2-fibre--adsl2--firewall-router-9H0D.html
-
Well as my Home Hub 5 Type B uses the same chipset, I might as well go back to that!!
-
I now got a open ticket with them.
I reminded them I am within 12 months of warranty, and if g.inp is not implemented it can be considered not fit for purpose in the uk market.
Their current stance in the ticket is they have raised it with the engineers to get a new firmware done.
They also claim vectoring is already implemented, but I remain unconvinced on that one.
-
So the website now confirms vectoring support, and G-INP is to come in a future firmware update.
-
They haven't actually confirmed that G.INP is coming, but just "checking with the engineers".
-
They haven't actually confirmed that G.INP is coming, but just "checking with the engineers".
No, they have confirmed it is coming in a firmware update!
-
Sorry, I didn't realise that. In the recent thread which I was following it wasn't confirmed.
(But I see it is now :) )
-
so good to see the combined effort of the community made them make the right decision :)
-
I asked them about the 8800AXL which is a later model but based on the same Broadcom chip. The answer was yes to vectoring and waiting for feedback from engineering on G.Inp
Sent from my iPhone using Tapatalk
-
The support agent has now confirmed that the 8800AXL along with the 8800NL will receive an update for G.INP.
Time scales - apparently soon!
-
There is now a test version of the 8800NL firmware with G.INP support built in. They are asking for people whose lines already have G.INP enabled to test this firmware.
http://www.billion.uk.com/forum/viewtopic.php?f=19&t=3522&start=10#p11078
-
thanks grabbed it incase they pull it again.
-
The old firmware version works perfectly well with G.INP. G.INP came on when I recycled my modem. Download connection speed increased from 73 mbps to 80 mbps and I have not had a single error all day. Very pleased.
Mark
-
How strange. That isn't what we were told on the Billion forum.
-
How strange. That isn't what we were told on the Billion forum.
Quite, but I can assure you it works really well. I've made a post on the Billion forum too. So the good news is that the Billion 8800NL already supports G.INP. Roll on vectoring!
Mark
-
Same here. My line synced on Sunday morning and afterwards G.inp was enabled. 8800NL on 2.32d.dh14. Sync rate increased by just over 3Mbps and very few errors also.
-
I've produced the following guide on G.INP (including stats with the Billion 8800NL):
http://www.increasebroadbandspeed.co.uk/g.inp (http://www.increasebroadbandspeed.co.uk/g.inp)
I'm really impressed with G.INP - at least on my line. Although vectoring is supposed to be the technology targeted at addressing crosstalk interference, G.INP really seems to improve a line suffering from crosstalk interference.
Mark
-
Hi
Indeed it isn't suppose to make any difference to sync speed or margins.
Either vectoring has also been enabled, or updating the firmware in the cab and enabling G.INP has knocked a couple of people of line until they reboot or update their own firmware. If those few people are the ones causing the majority of your cross talk, you could be seeing perhaps only a temporary improvement.
I suppose the other possibility is less errors for everyone allows other modems to back down their power outputs, so reducing cross talk?
Be interesting to see if it is a lasting effect.
Regards
Phil
-
so billion devs dont even know what their device supports :D
curious if anyone on a ECI cabinet has had g.inp enabled yet.
Also just remember the 8800nl has a PhyR on/off switch in its config, it should have clicked.
-
firmware here for 8800nl users, billion pulled it again out of paranoia just because it has issues on one isp, sky.
sorry I didnt grab the axl version.
8800nl new firmware (http://www.chrysalisnet.org/billion/ETEC8800NL_2.32d.dh61.afw)
-
Hi
Indeed it isn't suppose to make any difference to sync speed or margins.
Either vectoring has also been enabled, or updating the firmware in the cab and enabling G.INP has knocked a couple of people of line until they reboot or update their own firmware. If those few people are the ones causing the majority of your cross talk, you could be seeing perhaps only a temporary improvement.
I suppose the other possibility is less errors for everyone allows other modems to back down their power outputs, so reducing cross talk?
Be interesting to see if it is a lasting effect.
Regards
Phil
also possible he was previously interleaved. not fast path.
-
Indeed it isn't suppose to make any difference to sync speed or margins.
Really? An Openreach Spokeswoman told ISPreview.co.uk:
“Openreach is in the early stages of introducing G.INP correction, also known as Retransmission, for FTTC lines that we think can benefit from it. Retransmission supports our Dynamic Line Management process and will benefit customers by providing a slight improvement in speed on FTTC lines where it has been used. It will also improve the volume of FTTC lines running error free."
-
also possible he was previously interleaved. not fast path.
Definitely fast path, with ping of 7 ms.
-
Either vectoring has also been enabled, or updating the firmware in the cab and enabling G.INP has knocked a couple of people of line until they reboot or update their own firmware. If those few people are the ones causing the majority of your cross talk, you could be seeing perhaps only a temporary improvement.
Be interesting to see if it is a lasting effect.
Connection still going strong at 80Mbps and no errors. A neighbour reported last night a 5 Mbps improvement in downlink speed. He has been badly affected by crosstalk, particularly when he acquired a second FTTC connection.
-
when i compared stats from what i had on Fast path there's a slight increase in attainable rates and a low FEC rate, other errors have been zero , latency is around the same as fast path on G.inp It's certainly so far a hell of a lot better than the legacy interleave,delay and inp combo used by DLM
-
I notice someone on the Billion forum is reporting an increase in downstream connection rate from 54 to 59 Mbps with G.INP, and an increase in upstream connection rate from 16 Mbps to 19 Mbps.
-
also possible he was previously interleaved. not fast path.
If you see an improvement in sync speed, it seems more likely to have come from a reduction in the volume of FEC overhead, rather than *just* the turning off of interleaving.
I can see that Mark's line now shows a FEC overhead of 8 bytes out of 139 bytes - which is around 6%. I wonder what the FEC settings were before?
Definitely fast path, with ping of 7 ms.
The new interleaving settings are for a depth of 16 and a width of 139 - so the overall volume is only 2,200. In the old days (INP=3 and delay=8ms), the interleaving setup could be depth=1463 and width=64, so the volume would be 95,000. It is the volume of interleaving that corresponds to the delay of 8ms; having a volume 43x smaller makes for a delay of only 0.2ms - quite hard to measure.
-
I had my first resync post G.INP last night at around 02:48. Since G.INP was enabled I had noticed that my SNRM and attainable rate appeared to be behaving differently as before I’m sure they both rose/fell in sync, but lately they appeared to be going up and down independently and all over the place. At the weekend I took advantage of a higher attain rate and forced a resync to see what would happen and got a slightly higher sync rate. However the attain rate fell slightly and was sometimes below the actual sync rate. The FEC rate looked ok, some bursts, so I wonder what caused the DLM intervention? I’m using a Billion 8800NL at the moment (thanks to some Amazon vouchers from my bank) and wonder if there is a difference of opinion between it and the DLM given Billion are releasing a further firmware update?
-
I had my first resync post G.INP last night at around 02:48.
Judging from MDWS, you've had 4 new syncs since G.INP has become active, with slight alterations to the INP settings on 3 of them.
I suspect that the changes to the INP setting are making subtle internal adjustments to the speed vs SNRM calculation. I just don't know what yet, nor why the INP values have been changing.
-
Judging from MDWS, you've had 4 new syncs since G.INP has become active
Thanks for the reply. Mea culpa, can't stop plowtering with it! Interestingly this morning US SNRM has shot up, but DS has dropped.
-
My Billion 8800nl in the last hour has gone to G.INP enabled, down stream up from 44mb to 50, upstream 9.5 to 10mb, 800m to my cab.
:)
The old and new.
21-03-2105
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.0 5.9
Attenuation (dB) 21.5 0.0
Output Power (dBm) 13.3 5.0
Attainable Rate (Kbps) 52907 9413
Rate (Kbps) 44750 9413
B (# of bytes in Mux Data Frame) 51 237
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 64 44
R (# of redundancy bytes in the RS codeword) 12 16
S (# of data symbols over which the RS code word spans) 0.0370 0.8035
L (# of bits transmitted in each data symbol) 13848 2529
D (interleaver depth) 875 1
I (interleaver block size in bytes) 64 127
N (RS codeword size) 64 254
Delay (msec) 8 0
INP (DMT symbol) 3.00 0.00
OH Frames 953526230 248960483
OH Frame Errors 76394 2890
RS Words 2746407341 3172874
RS Correctable Errors 2373268 329
RS Uncorrectable Errors 31670 0
HEC Errors 107875 0
OCD Errors 3 0
LCD Errors 3 0
Total Cells 1297079051 0
Data Cells 297755596 0
Bit Errors 0 0
Total ES 2400 2526
Total SES 211 0
Total UAS 423 390
--------------------------------------------------
G.INP 25-03-2015
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.2 5.8
Attenuation (dB) 21.6 0.0
Output Power (dBm) 13.1 5.6
Attainable Rate (Kbps) 50907 10158
Rate (Kbps) 50740 10158
B (# of bytes in Mux Data Frame) 243 227
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 0
R (# of redundancy bytes in the RS codeword) 10 14
S (# of data symbols over which the RS code word spans) 0.1531 0.7139
L (# of bits transmitted in each data symbol) 13270 2712
D (interleaver depth) 8 4
I (interleaver block size in bytes) 254 242
N (RS codeword size) 254 242
Delay (msec) 0 0
INP (DMT symbol) 46.00 42.00
OH Frames 0 0
OH Frame Errors 0 0
RS Words 12723976 2739945
RS Correctable Errors 65 0
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 47714640 0
Data Cells 179266 0
Bit Errors 0 0
Total ES 0 0
Total SES 0 0
Total UAS 0 0
-
My line was G.INP'd this morning - more details on that contained in this thread (http://forum.kitz.co.uk/index.php/topic,15162.msg283221.html#msg283221).
My Billion 8800NL coped well with this, even though I haven't updated the firmware since purchase. It is currently running 2.32d.dh14 and A2pv6F039g1.d24m
However, the "HG612 modem stats" program fails to harvest stats from the modem. DSLstats v5.3 does harvest data, but there's a slight hint that it isn't collecting CRC values correctly.
-
Just to confirm, the latest version of HG612 Modem Stats does now correctly harvest ongoing stats from Billion (& ZyXel modems).
This does include all the new G.INP raw stats & the various new graphs (quite a few new ones).
I'm just awaiting a little more feedback from a couple of users before it is released for everyone.
-
It looks like it worked fine for me. Harvesting is running, and a full monty graph is available on the other thread. It is pretty boring though...
-
G.INP been on my line now for 5 days, very happy with it.
Billion 8800NL First 5 full day stats with G.INP. 30-03-20015
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 6.1 5.6
Attenuation (dB) 21.6 0.0
Output Power (dBm) 13.1 5.6
Attainable Rate (Kbps) 50892 10155
Rate (Kbps) 50740 10158
B (# of bytes in Mux Data Frame) 243 227
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 0
R (# of redundancy bytes in the RS codeword) 10 14
S (# of data symbols over which the RS code word spans) 0.1531 0.7139
L (# of bits transmitted in each data symbol) 13270 2712
D (interleaver depth) 8 4
I (interleaver block size in bytes) 254 242
N (RS codeword size) 254 242
Delay (msec) 0 0
INP (DMT symbol) 46.00 42.00
OH Frames 0 0
OH Frame Errors 14 1
RS Words 2745698736 1724924
RS Correctable Errors 1685141 27177
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 3853386937 0
Data Cells 564739582 0
Bit Errors 0 0
Total ES 3 1
Total SES 0 0
Total UAS 0 0
-
Interesting stats this afternoon. During a brief power cut in the village when presumably all competing X talkers went down (I have a UPS) my DS SNRM shot up to 14.9 and the attainable speed up to ~82Mbps from ~60Mbps. ;D It only lasted a few minutes however and returned to previous levels. :( Roll on vectoring if this is what might be possible on my line! and fingers crossed the 8800NL actually will support it.
Corrected.
-
. . . the attainable speed up to ~82Kbps from ~60Kbps.
I suspect that those upper case Ks should really be Ms! ;)
-
. . . the attainable speed up to ~82Kbps from ~60Kbps.
I suspect that those upper case Ks should really be Ms! ;)
Or I've missed out some zeros. ;)
-
. . . the attainable speed up to ~82Kbps from ~60Kbps.
I suspect that those upper case Ks should really be Ms! ;)
Or I've missed out some zeros. ;)
Ah, ha! ;D
The scientist within me feels that he should point out one other fact (and hopes that Vic will understand that I am just using his earlier posting as an example of a frequently occurring mishap). The upper case K refers to units on the Kelvin temperature scale whereas the lower case k is the kilo multiplier.
-
& these raw stats, directly obtained via a Telnet session to a Huawei HG612:-
Max: Upstream rate = 5513 Kbps, Downstream rate = 22352 Kbps
Bearer: 0, Upstream rate = 4999 Kbps, Downstream rate = 22399 Kbps
Does that mean my modem is in sync at 5513 Kelvin bits per second & 22352 Kelvin bits per second? :P
No wonder some of them feel rather warm ;) >:D
-
An oft repeated "mishap"! :-X
-
This forum is truly informative! It is a privilege to associate with such worthy contributors. >:D :)