HG612 is worse?

Hi, like others I was using a ECI modem for ages without issues (My sync was always 40000 on a 40mb package). Then g.inp arrived and I lost some speed, again like other people. It went down to 35xxx iirc. So I bought a HG612 on eBay as this seemed to help others, but it seems worse to me, except pings which went down to 12ms although seemed to go up to 13ms just a few minutes ago. Now my sync is 31xxx although upload is almost perfect (9989 - I have 10mb upload max package on sky)

I flashed it with SP08 firmware following instructions etc. I can't post stats right now, have to go out for a few hours. Cheers for any help.

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 10651 Kbps, Downstream rate = 54112 Kbps
Bearer: 0, Upstream rate = 10000 Kbps, Downstream rate = 32400 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 14.5 6.2
Attn(dB): 20.0 0.0
Pwr(dBm): 13.0 7.2


Is 20dB attn high? Maybe it's SNR, the 192.168.1.1 page says so anyway.

Edited by deleted (Mon 13-Apr-15 14:11:04)

can you post the rest of the results from that command please... mine looks like this

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 25739 Kbps, Downstream rate = 65916 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 66210 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 9.4
Attn(dB): 16.4 0.0
Pwr(dBm): 13.6 7.1
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 243 97
M: 1 1
T: 0 0
R: 10 8
S: 0.1173 0.1554
L: 17316 5457
D: 8 8
I: 254 106
N: 254 106
Q: 8 8
V: 0 2
RxQueue: 54 39
TxQueue: 18 13
G.INP Framing: 18 18
G.INP lookback: 18 13
RRC bits: 24 24
Bearer 1
MSGc: 154 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 6.4000 16.0000
L: 40 16
D: 3 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 596809136 1464403
RSCorr: 66 20
RSUnCorr: 0 0
Bearer 1
OHF: 1094349 49996
OHFErr: 0 0
RS: 10942879 99321
RSCorr: 1 28
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 7336 52
rtx_c: 69 4896
rtx_uc: 0 647

G.INP Counters
LEFTRS: 0 59
minEFTR: 66201 19997
errFreeBits: 17751543 620666946

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2238127197 0
Data Cells: 19242979 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 23 23
AS: 17578

Bearer 0
INP: 49.00 47.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 66278.17 20102.08

Bearer 1
INP: 4.50 4.00
INPRein: 4.50 4.00
delay: 3 0
PER: 16.06 16.06
OR: 79.68 31.87
AgR: 79.68 31.87

Bitswap: 2684/2684 307/307

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 10651 Kbps, Downstream rate = 54112 Kbps
Bearer: 0, Upstream rate = 10000 Kbps, Downstream rate = 32400 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 14.5 6.2
Attn(dB): 20.0 0.0
Pwr(dBm): 13.0 7.2
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 130 97
M: 1 1
T: 0 0
R: 16 14
S: 0.1279 0.3108
L: 9195 2883
D: 4 8
I: 147 112
N: 147 112
Q: 4 8
V: 2 2
RxQueue: 136 20
TxQueue: 34 10
G.INP Framing: 18 18
G.INP lookback: 31 10
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 268296660 3478280
RSCorr: 416 540
RSUnCorr: 0 0
Bearer 1
OHF: 536217 538327
OHFErr: 0 0
RS: 3216934 2153311
RSCorr: 0 13
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 8473306 33
rtx_c: 37 9772
rtx_uc: 0 0

G.INP Counters
LEFTRS: 0 244
minEFTR: 32395 10001
errFreeBits: 4254822 39542724

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 536639645 0
Data Cells: 7558363 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 0
SES: 0 0
UAS: 23 23
AS: 8614

Bearer 0
INP: 51.00 47.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 32649.19 10051.23

Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87

Bitswap: 3323/3323 56/56

How long have you had the modem connected?

You might need to leave it connected for a few days so that DLM can change the line as required.

