I am on BT backhaul but the Zen Portal shows that I am due a regrade to GEA. My Fritz!Box 7490 diagnostics is showing occasional internet line interruptions which I assume might be associated with the packet loss.

If it's a BT Wholesale (BTW) FTTC connection, you could ask for a Lower Threshold Breach (LTB) fault to be raised:

http://www.ispreview.co.uk/index.php/2012/12/when-sl...

"The 25% Rule

A lesser known fact is that of the 25% rule, which usually applies to services that initially sync up at 15Mbps Downstream or above. According to BTWholesale, �if the line rate drops by more than 25% over a 14 day continuous period then a fault can be reported�. In practice it helps to have a vigilant ISP on your side for this one as they�re best placed to provide BT with the necessary data."

EDIT: 85Mbps minus 25% is 64Mbps... at 67Mbps you're just over the threshold. But if diagnostics show 40% packet loss provable to the FTTC line this should still be raised to BT Wholsale as a line fault.

EDIT: Assuming this is a BT Wholesale connection there's a whole section on packet loss at:

https://www.btwholesale.com/assets/documents/Orders_...

From the decrease in sync speed and increase in packet loss it sounds like a copper line issue and not backhaul ('hot VP') related. A line test *should* pick up any physical line faults. Caveat: it's impossible to be conclusive about this without access to ISP diagnostic results from line tests, logs etc

Edited by deleted (Tue 07-Mar-17 11:21:18)

In reply to a post by Pontefract:

If it's a BT Wholesale (BTW) FTTC connection, you could ask for a Lower Threshold Breach (LTB) fault to be raised:

http://www.ispreview.co.uk/index.php/2012/12/when-sl...

"The 25% Rule

A lesser known fact is that of the 25% rule, which usually applies to services that initially sync up at 15Mbps Downstream or above. According to BTWholesale, �if the line rate drops by more than 25% over a 14 day continuous period then a fault can be reported�. In practice it helps to have a vigilant ISP on your side for this one as they�re best placed to provide BT with the necessary data."

EDIT: 85Mbps minus 25% is 64Mbps... at 67Mbps you're just over the threshold. But if diagnostics show 40% packet loss provable to the FTTC line this should still be raised to BT Wholsale as a line fault.

EDIT: Assuming this is a BT Wholesale connection there's a whole section on packet loss at:

https://www.btwholesale.com/assets/documents/Orders_...

From the decrease in sync speed and increase in packet loss it sounds like a copper line issue and not backhaul ('hot VP') related. A line test *should* pick up any physical line faults. Caveat: it's impossible to be conclusive about this without access to ISP diagnostic results from line tests, logs etc

I wandered down to the PCP and there are two guys working on the transfer of lines to the new PCP. It would seem that they tried some time to install new blocks in the old cabinet but after completing two columns they just gave up and installed a new PCP next to the VDSL box.

My line has yet to be transferred across: it should happen by Friday. The wiring in the old box is a tangled mess with the engineer having to move bundled aluminium and copper lines to find the line that he is trying to move across. Very kindly, the engineer has re-jumpered my line after he thought that he had detected a break under the insulation. The DSL has re-synched but I am still getting packet loss. I was told that they have had a number of SFI visits to fix broadband faults. I just wonder how those customers got their ISP to play ball: I failed.

How many BQM/Ping monitors are running on your line?

Did you know when Fritz!Boxes see too many pings, they don't reply and you see this cyclic pattern of packet loss. Perhaps Zen have a monitor running?

Do you have an IPv6 address you could monitor instead.

In reply to a post by bet_here:

How many BQM/Ping monitors are running on your line?

Did you know when Fritz!Boxes see too many pings, they don't reply and you see this cyclic pattern of packet loss. Perhaps Zen have a monitor running?

Do you have an IPv6 address you could monitor instead.

Interesting that you should ask. I was just running a single BQM. After today's fix, the baseline latency has fallen but the packet loss has returned. I set up an IPv6 BQM an hour or so ago and it is showing 100% packet loss. That said, both the IPv4 and the IPv6 speedtests are fine and the Fritz!Box error is nothing out of the ordinary. To date, no stuttering on streaming or on FaceTime. Zen say that they are seeing more packet loss than is showing on the BQM.

BQM v6

So Zen have a monitor running too. Suspend your monitors and ask Zen if theirs clears up.

In reply to a post by bet_here:

So Zen have a monitor running too. Suspend your monitors and ask Zen if theirs clears up.

Zen seem happy to receive BQMs from me and they haven't mentioned the possibility of a conflict. IPv6 is showing 100% packet loss.

It's a 'feature' of the Fritz!box.

If you (and/or Zen) run more than 1 monitor, then you will see high or complete packet loss on one or all of the graphs.

In reply to a post by bet_here:

It's a 'feature' of the Fritz!box.

If you (and/or Zen) run more than 1 monitor, then you will see high or complete packet loss on one or all of the graphs.

I would have thought that Zen Support would know that as they supply Fritz!Boxes as a VDSL modem/router. I should have added that I did not off the IPv4 BQM for a time last night and the IPv6 still showed solid red. I have turned it off again so I will see what happens .

Edited by lexden16 (Wed 08-Mar-17 10:40:54)

If you didn't know about the BQM, would you have said you're seeing performance issues from generally using your connection?