Slow FTTC?

Hi all,
I took FTTC with Aquiss as they seemed to be the best option, and Martin has been very helpful with his customer service.
THis issue has apparently been refered to BT a few times, with no fault found.
However this is what i experience....
When using Usenet or a multitthreaded download i get like 4.5mb/s which is correct ( synched at full 40mbit)
However when downloading via http or browsing the web, it is incredibly slow!
Downloaded the 100mb test file from aquiss a few times and....
maximum i get is 1024kb/s which is obiously far from unacceptable!

1. Best Effort Test: -provides background information.

Download Speed
9223 Kbps

0 Kbps 38717 Kbps
Max Achievable Speed

> Download speedachieved during the test was - 9223 Kbps
For your connection, the acceptable range of speedsis 12000-38717 Kbps .
Additional Information:
IP Profile for your line is -38717 Kbps

This is the BT Speedtester,
And
http://www.thinkbroadband.com/ping/share/84f12e225ed...

Thats Thinkbroadband Quality meter, which shows some loss at the top.

I was browsing via my 3 dongle earlier, and this is faster web browsing than my 40mbit connection!




I was wondering what suggestions or ideas anyone has here?
My thoughts maybe a long a faulty OR modem or faulty pair?
Cheers

Couple of obvious ones, are you connected via wifi or cable, and is the router giga or fast Ethernet (if fast Ethernet any other machines connected to same router?)
What is the OS of the machine? as it looks like multi threaded is OK but single thread can't run that fast, have you looked at the firmware of the router (what make/model?)
If running XP have you checked rWIN?

Thanks for the response.
Mixture of wired and wireless, same on either.
Router is 100mbit, buffalo whr300 v2, running ddwrt firmware, several machines connected to router, wired and wireless.
All pcs are windows 7, i have the same issue on my ipad and my htc desire
Cheers

i had a similar problem but it actually turned out to be windows took my 1gb ethernet cable down to 10mb make sure that this is not happening i would also check your router settings as my buffalo sometimes plays up as well

mentions the full 40mbit from usenet, so it's not the network connections in the home.

In reply to a post by eddie1150:

Download Speed
9223 Kbps

0 Kbps 38717 Kbps
Max Achievable Speed

> Download speedachieved during the test was - 9223 Kbps
For your connection, the acceptable range of speedsis 12000-38717 Kbps .
Additional Information:
IP Profile for your line is -38717 Kbps

Your download bar on the speed test was red, as you got less than the minimum acceptable speed. This should confirm it as a fault to BTO and your ISP should be over them like a rash to fix it.

Good luck.

DrT

Is it time-of-day related? If so, is it Entanet-based? Does it happen with the native firmware in the Buffalo, as someone with the gig-ethernet Buffalo which apparently comes pre-installed with DD-WRT had trouble until they flashed it to native?

Just to clarify, looking at your opening post as a whole, would I be right in thinking

When using Usenet or a multitthreaded download i get like 4.5mb/s ...
Downloaded the 100mb test file from aquiss a few times and maximum i get is 1024kb/s

all refer to Bytes not bits. There is a difference of a factor of 8! Though even as bytes, it is slow I agree - but within the possibilities of ISP congestion. Hence my query as to the underlying ISP. What does speedtest.net say the ISP is?

In reply to a post by RobertoS:

Hence my query as to the underlying ISP.

The customer is with ourselves. Reports have been from all times of the day and even when the network is not busy.

We were leaning towards the router at the start, however customer has reported that they have tested directly from the OR modem and report similar issues.

The fact he is getting correct speeds with multi threaded downloads but poor speed on single thread, does scream out to be network related and to the router, but connected directly on Win 7 could point to the modem, we have had a few of these with all sorts of odd ball issues, of course BT won't admit to any issues with the modems!

In reply to a post by vivaciti:

of course BT won't admit to any issues with the modems!

Unless they start smouldering like the Huawei VDSL modems...

In reply to a post by izools:

In reply to a post by vivaciti:

of course BT won't admit to any issues with the modems!

Unless they start smouldering like the Huawei VDSL modems...

????

LIKE?