Since Friday the 10th April. Guess I'll play the waiting game, thanks anyway.

I've just noticed your on Sky, may I ask what router you use with your connection?

The SR101.

Have you thought about ringing Sky and requesting a newer hub (SR102) I read on Kitz the other day that this is G.INP compatible and also then you only have one piece of kit rather than two!

32400 downstream suggests you've been 'banded' by DLM, see this guide

Are you saying the sr101 is the problem? I doubt they would just give me one, having a modem + router doesn't really bother me. I can't think my router affects the sync speed..

No It's not the problem just an idea really!

Always worth a try!

The only problem with requesting a sr102 is Sky will charge £69 + p&p. It's why I don't use a Sky supplied router anymore because they wanted me to pay for a new router when the Sagem they supplied blew up.

Oh Yeah.... Sky do the out of warranty charge just like with their Sky+ boxes don't they!

Well if in contract they wouldn't but then I suppose they would want good reason for it to be faulty!

Sorry I missed this post actually, thanks. Am I stumped then? Or should the speed eventually return? I never had DLM when I was on ADSL thankfully (bethere).

If it won't work with G.INP properly then you could argue that it's not compatible therefore they should replace it as it's not the fault of the customer that BT have Deployed G.inp Sky should provide compatible kit in this case they did not they supplied the cheapest like the others do

As for the DLM banded profile, this could be a result of sky's choice of DLM stability profile , DLM would probably need a reset to clear this banding , or it may take a very long time

Edited by tommy45 (Thu 16-Apr-15 14:42:02)

Post deleted by WelshWArrior

Whoops!

I was about to reply ....

Hi

It is worth knowing that modems degrade over many months of 24/7 usage, so after a year or more just swapping to a new one even of the same type can see some improvement over an older one, so depending on the age of HG612 and how much use it had before you, it may not be performing at 100%, especially if it ran hot.

The main issue is the capacitors, a lot play the role of reducing noise from the power supply and from other parts of the router/modem, but only have a lifetime rating measured in thousands of hours, and the hotter they are, the shorter the lifetime. As they wear out, the modem starts becoming more electrically noisy internally, this noise adds to everything else and can affect the sync speed.

Regards

Phil

hahaha yep - a made a silly post

I have swapped to the HG612 and obtained the highest sync I've ever seen on my line (just shy of 70,000 kbps), running SP08 firmware G.INP supported.

This is almost +10 Mbps up on what my line was previously capable of, so quite an improvement. Shame as I plan to downgrade back to 40/10 next month (cannot justify the price any more).

Anyway, when I swapped over, I tried to keep the number of re-syncs (router swaps/router reboots etc) to a minimum to avoid upsetting the DLM. As others have said, looks like DLM may have banded you but if you leave it alone, things should restore to what they were before.

Whilst I'm here, I wanted to ask a question (to anyone reading). Is it possible to determine the kind of cabinet I'm connected to (without physically looking at it) from the modem stats? I tried to google this and found no useful answers on the subject. Would be handy to at least know if the Huawei modem I'm now running is actually on a Huawei cab.

Edited by deleted (Thu 16-Apr-15 15:03:23)

Yes you could argue with Sky that your current equipment is not compatible with G.INP and they should give you a new Hub to replace the modem.

As far as the banded profile goes, it might reset once new equipment is put on the line but there is a slim chance of that happening... TBH I've not had any experience with banded profiles so hopefully someone else could shine some light on it, however I would assume the DLM will re-profile the line at some point after a length of uptime.

If you telnet into the locked HG612 and run

xdslcmd info --pbParams

(the upper case P matters) the band plan results are apparently different and a few people, not including me, can tell from those.

Edited by RobertoS (Thu 16-Apr-15 17:11:03)

In reply to a post by RobertoS:

If you telnet into the locked HG612 and run

xdslcmd info --pBparams

(the upper case B matters) the band plan results are apparently different and a few people, not including me, can tell from those.

