Zen fibre not so good?

HI guys. I have a question regarding some of the stuff that is happening here whilst on zen unlimited fibre package.

Basically speed supposedly at 60+ download and getting buffering and stuttering of HD streams be it bbc or anything else. Quality is an issue and have to watch in SD.

Tried downloading test files from various sources and example is for a 200MB file that took 2 minutes and 33 seconds to download during peak time (around 5pm). Around midnight or 6 am the same file took under 40 seconds to download.. So I wonder what is the matter?

After issues with streams I had done some speed test here and found that single thread during peak time is affected. Absolutely fine otherwise.

Tried eci, asus, hg612 all same results.

Please see attached results and current stats from modem.

http://www.thinkbroadband.com/speedtest/button/14540...

http://www.thinkbroadband.com/speedtest/button/14540...

http://www.thinkbroadband.com/speedtest/button/14540...

http://www.thinkbroadband.com/speedtest/button/14540...



Current stats:

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 19833 Kbps, Downstream rate = 70964 Kbps
Bearer: 0, Upstream rate = 19833 Kbps, Downstream rate = 71900 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.0 6.2
Attn(dB): 17.4 0.0
Pwr(dBm): 13.5 7.4
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 243 227
M: 1 1
T: 0 0
R: 10 12
S: 0.1081 0.3656
L: 18804 5251
D: 8 4
I: 254 240
N: 254 240
Q: 8 4
V: 0 0
RxQueue: 80 33
TxQueue: 20 11
G.INP Framing: 18 18
G.INP lookback: 20 11
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: 2450457496 972035
RSCorr: 3000962 2001
RSUnCorr: 0 0
Bearer 1
OHF: 4137587 1006968
OHFErr: 0 0
RS: 41375253 3725883
RSCorr: 6 13
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 10051 177
rtx_c: 533 506
rtx_uc: 0 36367

G.INP Counters
LEFTRS: 0 16
minEFTR: 71895 19829
errFreeBits: 72886251 35142959

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 599362195 0
Data Cells: 68285733 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: 28 28
AS: 66443

Bearer 0
INP: 51.00 46.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 71973.59 19876.15

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: 48153/48157 1781/1787

Total time = 18 hours 27 min 51 sec
FEC: 3000962 2001
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 28 28
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 12 min 51 sec
FEC: 270 47
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 40 29
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 18 hours 27 min 51 sec
FEC: 3000962 2001
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 28 28
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 18 hours 27 min 23 sec
FEC: 3000962 2001
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

Edited by deleted (Fri 29-Jan-16 17:25:48)

Most likely congestion, Zen run one of our speed test appliances on their internal network (does not feed our main speed test database) so contact support to get a support number and try running that and comparing to the external tests.

If external and internal are both bad, then points towards a problem between the cabinet and the zen internal network at peak times.

Thanks Andrew. This is how I understood the results too.

I have done the test on zens website too.. Earlier on today the single thread was as bad but now it seems to be in line with the six threaded one on zens website.

However the one here still shows single thread much slower. What is the reason for this difference?

I have been in contact with support at zen but did not get anywhere apart from the usual stuff ie connect via wire and reboot router as if I had not tried already.

What the did is that they failed to acknowledge this as a congestion issue and insisted that the multi threaded test results came back OK and therefore there is no issue with the line.

Yet HD stream is buffering and real life download speed is affected.

Really don`t know how to approach this with zen..

Any ideas?

With a migration order to another ISP?

Zen get notified, and are then supposed to notify you to make sure it is caused by you not a slamming.

Although they can't do anything to encourage you to stay at that point, they can if you respond to that notification telling them why you are going and that you are unhappy with their previous response about a problem that is making the system unreliable. Which would be true.

You might get some truth out of them then, or at least a price reduction. Not that a price reduction is any use to you if the service is inadequate.

You can cancel a migration at any time up to (theoretically) the appointed day by telling the gaining ISP you've changed your mind. You don't have to give any other reason for cancelling. In practice it seems to be more like eight working days as then pretty unstoppable Openreach and maybe BTW processes are going through.

How soon would they get notified? And can I go with anyone, even TT backhaul dependant or does it have to be btw provider?

Its a little bit scary as if something does not go to plan and I am unable to cancel I will be liable for paying up the rest which is around £500 mark..

Is there no other way?

It was only an "extreme circumstances" suggestion really. I expect some suggestions from others will come along.

If it did come to you wanting to move elsewhere then you would need to make the case they were not honouring the contract by allowing congestion like this on what is a premium service, and that they should therefore allow you to leave without paying off the outstanding period.

Product ordered, fine. Product delivered not fit for purpose.

We need to know which exchange you are on . Then we can see if you are on a full BT Wholesale service or Zen's own exchange backhaul.

Thanks I like the way you portrayed my case. Realistically what are the chances they would scrap the charges. i would need a solid proof that the service is not fit for purpose and at the moment we know about it but there is no solid proof in the eyes of the ISP.

Quite annoying really that I know and they know that I know yet pretend they don`t know. Haha this is getting interesting.

I had been zens customer in the past but their support back then was much better. Now I concur that they became like the rest of them..

In reply to a post by RobertoS:

We need to know which exchange you are on .

Exchange name: Aldershot
Exchange code: THAD

Depending on how up-to-date this site is, you are on normal BT Wholesale backhaul. Zen isn't listed in the LLU section, which is where samknows puts it if it has a POP (Point of Presence).

Congestion on the BTW network could be Zen handover capacity from it, a bottleneck somewhere within the BTW system between the exchange and Zen, or possibly a bottleneck within the exchange caused by an overloaded SVLAN. I know very little about those but several people on these forums have suffered them on a variety of ISPs and a shift to a different one has solved their identical problem.

There's this one on Zen that petered out without us knowing what happened.

Ah - same poster - a later thread. Maybe you should see if you can contact him in the thread or by PM.

Yes, I'm with Zen supplied via BT Wholesale and had a similar problem with massive speed drop off at peak times.

With poor results on BT Wholesale TAP 3 test Zen finally lodged a complaint with Openreach and they confirmed it was a congested SVLAN and that my exchange back-haul was running at capacity. Zen did get me moved to another SVLAN and that has helped a lot. The fault is still open until the back haul upgrade goes through around end of Feb.

By the way, the SVLAN is part of the BT Wholesale kit, so not Zen's fault or under-provision. But it is up to them to find out if that's the cause, and if it is to get you moved to another.

There was another recent thread on this, where that happened and it worked. One post in it has a really good explanation of it with FTTC. I haven't time now to find it, but you can by doing what I would.

Do a Search on these forums set to All forums for the last 6 months. The search word is just - SVLAN.

Then plough through one by one starting at the newest until you find it. I right click on each and open in a new tab, and if it isn't that one I close the new tab. That leaves you always at the point you were so you don't get lost. Another tip is if there are several all with the same subject, once in the new tab swap it to Flat mode - menu button towards the top right - and inspect all of that thread in one go.

I think it was within the last two months so shouldn't take you too long.