|
|
A recent change to Sky fibre has turned into a bit of a nightmare. I moved my mum over a couple of weeks ago. I've been monitoring the connection and it's appalling. I believe there is peak time congestion at the exchange.
There seems to be a lot of feedback on the Sky forums regarding congestion.
I'm interested to hear from anyone else on the same exchange (Kenton) - http://www.samknows.com/broadband/exchange/NEK or other exchanges who believe they're seeing peak time congestion.
I've had SmokePing running on my mums connection, results here https://www.dropbox.com/sh/mlk2o2fb125ip84/wVCkRUKwNl - I'd like to SmokePing connections of others who think they're having congestion too - will be useful in my fight with Sky.
|
|
|
|
when I changed to Sky fibre this time last year, the service was appalling, it took them around 8 weeks to resolve. it was purely down to congestion at the exchange!
I did get around £100 back as compensation.
register your complaint with Sky and when its sorted you can ask for money back, I know this does not make up for the terrible service inbetween!
|
|
|
|
I've seen this problem before back when I was with O2. It took a long time for the capacity to be upgraded. So long infact I switched to Plus Net on a 3 month contract then switched back to O2 as that gave them enough time to fix the issue.
Sky might be reliant on Openreach to upgraded Sky's Ethernet Backhaul Direct service in your exchange. Or Sky could be waiting on a new service delivered as part of their new contract with Virgin Media. Either way it can take 3-6 months from order for the upgrade to actually happen ... yes Openreach can be that slow!
Part of the slowness I suspect is simply down to Openreach ensuring BT retail has the upper hand on its competitors.
This assumes it's a problem with Sky's capacity in the exchange. it could be the GEA cable link (also in the exchange between Sky's rack and backhaul to Openreach's fibre switch that connects all cabinets served by the exchange). Or it might be congestion on the fibre to your individual cabinet. If either of these reasons then ADSL2+ services won't be affected.
Really you need to see ping graphs for a mix of ISP's and cabinets served by the same cabinet as you.
It's far easier for people to set-up a think broadband graph and share this.
See mine for my Sky Fibre at Canterbury in my signature below. The spikes in ping are my SamKnows box testing the line.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Part of the slowness I suspect is simply down to Openreach ensuring BT retail has the upper hand on its competitors.
Openreach have absolute no way of favouring BT Retail over all competitors, they can only favour BT Wholesale over the LLU operators, which they don't.
BTWholesale and LLU operators can use the same EAD product set now. Before they used WES and BES respectively but it's the same product set now if they choose to, and the older products are only available in 2.5Gb and 10Gb flavours and carry some disadvantages over the EAD product set.
|
|
|
Thanks for the feedback so far.
I've set up a TBB Ping monitor now (I didn't think I could on a dynamic IP, turns out it works on Sky ones!) It can be seen here http://www.thinkbroadband.com/ping/share/2dd6943fa6f... It's not a pretty sight.
I've already placed an order to move to Plusnet, the fun I'm looking forward to (not) is getting a nice final bill from Sky - thankfully I've informed them of cancellation within 8 working days of the service going live, so, it shouldn't be tooo painful. There is the minor issue that the ADSL contract before moving to VDSL (all with Sky) hadn't run it's course. I'm far from happy. I live far away and it's a logistical challenge doing ISP swaps!
|
|
|
Yeah that confirms what you are seeing with Smoke Ping.
All that matters is the router responds to ping on the WAN interface which it seems to. The default for Sky routers is to not respond but there is the option to enable.
However if your IP changes that the monitor will stop working or start graphing someone else's connection.
Sky can't hold you to the contract if the service is not fit for purpose (as described when sold). Good luck getting them to accept that without having to take it to The Ombudsman Services.
|
|
|
All that matters is the router responds to ping on the WAN interface which it seems to. The default for Sky routers is to not respond but there is the option to enable.
Cheers, the big scary message of "We have detected that your IP address (x.x.x.x) is dynamic.
We do not currently support monitoring of dynamic addresses." has previously had me think that it was not possible to set them up, turns out it is.
Interestingly the SR102 is responding to ping without any adjustment. I also pinged 5 IP addresses higher than the one I'm monitoring, all responded to ping.
Sky can't hold you to the contract if the service is not fit for purpose (as described when sold). Good luck getting them to accept that without having to take it to The Ombudsman Services.
Yeah, should be fun - I need the luck, so far all I've had are two template emails saying I can't cancel until December 2014.
|
|
|
when I had a congestion problems this time last year, sky were happy for me to leave without any fuss, however I couldn't leave at that time as it would have meant losing my phone number etc...
all sorted now though and on my way to BT
good luck
|
|
|
With the 12 month contract with Openreach on FTTC they will be less likely to let people leave penalty free unless there is something very obviously broken.
the joy of congestion is that an ISP may upscale backhaul for the holiday period and then see it under used for the next 12 months.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
The thing is though you don't know where the headend is for the fibre cabinets in Kenton (where they are actually physically connected to). It might well be inside a different exchange. So if someone on Sky ADSL in Kenton tells you they are experiencing slowdown at peak time, that information may be completely irrelevant to you.
|
|
|
|
Hi Sean,
I too am having major backhaul congestion problems on Sky Fibre at NEK exchange...especially since Xmas.
Absolutely terrible tonight...10% packet loss, response times are 2000ms plus.
|
|
|
|
When we had congestion issues at the Hastings exchange it was sorted out within 3 months. It would have been sooner except Alcatel-Lucent, who manage Sky's network, kept putting the date back due to resourcing problems.
|
|
|
|
Ended up at 80% packet loss last night.
Absolutely ridiculous.
|
|
|
Thanks for the additional feedback from everyone.
Good to find someone on the same exchange with the same issue!
It does seem that ADSL via Sky preforms OK, just VDSL doesn't - I suspect the backhaul for VDSL is awful while ADSL is fine. VDSL is pretty new to this exchange I think.
Here's 10 days of SmokePing https://www.dropbox.com/s/z6uan3ubhvm98ds/10%20Days.png - it is the case that last night was the worst in the last 10 days.
It does appear normal from what I've seen on a number of online forums - that it takes Sky around 3 months to resolve these issues. It's not really good enough, they need to better manage their networks.
The fact they push hard on advertising they don't do any traffic management - I think that's wrong, I'd prefer to be traffic managed and have critical things like VoIP and streaming media to work and non time critical things to take longer.
The switch to anther provider will be happening in 3 days, shall be interesting to see how that works out!
|
|
|
|
How are you managing to switch to another provider...? I assume you are within contract? I'm wanting to do this as well but hitting a brick wall currently!
|
|
|
|
The connection has been a ADSL connection for a while, I put in a request to swap to VDSL just before Christmas. Very soon I observed the connection was not fit for purpose.
I emailed Sky within 8 working days notifying them I was cancelling. Their T&C's show that you can cancel within 8 days... I've since had emails back from them stating I can't cancel and to contact them again in 12 months. Well, NO! After my initial contact with them had me very angry, I just proceeded with ordering service with another provider on the line which is to take over the service in a few days.
I'll then continue my battle with their complaints department / ombudsman / Ofcom.
|
|
|
Damn - I'm well past the 8 days
|
|
|
 How have your dealings with their support team gone so far? Have they admitted there is a problem?