NO...

xdslcmd info --pbParams

An uppercase P

Here you go:

xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status:   0
Max:    Upstream rate = 29033 Kbps, Downstream rate = 67736 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 69112 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
Medley Phase (Final) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)
                  VDSL Port Details               Upstream                Downstream
Attainable Net Data Rate:           29033 kbps              67736 kbps
Actual Aggregate Tx Power:             6.9 dBm               12.5 dBm
====================================================================================
        VDSL Band Status                U0              U1              U2              U3              U4              D1              D2              D3
  Line Attenuation(dB):  3.9     19.1    28.6     N/A     N/A    10.8    25.0    38.7
Signal Attenuation(dB):  3.9     18.6    27.9     N/A     N/A    14.7    24.8    38.8
                SNR Margin(dB):  11.6    11.7    11.7     N/A     N/A    5.9     5.9     5.9
                 TX Power(dBm): -5.1    -23.8    6.6      N/A     N/A    8.3     7.7     6.9

Indeed to goodness .

Thanks, will edit immediately.

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)

It's a Huawei

In reference to forums.thinkbroadband.com/fibre/t/4257930-re-huawei-hg612-working-a...:

Yep.

This confirms it's an ECI DSLAM:-

Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)




This is the band plan for a Huawei DSLAM:-

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)

The U0 with (0,95) always interests me. As D1 starts at 33, how can 33 to 95 be used for both up and down?

The U0 is variable in width, to allow for a slightly high upstream speed on long lines. I might expect to see (x,95) in the discovery phase, however, I would have though negotiation would have agreed the U0/D1 boundary and it reflected in the medley phase.

On my modem, connected to a Huawei cabinet I see:

US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)

Where U0 stops at tone 32!

Edited by MHC (Thu 16-Apr-15 20:36:50)

Ta!

How do you "Automated Hourly HTTPx5 TBB Speed Tests"?

A timed BASH script running 5 parallel wgets on the TTB 20MB.zip test file. Dump the result to a file, and graph it. Crontab job runs it once every hour, and it has a random sleep interval (in minutes) at the start so that, for the hour being covered, it will actually run the speed test at some random point during that hour to avoid regularity of the tests.

The graph colouring and lines are a result of me getting bored on a rainy weekend. I implemented +/- 3 sigma standard deviation lines and varied the shading of the bars depending on where each speed test result falls (dark for slow speed, way out side the 3 standard deviations from the mean, light for fast speed, way out side 3 standard deviations from the mean in the other direction). The dark lines basically indicate extremely/rare unusual results for the time periods each graph covers (1 day, week, month and year).

The BRAS and SYNC rate are hard coded from my latest entry in the Zen portal but if I can work out how to get that from the Huawei modem, I'll automate that too!

That's basically it.

Oh ok, so you haven't automated the HTML5 widget. I just use JDAST

The sync speed is available from the modem. The BRAS is just 96.69% of it.

Looks like that's Windows only. I appear to have moved on from that malarky over the past 5 years or so.

In reply to a post by BatBoy:

The sync speed is available from the modem. The BRAS is just 96.69% of it.

I make that 96.79%, from the average of the stats recorded in my Zen portal (for my line, at least). So that's what I've gone with.

Graphs updated. Wrote a little Python script using the telnetlib module which telnets in and pulls all the required numbers out of the modem. Hence the new addition of the upstream sync line.

Edited by deleted (Fri 17-Apr-15 15:52:52)

In reply to a post by mixt:

In reply to a post by BatBoy:

The sync speed is available from the modem. The BRAS is just 96.69% of it.

I make that 96.79%, from the average of the stats recorded in my Zen portal (for my line, at least). So that's what I've gone with.

Although in the past the IP Profile has been 96.79% of sync, the indications so far are that it is 96.69% on G.INP-enabled lines.

AIUI 0.01Mbps or 0.1Mbps is reserved by the system for Bearer 1.

