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.