Strange Behavior - Zen Internet

Hi chaps,

I have a strange issue that I could do with some help with.

Some background information first.

In our premises we have three fibre broadband connections. BT Business Fibre. Plusnet Fibre and Zen Internet Fibre.

Both the BT and Plusnet fibre are working fine, flawlessly in fact!

The Plusnet and Zen circuits use the same cabling from the joint box external to the building. This cable was replaced by BT around 6 months ago.

The BT circuit uses a different internal and external cabling.

I am seeing strange issues with the Zen circuit. Latency increases and large amounts of packet loss at certain times of day. I of course have contacted Zen about the issue, they monitored the line from their end and confirmed that there are issues with latency and packet loss.

I asked if there was a contention issue, they say that BT Openreach informs them that there is no contention issues on my cabinet or the exchange.

They had the line tested remotely by BT Openreach. The test shows a Rectified Loop fault. However, this fault is only apparent when a telephone is connected to the BT master socket.

If I remove the telephone, the fault clears. I have tried a different telephone and the fault remains. The fault is also clear when the BT Openreach fibre modem is connected to the top connector on the BT master socket.

Faceplate is removed and currently using the test socket. Same issue still apparent.

I will now provide you with some BQM graphs that show whats going on.


The first two graphs show the day the issue began.

Zen Fibre on day issue started

BT Fibre on day issue started


Zen fibre snapshot from today.

Zen Fibre today


Snapshots taken on same day for Zen and Plusnet (remember they use the same wiring to external joint box)

Plusnet Fibre on 12 May 2016

Zen Fibre on 12 May 2016


So from the BQM graphs showing the Zen data from today, its clear to see that the issue start in the morning from around 6am, and continues until around 2am. Almost as if a switch has been turned on and causing some type of interference! This has happened like clockwork since the issue started on the 5th May.

Ive tried a different modem on the Zen circuit, same issue. I have ruled out the actual equipment being at fault. and I think its safe to say that REIN is not the issue, as I would imagine that the Plusnet circuit would be showing similar graphs as it uses the same cabling as the Zen, all be it a different pair of course!

Any clues as to whats going on before the SFI Engineer comes?

How does http://www.thinkbroadband.com/speedtest behave?

Zen has had some on/off contention issues in the network elements they control for a while, so might be that and nothing to do with line, or it may be contributory factor i.e. on top of any fault condition

I take your point re the Plusnet and Zen cabling running together, but if you have just started using the air conditioning now the weather is hot, what happens if you turn it off for ten minutes?

Just to absolutely rule it out.

Adding to MrSaffron's post, please could you tell us the exchange.

Thanks for the replies so far.

Here are the results of the speed test.

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

The speeds are fine, there is no issues with them. However, the latency is a different matter.

Here is a ping test to 8.8.8.8

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=25.936 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=31.272 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=28.098 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=25.535 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=33.402 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=28.273 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=26.871 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=57 time=24.931 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=57 time=27.860 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=57 time=25.415 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=57 time=26.741 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=57 time=27.619 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=57 time=27.927 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=57 time=28.184 ms
Request timeout for icmp_seq 14
64 bytes from 8.8.8.8: icmp_seq=15 ttl=57 time=23.840 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=57 time=28.749 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=57 time=28.381 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=57 time=28.043 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=57 time=31.562 ms

--- 8.8.8.8 ping statistics ---
20 packets transmitted, 19 packets received, 5.0% packet loss
round-trip min/avg/max/stddev = 23.840/27.823/33.402/2.289 ms

Note the packet loss.

Here is a ping test to bbc.co.uk

