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.

Did you get a case number from the Zen website? If so can access those tests and compare to your others and pass comment

I don't think there is anything wrong with the line, but rather once you hit some shared part of the network.

Thanks for joining in .

Thank you all. I shall do the search re SVLAN.

It does not affect the btw test so I have no solid proof apart from my real time feeling when downloading test file or doing TBB speed test.

Aaaargh seems like it will have to get much worse before it can get better.

You are really great thanks again for your time guys

If you look in my thread its the same, and other guy just posted the same man . http://forums.thinkbroadband.com/zen/f/4458979-slow-...

It might be time too look at others ISP but where ....

Im on zen LLU without pop presence in my exchange. Something to do with mother exchange I was told. so Is it Zen network struggling ?

Edited by deleted (Fri 29-Jan-16 21:15:04)

In reply to a post by aparat:

Im on zen LLU without pop presence in my exchange. Something to do with mother exchange I was told. so Is it Zen network struggling ?

It is still Zen's job to get "mother exchange" problems affecting you resolved. None of us on any ISP sign up to congestion at our exchange.

Speed slowdowns outside BT Wholesale's purview, i.e. after it leaves their systems for the www are one thing. We know that is bound to happen at times. BT Wholesale capacity failures are not.

Our ISP can have insufficient capacity. We know that. If they don't increase it, we move on. They either learn or lose customers.

Capacity issues under BTW's control, when its whole purpose is to provide sufficient throughput and charge ISPs enough to provide that but also make a profit, have to be accepted in the short term when they occur. But they can and should be fixed. Quickly.

The search I suggested the OP carry out is relevant, as the post I remember is about SVLANs and their capacity.

By mother exchange I meant thats how Im on Zen LLU not that there is a problem there, sorry. Zen said there is no problem if multi threaded download is fine. So I can not be bother sending more emails I think. Just slowly looking for another ISP just dont know where to look now but that might be a question for another thread. Dont want to hijack Kamils thread

Zen don't have LLU. That is just where samknows stick their non-BT Wholesale backhaul for them, to save creating a new category box for a single provider.

Quite how it works technically I admit I don't know. I believe on ADSLx it is between the user and the BTW MSAN but is then split off to Zen backhaul rather than through the BTW WBMC cloud to a handover point or points where the rest of their traffic is concentrated, and on FTTC is (perhaps) fed directly by Openreach to the Zen backhaul. Though the latter would require Zen to have a GEA link installed at the exchange, which is unlikely. So perhaps that too is somehow split out from BT Wholesale.

If I had second chance I would have gone with pulse8. been their customer past year and a half and not had any issues. only reason I went with zen was unlimited service slightly better price and past experience. what a silly thing to do

The difference between the multi-thread and single thread download tests are interesting.

As far as I can tell/understand the ISP network sees no difference between the two.

A single test will have one data stream between your routers IP address and the test sites IP address. I assume a multi-thread test uses the same IP addresses but with different originating port addresses. The port addresses are part of TCP protocol while the ISP network is responsible for the IP part - TCP on IP.

I wonder if you have a firewall that's not great on individual threads.

I'm on Zen FTTC and sync at 80/20 and testing reliably reports 75/18 although testing now with the family active I get this test result of 74/15.

The drop on the single thread test is interesting and I suspect buffer bloat in the router which can impact speeds.

As a whole my service is fast and reliable - I have a samknows box - and the thinkbroadband BQM has recent results like this.

My understanding of Zen's POP rollout is that they have kit in many BT exchanges and the backhauls from the exchange to Zen's core network are under Zen's control. Unfortunately I've not found a list of exchanges with POPs.

Thanks for your input

I can not access your bqm as it comes back with error.

The firewall theory I do not believe in as the issue only presents itself in the hours of high use of the btw network.

See this :

this morning

On the whole my connection works and I do not experience `stand still` like browsing or anything. It is frustrating tho on a supposedly 60meg line to not being able to watch HD streams without hiccups.

I hope zen will have a pop in my exchange soon. Although I seriously doubt that

In reply to a post by MrSaffron:

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.

I'm guessing your appliance within Zen is the one at http://speedtest.zen.co.uk.

