Daytime problems

I am on an Unlimited FTTC product from an ISP that I'd rather not name.
My exchange isn't 21CN.

During the evening, I get a solid 75Mbit/s or over on every download speed test I've tried.

Here's an example wholesale speed test result from just now:

Download speed achieved during the test was - 77.77 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

Upload speed is about 13Mbit/sec and does not slow during the day -- it is pretty constant (IP Profile is 20Mbps according to the BT wholesale test)


Here's the problem:
During the day, from around 10am to 5pm, speeds plummet, down to 2 or 3Mbit/sec at times, though today it has been more like 30Mbit/sec.

I don't care about these slowdowns really. What I do care about is what seems to packet loss or at least a latency increase at the same time as things slow down. When using ssh my connection is laggy. VoIP is usable but only just, with nasty juddery audio. Using MTR I see packet loss on every single hop, right after the router.

The TBB BQM typically looks like this:

example loss

My ISP (who are a BT wholesale customer) says there is no problem on their network and there are no issues on my line. They are blaming my equipment.

Is my problem likely to be congestion somewhere? I'd love some expert opinions on this.

It is highly unlikely to be electrical interference - we are in a residential neighbourhood with no industrial anything anywhere near, and not anywhere near the path the phone line takes to the cabinet.

Besides, the upload is unaffected, and although I appreciate it uses different frequencies to the download, they aren't that different, are they? I mean it would have to be something pumping out noise at a very specific frequency to affect only download and not upload?

If congestion the tbbx1 speed test line will wobble around, but the HTTPx6 should be a lot better

Thanks Andrew.

Here's one I did a while ago when it was quite bad:

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

It kind of wobbles

Here's another not good one:
http://www.thinkbroadband.com/speedtest/results.html...

And this is what it looks like at a weekend (same in the evenings or mornings)

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

So, evenings, weekends and mornings are normally OK?

Which exchange are you on?

Do you have a TBB ping monitor running, that may help to show what's going on, also an unlocked HG612 modem to get stats from.

Similar experiences have been mentioned on here before. Just because you're in a residential area doesn't mean that there won't be any electrical or radio noise.

Looks most likely to be congestion.

I have seen a similar effect sometimes in the prelude to the recent BT Wholesale congestion issues.

There's a link to the BQM in my first post showing the issues. Yes, evenings, weekends are fine. Just working hours sort of thing that's the problem.

I forgot to mention that I'm an EBE connection as well

It is a small exchange in north wales - roughly 4000 lines according to samknows.

I'm peripherally aware of the BT Wholesale congestion issues - but don't remember the details? Has it been resolved?

As Mr S says, it looks like congestion.

However, I wonder if there is a nearby small trading estate or factory which may be creating a lot of electrical noise during working hours?

People have stopped complaining so looks likely.

If the peak is in the 3 to 5pm area, then its likely that ISP has a high small home business and kids returning from school at making it their peak time. For the more residential Sky/TalkTalk peak tends to climb until midnight.

If I remember correctly, the issues continue on bank holidays, even though nothing much closes.

I found the article I was thinking about regarding congestion, I presume? http://www.thinkbroadband.com/news/6360-no-sign-yet-... -- I had been searching the forums and found nothing except my own post

But wouldn't we expect that to affect peak times (e.g. evenings) rather than working hours?

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.

Which of your neighbours went away for Easter and have just returned?

None that I know of

But I think we've pretty much eliminated interference and are homing in on congestion somewhere.

The BQMs from today show huge loss on my connection, some but much less loss on another connection (same exchange, same ISP), no loss on a heavily used BT Retail connection on the same exchange, and no loss on a connection on the same ISP but a different exchange

I've sent you a PM. (Flashing envelope in the menu bar).

thanks. I've replied.

You're not on one of the exchanges listed here are you? It's a Plusnet page but relates to exchanges in general.

Nope. Unfortunately not.

And we have, unfortunately, reached the end of the line.

BTW has punted the fault back twice, once because the TAP3 couldn't be run (and I don't see how it can be run if you can't resolve the test domain), and once again after that saying no fault found. The only option is therefore an SFI.

I just don't see what good an SFI would do.

I just wish I could do a TAP3. If I could do that then we'd know the issue is totally unrelated to the ISP and we could just get on with it.

Has anyone ever managed to do a TAP3? BTW obviously expect people to be able to run it, but their DNS servers timeout totally when trying to resolve the test domain when using the speedtest@speedtest_domain username so I just don't see how it is possible.

correction - our area code is one of the ones shown under the Manchester entry. But I see that a lot, and it has never had any effect on us at all. Also it is listed as being the 19th and this started on the 7th.

Still, it could be successive faults, couldn't it? Mind you, BTW didn't pick it up as being a potential issue - wasn't mentioned when they punted fault back to ISP.

OK I've been put on a superstable profile which by my thinking should do no good whatsoever. Except today things have been great. Minimal loss, and 79Mbit downloads all day.

But since I've seen good days in the past I'm not counting my chickens. The very high download speed is encouraging though.

If you have shifted profile, then it is likely they have reset DLM; you aren't likely to see any changes until 2 days time.

Remember to keep copies of those "status" numbers over the next few days, so we have something to compare.

I agree though... I'm not sure it will fix things.

Supposedly it had happened by the time I tested on that day.

Anyway, it has been as smooth as I'd ever want on Thursday and today.


By status, do you mean the modem status?

Nothing has changed:

Text
1 23 4	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

In reply to a post by sfo32:

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

Why not look up the IP when connected normally, then put that into your hosts file? Then it'll maybe work on the test connection - unless that uses an internal IP, of course

I will try it - great idea - but that assumes the IP is exclusive to the test site ( which is likely but not guaranteed),

But the thing is that I shouldn't need to do that. Something is fundamentally wrong with the way the DNS and IP addresses are being allocated when using the speedtest credentials. Google indicates a number of other people complaining about the same thing, but it obviously works most of the time for most people otherwise BTW would have noticed by now

At any rate everything has remained 100% perfect since last week, with 75+/17+ speed tests with very few wobbles in the lines in most of the charts, and no noticeable packet loss.

I'm crossing everything I can cross that it will remain this way. I would find it very annoying not to know what the problem was though.