Edited by RobertoS (Fri 17-Apr-15 16:52:56)

In reply to a post by BatBoy:

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3959)

It's a Huawei

In reference to forums.thinkbroadband.com/fibre/t/4257930-re-huawei-hg612-working-a...:

Yep.

This confirms it's an ECI DSLAM:-

Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)




This is the band plan for a Huawei DSLAM:-

Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)

It seems there are now 'different' versions of Huawei DSLAMS in active service.


This is mine (connected in 2011):-

Discovery Phase (Initial) Band Plan
US: (7,32) (871,1205) (1972,2782)
DS: (33,859) (1216,1961) (2793,3970)


The telnet command xdslcmd info --vendor will also confirm the DSLAM details:-


xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 5228 Kbps, Downstream rate = 21700 Kbps
Bearer: 0, Upstream rate = 4999 Kbps, Downstream rate = 22399 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
ChipSet Vendor Id: BDCM:0xa44f
ChipSet VersionNumber: 0xa44f
ChipSet SerialNumber:


Some of this information will be included in the next update to HG612 Modem Stats - in the pbParams chart in the snapshot montage:-


Selected modem type = HG612
xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C038m.d24j
software version: V100R001C01B030SP08
xdsl firmware version: A2pv6C038m.d24j
cpu version: BCM6368
cfe version: 1.0.37-102.6

=========================================================================================

DSLAM type: Broadcom (Huawei)
ChipSet Vendor Id: BDCM:0xa44f
ChipSet VersionNumber: 0xa44f

Are you suggesting I am not on a G.INP enabled line then? As the latest sync and bras figures from the Zen portal indicate that the ratio is definitely still 96.79%.

If I am on a G.INP enabled cab (I must be as that is why I replaced the modem, due to latency issues), will it be enabled? Or must it already be enabled as I seem to have gained +10Mb sync speed out of know where?

