video stream buffering

hi

i have a problem with my FTTC where using sky go or iplayer will result in either buffering in iplayers case or loss of connection to sky go

my connection speeds are 68/18 and speed tests are always at 64/18

i know sky say they cant guarantee their services on other platforms but the complete loss seems over the top if it is sky's doing

any suggestions?

i am now on BT Fibre 2

Using which device over which type of connection to your router?

To add to that, Wi-Fi interference locally can be an issue so the suggestion is to use a PC with an Ethernet cable to rule that out as the issue.

Another can be that speed tests will give nice numbers but the throughput graph can show hints of what your problem is, one reason why the graphs are stored in our test we run at http://www.thinkbroadband.com/speedtest so run that and post the results link, ideal world the line should rise rapidly to a horizontal position just below your connection speed, but if wobbling up and down it may indicate variable speeds on the connection.

hi there thanks for the responses i am using an Ethernet connection to the HH5

speed test results...

main speed test

Alternate speed test

the actual connection speeds are a bit poor considering i am right next to the cabinets and my attenuation is only 6.8


1. Product Name: HomeHub5
2. Serial number: +076284+1506004047
3. Firmware version: v0.07.03.0814-BT (Type B) Last updated [Unknown]
4. Board version: 01
5. VDSL uptime: 2 days, 01:17:50
6. Data Rate: 20000 / 67437
7. Maximum Data Rate: 26742 / 67787
8. Noise Margin: 9.6 / 6.3
9. Line Attenuation: 0.0 / 6.8
10. Signal Attenuation: 0.0 / 0.0
11. Data sent/received: 484.9 MB / 8.2 GB
12. Broadband username: [email protected]
13. BT Wi-fi: Yes
14. 2.4GHz wireless network/SSID: BTHub5-5M8Z
15. 2.4GHz wireless connections: Enabled (802.11 b/g/n (up to 144 Mb/s))
16. 2.4GHz wireless security: WPA2 Only (Recommended)
17. 2.4GHz wireless channel: 7
18. 5GHz wireless network/SSID: BTHub5-5M8Z
19. 5GHz wireless connections: Enabled (802.11 a/n/ac (up to 1300 Mb/s))
20. 5GHz wireless security: WPA2 Only (Recommended)
21. 5GHz wireless channel: Automatic (Smart Wireless)
22. Firewall: Default
23. MAC Address: 4c:09:d4:cd:e6:9b
24. Software variant: -
25. Boot loader: 0.5.0-BT (Tue Jun 17 18:52:56 2014)

You may have a low level of attenuation, however there are pointers that your actual noise level is high. That is what is pushing your speed down.

Do you get the same problem if streaming during a weekday, not in the evenings or at weekends? If you don't it may be due to congestion.

But even so that is a darned good speed test in terms of its quality anyway, with no suggestion as to why there might be video buffering

The second one is, the first not so. A delay before ramping up and the upstreaam oddity.

As you say, no suggestion why there is buffering. These oddities happen - if I try to watch some on demand services on any of three PCs, it starts buffering after about 40 seconds before the router falls over! at the third attempt it might work. Whereas if I use the Smart TV, it will work straight away. Just one of these hard to explain anomalies.

In reply to a post by Ianph:

hi there thanks for the responses i am using an Ethernet connection to the HH5

speed test results...

main speed test

Alternate speed test

the actual connection speeds are a bit poor considering i am right next to the cabinets and my attenuation is only 6.8


1. Product Name: HomeHub5
2. Serial number: +076284+1506004047
3. Firmware version: v0.07.03.0814-BT (Type B) Last updated [Unknown]
4. Board version: 01
5. VDSL uptime: 2 days, 01:17:50
6. Data Rate: 20000 / 67437
7. Maximum Data Rate: 26742 / 67787
8. Noise Margin: 9.6 / 6.3
9. Line Attenuation: 0.0 / 6.8

Yes, your speed does seem low for your attenuation. Perhaps you have some aluminium cables to the cabinet?

I notice your have a HH5 Type B which is good on a Huawei cabinet but maybe you are connected to an ECI cabinet, which means you won't get G.INP ?

In reply to a post by MHC:

The second one is, the first not so. A delay before ramping up and the upstreaam oddity.

As you say, no suggestion why there is buffering. These oddities happen - if I try to watch some on demand services on any of three PCs, it starts buffering after about 40 seconds before the router falls over! at the third attempt it might work. Whereas if I use the Smart TV, it will work straight away. Just one of these hard to explain anomalies.

My speed test results using the htlm5 test differ depending on the browser i use, firefox performs poorly compared to opera, both have a delay on the ds, i don't see any buffering issues with I player with smart tv or pc, i don't have sky go, so can't test that

In reply to a post by rogerfp:

Do you get the same problem if streaming during a weekday, not in the evenings or at weekends? If you don't it may be due to congestion.