The BT modems are Huawei !

In reply to a post by MHC:

In reply to a post by izools:

In reply to a post by vivaciti:

of course BT won't admit to any issues with the modems!

Unless they start smouldering like the Huawei VDSL modems...

????

LIKE?

The BT modems are Huawei !

That's what I mean... There have been one or two reports on these boards of the modem actually overheating to the point of smouldering...

The 'secret' seems to be making sure they are mounted on the wall - not left freestanding. The engineer that did mine said they were under instruction now to always fit to the wall. Mine is wall hung and after two weeks continuous use remains as cool as the proverbial cucumber..........

Not time of day related, and yes enta based.
Also happened with buffalo firmware.
sorry
the 100mb file is megabytes
the speeds are in Bits!


Just run another BT speedtest as martin said BT needed test 3 which i didnt run before, and for the first time ever its come back green, however at 12,500mbit, which is only just over and to me still not acceptable for a 40mbit connection!
So i will run again tomorrow, pretty much guarantee its red, and complete test 3 so it can be passed to BT!

I've sometimes seen some text in the top panel of the BT Speedtester telling me it was working with 16 threads... so don't assume that BT's speedtester is only single-threaded. On the other hand, I've only seen those messages related to upload, and usually just before the result comes back around 4Mbps instead of the usual 8Mbps.

When I had FTTC first installed, I got some strange results from some of my machines. Reasons included:
- On Windows 7: A bad plugin in Firefox kept the limit to 10Mbps for flash-based testers. (Plugin was Firebug)
- On Windows XP: Use of Wireless G restricted speed to 20Mbps.
- On Linux: Old version of Fedora (probably old Perl version, or old LWP version) limited speed to 16Mbps.

So it is worth trying other browsers, other versions of software, and maybe even a different OS - at least temporarily.

When DLM started monitoring my line, I was getting full sync speed (and no interleaving), but 4% packet loss for the first 48 hours (as seen on a BQM). DLM cut in, and first added interleaving (solving the packet loss), then cut the sync speed by 4Mbps.

Strangely, download speeds only dropped by 1Mbps at the same time... suggesting that the packet loss was having a larger effect on throughput than at first appeared.

In reply to a post by WWWombat:

I've sometimes seen some text in the top panel of the BT Speedtester telling me it was working with 16 threads... so don't assume that BT's speedtester is only single-threaded. On the other hand, I've only seen those messages related to upload, and usually just before the result comes back around 4Mbps instead of the usual 8Mbps.

Those 16 threads are for the download- my previous router (Airport Extreme) logged the amount downloaded for each thread.

suggesting that the packet loss was having a larger effect on throughput than at first appeared.

In extreme cases, 10% packet loss can reduce TCP throughput by as much as 90%!

TCP windowing means that a small amount of packet loss has a disproportionate effect. If a transmitted packet is lost it will be re-sent along with every packet that had been sent after it. This retransmission causes the overall throughput of the connection to drop. The TCP window size is reduced in response to packet loss, reducing the number of packets that need to be resent each time at the expense of efficiency.

In extreme cases, 10% packet loss can reduce TCP throughput by as much as 90%!

TCP windowing means that a small amount of packet loss has a disproportionate effect. If a transmitted packet is lost it will be re-sent along with every packet that had been sent after it. This retransmission causes the overall throughput of the connection to drop. The TCP window size is reduced in response to packet loss, reducing the number of packets that need to be resent each time at the expense of efficiency.

Sort of.

TCP has selective acknowledgement (RFC2018), this is implemented in Windows XP and up (not sure about previous versions) and linux beyond about 2.2 kernels. So retransmission of every packet after the one which was dropped is not required in modern network stacks.

Otherwise you are correct in that excessive packet loss will shrink the send window - this is on the assumption that the main cause of packet loss is congestion and limiting the data in flight will throttle the transmit rate down to that which can be supported without packet loss.

The trouble is that if you send too quickly into a congested network and then back off when you realise packets are being dropped the window and transmit rate will settle down to appropriate values - if you send into a network which looses a fixed percentage of packets all the time than the algorithm will just go on thinking that it must be sending too quickly and keep on shrinking the window forever (until it stalls completely)!

