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.