i get the issues at anytime of the day and always the same

i do believe there is some aluminium in this area but i cannot say for sure the only over ground wire is the drop wire which is about 10 meters and then about 5 or 6 meters underground to the cabinet and my fttc cab is an eci 1

i do have an eci openreach modem in the cupboard. is it possible to connect that before the router like on my old talk talk connection?

the talktalk fibre ran at 80/20 for over a year then i went to sky 40/10 and now to BT

Edited by deleted (Fri 13-Nov-15 16:08:13)

Yes, connect LAN1 on the modem to red WAN on the Homehub.

In reply to a post by Ianph:

the talktalk fibre ran at 80/20 for over a year then i went to sky 40/10 and now to BT

Bet you wish you'd stuck with TalkTalk now.

The presence of aluminium should be evident in the attenuation figure; which at 6.8dB appears very low; suggesting the problem isn't that.

Maybe fit the ECI, and use a PC to create the ppp session; to eliminate the router as the problem.

In reply to a post by edwincluck:

The presence of aluminium should be evident in the attenuation figure; which at 6.8dB appears very low; suggesting the problem isn't that.

And the problem would have been there on TT.

Quite. But since it's not aluminium in the local loop, and it's not a faulty router (to be determined), then the finger of suspicion points at the ISP -- BT Broadband.

The ISP doesn't control the sync speed.

If aluminium cable was causing high attenuation then that would have been reflected in a high attenuation figure. Aluminium isn't some sort of secret monster gobbling up megabits without being reflected in attenuation figures.

I suspect it's probably a problem with noise.

Aluminium increases noise rather than attenuation.

The joints cause the noise problem, as a cable it has a higher attenuation per km compared to copper though, this is largely not an issue at voice frequencies but as you increase the frequency the signal does not travel as far in the cable.

Aluminium cable is thicker than copper to improve the attenuation.

thank you i will give that a try a bit later after the wife drags me shopping

i have not seen any other issues with the router but can maybe try connectify for the wife and daughters wi-fi access

they only use a phone and a tesco hudl2 which does not affect the speed tests

Yes but past experience with people on known Al lines showed high loop loss than copper

In reply to a post by MrSaffron:

Yes but past experience with people on known Al lines showed high loop loss than copper

It's a pity there's no way to quantify that to be able to determine whether aluminium is present or not.

In reply to a post by BatBoy:

The ISP doesn't control the sync speed.

I never said it did. This complaint is about "video stream buffering". Indicative of an issue with packet loss or delay. Since the aggrieved has a reasonably high sync rate (~65Mbps) it's unlikely that bandwidth - between the MSAN and the CPE - is the issue.

P.S. it would be interesting to read some evidence that aluminium pairs suffer more from noise than copper pairs. What sort of noise? Inductive noise? Noise from semi-conducting corroded joints? A quick google search unearthed nothing on the subject.

However it's common knowledge that signal attenuation is higher in aluminium, than in copper wire of the same gauge, due to higher resistive loss in aluminium. And of course with higher attenuation, there will poorer signal propagation, especially at higher frequencies, causing a lower signal-noise ratio across the subcarriers. But that lower SNR wouldn't in itself cause stuttering and video stream buffering.

As usual the fact that BT has locked down its CPE preventing us from examining our line statistics, including error rates, as they clock up - means we're all stabbing in the dark for answers. Which is just the way BT likes it. Information is power, and locking-down CPE devices is a way of dis-empowering the end-user, leaving them ignorant and unable to prove the cause of a fault.

Edited by deleted (Sat 14-Nov-15 20:45:55)

In reply to a post by edwincluck:

In reply to a post by BatBoy:

The ISP doesn't control the sync speed.

I never said it did. This complaint is about "video stream buffering". Indicative of an issue with packet loss or delay. Since the aggrieved has a reasonably high sync rate (~65Mbps) it's unlikely that bandwidth - between the MSAN and the CPE - is the issue.

P.S. it would be interesting to read some evidence that aluminium pairs suffer more from noise than copper pairs. What sort of noise? Inductive noise? Noise from semi-conducting corroded joints? A quick google search unearthed nothing on the subject.

However it's common knowledge that signal attenuation is higher in aluminium, than in copper wire of the same gauge, due to higher resistive loss in aluminium. And of course with higher attenuation, there will poorer signal propagation, especially at higher frequencies, causing a lower signal-noise ratio across the subcarriers. But that lower SNR wouldn't in itself cause stuttering and video stream buffering.

As usual the fact that BT has locked down its CPE preventing us from examining our line statistics, including error rates, as they clock up - means we're all stabbing in the dark for answers. Which is just the way BT likes it. Information is power, and locking-down CPE devices is a way of dis-empowering the end-user, leaving them ignorant and unable to prove the cause of a fault.

get a Huawei HG612 flash it's firmware with an unlocked version and you get all the line stats, or buy a billion 8800nl