PING bbc.co.uk (212.58.246.78): 56 data bytes
64 bytes from 212.58.246.78: icmp_seq=0 ttl=57 time=14.085 ms
64 bytes from 212.58.246.78: icmp_seq=1 ttl=57 time=18.281 ms
64 bytes from 212.58.246.78: icmp_seq=2 ttl=57 time=22.720 ms
64 bytes from 212.58.246.78: icmp_seq=3 ttl=57 time=17.143 ms
64 bytes from 212.58.246.78: icmp_seq=4 ttl=57 time=16.407 ms
64 bytes from 212.58.246.78: icmp_seq=5 ttl=57 time=14.045 ms
64 bytes from 212.58.246.78: icmp_seq=6 ttl=57 time=14.322 ms
64 bytes from 212.58.246.78: icmp_seq=7 ttl=57 time=14.568 ms
64 bytes from 212.58.246.78: icmp_seq=8 ttl=57 time=14.303 ms
64 bytes from 212.58.246.78: icmp_seq=9 ttl=57 time=14.471 ms
64 bytes from 212.58.246.78: icmp_seq=10 ttl=57 time=13.877 ms
64 bytes from 212.58.246.78: icmp_seq=11 ttl=57 time=14.297 ms
64 bytes from 212.58.246.78: icmp_seq=12 ttl=57 time=13.882 ms
64 bytes from 212.58.246.78: icmp_seq=13 ttl=57 time=14.651 ms
64 bytes from 212.58.246.78: icmp_seq=14 ttl=57 time=14.520 ms
64 bytes from 212.58.246.78: icmp_seq=15 ttl=57 time=13.859 ms
64 bytes from 212.58.246.78: icmp_seq=16 ttl=57 time=14.083 ms
64 bytes from 212.58.246.78: icmp_seq=17 ttl=57 time=14.980 ms
64 bytes from 212.58.246.78: icmp_seq=18 ttl=57 time=14.583 ms
64 bytes from 212.58.246.78: icmp_seq=19 ttl=57 time=16.283 ms

--- bbc.co.uk ping statistics ---
20 packets transmitted, 20 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.859/15.268/22.720/2.073 ms

No packet loss bit some jitter.

We do have air conditioning on the premises. And the telephone cabling does run nearby. However, the air conditioning has only been turned on since last week, this issue started to occur at the start of May.

There was a dip in the tbb result (Single thread that is thus sensitive to congestion issues) so not a perfect test.

Next time latency is bad run a test and see how its behaving.

Looking at the bbqm, could it possibly be someone piggy backing your wifi or even getting into one of the work pc's somehow? have you checked your usage from the time you personally know no one should be using that connection and then when you next go to use that line check zen portal to see if the dowload or upload usage has dramatically changed.

Because to me it looks like someone is heavily using the line, also weird that its showing that during the day and early morning.

Am also with zan office and i dont see whats happening to you but when i do use my line heavily it looks similar to your bbqm albeit you have much more packet loss.

Just to add, i had line problems in may with zen. It was related to g.inp being enabled on my eci fttc cabinet, crazy errors and syncs until bt engineer came out and reset the line which i had to fight zen to get.

Edit

Actually now that i look at my bbqm whilst streaming uhd movie on netflix over 60/15 connect i can see even maxed out my line hasnt got as much packet loss, however i do know zen had problems like you are seeing in the london region. I connect from scotland and go down to north of england to hit zen so it could be the line fault and also if you are located near London that causing the problems for you ?

Bbqm 1

Roughly what mine looks like

And this is today and yesterday, disregard the redstripes as i was messing about with my router trying to get ipv6 and aload of wireless devices configured and each time i push apply that red line appears.

Bbqm 2

Between 10:30 and 1pm is when i was just short of maxing the line out.

Edited by deleted (Wed 08-Jun-16 15:15:02)

We have a Zen ADSL line with congestion problems over the last 24 hours.
http://www.thinkbroadband.com/ping/share/475f8064551...

Posted on the Zen website
We will be carrying out emergency maintenance on our core routers in Manchester and London.
http://status.zensupport.co.uk/incident/1/4690

I'm not seeing anything obviously wrong on my Zen circuit , throughput seems within acceptable limits Speed test result today(flash test)

Although there has been an increase in the level of Jitter today on my TBQM (Today)

Your TBQM does appear to show congestion like events, the increase in base latency/jitter coupled with packet loss and that all too familiar hump shape that is at it's highest point in the evening time, Just because the cab and exchange aren't reaching utilisation limits ,
doesn't mean that the Svlan your Zen connection is on isn't , also the route through BTW's network to plusnet and zen will be different,, and your plusnet connection maybe using WBMC dedicated were as zen will probably use WBMC shared ,

so there's quite a few variables that could make a difference to the level of service an end user will see just within the realms of BTW, my guess is that Zen haven't reached a similar situation that plusnet reached back in 2015 forcing them to use WBMC dedicated ,

Edited by tommy45 (Wed 08-Jun-16 20:01:44)