Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: les-70 on April 02, 2013, 08:12:13 PM
-
Previously the HG612 has refused to sync with Annex m adsl2+ however asbokid :clap2: has recently provided a new firmware with an updated blob. see http://huaweihg612hacking.wordpress.com/ using this new firmware annex m can be made to work.
The command " xdslcmd start --mod dlt2pmv" needs to be applied each time the modem is powered up. An alternative command "xdslcmd configure --snr XX --mod m" also works on its own where XX has the usual SNR tweak values. If you use roseway's rx-ux or rx-w, all you need to do is to tweak the snr with annex m enabled, this will apply the configure comand. Alternatively you can use the special login options to give the needed command on first start.
Not many use annex m but this is of interest as the HG612 performance with the new blob seems very good. An HG622 gave me a 0.5 Mb/s improvement relative to a DG834G. This new blob gives a consistent 0.9 Mb/s more :) than the HG622. It is too early to report on relative error performance but when I get the HG612 more permanently in place I will report on it.
One oddity is the behaviour of the dsl green light on the HG612. With the old firmware it just flashed forever failing to sync, the commands noted had no effect. Now with the new firmware it does not flash at all on power up. Then with one of the "mod m" commands it consistently does first a short flash then goes out for long moment before coming back for a longer flash and sync. My only complaint is this slow sync - but the result is excellent.
I would be interested in how the new blob firmware performs on other peoples lines, whether annex m, plain adsl2+ or vdsl
-
I would be interested in how the new blob firmware performs on other peoples lines, whether annex m, plain adsl2+ or vdsl
I'm currently testing it on my VDSL2 connection (it's been running for a couple of days now).
It does seem to have moved some of the bitloading to different tones & there are now some gaps where the original BLOB provided some bitloading (see attached snapshot graphs).
I will revert to the original firmware after a few days, just to rule out any brewing line problems.
Following a few days back on the original firmware, I'll update to the new BLOB again, just to see if the bitloading is still 'different'.
-
Glad it works on Annex M for you, Les-70 :congrats:
This newer BLOB (Broadcom DSL Version A2pv6C035m, built on 03/06/2012 17:48:07) does seem to sync higher than both the HG622 (A2pv6C033f, built on 03/21/2011 15:56:03) and the HG612 original BLOB (A2pv6C030b, built on 01/06/2010 16:31:25).
cheers, a
-
I'm currently testing it on my VDSL2 connection (it's been running for a couple of days now).
It does seem to have moved some of the bitloading to different tones & there are now some gaps where the original BLOB provided some bitloading (see attached snapshot graphs).
In an earlier e-mail message to Bald_Eagle1, I mentioned that the gap in the tone bit-loading is not well quantified. By taking the raw data that he presented in his message and munging it about, I think the following shows the non-used tones quite clearly --
Tone BLOB BLOB
number old new
0 0 0
1 0 0
2 0 0
3 0 0
4 0 0
5 0 0
6 0 0
7 7 5
. . .
. . .
. . .
32 7 12
33 7 0
34 7 0
35 7 0
36 7 0
37 7 0
38 7 0
39 7 0
40 6 0
41 7 0
42 6 0
43 6 0
44 6 0
45 6 0
46 6 0
47 6 0
48 6 0
49 6 0
50 6 0
51 6 0
52 6 0
53 6 0
54 6 0
55 6 0
56 6 0
57 5 0
58 5 1
. . .
. . .
. . .
We can see that the tones not being used are numbers 33 - 57, inclusive. By putting that information to the Kitz community, the collective knowledge and intelligence may discover some information about the (non-)usage of that block of tones. :)
-
I wondered on saving the Annex m option permanently in the HG612.
Does anyone know if configuration settings can be saved from the command interface? I have not seen anything on this anywhere and if it is possible asbo will most likely know.
There is a save a configuration file settings option in the HG612 but I see this is greyed out in the web GUI. On some Netgears a saving to a file and then recovering could permanently save and then enable a few things not alterable on the web GUI and only otherwise set every power up via telnet. To make it really easy the settings files were also ASCII and were editable!
-
at the ATP> command line rather than the busy box >sh(ell). an ATP>save
gives Successed in saving config datas
Though which they are I couldn't say ... ???
Trial and error might reveal if it does what you want ... after all if it doesn't save that single change then you haven't changed anything else, have you? :)
-
We can see that the tones not being used are numbers 33 - 57, inclusive. By putting that information to the Kitz community, the collective knowledge and intelligence may discover some information about the (non-)usage of that block of tones. :)
B*Cat, this may _just possibly_ be related to the strange (to me at least ???) behaviour that has come up in the thread by fbnts over on the FTTC and FTTH part of the forum. Or not .... ;D That seems to happen to me between tones 33-98
-
I had a check after Paul (Bald_Eagle) noted the gap/s and didn't find any here. So maybe it's a blip on Paul's line?
# xdslcmd --version
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C035m.d22g
******* Pass *********
#
#
# xdslcmd info --Bits
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 7225 Kbps, Downstream rate = 39168 Kbps
Path: 0, Upstream rate = 7227 Kbps, Downstream rate = 38816 Kbps
Tone number Bit Allocation
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 3
8 5
9 5
10 6
11 7
12 8
13 9
14 9
15 10
16 10
17 10
18 11
19 11
20 11
21 11
22 11
23 11
24 11
25 11
26 12
27 11
28 11
29 11
30 11
31 11
32 10
33 10
34 10
35 10
36 11
37 11
38 12
39 12
40 13
41 13
42 13
43 14
44 14
45 14
46 14
47 14
48 15
49 15
50 15
51 15
52 15
53 15
54 15
55 15
56 15
57 15
58 15
59 15
60 15
61 15
62 15
63 15
64 15
65 15
66 15
67 15
68 15
69 15
70 15
71 15
72 15
73 15
74 15
75 15
76 15
77 15
78 15
79 15
80 15
81 15
82 15
83 15
84 15
85 15
86 15
87 15
88 15
89 15
90 15
91 15
92 15
93 15
94 15
95 15
96 15
97 15
98 15
99 15
100 15
101 15
102 15
103 15
104 15
.........etc..
cheers, a
-
I tried an "ATP>save" but it did not save the annex m. It had no obvious effect.
I have had the HG612 with new blob running for nearly one day so far. Good performance has been maintained so far with no obvious drawbacks and only the previous low error rates. The upstream sync is a little slower than with the HG622 or DG834G but with annex m it is often observed that modems with improved downstream generally seems to do this.
-
Just a quick update.
Reverting to the original BLOB today has restored the 'missing' Shared/Other bitloading.
Sync speed was a shade higher via the new BLOB & error counts didn't seem to change.
I wonder if intentionally moving bitloading to stronger/quieter tones (maybe on a connection-by-connection basis) is what provides higher sync speeds.
My only concern is that the new BLOB has been 'messed about with' whereas the original unlocked firmware didn't interfere with the BLOB at all as it purely amended the firewall level to allow user access.
In 'normal' use the higher sync speed is an obvious advantage, but could the use of an amended BLOB allow BT/ISPs to fob off users claiming 'faulty' connections?
-
Can someone please provide a link to the new firmware.
I've just downloaded and installed what I thought was the new FW from a link on asbokid's site and the modem still shows v A2pv6C030b.d22g.
There was nothing to indicate anything went wrong with the flashing.
-
It seems to need a long reset when plugging the power cable back in (i.e. holding the reset button down for more than 10 seconds).
That method definitely worked for me.
The modem should also reboot itself after the new firmware has been uploaded.
If it didn't do that, maybe you could reboot it manually to see if that does the trick?
-
Can someone please provide a link to the new firmware.
I've just downloaded and installed what I thought was the new FW from a link on asbokid's site and the modem still shows v A2pv6C030b.d22g.
There was nothing to indicate anything went wrong with the flashing.
Did you try to use the unlocked modem's internal GUI to apply the new firmware? B*Cat has already proved that this does not work (in the way you describe) and you need to follow the long-reset method that B-E has already suggested (and as described in Asbokid's original instructions).
This is becuase the file formats required/used by the two different mechanisms are different - sort of obvious once someone has explained it to you, as B*Cat did to me. :-[
-
Thanks Bald_Eagle1, I was trying to use the upgrade page in my unlocked modem. Look like it only works from the upgrade page obtained from the reset button method.
All working now, but there's no improvement in my rather poor vdsl stats. I'll try a resync in daylight hours and see how that goes.
PS
Thanks ColinS, yes it is rather obvious once someone points it out. ;)
-
After a several more router swaps and tweaks (doing this without consequences is one advantage of TalkTalk LLU) I have concluded that the overall sync speeds with the HG622 are in fact just as good, i.e. essentially the same, as with the "new blob HG612" (possibly the HG622 gives a better upstream speed). My first 24 hours seems to have been, either a fluke with a big snr jump occurring on the line just when I first swapped the "new blob HG612" in, or me writing down a wrong speed. Edit -the error has been worrying me as I did several re-syncs and the above possible explanations don't really work -- but I have worked out the cause - earlier I had tweaked the HG612 to lower the snr by 2db and as I did not power down when I swapped the dsl line cable between the modems the tweak was remembered!! :-[
The HG622 is using blob A2pv6C033f.d23d c.f the A2pv6C030b.d22g blob of the original HG612 firmware so this on its own need not discourage trying the new blob on HG612 with adsl2. (The original HG612 with blob A2pv6C030b.d22g would not sync on my annex m line.)
One question to asbokid :-- The old blob HG612 firmware had a web GUI that was happy with google chrome on windows XP. The new blob GUI fails with chrome but is ok but slow with IE. Surely more than the blob would need to have changed to cause this. Assuming they were used, I wonder if the openreach source files do actually rebuild exactly the SP10 firmware?
-
Hi Les-70,
When using ADSL2+, I didn't really notice much if any performance gain between the BLOBs. However, the gain is more apparent with VDSL2. It's not a massive amount - a couple of extra megabits in the downstream, and a proportionate amount in the upstream.
That's strange that Chrome doesn't work. I diffed the two root file systems (the original one and the one modified with a new blob) and the blob is the only difference. Unless the wrong image was uploaded?! Did you flash the image with md5sum b44ffc3a98eae8e264a7540982fb1114? That was the image I diffed as correct.
Could it be cookie-related? All the Huawei home gateways rely on the same cookies. Swapping out these devices seems to confuse a browser. In what way does Chrome not work properly? It would be easier for me to illustrate with screenshots, but are there blank fields on the Device Info page? If so, that is the cookie issue.
cheers, a
-
Hi,
The initial log page is fine, after that I just get one page as below. It is the same on a laptop, both worked with original image. I have tried deleting all cookies for the modem IP. I used the image from
https://docs.google.com/folder/d/0B6wW18mYskvBNWZLWVNXWmUtME0/edit?pli=1
which looks correct. I had noticed that you got no effect with asdl2 in your dynamic blob swap test but wondered on annex m. Which as noted works now.
Les
-
Strange that it should only affect Chrome. Sorry. No idea!
cheers, a
-
I think you were correct re cookies or at least something related. I tried a Puppy Linux Chrome and that was fine so I went back to XP but it still did not work after the reboot. Then I did a full clear of all browsing data other than passwords and closed and opened chrome. It worked then!!! It seemed to need more than the modem IP's cookies being deleted.
-
Aha! I thought it might be something like that! That got me flummoxed for ages. When we first started re-flashing firmware for the HG612 they all seemed corrupted! It was only by chance from using the "Private Browsing" tool of Firefox that it became clear that the firmware was actually okay and it was the browser. Presumably the "Incognito" tool of Chrome works similarly. IIRC, deleting x hours of browsing history has the same effect in Firefox. More than just cookies. Wonder what it is? Browser cache? Glad you got it sorted.
cheers, a
-
I've just upgraded to the new BLOB and have noticed a 4meg increase in sync speed on my FTTC line, from 66M to 70M, upload is limited to 20M. I also have the advantage of being in the Samknows Whitebox programme so I'll see if speeds take a corresponding upward change too in the next few days.
-
Great news, Pettaw! Please keep us informed!
Cheers, a
-
Hi,
After making some tests this new blob show consistent better SNR in my connection.
My provider limits down/up based on a profile. In my case 38/4 Mb/s.
A very curious effect shows using telnet and enabling SRA on the connection. The SNR of downstream increases about 6dB. I don't change the training margin.
xdslcmd stop
xdslcmd start --up --sra on
The connection looks stable and I have no trouble with SRA on. I'm testing over the last 2 days.
The big questions:
- what SRA does to change the SNR ? or is just a bug in firmware that shows altered values ?
- If is worth how can this setting be saved in modem config ?
-
I've reverted back to using a HG612, using this new blob.
As some of you may remember, I was able to determine that when I previously switched to a HG612 from my ECI, DLM was applied to my line after a duration of time in the form of interleaving being applied and a reduction in sync speed.
Although I'm still not quite able to get 24/7 logging, I'm able to go and plug my laptop into the modem occasionally and keep an eye on what's happening.
-
Here are the differences between the original BLOB & the new BLOB on my own VDSL2 connection.
The original BLOB uses all the blue 'Shared/Other' tones & the new BLOB only uses some of them, also moving DS bitloading to slightly higher frequencies.
Switching back to the new BLOB this afternoon has again slightly increased sync speed.
Original BLOB:-
Max: Upstream rate = 5320 Kbps, Downstream rate = 29896 Kbps
Path: 0, Upstream rate = 5379 Kbps, Downstream rate = 25101 Kbps
New BLOB:-
Max: Upstream rate = 5443 Kbps, Downstream rate = 30652 Kbps
Path: 0, Upstream rate = 5446 Kbps, Downstream rate = 26381 Kbps
-
Thank you, Paul, for running those tests. They're not the quickest tests to perform, either, what with all the swapping over involved.
Overall, you gained slightly more than a megabit per second in the actual net data rate for the downstream. Presumably with a better line, supporting potentially fast speeds, the gain would be magnified.
Useful to see that there is still some advantage though, even on a fairly poor line, if you don't mind me calling it that.
The newer BLOB also supports a new standard G.Inp, for enhanced protection from impulse noise. G.Inp is defined in ITU-T G.998.4. [1]. Maybe there is something to gain there, too, in terms of stability.
Apparently, G.Inp support is also present in the latest firmware for the Sky router. [1] It looks like Sky is already supporting G.Inp in the LLU DSLAMs providing its ADSL2+ service.
cheers, a
[1] http://www.itu.int/rec/T-REC-G.998.4-201006-I
[2] http://helpforum.sky.com/t5/Broadband-Speed/Fastpath-is-enabled-on-my-Sky-connection/td-p/1036404
-
I was able to flash the quick way but following bald eagle's advice I then flashed again the reset method.
In both cases I seen no noticeable change of sync speed but the error rate has decreased about 25% or so.
-
Just an update from my side - I've been running the HG for about 20 days or so now, sync speed is still as high as the ECI (76500k) and no interleaving has been applied either - a far cry from the last time I ran the HG modem!
-
OK I've had the new blob installed for just about a month now, and tbh, although sync speed is still higher than it was before, its dropped a bit and is currently at about 68M. I still get the resyncs approximately every 3 days due to intermittent noise spikes. Whether that's REIN, or crosstalk or whatever. I did complain to BT, but they said that as my sync speeds were good, its perfectly acceptable to have resyncs every 3 days....well fine. Luckily I have no INP or Interleaving applied so DLM obviously is happy too. Anyway..
Samknows throughput testing hasn't really shown any difference whatsoever. Approximately 62M throughput which has remained fairly steady throughout.
I'm still glad I flashed it though.
Hope that helps.