The figures Zen show in the portal are direct from BT (that's what they say anyway). I guess what I'm trying to say is, based on what you and others are saying, and observing, something does not add up with the figures I am seeing if I am indeed on a G.INP enabled line.

Hope you can clarify.

Run the BT Wholesale Performance Test (ignoring all the red instructions - just say you've done them), and at the bottom of the initial results page click Further Diagnostics. That gives you the IP Profile straight from BTW.

Cool, ok, so 66.82 Mbps IP profile is 66820 kbps. Since BT seem to omit the last digit, let's make it 66825 kbps. 66825/69112 = 96.69%

Brilliant!

Which suggests that if your Zen portal is showing 66.89Mbps IP Profile summat is oop at their end.

Indeed. The last update they have is this one:

19978	66513	68716	TR101	Auto	13-Apr-2015 20:55	13-Apr-2015 20:55

This was a sync with the Huawei *but* it has since re-synced (I rebooted it) and the new value has not shown up at Zen. Also, the above is clearly 96.79%, and not 96.69%.

So yeah, their line data section doesn't seem accurate.

In reply to a post by mixt:

So yeah, their line data section doesn't seem accurate.

It rarely has been. Zen's lack of insight into the state of your line bothers me a lot.

In reply to a post by therioman:

In reply to a post by mixt:

So yeah, their line data section doesn't seem accurate.

It rarely has been. Zen's lack of insight into the state of your line bothers me a lot.

I read somewhere or other that Zen have been seeing problems with line data visibility, this may have started with the G.INP rollout but it may have been present before.

Gained a little bit of speed back last night.. 32400 to 34999. Hopefully it will get back to 40000 one day!

# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 10372 Kbps, Downstream rate = 54392 Kbps
Bearer: 0, Upstream rate = 10000 Kbps, Downstream rate = 34999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 13.5 6.0
Attn(dB): 20.0 0.0
Pwr(dBm): 13.0 7.3
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 146 97
M: 1 1
T: 0 0
R: 16 14
S: 0.1332 0.3108
L: 9790 2883
D: 4 8
I: 163 112
N: 163 112
Q: 4 8
V: 1 2
RxQueue: 132 20
TxQueue: 33 10
G.INP Framing: 18 18
G.INP lookback: 31 10
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 903756448 2296505
RSCorr: 53844 1286
RSUnCorr: 0 0
Bearer 1
OHF: 1880964 839747
OHFErr: 0 7
RS: 11285417 3258326
RSCorr: 6 95
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 8484250 11852
rtx_c: 8042 16271
rtx_uc: 77283 573

G.INP Counters
LEFTRS: 12 487
minEFTR: 34994 10001
errFreeBits: 668335793 143163694

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1971765491 0
Data Cells: 1937365 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 11 24
SES: 11 12
UAS: 57 46
AS: 30214

Bearer 0
INP: 52.00 47.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 35178.65 10051.23

Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87

Bitswap: 21941/21941 530/530

In reply to a post by rippedcotton:

I read somewhere or other that Zen have been seeing problems with line data visibility, this may have started with the G.INP rollout but it may have been present before.

One thing to bear in mind is that Zen provides the following dislcaimer in relation to line data which clearly states;

Please Note:

The following tables show any available information received from BT relating to your Zen Broadband line.

It is not beyond the realms of possibility that the lack of information is due to BT not sending it.

My current line sync rate is showing as 79111kbps down and 19978 up on the Zen customer portal. My router currently reports 79999 down and 20000 up. Which one is right?

When I first had the service last year, the Zen reported sync rate was 79987 down and 19999 up - that also didn't coincide with what the router was telling me.

My circuit is definitely running G.INP and that led to a significant increase in sync speed from a router reported 75876 to 79999

The router is a Cisco 887VA with a Broadcom chipset.

Edited by caffn8me (Tue 21-Apr-15 23:29:02)

In reply to a post by caffn8me:

In reply to a post by rippedcotton:

I read somewhere or other that Zen have been seeing problems with line data visibility, this may have started with the G.INP rollout but it may have been present before.

One thing to bear in mind is that Zen provides the following dislcaimer in relation to line data which clearly states;

Please Note:

The following tables show any available information received from BT relating to your Zen Broadband line.

It is not beyond the realms of possibility that the lack of information is due to BT not sending it.

My current line sync rate is showing as 79111kbps down and 19978 up on the Zen customer portal. My router currently reports 79999 down and 20000 up. Which one is right?

When I first had the service last year, the Zen reported sync rate was 79987 down and 19999 up - that also didn't coincide with what the router was telling me.

My circuit is definitely running G.INP and that led to a significant increase in sync speed from a router reported 75876 to 79999

The router is a Cisco 887VA with a Broadcom chipset.

All good points, when it comes to sync speed your router is the thing to believe. I can quite believe that BT may not send every update in their database to Zen.

OR installed an ECI modem in late February. Initially I had 80/20 sync, then there were several resyncs and speed fell to 74/19.8 in mid-March. I bought and unlocked an HG612. Swapping in the HG612 on 9th April resulted in similar reduced speeds and latency at about 28ms. G.INP switched in on 10th April at 3am, straight back to 80/20 sync and the latency reduced to 18ms.

Maybe if Zen move me to GEA-FTTC the latency may fall further, I have heard of people with <10ms latency.

In reply to a post by rippedcotton:

Maybe if Zen move me to GEA-FTTC the latency may fall further, I have heard of people with <10ms latency.

But you are on GEA-FTTC.

In reply to a post by RobertoS:

In reply to a post by rippedcotton:

Maybe if Zen move me to GEA-FTTC the latency may fall further, I have heard of people with <10ms latency.

But you are on GEA-FTTC.

rippedcotton is indeed already on GEA-FTTC. I took the comment as referring to the possibility of being moved from FTTC over BT Wholesale backhaul (which appears as a line technology of "WBMC" on the Zen portal) and FTTC over Zen backhaul (which appears as a line technology of "GEA FTTC" on the Zen portal).

My first hop latency to LINX went up when I moved to the Zen network - it was ~10ms to the Zen gateways over BT Wholesale and ~15ms to the Zen gateways on the Zen network. In both cases, I connect to the Manchester gateways rather than the London gateways, though I'm only ~40 miles north of Marble Arch.

DSLAM type: Broadcom (Huawei)
ChipSet Vendor Id: BDCM:0xa44f
ChipSet VersionNumber: 0xa44f

Mine is a slightly different Vendor Id. Do all Huawei cabs show up as "BDCM" or is it specifically the 0x???? string which defines the vendor? Would an ECI cab show something other than "BDCM" ?

Mine is below:

ChipSet Vendor Id:      BDCM:0xa451
ChipSet VersionNumber:  0xa451

Note, my cab has already been identified as Huawei by BatBoy elsewhere in this thread, based on looking at the Band Plan figures, so purely asking this for clarification really.

In reply to a post by David_W:

In reply to a post by RobertoS:

In reply to a post by rippedcotton:

Maybe if Zen move me to GEA-FTTC the latency may fall further, I have heard of people with <10ms latency.

But you are on GEA-FTTC.

rippedcotton is indeed already on GEA-FTTC. I took the comment as referring to the possibility of being moved from FTTC over BT Wholesale backhaul (which appears as a line technology of "WBMC" on the Zen portal) and FTTC over Zen backhaul (which appears as a line technology of "GEA FTTC" on the Zen portal).

Yes, that's what I meant, my line shows up as WBMC at present.

My first hop latency to LINX went up when I moved to the Zen network - it was ~10ms to the Zen gateways over BT Wholesale and ~15ms to the Zen gateways on the Zen network. In both cases, I connect to the Manchester gateways rather than the London gateways, though I'm only ~40 miles north of Marble Arch.

I suppose there's always the possibility of a downside, but some people have reported the reverse with first-hop latency falling below 10ms.

https://insidehuaweima5616msan.wordpress.com/

IFTN ?

In reply to a post by mixt:

DSLAM type: Broadcom (Huawei)
ChipSet Vendor Id: BDCM:0xa44f
ChipSet VersionNumber: 0xa44f

Mine is a slightly different Vendor Id. Do all Huawei cabs show up as "BDCM" or is it specifically the 0x???? string which defines the vendor? Would an ECI cab show something other than "BDCM" ?

Mine is below:

ChipSet Vendor Id:      BDCM:0xa451
ChipSet VersionNumber:  0xa451

Note, my cab has already been identified as Huawei by BatBoy elsewhere in this thread, based on looking at the Band Plan figures, so purely asking this for clarification really.

An ECI cabinet DSLAM would include "IFTN" rather than "BDCM".

e.g:-

ChipSet Vendor Id: IFTN:0xb204
ChipSet VersionNumber: 0xb204


It seems there are now 3 versions of Huawei cabinet DSLAMS in use:-

Original - 0xa44f - uses up to tone 3970 in the Discovery Phase band plan


Newer DSLAMS - 0xa451 & 0xa458 - These seem to only use up to tone 3959.

Awesome, thanks!

Posting here because it is in context to my previous parent post but in all honesty has nothing to do with the the topic of this thread.

Just had a neighbourhood wide powercut, and thought I would take a reading of the modem stats right after the power came back on.

# xdslcmd info
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:	0
Last initialization procedure status:	0
Max:	Upstream rate = 38540 Kbps, Downstream rate = 102296 Kbps
Bearer:	0, Upstream rate = 20000 Kbps, Downstream rate = 74000 Kbps
Bearer:	1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps

IP Profile: 71.55 Mbps

Stats before powercut (see parent post):

Max:    Upstream rate = 29033 Kbps, Downstream rate = 67736 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 69112 Kbps

I suppose this is most likely because everyone else on the cabinet disconnected and the readings and sync it has obtained is during a brief moment when there is no cross-talk occurring.

Pretty cool!

Anyway, I expect some further re-syncs back to what the original sync speed was. I'm sure my experience of this kind of sync speed will be short lived.

Edited by deleted (Thu 30-Apr-15 00:45:34)

I found there is a danger in not re-sync'ing yourself. Once everyone else reconnected my error rates became so high that although I kept sync for a few days at the higher speed DLM suddenly jumped in with drastic interleaving levels.

I ended up with the loss of several Mbps from my norm, for about three weeks and very high latency, until G.INP was implemented on my cabinet. That has given me my best ever "valid" connection speed and normal latency, but with a residual small amount of interleaving.

Edited by RobertoS (Thu 30-Apr-15 01:16:52)

I forgot. You now have G.INP on, which usually does improve sync speeds by a few Mbps.

Yeah, but before G.INP was enabled, I was getting ~60 Mbps. Then G.INP got enabled, and with switching to the Huawei, that rose to ~69 Mbps. Now after a power cut, it's at 74 Mbps, and the Huawei is telling me the line can do ~102.5 Mbps?!

For a line that must be ~400m long, that's pretty impressive stats (I think the Huawei is reporting rubbish).

Edited by deleted (Thu 30-Apr-15 06:47:53)

In reply to a post by mixt:

(I think the Huawei is reporting rubbish).

So do you think the Huawei is picking on you personally, or do you think the max attainable is always rubbish?

No, I think it is as you said a while ago where it calculates these max attainable values during initial sync. I guess during its re-sync after the power outage, the cabinet was pretty "quiet" due to no noise/cross-talk.

Yes, it calculates the Max Attainable during sync and with other modems still booting and little traffic a high figures can often be achieved.

However, max attainable will continually vary - I see mine changing sometimes several times a minutes - albeit small steps but is is continually monitoring it.

In reply to a post by mixt:

For a line that must be ~400m long, that's pretty impressive stats (I think the Huawei is reporting rubbish).

If you were the only line on the cabinet, so that no crosstalk existed, you ought to expect that kind of result.

The introduction of vectoring has the aim of making every line behave like it is the only one on the cabinet. Trials of vectoring suggest that lines of 500m can get 100Mbps.

Unfortunately, such speeds may be restricted in the UK,as we employ power reduction masks to ensure that the VDSL2 signal from the cabinets doesn't smother the ADSL signals coming from the exchange. Those masks might cause us to get 5-10Mbps less than the theoretical best.

Interestingly, latency has increased (ever so slightly) and there is an overall higher max latency.

http://www.thinkbroadband.com/ping/share/f4f16f8a6b6...

I presume that's because of G.INP - it's able to handle more errors allowing the line to hold a higher sync, with the side effect of a minor latency increase.

Very interesting graph - I don't think I have seen the green area change pixel-by-pixel before. Obviously I've seen jumps at resyncs, but within a sync - rarely.

But you were getting that behaviour before the resync!

Anyway, with you running at a higher speed by about 5mbps, I'd expect your SNRM to be reduce by 1.5dB or so, and you to be getting a few more errors.

The errors ought to be enough to be handled by G.INP retransmission, but there will be extra latency for *some* packets. That seems to be borne out by the yellow area (the max latency incurred by any packet) being notably higher - by some 2-3ms - while the blue area (the average latency) not really shifting above the green to any greater extent.

Unexplained is the fact that the green area becomes perhaps 1 pixel higher.

Can you see your G.INP counters? The rtx_* counters, and the LEFTRS ones? If so, you might want to track them for a bit.

Tiny changes like that on the minimum line (the green boundary) occur on Plusnet when moving between certain gateways. Others add a few ms rather than 1.

It's quite possible that's what is happening with Zen.

Edited by RobertoS (Thu 30-Apr-15 22:24:45)