If you wish to PM me your IP I can set up smokeping on your connection to observe how it compares to mine.
I'd also suggest you set up monitoring here http://www.thinkbroadband.com/ping
It should hopefully be helpful for you to have graphs showing the problematic service, when helping to convince Sky.
|
|
|
To be honest up to now I've avoided contacting them - I'm using a non-sky router at present, and not wanting to swap back just to ring them. I've emailed them today and will see what comes...
I PMd you a little earlier
|
|
|
|
I wish you lots of luck with regards to getting a useful response from them.
Hmm. the PM hasn't made it to my unfortunately.
|
|
|
|
|
|
|
|
Ah! Thanks. Good to see it's going to be fixed. It's outrageous and unacceptable that Sky think it's OK for connections to be very slow and unusable for time critical applications during peak times, for weeks or months at a time.
I dispute their product advertising of "And we'll never slow you down". Their lack of network management does indeed result in being slowed down at peak times!
|
|
|
Their lack of network management does indeed result in being slowed down at peak times!
In the vast majority of exchanges where Sky LLU is not congested, network management is not needed on Sky Broadband.
I for one am quite happy Sky has no network management, perhaps a view Plusnet users will find exception with.
Oliver.
|
|
|
|
That's not really strictly true. I'm a network engineer by trade, and just because there is bandwidth available doesn't mean its not good practice to traffic manage. Moreover, not a single exchange will be "uncongested" - they are all contended services, so by definition there will be congestion - it's a very cost prohibitive model to run without congestion/contention. It's a matter of relative nature of congestion, whereby its not noticed or it is noticed.
That said, on a shared medium of different customers, especially domestic customers, wants and needs will differ, so very difficult to traffic manage appropriately. That doesn't mean that traffic management is a bad thing, just virtually impossible to get right for such a diverse customer base.
Lets be clear - those customers on traffic managed service providers who download large amounts of data using P2P or similar will hate it - customers on the same service provider who simply web browse will get a much better service than a non traffic managed service. Its all relative.
|
|
|
All I can say is from my own experience, having been on networks with no traffic management (UK Online, O2 and now Sky) is that the lack of traffic management on these networks has caused me no trouble whatsoever, regardless of which protocol I was using. Line speed on all protocols at all times of day.
Oliver.
|
|
|
|
That will be mainly because the low bandwidth usage protocols are generally less susceptible to congestion, or are less visibile when used in a congested/contended scenario.
E.G. A download will immediately be apparent if theres congestion, as the download rate will vary - very visible. Web browsing is stateless and transactional, not real time, and there is no obvious measure visible when you generally web browse.
Theres also a big difference between traffic management and traffic limiting/policing. If you really think that large service providers don't traffic manage in some respect, you'd be very wrong. They just don't overtly ramp back traffic available to "scavenger" traffic that's all.
|
|
|
Theres also a big difference between traffic management and traffic limiting/policing. If you really think that large service providers don't traffic manage in some respect, you'd be very wrong. They just don't overtly ramp back traffic available to "scavenger" traffic that's all.
I know the difference. Are you suggesting that Sky use DPI and prioritise p2p traffic differently to http traffic in the same way that Plusnet do?
Oliver.
|
|
|
|
No, I didn't say they did it in the same way, I said that I would be absolutely shocked if Plusnet and/or other service providers do not apply traffic management across their core. and backhauls.
|
|
|
No, I didn't say they did it in the same way, I said that I would be absolutely shocked if Plusnet and/or other service providers do not apply traffic management across their core. and backhauls.
We know Plusnet use DPI with protocol prioritisation, what I am saying is that Sky don't and I'm perfectly happy with that.
Oliver.
|
|
|
|
No what you said was that "exchanges that werent congested did not need traffic management" - this is the part that I am querying. If you are happy with something or not is clearly your own personal preference!
As an aside - you are saying really that Sky don't use DPI that you know of. Again, I'd be very surprised if any kind of ISP in this day and age didn't DPI traffic. They may not do anything with it but that's a different story - especially as Sky traffic is all proxied.
Plus, DPI isn't the only way to skin a cat. I maintain my position that Sky will traffic manage to some extent. No way they will just have a free for all across their core.
|
|
|
|
Apart from anything else, if they had no traffic management in place, their dynamic routing protocols would die a death very quickly.
|
|
|
Plus, DPI isn't the only way to skin a cat. I maintain my position that Sky will traffic manage to some extent. No way they will just have a free for all across their core.
Sky publicly state they don't use traffic management, so I tend to believe that more than your hunch.
Oliver.
|
|
|
Apart from anything else, if they had no traffic management in place, their dynamic routing protocols would die a death very quickly.
There are two things here, I agree Sky will manage their network, but the words "traffic management" in the UK retail ISP world means the stuff that Plusnet do, and advertise they do. (which I and others) dislike. This is where the ISP gives traffic from the user that is voip a big priority over someone else who is downloading the latest Windows or Mac update.
However what I think you mean is at the network core and peering points they manage traffic to ensure there is no overload condition, as TCP/IP goes badly wrong when overloaded (packet loss) which most of us have seen on smaller ISPs (including BE and O2). That isn't what is meant by consumer traffic management - but is what all ISPs must do and is what network engineers in big corporates are doing as well.
James BT Infinity 2 19/09/2012 - Sold 42/6 - Getting 49/8.5 - Sync 53 / 9.5 Mbps @ 470m approx
14 years of broadband (ntl: cable to BT FTTC) - Router: Asus RT-N66U - Modem: Huawei HG612 speedtest
|
|
|
|
Agreed, and you are right they are different things. Its all a bit off topic really, as all I was really meaning to respond to was the incorrect statement that "traffic management is not needed on the majority of exchanges".
|
|
|
Its all a bit off topic really, as all I was really meaning to respond to was the incorrect statement that "traffic management is not needed on the majority of exchanges".
Don't use quotation marks unless you are going to quote me directly. I was using the word "exchanges" since that is usually the scope of congestion. And you're the only one here who isn't taking traffic management to mean DPI with protocol prioritisation and/or speed limits (which, despite your hunch, Sky don't utilise).
Oliver.
|
|
|
|
Which I just acknowledged.
Fine I'll quote: "In the vast majority of exchanges where Sky LLU is not congested, network management is not needed on Sky Broadband."
False, and against best practice.
|
|
|
|
PS - somewhat picky to whinge about using quotation marks in a paraphrased quote, when the semantics of the quote in the context of the conversation was basically identical.
|
|
|
OK Look lets bring this conversation back to something more positive and constructive rather than sniping.
My point is that any network engineer and network designer worth their salt knows that it is best practice to incorporate traffic management policies end to end, in order to get the best use of the bandwidth available and provide required services to end users (in this case domestic customers).
This is for two main reasons:
1) Bandwidth is very expensive (comparatively) so it makes more economic sense to manage existing bandwidth effectively and run close to capacity than to leave a raft of spare bandwidth available.
2) Many protocols are "greedy" and will take as much bandwidth as is available in order to fulfil a transactional request more quickly. Therefore you often see "microspikes" in bandwidth utilisation and queueing on interfaces.
Point 2 is even more important in this situation, as there is a heavy contention ratio on the backhaul due to the bandwidth on the last mile to customers. At the very least, this contention ratio is certainly not 1:1.
As such, whilst some exchanges are more congested than others, no exchanges are "uncongested" - nor, more importantly, should they be strictly speaking as this implies poor capacity management and poor economic sense from the provider. Capacity of backhauls should be running at at least 80% at times if not higher.
As an absolute minimum, traffic management is most definitely best practice to prevent one "greedy" user from causing congestion for 50/100 others - even in microspike terms. More widely, yes there is some debate as to whether this is "good" or "bad" in a domestic consumer environment. This is purely because of what is acceptable as opposed to what "should" be done, according to best practice.
This can be easily highlighted by the issues that myself and the OP are having. Were there traffic management in place, even very limited traffic management, then my internet connection would not be completely destroyed by a number of users sharing my bandwidth using high bandwidth protocols.
Traffic management is not about penalising users, its about creating a level playing field for all users and effective economic use of bandwidth.
Therefore, to come back to your point - do some users benefit from Sky not traffic managing? Absolutely. Is it "needed"? Anyone working in the industry would tell you that to guarantee even a very low level of service to your customers, the answer is a resounding yes - even on a relatively less congested exchange.
Edited by deleted (Wed 15-Jan-14 12:09:26)
|
|
|
|
A third reason is by the way (sorry, completely forgot about this), bandwidth demands tend to change much more quickly than bandwidth capacity can be changed.
|
|
|
I've said all I'm going to say on this thread, no point in repeating it. Good luck with getting your connection sorted.
Oliver.
|
|
|
You keep replying to yourself when you could just edit a previous post.
Just as an aside, if you know all this technical stuff, why did you go with Sky?
Was Eclipse Home Option 1, VM 2Mb & O2 Standard
Now Utility Warehouse (up to 16mbps) via Talk Talk
|
|
|
Yes I know - apologies!
Short answer - cost - I got a very good deal off Sky in relation to the price of the product, and I didn't do enough research on the actual product - my bad! Plus, wasn't really expecting the contention issues that I have experienced.
The benefit of the cost is that worst comes to worst, I may just pay up my contract and move on.
My professional experience is more on enterprise and carrier grade circuits - as such, whilst the actual deployments are the same or broadly similar, the last mile of domestic grade VDSL (for example) isn't really my day job. I'm more involved in MPLS type of deployments using various technologies.
Edited by deleted (Wed 15-Jan-14 12:58:06)
|
|
|
A third reason is by the way (sorry, completely forgot about this), bandwidth demands tend to change much more quickly than bandwidth capacity can be changed.
Which is a very good point - however I won't be a Plusnet customer as I don't mind *all* traffic being slowed down in an area, due to network management, but I dislike the idea that customer A's traffic (because it happens to be Skype, or iPlayer) is more valuable to the ISP than customer B's traffic (because its an Apple iOS download), when we pay the SAME money for the SAME product. (If customer B was discounted for being an inferior service, then that may appeal to some).
I suspect this is where Oliver is coming from, as we were both on O2/BE which didn't do the Plusnet type traffic management either.
James BT Infinity 2 19/09/2012 - Sold 42/6 - Getting 49/8.5 - Sync 53 / 9.5 Mbps @ 470m approx
14 years of broadband (ntl: cable to BT FTTC) - Router: Asus RT-N66U - Modem: Huawei HG612 speedtest
Edited by jchamier (Wed 15-Jan-14 19:18:55)
|
|
|
|
Some good news...
Sky are no longer providing me service on the line which I was facing this issue on. Plusnet are now providing service. There was no peak time congestion last night and the speeds are hugely improved in general too.
So, I'm happy to see that my theory was right in that the congestion was not from the PCP to exchange but was further into the Sky network.
|
|
|
|
Thanks for this sean. Having a battle with Sky currently to try and get them to release me - want to move to Zen!
|
|
|
I wish you luck
I'm not sure how Sky are going to proceed, having told me twice that I can't leave them and to contact them in 12 months instead - they're no longer providing the service as I left them anyway. I'll wait a little while to get lots of pretty graphs on Plusnet, then send them a big complaint demonstrating how their service was not fit for purpose and the solution was to leave them!
|
|
|
|
Hi Sean,
For your information...Sky have confirmed that they will release me from my contract!!
Two things:
1) Sky confirmed in writing to me that they were not providing the service that they had contracted to, and as such would release me from my contract. If you are still having issues with regards this, I have no problem in providing you with some information re: who I have been speaking to etc.
2) I'm desperately trying to decide who to use moving forward - what have your experiences of Plusnet been? Specifically asking you as you are on the same exchange!
|
|
|
|
Great news! Thank you.
I've not yet drafted my many page letter of complaint to them - Shall get that done in the near future. I'm currently waiting to see what their next move is, while getting graphs of how much better service is since leaving - that way I can show them a nice comparison.
Plusnet have been very good indeed. There was a minor screwup, which I kind of expected.
It was a fibre to fibre migration. It seems to be the case that on these the engineers don't bother turning up to the property. The issue I had is that Sky was a self install with an all in one router/modem. Plusnet required a Openreach modem. One was not supplied as the engineer didn't bother to turn up! I work in the industry and like to think I know my stuff in this area, so, I took my own Openreach modem ready for the activation day. Everything worked fine with that.
Having contacted Plusnet regarding the engineer failing to turn up - they've credited the account with the invoice I sent them for the cost of my own installation and providing the relevant hardware etc.
I'll PM you with some further info too...
|
|
|
Thats interesting - my Sky install was a seperate install, with an Openreach engineer!
Was there much downtime during the migration process for you?
Most importantly - how are the speeds/reliability since the move
|
|
|
|
The 'self install' is a pretty recent method of getting new Sky Fibre customers online.
The fact you have a modem already should assist with a smooth change over.
There wasn't any major downtime. The engineer was meant to turn up between 1pm and 6pm. I turned up myself at 12:40 and checked the line, it had already moved from Sky LLU to BTw, checking in the Sky modem showed the line speed had changed from 40/10 to 80/20 - so, I knew then the service had moved over. I didn't actually hook up the modem until a few hours later.
Speeds have been perfect, full line speeds. There's been 2 drops in the service, during the early hours. Line training I suspect.
|
|
|
|
Fantastic. Thanks - think I'll go that way then (Zen was just a bit too pricey, same with BT!).
Will let you know how I get on!
|