Im still really unhappy with my speeds
Was reading a thread on here and someone was saying they should get 38000kbs throughput on the tbb test...
mine is
Speed Down 6312.33 Kbps ( 6.2 Mbps )
Speed Up 8111.67 Kbps ( 7.9 Mbps )
which for a 40mbit sync isnt right :/
Although annoyingly i cant get the BT speedtest to go read anymore, its hovering around 14mbit now...
What can i do?

Sorry to hear about your speed woes but you're on an entanet reseller service where you're competing for bandwidth and resources, your interconnect node could be over subscribed, no one buying an FTTC service should assume they will get the full throughput of their line unless they buy a L2TP business connection which aren't as badly affected by the rush to download when off peak starts.

Morning Edward,

I've been checking out your line since 5.30am this morning. Your node at time of report here was operating at 23% capacity, so plenty of available bandwidth. I have therefore gone and got your VP checked, BT are reporting this to be red, which highlights that BT could be having local capacity issues in busy times in your area. We have seen alot more VP issues since BT Retail made their product unlimited.

In reply to a post by aquiss:

We have seen alot more VP issues since BT Retail made their product unlimited.

How very strange . Along with an exodus from Sky and O2/BE LLU to Infinity. Who would have thought that could happen!

Edited by RobertoS (Fri 15-Jul-11 08:43:24)

When you get slow speeds, check out noc entanet node to see what you node capacity is.

EDIT: just seen Martin's reply about a red vp, but keep the link as a reference.

The Thinkbroadband speedtest is and has been ropey for me for a long time on both of my FTTC isp's though, always giving me slow speed result, however all other speed tests performed on the various sites out there and on downloads show the maximum speed for me.

Edited by deleted (Fri 15-Jul-11 09:28:57)

Martin,
Thanks for this, what does this mean and what can be done about it?
Last night i got a reasonably good result on TBB speed test
and a brilliant one on speedtest.aquiss.net (38mb/8mb) which is brilliant for me, just done one now and its 1mb down\1mb up which obiously isnt any good!
I have looked at the NOC status a few times, and doesnt seem to be full most of the time ( providing im connected to Leeds)
Cheers
Eddie

VP = Virtual Path, and is something to do with the internal links in the exchange before your link gets from the MSAN onto the backhaul proper, I think. It doesn't affect all connections as there are several VPs at an exchange.

It's an exchange upgrade needed. It may show up on this checker, and there is a similar one here, as how up to date these things are varies.

Cheers.
Both checkers say green so unsure?
Cheers

And forgive me if im been stupid, but would this now be cab based instead of exchange based? since the cab is now basically the mini exchange.

Green means you can't be sure, unless there is a recent "Last updated" date.

From your FTTC cabinet DSLAM there is an ethernet handover to your (wholesale) provider at the exchange. As I understand it that goes into an MSAN, and from there to the main backhaul. I think VPs are the link from the MSANs to the main backhaul, but could very well be corrected about that by more knowledgeable people. Even if I'm wrong in that detail, I'm sure they are the other side of the MSAN from you but within the exchange.

This might be of interest:
http://technet.microsoft.com/en-us/library/cc978149....

Hey? That link is good, as you say, but surely the Virtual Path and Virtual Channel labels on the diagram are the wrong way round? All the text indicates this.

Doh! Good point.

Mind you, it's Microsft Technet ........... (pity we can't do a drooping curve). Though?

Technet .......
               ......
                     .....
                          ....
                             ...
                               ..
                                 .
                                  .
                                  .

In reply to a post by RobertoS:

Mind you, it's Microsft Technet ........... (pity we can't do a drooping curve). Though?

A pretty good resource given its all free. Other companies require subscriptions to read this sort of detail. Shame about the pic, but comms is not a core technology for them.

(edit - fix broken quote)

Edited by jchamier (Mon 18-Jul-11 19:01:42)

Yeah .... Was meant as a joke really. Technet is excellent.

Shame about that diagram. Also a shame there isn't a "report a problem" link on the site :/