You might expect it to only affect evenings, but depends on the ISP and user patterns for their customers.

That would imply congestion within the IPS's network as opposed to BT Wholesale though, wouldn't it?

Incidentally, just to confuse the heck out of things, right now I'm getting 0 packet loss, BQM has hardly any red in it, and normally by now I'd be suffering from problems. There was one day last week that was similar.

Speed tests are also superb:
Download speed achieved during the test was - 79.91 Mbps
For your connection, the acceptable range of speeds is 40 Mbps-77.42 Mbps .
Additional Information: IP Profile for your line is - 77.42 Mbps

The TTB speedtest result is quite interesting too
http://www.thinkbroadband.com/speedtest/results.html...

This is maddening. There are just too many variables here

The ISP did change the LNS I connect to yesterday, but that was yesterday morning and I did a full reboot (modem and router) afterwards which had no effect on the loss/poor speeds...

Entanet is an isp that showed an increase in jitter during office hours, or their o2 wholesale products did , can't speak for their BTW based products though

Edited by tommy45 (Tue 15-Apr-14 13:36:30)

I'm intrigued by the nature of the BQM in the middle of the day.

If this were a case of congestion, we'd see lots of packets queued, and some packets dropped. Surely, therefore, we'd see both the red "packet dropped" portions *and* periods where the yellow (maximum latency) section were raised considerably. If 5% of packets were being dropped, surely some percentage would get delayed noticeably. Even 1% would show - one packet delayed out of the 95 that got through - yet there is no shift in the yellow.

Personally, I'd also expect to see the blue (average) rise too.

This is what "congestion" looks like on my line: BQM. Busy hour isn't very noticeable here, but you can see *something* in the yellow and blue before you ever see the red.

However, with the yellow and blue portions sticking resolutely near the minimum, it suggests that the packet loss is not being caused by congestion. Or at least "normal" congestion with queues involved.

The most obvious, non-congestion, cause of packet loss is interference on the copper portion of the line. However, I'd expect DLM to see that rate of errors and intervene.

Here is a BQM with packet loss from my first FTTC line, with the switch as DLM intervened.

I think I would probably unlock the modem, and start tracking the error counters, to try to rule this part of the network out.

I don't want to mess with the modem - I'd need to get hold of another one specifically for unlocking.

But now that I think about it, my Draytek 2860 can do VDSL2 itself - I've just not bothered to try to figure out how to configure it to do so. I'll have a go over the Easter break. That way I should have access to some sort of stats.

Now then, the key was setting the vlan tag to 101 or something...lets see what Mr Google has to say...

OK, well this doesn't tell us anything at all:

Text

1 23 45 67 89 1011 1213 1415

> adsl status   --------------------------- ATU-R Info (hw: annex A, f/w: annex A) -----------   Running Mode            :  unknown       State                : SHOWTIME    DS Actual Rate          : 80000000 bps   US Actual Rate       : 20000000 bps   DS Attainable Rate      :        0 bps   US Attainable Rate   :        0 bps    DS Path Mode            :        Fast    US Path Mode         :        Fast   DS Interleave Depth     :        0       US Interleave Depth  :        0    NE Current Attenuation  :       13 dB    Cur SNR Margin       :        7  dB   DS actual PSD           :     0. 8 dB    US actual PSD        :    11. 6   dB    ADSL Firmware Version   : 05-04-08-00-00-06  -------------------------------- ATU-C Info ---------------------------------    Far Current Attenuation :        0 dB    Far SNR Margin       :        9  dB   CO ITU Version[0]       : 00004e54       CO ITU Version[1]    : 000003b2    DSLAM CHIPSET VENDOR    : < unknown >>

EDIT: Correction. Fiendishly hidden away was this (under "show status"):

Text
1 23 45 6	VDSL Information:      VDSL Firmware Version:05-04-08-00-00-06 Mode:17A               State:SHOWTIME   TX Block:0     RX Block:0  Corrected Blocks:0     Uncorrected Blocks:0  UP Speed:20000000   Down Speed:80000000   SNR Margin:7   Loop Att.:13

But those stats are for only a few minutes uptime.

Edited by sfo32 (Thu 17-Apr-14 00:27:40)

Things remain good today.

The router reports 0 corrected/uncorrected blocks, though I'm not sure how accurate that really is given that it still shows 0 for "TX block" and "RX block".

Latest speed test shows poor 1x and great 6x (@ 1pm).

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

BQM shows no significant loss - the red is almost invisible.

I've added some additional BQMs to my account:
1) a BT Retail FTTC on the same exchange (different cabinet) to use as a handy comparison. Unfortunately it is quite a slow connection (~50Mbps down) and non-EBE
2) Same ISP as me but different cabinet and no EBE
3) Same ISP as me but different exchange an non-EBE.

(I look after all of the above - don't worry folks!)

I'll keep an eye on things.

In reply to a post by sfo32:

The router reports 0 corrected/uncorrected blocks, though I'm not sure how accurate that really is given that it still shows 0 for "TX block" and "RX block".

The counter representing "corrected blocks" must refer to FEC blocks. However, your modem doesn't have FEC or interleaving applied (it reports fast mode), so you should expect that to say zero.

Uncorrected blocks is highly likely to refer to FEC errors that couldn't be corrected, rather than errors in CRC blocks. In fast mode, you'd expect that to be zero too.

So that probably won't help.

However, it does at least tell us you are running at 80/20 in fast mode, with (if I read it correctly) and SNRM of 7dB.

It looks very much like DLM has not intervened - so it doesn't see your line as having problems. That makes me swing back to the thought of congestion again, rather than line problems.

Thanks for the info. I really appreciate the input I've had here.

Things have remained great for the past few days, but since we are in the Easter break I can't really say things are permanently fine.

Hmmm. The problem returned today. Nasty. Same problem as before. Sub 6Mbit/sec download speeds, and around 10% packet loss.

BTW want a TAP3 test done, which I can't seem to do because I can't resolve test3.speedtest.btwholesale.com when logging in as speedtest@speedtest_domain

I checked and the PC I'm using to test with picked up the DNS servers that the router picked up when authenticating with the test credentials, and those IPs are not the ones the ISP uses.