In reply to a post by Chrysalis:

your packetloss is all day, I am going to guess the most likely cause is your line with crc errors.

No Chris, it is not. You either haven't read or understood my previous post that proves it is not. So let me re-iterate again.

I symultaneously launched 2 independent tcpdump packet captures to terminate after capturing exactly 3600 packets, one looking at ICMP type 8 (echo request) coming from the BQM IP and the other looking at type 0 (echo reply) being sent back to it.

Both were launched at exactly 10:55 and 10 seconds. Both terminated on the 3600th matched packet (11:55 and 09 seconds).

I received all 3600 ping requests the BQM monitoring IP sent me. I know this by looking at the sequence ID of the packets which varied from 12800 to 13055 (the sequence IDs appear to cycle around with a period of 256). Analysis shows I received every single ping packet sent by BQM, as there are no sequence ID gaps present.

The router also sent replies to every single one of these ping requests.

Thus I have no reason to suspect there is packet loss on my connection, and that it has anything to do with CRC errors. I received all the packets I was supposed to receive, and replied to them.

Yet the BQM graph is showing packet loss across the exact same packet set I just recorded using tcpdump. That does not make sense I'm afraid.

going from 40/10 to 80/20 will put more pressure on the line if it had excess snrm on 40/10.

unlock your modem, or ask zen to temporarily put you on 40/10 and see what happens.

I doubt Zen will do that as that would require a product change with BT Openreach contracting them into a further 12 months.

EDIT: Unless the packet loss is only happening on the upstream frequencies; an unlocked modem is going to be the only thing that shows that. Or, it's a dodgy hop on the way back to the BQM IP.

Edited by deleted (Thu 10-Jul-14 08:21:08)

until you unlock your modem you cant prove otherwise in my view.

what have zen said? as I assume you have contacted them.

The *nix equivalent that comes to mind is mtr, I'm not sure that tracepath will give you packet loss statistics?

The thing to be looking out for is a point at which all further hops after it have loss. A single router showing loss half-way along the route but no loss after it or on the actual target address means that hop along the way simply isn't putting much effort into responding to pings as it's got more important stuff to do.

Having looked at your BQM, you're getting a great deal more red at the top than I do (Example). Therefore I'd be less inclined to blame the Zen -> TTB route, and more inclined to blame what's responding your end, or the BT network between you and Zen.

Is the device responding to pings your end your router? If so why not try redirecting ICMP to a device inside the network that will always respond reliably (like a linux PC or server) and seeing if that changes anything in your graphs.

Edit: I see your other post earlier states you've already checked every single request sent a response back to TTB, so never mind that last bit!

Edited by summat (Thu 10-Jul-14 17:50:28)

Purely out of interest, is your connection 40/10 or 80/20 ? Interleaving on/off ? And finally, what is the IP address of the Zen gateway you are connected to? (first hop).

80/20 on Zen, was previously 40/10 on Entanet. Never had any flecks of red on the TTB graph when I was on my Enta connection, do get a few on this Zen connection, but so little I don't notice it as I said previously. No interleave.

Max: Upstream rate = 36495 Kbps, Downstream rate = 98064 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79987 Kbps

                Down      Up
SNR (dB): 11.3       17.7

I'm on 62.3.83.10 (losubs.subs.dsl5.wh-man.zen.net.uk) right now but I've been on various over the last several months due to various issues like powercuts/firmware upgrades on modem, etc. Doesn't seem to have much if any impact on my TTB graphs.

Edited by summat (Thu 10-Jul-14 20:12:42)

The problem could be on the graphing side of course, "they" are now doing stats on a lot of connections they may even be getting the responses but just not processing them quickly enough.