I have the same issue as Kamil and aparat, and I get identical results whether using the TBB test hosted on your side, or on Zen's network. It also affects basically anything single-threaded regardless of origin - e.g. HTTP downloads in a web browser.

I don't believe cabinet congestion to be the issue, because that would surely impact multi threaded performance? I get absolutely flawless speeds if I can use a download manager or something like bittorrent. It's universally poor too, regardless of time of day (though I haven't yet tried it at 3am). I think Zen did tell me that Openreach didn't report any congestion issues?

Here's a more extreme example from my connection: http://www.thinkbroadband.com/speedtest/results.html...

Though occasionally it's fine: http://www.thinkbroadband.com/speedtest/results.html... (ignore the fact that it's IPv6, when it's poor it's poor with either protocol - and this is Zen's native IPv6, not a tunnel)

Right now it's all over the place on single threaded, but absolutely solid with multi threaded: http://www.thinkbroadband.com/speedtest/results.html...

I've noticed one instance where the BT wholesale speedtest gives me poor results, but doing the test3 while connected to the BTwholesale test network gives me great results.

In reply to a post by bsdnazz:

The difference between the multi-thread and single thread download tests are interesting.

As far as I can tell/understand the ISP network sees no difference between the two.

A single test will have one data stream between your routers IP address and the test sites IP address. I assume a multi-thread test uses the same IP addresses but with different originating port addresses. The port addresses are part of TCP protocol while the ISP network is responsible for the IP part - TCP on IP.

I wonder if you have a firewall that's not great on individual threads.

I use pfSense on a beefy box (and have CODEL enabled to try to handle bufferbloat), so my router or lack of performance is not the issue. But I get exactly the same result even if I connect a computer directly to the Openreach modem, so my entire network can be ruled out.

In reply to a post by bsdnazz:

My understanding of Zen's POP rollout is that they have kit in many BT exchanges and the backhauls from the exchange to Zen's core network are under Zen's control. Unfortunately I've not found a list of exchanges with POPs.

There's a map showing their PoPs if you click the link in their press release. I'm not on the "Zen network", I'm definitely connected via BT wholesale.

Edited by deleted (Sat 30-Jan-16 11:22:27)

I really don't understand the difference between the single and multithread tests.

As you say, a beefy box running pfSense with CODEL is unlikely ( ! ) to be causing a problem so why the single thread speed does not max out the connection is very odd.

The Zen POP map is really just a bunch of white squares on a map of the UK so it's not possible to say which exchanges the squares relate to.

In reply to a post by bsdnazz:

I really don't understand the difference between the single and multithread tests.

+1 on that its beyond my understanding why

As to the pop`s yeah can not tell much from that map not even able to zoom in there. Pretty useless.

Small update.

After all the saga last week and emails sent to zen support I have not heard anything back for a while.

Yesterday I got email from Zen saying that the have some suspicion of `other` issues on the line here..

I have a guy looking in to this and I am getting in contact with him on Thursday.

Seems like someone is keen on getting it addressed so we shall see.

I will update here once I get anything from Zen.

Cheers

In reply to a post by Kamil:

Small update.

After all the saga last week and emails sent to zen support I have not heard anything back for a while.

Yesterday I got email from Zen saying that the have some suspicion of `other` issues on the line here..

I have a guy looking in to this and I am getting in contact with him on Thursday.

Seems like someone is keen on getting it addressed so we shall see.

I will update here once I get anything from Zen.

Cheers

Are they trying to claim it's an issue specific to your line? When I got the run around they kept suggesting stuff like cabinet congestion or some local issue.

This is what I'm getting right now: http://www.thinkbroadband.com/speedtest/results.html...

Here is mine:

http://www.thinkbroadband.com/speedtest/results.html...

Basically they said that there might be REIN on the line but I am not so sure about this as somehow it only affects single threaded DL.

I will know more on Thursday (hopefully) after I have spoken with the guy who is looking at it.

And here is mine :

http://www.thinkbroadband.com/speedtest/results.html...

I dont think its RAIN on the line otherwise do we all have the same problem?

I dont think so.

Keep us updated Kamil please.

Just seen this thread. I emailed support earlier about my test from http://speedtest.zen.co.uk./

https://www.dropbox.com/s/mml7aph3uyc3l8e/Zen%20Spee...

Awaiting a reply...

I take it that you are on Zen's back-haul ? there is my speed test for comparison
Zen WBMC based

If you are like me reliant on BT wholesale for back-haul then the issue is more than likely with BT

I believe it is btw equipment here at Aldershot exchange.

The first point is for Zen to admit that there is something not right. At the moment they do not seem to see the issue. And bottom line is they are paying btw for trough put for their customers and I am paying them so any issues I am going to contact zen and they should kick bt up the [censored] to get it sorted for them.

But first we must prove that there is in fact an issue..

Till thursday..

Good luck, please report back with what they had to say

Cheers.

I would not expect much Kamil in this case, but I might be wrong.

I was told this: "If you are able to achieve your predicted throughput via a multi threaded download test we would say there is nothing wrong with your connection"

Proof of a contention /congestion issue is also required by BTW or they will pass it back to the isp, i think Zen just want to provide BT with enough evidence first time round, As BT can be a bit stupid and try and generate some revenue by claiming its a line fault, or that's the line they spin to the isp when they raise a contention fault

Twice Zen have sorted similar probs out for me,though it can be a little frustrating knowing what the problem is, and not being able to do much about it straight away
If you can get a low enough BT speedtest and it offerers the tap3, and that shows poor throughput also you should then have a better chance of zen taking more notice, maybe even raising /escalating it within btw to get a resolution

I agree with you fully we are paying a premium price so should receive a better service than if we were on a bargain basement deal

if you guys are on BTw exchanges then it may be down to BTw congested MSIL's.

In reply to a post by Chrysalis:

if you guys are on BTw exchanges then it may be down to BTw congested MSIL's.

The unanswered question is why multi-threaded performance is flawless - congestion would logically affect both equally

I am on Zen backhaul

Edited by deleted (Wed 03-Feb-16 13:10:59)

In reply to a post by sor:

In reply to a post by Chrysalis:

if you guys are on BTw exchanges then it may be down to BTw congested MSIL's.

The unanswered question is why multi-threaded performance is flawless - congestion would logically affect both equally

Well to a point yes, but not in all cases, as it will depend on how bad the level of congestion is, I have had the single threaded issue mainly when i was with Plusnet, as have lots of others,I have seen where both multi and single threaded are affected, imo it maybe that single threads are impacted first where there is high contention or congestion in the network could be down to the type of hardware or how it has been configured

Edited by tommy45 (Wed 03-Feb-16 20:20:20)

nope, its single threaded that takes the brunt. I know as it was affecting me and others when on plusnet.

So because btw tester does in fact use multi thread the matter has to get much worse before they actually class anything like what we are seeing as a problem.

Beyond funny this.

I wonder what the chap at Zen will tell me tomorrow.

Last one I have spoken to suggested using LAN for streaming rather than wifi (ps3)..

What else can I say

In reply to a post by Chrysalis:

nope, its single threaded that takes the brunt. I know as it was affecting me and others when on plusnet.

Zen claimed that they'd already checked for "hot VPs" (I guess they used 20CN lingo even though this is 21CN) and BT wasn't reporting anything wrong.

I can't see why it would only affect single threads though. Congestion is congestion, unless BT/Zen are doing DPI and fancy traffic shaping I don't see why it doesn't affect both equally.

In reply to a post by sor:

In reply to a post by Chrysalis:

nope, its single threaded that takes the brunt. I know as it was affecting me and others when on plusnet.

Zen claimed that they'd already checked for "hot VPs" (I guess they used 20CN lingo even though this is 21CN) and BT wasn't reporting anything wrong.

I can't see why it would only affect single threads though. Congestion is congestion, unless BT/Zen are doing DPI and fancy traffic shaping I don't see why it doesn't affect both equally.

It's the Svlans that are often the cause of issues, but they can occur in other parts of what is BT's network topology as well, and that could cause odd results that appear illogical ,

In reply to a post by Kamil:

So because btw tester does in fact use multi thread the matter has to get much worse before they actually class anything like what we are seeing as a problem.

Beyond funny this.

I wonder what the chap at Zen will tell me tomorrow.

Last one I have spoken to suggested using LAN for streaming rather than wifi (ps3)..

What else can I say

Unfortunately yes on that, and that could well be why the BTW speed-tester uses multi threaded ,it also will allow the speed to ramp up before it actually starts measuring throughput too,
And yes mention wireless to any ISP they will always point the finger at that, (because quite a lot of customer complaints about speed and buffering ect are actually caused by wireless ) or it's down to how it has been set up by the EU Some aren't very knowledgeable
Just keep testing your throughput and if it seems lower at any point run a bt speedtest and compare ,It took me a while before i was able to provide a TAP3 that was under performing below 40mbps your IP profile from that BT tester tells you what they consider to be the acceptable range for your line, if it falls below this, you get the TAP3

Yes that`s what I am trying to get. Mine has to be below 48Mb. I am yet unable to make this happen.

I have just run test on zen`s website, and it averaged 6Mbps on a single thread and 32Mbps on a x6.

Running btw straight after unfortunatel did not produce the required results.

But I have something to talk about with the guy tomorrow as I have done test early hours of the morning and couple in the afternoon/evening.

He can compare and sod btw tester it is rigged piece of garbage

I am going to have to keep trying.

MSIL's arent the exchange VPs, zen may not be aware of the problem.

The good news is plusnet are shifting people of the shared BTw MSIL's so that congestion will ease up eventually.

Of course this could be something within zen's own network, but I was just letting you know there is/was a BTw msil congestion problem.

So no update at all for now. the guy that has sent an email is off until Monday with illness and nobody else know what he wants to do..

I put all the questions on hold until I finally speak with him.

Have you created a TBB BQM yet? If not, it would be a good idea to create one, email the live BQM link to Zen support and then they can see for themselves the network congestion...usually indicated by packet loss and/or high latency at peak times on the BQM monitor. Up until recently this is what my TalkTalk Business line looked like:
http://www.thinkbroadband.com/ping/share/5aa41f20238...

And after TalkTalk added extra capacity at my exchange a few days ago:
http://www.thinkbroadband.com/ping/share/07b4d36b37d...

Edited by deleted (Fri 05-Feb-16 16:10:09)

Yes, got it all set up and also linked to my dsl stats here..

I have not emailed them the details as I believe they have there own QM running on the line.

But to be honest with you I do not see anything worrying on the BQM:

http://www.thinkbroadband.com/ping/share/13e268e77d8...


The only issue I have is with single thread DL at peak times (roughly 3pm until midnight) and buffering of HD streams when trying to watch. So not really the end of the world to be honest.

I just want to Zen to admit the problem and perhaps try to do something about it.
Nothing should be buffering on a 60meg connection but that`s my opinion anyway.

Thanks for your advice mate. Glad you got sorted with your connection

In reply to a post by Kamil:

The only issue I have is with single thread DL at peak times (roughly 3pm until midnight) and buffering of HD streams when trying to watch.

This could be related to the packet loss (not huge but sustained) between 3pm and 10pm shown on your live BQM. On a good line there should just be the odd red tiny spike....

This is mine from yesterday. Zen POP. Not too bad, but there was no-one in during the day.

My Broadband Ping

Yours looks a bit more lively in the evening.

Edited by deleted (Fri 05-Feb-16 17:38:22)

In reply to a post by baby_frogmella:

In reply to a post by Kamil:

The only issue I have is with single thread DL at peak times (roughly 3pm until midnight) and buffering of HD streams when trying to watch.

This could be related to the packet loss (not huge but sustained) between 3pm and 10pm shown on your live BQM. On a good line there should just be the odd red tiny spike....

Thanks for that

Here are mine:

IPv4 - http://www.thinkbroadband.com/ping/share/512bd86e877...

IPv6 - http://www.thinkbroadband.com/ping/share/882423bd50f...

Nothing particularly outrageous, but I still have the single thread issue. Ignore the deep red spike, that's when I was doing stuff to my router. (I have the issue even during the middle of the day, where packet loss is minimal or non existent)

Edited by deleted (Fri 05-Feb-16 21:22:56)

In reply to a post by aparat:

Keep us updated Kamil please.

An update guys.

It took a long time but still have not managed to speak with the guy that I wanted to in the first place.

Luckily I have come across another support person at Zen that knew exactly of the issue that I was presenting to him.

He confirmed that there is an issue somewhere within the network and that the core network team is working on fixing it.

Apparently they were able to reproduce the single threaded issue them self and acknowledged it as a fault.

Now to wait for the outcome and hopefully that won`t be too long.

Its been outstanding for 5 days so far he said.

Happy days.

Edited by deleted (Tue 23-Feb-16 18:30:52)

Nice one Kamil. Just like we all thought, within Zen network. Lets hope they fix it soon

That sounds a bit like the problem Plusnet had for most of last year. AIUI it turned out to be congestion at the shared MSILs at some of the WBMC nodes. (Scroll down to the two network diagrams). I believe Plusnet have moved or are moving to dedicated.

Edited by RobertoS (Tue 23-Feb-16 19:00:56)

In reply to a post by Kamil:

An update guys.

My Zen contact seems to have gone AWOL since last week. Hopefully something is happening.

What's strange is that when I was getting the cold shoulder, the person I spoke to (a different one) said that he could reproduce the issue with one of his colleague's connections via remote desktop to his home. That should ring alarm bells that perhaps I'm not making it up or that it's not a localised issue (I live nowhere near Rochdale)

In reply to a post by RobertoS:

That sounds a bit like the problem Plusnet had for most of last year. AIUI it turned out to be congestion at the shared MSILs at some of the WBMC nodes. (Scroll down to the two network diagrams). I believe Plusnet have moved or are moving to dedicated.

I believe at least one of us isn't on WBMC, but is on Zen's own backhaul. So it may not be a BT issue.

Glad they seem to know what it is now, I only started reporting these issues in October 2015 - November 2015 just to be told that its fine because my usage was high...

Not sure how that made sense but as soon as they came up with that [censored] and tried washing there hands of the issues I gave up and got another connection for Virgin installed to do gaming on.

I was going to revisit the issue but then ended up in mad rush to vacate my previous property due to [censored] landlord wanting too sell so we proved a point y getting moved ASAP and now he's had the house sitting empty for near three months...

In reply to a post by RobertoS:

That sounds a bit like the problem Plusnet had for most of last year. AIUI it turned out to be congestion at the shared MSILs at some of the WBMC nodes. (Scroll down to the two network diagrams). I believe Plusnet have moved or are moving to dedicated.

This is what I thought initially too. I have seen the above whilst trying to find some answers.

According to the support though they reckon it is happening further inside their network. Bizzare and unknown issue that only seems to affect certain aspects of certain connections.

I feel it will take some time before they find the cause.

Main thing is that they are doing something about it now.

In reply to a post by sor:

I believe at least one of us isn't on WBMC, but is on Zen's own backhaul. So it may not be a BT issue.

I do remember someone on this thread connected to Zens POP so this would indicate what you are suspecting is true.

Edited by deleted (Wed 24-Feb-16 19:04:27)

I'm on zen backhaul with same problem.

Edited by deleted (Wed 24-Feb-16 23:40:10)

Hey aparat,

Do you still have the issue?

Since yesterday my connection has been fine. The Speed is matching all the time during all hours and BQM looks clean as a whistle with none of the packet dropping. I get none at all.
Also spikes in latency are very small.

Is it coincidence or has something been finally done?

Thanks

Yes still issues. Still no fix.

In reply to a post by Kamil:

Thank you all. I shall do the search re SVLAN.

It does not affect the btw test so I have no solid proof apart from my real time feeling when downloading test file or doing TBB speed test.

Aaaargh seems like it will have to get much worse before it can get better.

You are really great thanks again for your time guys

Last week for a few days i was seeing a jitter fest that was apparent during office hours and evening peak time, the single threaded test on tbb was showing lower results upto 50% lower at times , but the zen speed test i was near normal, my connection joins the Zen network at Manchester , their speedtester is also in Manchester ,So it was caused by something on the london side of their network imo

I have also in the past have had peak time congestion issues caused by BTW's Svlan's being run to their max , the last two instances Zen have been my isp, and can report both times they did escalate this with the correct part of BTW who didn't argue,and swapped me onto a different Svlan , though you do have to provide Zen with sufficient evidence TAP3's ect before they will get onto BT ,

I dont know if I am just lucky on good gateway or what but its day 3 and the connection is holding pretty good.

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


Can some other folks please share their most recent experience also.

I am not restarting this modem ever again

Hi guys,
Apologies to revive this thread up, but I see similarities with my issues, so wondered if I could have the same problem going on (that I only partially understand from reading this!). Is the problem described and sorted in this thread the sort of thing that was fixed for individuals, individual exchanges, or should it have been sorted overall across the network, making this not likely to be my problem?

I'm FTTC, on Bristol North exchange, which is listed as having Zen LLU on samknows (which I believe means they have their own backhaul). Samknows gives me 73-80mbps downstream / 20 upstream estimate.

I have found in recent months (6-9 maybe longer), that web browsing feels sluggish, lethargic, and a bit laggy - enough for my wife to notice the 'internet is a bit slow'. Yet sustained downloading speeds of files is good, and when I've tested on speedtest.net or something all looks good (prob slower than when I first got the fibre 2yrs ago though).

However, now I've used the thinkbroadband and zen's own speedchecker (which says thinkbroadband on it), it reveals this slower single threaded speed (and inconsisten/all over the place) that people have described here, with the 6x thread being ok (not perfect). This is regardless of time of day/middle of night.
Typical readout in middle of day:
https://s32.postimg.org/hm9smagid/speed201606241328.png
https://postimg.org/image/5x5sybpjl/

My thoughts/questions:
When would Zen have introduced the backhaul to the exchange? Could this coincide with when performance dropped, and would that make sense? Is this the cause (or related to the cause) of the lagginess? Is this something I could talk to Zen about? Could it be related to what's on this thread? If so, how do summarise describe this to help them if I call up?

Thanks for your thoughts!

Leftfield maybe but have you investigated bufferbloat?

Navigate to DSLReports and run their speed test, this will give you more info.

For reference, I recently investigated and changed config to drastically reduce bufferbloat (which will give you sluggish web browsing) and I instantly noticed the improvement as you'd expect. That improvement remains some weeks later.

To save you some time, you can use QoS settings in your gateway/ modem/ router to improve bufferbloat. Essentially, set the uplink rate to just below what your best speedtest results have shown.

Paul

Thanks for the reply. I haven't ever looked into bufferbloat.

DSLReports:
http://www.dslreports.com/speedtest/4258694
Grading: BufferBloat A, Quality C, Speed C

Does that suggest bufferbloat isn't a problem? Is the Quality/Speed grading to do with bufferbloat, or something else?

I have a Buffalo WZR-1166DHP, with QOS setup.
Will start doing more research on bufferbloat!

Bufferbloat stats look very good. Mine comes in at 'C' with an original stat of 'F' before the QoS changes. Browsing is how I would expect now. I.e. as good as instant to change pages/ searches. I should state that I perform these tests over a WiFi connection.

'Quality' relates to the average detected packet loss/ re-transmit percentages during the download part of the test. So you're getting '5% or less' for that measure. Mine comes in at A every time, which is '1% or less'. So that might be some indication of your issue.
I wouldn't worry about the 'Speed' rating as that's just a measure compared against everyone else who runs the test.

Paul

Edited by deleted (Sun 26-Jun-16 21:49:13)

Ok, thanks for the info. So if I'm not looking at buffer bloat, and may be looking more at packet loss/quality, and given that my speed tests generally look like:
https://s32.postimg.org/hm9smagid/speed201606241328.png
with inconsistent/poor single thread speed, yet pretty good 6x thread speed (though not quite as much as I'd expect or it was originally before things became more sluggish), any idea where/how I should further work out the problem?

After talking to my wife, she's pretty certain as well that it suddenly became not as sharp one day, and has mainly stayed that way. Pages definitely don't load instantly, which was how I remembered things being when I first went onto fibre on this line 2yrs ago with Zen. I'd sort of wondered if my standards had just gone up, but have gone off that idea now!

Having a quick read around, packet loss can be caused by: network congestion, overworked routers and switches, slow round trip times, or possibly a result of traffic prioritisation schemes used by service providers or the company hosting the site you are trying to access.

So there's a few things to investigate there. I wonder if congestion = contention. Maybe a load of new homes switched to FTTC in your area around the time of the slowdown...

Paul