Many sites extremely slow/unusable (past week on eFibre)

rat_race · 28-10-2014 1:12am #1

Sites like cnn.com, bbc.co.uk, youtube.com, facebook.om are unusable. This has been going on for a week now.

Other sites like Netflix.com are fine, and of course, speedtest.net.

Tested on multiple machines, multiple browsers, and with multiple router restarts. Not a wireless problem as connected via ethernet. Eircom NS and Google NS both tested, neither help the matter.

Seems to me a major problem that many people are facing, with no update from Eircom.

Could an Eircom rep please respond?

Doodah7 · 28-10-2014 10:20am

Have to chime in on this and agree. I get 102mbs according to my router diagnostics and over 60mbs wireless from where I usually sit. Speeds for the past week or so for certain websites have been appalling where they don't load or render correctly. Speedtest.net says that everything is fine so it is certainly to do with Eircom themselves.

It took me 25 MINUTES to download a 42MB file the other day at a dizzy 26kb/s.

I want someone from Eircom to answer these issues. I also don't want to see the usual trotted out links to speed up broadband on the eircom website because it is not the solution to the problem because the problem is you NOT me...

SORT IT OUT!

looksee · 28-10-2014 10:23am

Thanks for this, I thought it was me and my new computer or something. Yes some sites very slow, including fb, others - including boards, no problem. I will be interested to hear any answers. Should add, also on efibre.

Dom1978 · 28-10-2014 10:29am

I'm in Midleton and for most of the weekend speeds have dropped from 17-18MB/s to a lowly 1-2MB/s, friends using Eircom are reporting similar stories so there seems to be a fault somewhere.

dalta5billion · 28-10-2014 10:31am

Routing your connection through a VPN actually achieves better speeds than allowing Eircom to handle it these days.

It's a joke.

rat_race · 28-10-2014 10:45am

Spoke to friends in Cork, Galway and Wicklow, and they're all experiencing the same problem.

This has affected my work, greatly.

Eircom is creating a PR disaster for itself, all they need to say is "we screwed up, and we'll fix it" -- however, I've gathered from about 10 other forums, that Eircom is just blaming the consumer (you have too many devices connected to your router), and telling others to reboot their router (pointless).

Eircom, do your job and give us an update.

major deegan · 28-10-2014 11:00am

tallpaul wrote: »

Have to chime in on this and agree. I get 102mbs according to my router diagnostics and over 60mbs wireless from where I usually sit. Speeds for the past week or so for certain websites have been appalling where they don't load or render correctly. Speedtest.net says that everything is fine so it is certainly to do with Eircom themselves.

It took me 25 MINUTES to download a 42MB file the other day at a dizzy 26kb/s.

I want someone from Eircom to answer these issues. I also don't want to see the usual trotted out links to speed up broadband on the eircom website because it is not the solution to the problem because the problem is you NOT me...

SORT IT OUT!

Sorry but dont hold your breath waiting for an explanation off the reps on here,at best they'll pass the buck and give you the famous technical assistance number. It's never Eircoms fault you know.
I've been trying for a decent service for six months now!!!
Yeah was particularly bad this weekend alright.

Stargal · 28-10-2014 11:03am

Just to add that I've had the same thing too in Rathmines in Dublin. Significant deterioration in recent days. Not on eFibre because it's not available on my road yet so it's just regular old broadband, but it's becoming unusable. Rang them about it last week but it hasn't made any difference.

rat_race · 28-10-2014 11:15am

I'm moving into a new gaf soon. Guess what broadband provider I won't be going with?

Also, a company I work for needed a second line (for a project I'm working on) -- guess who just cancelled that broadband provider, which was due to be set-up this week? We'll go with Vodafone instead.

Too many issues with Eircom. These speeds, messed up DNS (yes, Eircom can't even get DNS right -- a very simple technology, over 30 years old), and random connection drops.

Never had a single memorable issue when I was with Vodafone.

Eircom will pay heed if we start dropping our contracts.

major deegan · 28-10-2014 3:19pm

Surprise surprise, no response to the customer concerns on here..see one reply by 'tracy' on another 4 day old thread...What a waste of our hard earned money.

eircom: Tracey · 28-10-2014 5:54pm

Hi all,

I'm sorry to hear of the issues you are having with you service.

We understand your frustration with this, I have reported this thread onto our support team.

I would like to assure you that I have compiled and gathered a report highlighting the number of threads and posts on the issues surrounding slow speeds at peak times and requested that this be looked in to.

Completion of this investigation is going to take time considering the scale of the issue, we will aim to update you on the progress reported back to us here.

We understand that slow speeds and not having access to certain sites can be of a major inconvenience and cause a lot of frustration, however we cannot at this time offer more information on the posts raised here for now.

In light of the above it is still important to contact technical support on 1890 260 260 (tel number and option 0) as some seemingly similar issues may not necessarily be the same to the issues reported on this thread.

Apologies for the inconvenience that this is causing you all.

Thanks

Tracey

major deegan · 28-10-2014 6:22pm

Folks, this is the exact same computer generated response on the other eircom thread..As predicted it's the usual call the technical support number.The reason i'm on here is i have used that number till i'd be blue in the face and all to no avail,thought there might be help or advice available in this forum.No help to me to repetitively give me a useless phone number!

Dom1978 · 28-10-2014 11:41pm

I have to admit that the lack of proper response is getting frustrating, surely if this problem is effecting business customers too Eircom must be breaking SLA's?

eircom: Tracey · 29-10-2014 2:42pm

Hi All,

The last time we had these issues, we found it really helpful for customers experiencing the issues to send on trace routes. This helped us identify the issues and resolve it. If any of you would like to help us here please PM them to me.

I completely understand your frustration with this and please don't think that I am ignoring you all. All information supplied will help us identify the issue.

Thanks for your help.

Tracey

rat_race · 29-10-2014 3:25pm

eircom: Tracey wrote: »

Hi All,

The last time we had these issues, we found it really helpful for customers experiencing the issues to send on trace routes. This helped us identify the issues and resolve it. If any of you would like to help us here please PM them to me.

I completely understand your frustration with this and please don't think that I am ignoring you all. All information supplied will help us identify the issue.

Thanks for your help.

Tracey

Hi Tracey,

The problem is that a browser visiting a site like Facebook or CNN, retrieves the data from many domains (often from other domains, as instructed by the website you're visiting).

So, for a traceroute to provide effective information, the person doing it would need to know the exact location where the bottleneck occurs.

So, anyone reading this, just be aware of that. A traceroute to, for example, facebook.com, is not necessarily going to be useful information, even if that is the site which appears to be "slow".

Anyway, to get a traceroute, follow the below.

On Windows, run Command by going to Start -> Run -> and typing "cmd", or just search for "cmd", and then type:

"tracert www.thesiteyoucannotaccess.com".

On Os X or linux, load a Console and type:

"traceroute www.thesiteyoucannotaccess.com".

Copy and paste your results here.

Cheers,
Cormac

eircom: Alan · 29-10-2014 4:24pm

rat_race wrote: »

eircom: Tracey wrote: »

Hi All,

The last time we had these issues, we found it really helpful for customers experiencing the issues to send on trace routes. This helped us identify the issues and resolve it. If any of you would like to help us here please PM them to me.

I completely understand your frustration with this and please don't think that I am ignoring you all. All information supplied will help us identify the issue.

Thanks for your help.

Tracey

Hi Tracey,

The problem is that a browser visiting a site like Facebook or CNN, retrieves the data from many domains (often from other domains, as instructed by the website you're visiting).

So, for a traceroute to provide effective information, the person doing it would need to know the exact location where the bottleneck occurs.

So, anyone reading this, just be aware of that. A traceroute to, for example, facebook.com, is not necessarily going to be useful information, even if that is the site which appears to be "slow".

Anyway, to get a traceroute, follow the below.

On Windows, run Command by going to Start -> Run -> and typing "cmd", or just search for "cmd", and then type:

"tracert www.thesiteyoucannotaccess.com".

On Os X or linux, load a Console and type:

"traceroute www.thesiteyoucannotaccess.com".

Copy and paste your results here.

Cheers,
Cormac

Hi Cormac,

Thanks for the clarification on this

Al

rat_race · 29-10-2014 9:28pm

Hi Eircom,

Okay, here are some traceroutes. The first three are pointing to a site which I'm fairly certain cnn.com streams its videos from, and the speed is currently causing the site to be unusable. Note the timeout error as well as the asterisks (*), which indicates a timeout also -- and the default timeout is 4 seconds (4000 millis), which is huge.

There is clearly an infrastructural problem here.

C:\Users\Cormac>tracert cnn-f.akamaihd.net

Tracing route to a513.w23.akamai.net [92.122.48.75]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 5 ms 4 ms 26 ms 95.45.80.1
3 5 ms 6 ms 5 ms 86.43.11.33
4 5 ms 5 ms 5 ms tenge-4-1-1.core1.dbn.core.eircom.net [86.43.252.205]
5 21 ms 20 ms 21 ms 86.43.11.182
6 20 ms 20 ms 20 ms ge0-0-0.corea.thn.london.eircom.net [86.43.245.162]
7 27 ms 20 ms 20 ms xe-2-3-2.lon11.ip4.gtt.net [77.67.76.161]
8 49 ms * 53 ms xe-4-3-0.mil21.ip4.gtt.net [89.149.186.18]
9 51 ms 53 ms 51 ms a92-122-48-75.deploy.akamaitechnologies.com [92.122.48.75]

Trace complete.

C:\Users\Cormac>tracert cnn-f.akamaihd.net

Tracing route to a513.w23.akamai.net [92.122.48.89]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 7 ms 4 ms 4 ms 95.45.80.1
3 5 ms 5 ms 5 ms 86.43.11.33
4 5 ms 5 ms 5 ms tenge-4-1-1.core1.dbn.core.eircom.net [86.43.252.205]
5 * * * Request timed out.
6 20 ms 20 ms 20 ms ge0-0-0.corea.thn.london.eircom.net [86.43.245.162]
7 21 ms 21 ms 20 ms xe-2-3-2.lon11.ip4.gtt.net [77.67.76.161]
8 55 ms * 53 ms xe-4-3-0.mil21.ip4.gtt.net [89.149.186.18]
9 54 ms 53 ms 53 ms a92-122-48-89.deploy.akamaitechnologies.com [92.122.48.89]

Trace complete.

C:\Users\Cormac>tracert cnn-f.akamaihd.net

Tracing route to a513.w23.akamai.net [92.122.48.75]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 5 ms 4 ms 4 ms 95.45.80.1
3 5 ms 5 ms 5 ms 86.43.11.33
4 5 ms 5 ms 5 ms tenge-4-1-1.core1.dbn.core.eircom.net [86.43.252.205]
5 * * 20 ms 86.43.11.182
6 20 ms 20 ms 20 ms ge0-0-0.corea.thn.london.eircom.net [86.43.245.162]
7 21 ms 21 ms 21 ms xe-2-3-2.lon11.ip4.gtt.net [77.67.76.161]
8 43 ms * 42 ms xe-4-3-0.mil21.ip4.gtt.net [89.149.186.18]
9 40 ms 40 ms 39 ms a92-122-48-75.deploy.akamaitechnologies.com [92.122.48.75]

Trace complete.

Now note the next three traceroutes which are against a site that I have been suspecting has had NO routing problems, because it has worked alright for me (Netflix). Notice how it does NOT go through London? It doesn't even leave Ireland.

Absolutely no problems here:

C:\Users\Cormac>tracert 159.134.236.77

Tracing route to netflix-c01-srl.dub01.eircom.net [159.134.236.77]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 34 ms 6 ms 5 ms 95.45.80.1
3 5 ms 5 ms 5 ms 86.43.11.33
4 6 ms 5 ms 6 ms tenge-3-1-1.core1.prp.core.eircom.net [86.43.252.201]
5 7 ms 6 ms 6 ms tenge-4-1-1.core1.prp.core.eircom.net [86.43.252.89]
6 6 ms 6 ms 5 ms netflix-c01-srl.dub01.eircom.net [159.134.236.77]

Trace complete.

C:\Users\Cormac>tracert 159.134.236.77

Tracing route to netflix-c01-srl.dub01.eircom.net [159.134.236.77]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms 192.168.1.254
2 12 ms 5 ms 13 ms 95.45.80.1
3 5 ms 5 ms 5 ms 86.43.11.33
4 5 ms 5 ms 9 ms tenge-3-1-1.core1.prp.core.eircom.net [86.43.252.201]
5 6 ms 6 ms 5 ms tenge-4-1-1.core1.prp.core.eircom.net [86.43.252.89]
6 5 ms 5 ms 5 ms netflix-c01-srl.dub01.eircom.net [159.134.236.77]

Trace complete.

C:\Users\Cormac>tracert 159.134.236.77

Tracing route to netflix-c01-srl.dub01.eircom.net [159.134.236.77]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 17 ms 5 ms 68 ms 95.45.80.1
3 5 ms 5 ms 6 ms 86.43.11.33
4 10 ms 5 ms 5 ms tenge-3-1-1.core1.prp.core.eircom.net [86.43.252.201]
5 6 ms 6 ms 5 ms tenge-4-1-1.core1.prp.core.eircom.net [86.43.252.89]
6 6 ms 5 ms 5 ms netflix-c01-srl.dub01.eircom.net [159.134.236.77]

Trace complete.

Everything points to London.

major deegan · 29-10-2014 10:24pm

Now that's impressive!!! Take note Eircom...ye might learn something.

dalta5billion · 29-10-2014 10:43pm

:~$ traceroute 'r1---sn-4g57knkz.googlevideo.com'
traceroute to r1---sn-4g57knkz.googlevideo.com (173.194.48.134), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  4.269 ms  4.375 ms  4.489 ms
 2  95.45.62.1 (95.45.62.1)  239.588 ms  239.586 ms  239.973 ms
 3  86.43.11.49 (86.43.11.49)  237.238 ms  237.365 ms  237.777 ms
 4  tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205)  237.493 ms  237.636 ms  237.882 ms
 5  * * *
 6  83.71.115.181 (83.71.115.181)  239.349 ms  6.848 ms  8.999 ms
 7  74.125.51.185 (74.125.51.185)  39.997 ms  40.436 ms  40.436 ms
 8  209.85.252.196 (209.85.252.196)  9.342 ms 209.85.252.198 (209.85.252.198)  9.884 ms  10.233 ms
 9  209.85.252.28 (209.85.252.28)  21.023 ms 66.249.95.20 (66.249.95.20)  36.122 ms  36.119 ms
10  209.85.241.229 (209.85.241.229)  42.841 ms  43.253 ms 209.85.241.227 (209.85.241.227)  40.317 ms
11  72.14.234.230 (72.14.234.230)  40.831 ms 209.85.251.249 (209.85.251.249)  41.256 ms 72.14.234.230 (72.14.234.230)  55.852 ms
12  209.85.248.13 (209.85.248.13)  41.836 ms 209.85.253.245 (209.85.253.245)  69.257 ms 209.85.246.67 (209.85.246.67)  40.881 ms
13  209.85.248.107 (209.85.248.107)  43.296 ms 216.239.47.239 (216.239.47.239)  42.288 ms  42.814 ms
14  216.239.48.197 (216.239.48.197)  44.389 ms  42.809 ms  43.918 ms
15  173.194.48.134 (173.194.48.134)  42.798 ms  43.905 ms  44.360 ms

I notice that this (r1---sn-4g57knkz.googlevideo.com) was the "slow" server where Youtube requested the video fragments from.

When I refreshed, a different server was used, which was a lot faster at serving the fragments. Here is its traceroute:

traceroute 'r5---sn-cg07luel.googlevideo.com'
traceroute to r5---sn-cg07luel.googlevideo.com (74.125.216.52), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  4.334 ms  4.380 ms  4.499 ms
 2  95.45.62.1 (95.45.62.1)  6.657 ms  8.242 ms  8.244 ms
 3  86.43.11.49 (86.43.11.49)  8.455 ms  8.577 ms  8.699 ms
 4  tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205)  8.822 ms  9.511 ms  9.617 ms
 5  * * *
 6  83.71.115.181 (83.71.115.181)  9.808 ms  6.952 ms  6.933 ms
 7  * * *
 8  209.85.252.196 (209.85.252.196)  7.425 ms 209.85.252.198 (209.85.252.198)  8.282 ms  8.284 ms
 9  209.85.250.217 (209.85.250.217)  17.071 ms  17.561 ms 209.85.251.191 (209.85.251.191)  18.418 ms
10  72.14.232.134 (72.14.232.134)  23.467 ms 72.14.242.220 (72.14.242.220)  24.084 ms 72.14.232.134 (72.14.232.134)  24.088 ms
11  72.14.236.161 (72.14.236.161)  24.970 ms  24.970 ms  25.895 ms
12  74.125.216.52 (74.125.216.52)  25.875 ms  25.872 ms  25.881 ms

Hope this helps.

EDIT: any variation of "r[integer]---sn-4g57knkz.googlevideo.com" seems to be really slow. It also has a similar traceroute, see below.

~$ traceroute 'r20---sn-4g57kn6r.googlevideo.com'
traceroute to r20---sn-4g57kn6r.googlevideo.com (74.125.173.121), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  5.197 ms  5.308 ms  5.425 ms
 2  95.45.62.1 (95.45.62.1)  6.543 ms  7.266 ms  7.662 ms
 3  86.43.11.49 (86.43.11.49)  8.166 ms  8.603 ms  9.084 ms
 4  tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205)  10.272 ms  10.402 ms  10.529 ms
 5  * * *
 6  83.71.115.181 (83.71.115.181)  11.509 ms  7.443 ms  7.052 ms
 7  74.125.51.185 (74.125.51.185)  64.746 ms  64.743 ms  64.738 ms
 8  209.85.252.198 (209.85.252.198)  7.958 ms 209.85.252.196 (209.85.252.196)  8.521 ms 209.85.252.198 (209.85.252.198)  8.992 ms
 9  66.249.95.20 (66.249.95.20)  19.898 ms  20.397 ms  20.384 ms
10  * 209.85.241.229 (209.85.241.229)  41.471 ms  42.119 ms
11  72.14.234.236 (72.14.234.236)  41.938 ms 72.14.234.232 (72.14.234.232)  41.912 ms 209.85.250.142 (209.85.250.142)  42.435 ms
12  72.14.238.45 (72.14.238.45)  41.097 ms 209.85.246.65 (209.85.246.65)  40.600 ms *
13  209.85.248.107 (209.85.248.107)  77.722 ms 216.239.48.7 (216.239.48.7)  42.099 ms 216.239.47.247 (216.239.47.247)  91.400 ms
14  72.14.232.237 (72.14.232.237)  42.776 ms  41.530 ms  42.184 ms
15  74.125.173.121 (74.125.173.121)  42.009 ms  42.167 ms *

EDIT2: Facebook photos are also ridiculously slow to download on fbcdn-sphotos-a-a.akamaihd.net; 7 seconds for a 92KB image: Further edit: akamai returns different IP's for that hostname everytime, it was only the 77.67.11.40 server that was painfully slow

Resolving fbcdn-sphotos-a-a.akamaihd.net (fbcdn-sphotos-a-a.akamaihd.net)... 77.67.11.40, 77.67.11.48, 77.67.11.50, ...
Connecting to fbcdn-sphotos-a-a.akamaihd.net (fbcdn-sphotos-a-a.akamaihd.net)|77.67.11.40|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 94107 (92K) [image/jpeg]
Saving to: &#8216;/dev/null&#8217;

100%[============================================================================>] 94,107      11.6KB/s   in 7.9s   

2014-10-29 22:02:06 (11.6 KB/s) - &#8216;/dev/null&#8217; saved [94107/94107]

traceroute of above facebook photo server:

traceroute 77.67.11.40
traceroute to 77.67.11.40 (77.67.11.40), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  4.278 ms  4.285 ms  4.416 ms
 2  95.45.62.1 (95.45.62.1)  6.750 ms  7.361 ms  7.813 ms
 3  86.43.11.49 (86.43.11.49)  7.992 ms  8.083 ms  8.196 ms
 4  tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205)  9.154 ms  9.279 ms  9.759 ms
 5  * * *
 6  83.71.115.181 (83.71.115.181)  10.790 ms  8.069 ms  8.523 ms
 7  xe-1-1-0.dub20.ip4.gtt.net (77.67.64.161)  7.189 ms  7.578 ms  7.592 ms
 8  xe-0-0-1.par70.ip4.gtt.net (89.149.186.157)  26.290 ms  26.670 ms  26.670 ms
 9  77.67.11.40 (77.67.11.40)  27.202 ms  25.095 ms  25.960 ms

EDIT3: Just like the googlevideo servers, one of the Facebook image servers is fast however; fbcdn-sphotos-h-a.akamaihd.net: See further edit note on akamai's DNS above

Resolving fbcdn-sphotos-h-a.akamaihd.net (fbcdn-sphotos-h-a.akamaihd.net)... 195.245.125.177, 195.245.125.179, 195.245.125.178, ...
Connecting to fbcdn-sphotos-h-a.akamaihd.net (fbcdn-sphotos-h-a.akamaihd.net)|195.245.125.177|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 94409 (92K) [image/jpeg]
Saving to: &#8216;/dev/null&#8217;

100%[================================================================================================================>] 94,409      --.-K/s   in 0.08s   

2014-10-29 22:09:54 (1.20 MB/s) - &#8216;/dev/null&#8217; saved [94409/94409]

:~$ traceroute 195.245.125.177
traceroute to 195.245.125.177 (195.245.125.177), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  3.023 ms  3.370 ms *
 2  95.45.62.1 (95.45.62.1)  8.299 ms  9.417 ms  11.214 ms
 3  * * *
 4  tenge-3-1-1.core1.prp.core.eircom.net (86.43.252.201)  15.543 ms  15.805 ms  15.896 ms
 5  * * *
 6  tenge-2-2-1.pe1.the.the-thn.eircom.net (86.43.253.110)  29.794 ms * *
 7  ge7-1-0.corea.the.london.eircom.net (86.43.244.190)  33.391 ms  35.149 ms  35.145 ms
 8  195.66.236.168 (195.66.236.168)  46.369 ms  47.694 ms  47.595 ms
 9  195.245.125.177 (195.245.125.177)  33.556 ms  36.761 ms  36.313 ms

EDIT4: pdl.vimeocdn.com is very slow, <20KB/s.

traceroute:

:~$ traceroute pdl.vimeocdn.com
traceroute to pdl.vimeocdn.com (184.51.148.185), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  4.216 ms  4.265 ms  4.681 ms
 2  95.45.62.1 (95.45.62.1)  15.794 ms  21.159 ms  29.950 ms
 3  86.43.11.49 (86.43.11.49)  8.266 ms * *
 4  * * *
 5  * * *
 6  ge0-0-0.corea.thn.london.eircom.net (86.43.245.162)  24.168 ms  22.077 ms  22.450 ms
 7  xe-2-3-2.lon11.ip4.gtt.net (77.67.76.161)  21.484 ms  21.139 ms  22.514 ms
 8  xe-2-2-1.par70.ip4.gtt.net (89.149.185.133)  27.837 ms xe-11-3-0.par70.ip4.gtt.net (89.149.180.33)  28.694 ms xe-2-1-0.par70.ip4.gtt.net (89.149.186.165)  28.698 ms
 9  a184-51-148-185.deploy.static.akamaitechnologies.com (184.51.148.185)  28.695 ms  29.397 ms  29.382 ms

rat_race · 29-10-2014 11:16pm

dalta5billion wrote: »

:~$ traceroute 'r1---sn-4g57knkz.googlevideo.com'
traceroute to r1---sn-4g57knkz.googlevideo.com (173.194.48.134), 30 hops max, 60 byte packets
 1 &#160;MitraStar.Home (192.168.1.254) &#160;4.269 ms &#160;4.375 ms &#160;4.489 ms
 2 &#160;95.45.62.1 (95.45.62.1) &#160;239.588 ms &#160;239.586 ms &#160;239.973 ms
 3 &#160;86.43.11.49 (86.43.11.49) &#160;237.238 ms &#160;237.365 ms &#160;237.777 ms
 4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;237.493 ms &#160;237.636 ms &#160;237.882 ms
 5 &#160;* * *
 6 &#160;83.71.115.181 (83.71.115.181) &#160;239.349 ms &#160;6.848 ms &#160;8.999 ms
 7 &#160;74.125.51.185 (74.125.51.185) &#160;39.997 ms &#160;40.436 ms &#160;40.436 ms
 8 &#160;209.85.252.196 (209.85.252.196) &#160;9.342 ms 209.85.252.198 (209.85.252.198) &#160;9.884 ms &#160;10.233 ms
 9 &#160;209.85.252.28 (209.85.252.28) &#160;21.023 ms 66.249.95.20 (66.249.95.20) &#160;36.122 ms &#160;36.119 ms
10 &#160;209.85.241.229 (209.85.241.229) &#160;42.841 ms &#160;43.253 ms 209.85.241.227 (209.85.241.227) &#160;40.317 ms
11 &#160;72.14.234.230 (72.14.234.230) &#160;40.831 ms 209.85.251.249 (209.85.251.249) &#160;41.256 ms 72.14.234.230 (72.14.234.230) &#160;55.852 ms
12 &#160;209.85.248.13 (209.85.248.13) &#160;41.836 ms 209.85.253.245 (209.85.253.245) &#160;69.257 ms 209.85.246.67 (209.85.246.67) &#160;40.881 ms
13 &#160;209.85.248.107 (209.85.248.107) &#160;43.296 ms 216.239.47.239 (216.239.47.239) &#160;42.288 ms &#160;42.814 ms
14 &#160;216.239.48.197 (216.239.48.197) &#160;44.389 ms &#160;42.809 ms &#160;43.918 ms
15 &#160;173.194.48.134 (173.194.48.134) &#160;42.798 ms &#160;43.905 ms &#160;44.360 ms

I notice that this (r1---sn-4g57knkz.googlevideo.com) was the "slow" server where Youtube requested the video fragments from.

When I refreshed, a different server was used, which was a lot faster at serving the fragments. Here is its traceroute:

traceroute 'r5---sn-cg07luel.googlevideo.com'
traceroute to r5---sn-cg07luel.googlevideo.com (74.125.216.52), 30 hops max, 60 byte packets
 1 &#160;MitraStar.Home (192.168.1.254) &#160;4.334 ms &#160;4.380 ms &#160;4.499 ms
 2 &#160;95.45.62.1 (95.45.62.1) &#160;6.657 ms &#160;8.242 ms &#160;8.244 ms
 3 &#160;86.43.11.49 (86.43.11.49) &#160;8.455 ms &#160;8.577 ms &#160;8.699 ms
 4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;8.822 ms &#160;9.511 ms &#160;9.617 ms
 5 &#160;* * *
 6 &#160;83.71.115.181 (83.71.115.181) &#160;9.808 ms &#160;6.952 ms &#160;6.933 ms
 7 &#160;* * *
 8 &#160;209.85.252.196 (209.85.252.196) &#160;7.425 ms 209.85.252.198 (209.85.252.198) &#160;8.282 ms &#160;8.284 ms
 9 &#160;209.85.250.217 (209.85.250.217) &#160;17.071 ms &#160;17.561 ms 209.85.251.191 (209.85.251.191) &#160;18.418 ms
10 &#160;72.14.232.134 (72.14.232.134) &#160;23.467 ms 72.14.242.220 (72.14.242.220) &#160;24.084 ms 72.14.232.134 (72.14.232.134) &#160;24.088 ms
11 &#160;72.14.236.161 (72.14.236.161) &#160;24.970 ms &#160;24.970 ms &#160;25.895 ms
12 &#160;74.125.216.52 (74.125.216.52) &#160;25.875 ms &#160;25.872 ms &#160;25.881 ms

Hope this helps.

EDIT: any variation of "r[integer]---sn-4g57knkz.googlevideo.com" seems to be really slow. It also has a similar traceroute, see below.

~$ traceroute 'r20---sn-4g57kn6r.googlevideo.com'
traceroute to r20---sn-4g57kn6r.googlevideo.com (74.125.173.121), 30 hops max, 60 byte packets
 1 &#160;MitraStar.Home (192.168.1.254) &#160;5.197 ms &#160;5.308 ms &#160;5.425 ms
 2 &#160;95.45.62.1 (95.45.62.1) &#160;6.543 ms &#160;7.266 ms &#160;7.662 ms
 3 &#160;86.43.11.49 (86.43.11.49) &#160;8.166 ms &#160;8.603 ms &#160;9.084 ms
 4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;10.272 ms &#160;10.402 ms &#160;10.529 ms
 5 &#160;* * *
 6 &#160;83.71.115.181 (83.71.115.181) &#160;11.509 ms &#160;7.443 ms &#160;7.052 ms
 7 &#160;74.125.51.185 (74.125.51.185) &#160;64.746 ms &#160;64.743 ms &#160;64.738 ms
 8 &#160;209.85.252.198 (209.85.252.198) &#160;7.958 ms 209.85.252.196 (209.85.252.196) &#160;8.521 ms 209.85.252.198 (209.85.252.198) &#160;8.992 ms
 9 &#160;66.249.95.20 (66.249.95.20) &#160;19.898 ms &#160;20.397 ms &#160;20.384 ms
10 &#160;* 209.85.241.229 (209.85.241.229) &#160;41.471 ms &#160;42.119 ms
11 &#160;72.14.234.236 (72.14.234.236) &#160;41.938 ms 72.14.234.232 (72.14.234.232) &#160;41.912 ms 209.85.250.142 (209.85.250.142) &#160;42.435 ms
12 &#160;72.14.238.45 (72.14.238.45) &#160;41.097 ms 209.85.246.65 (209.85.246.65) &#160;40.600 ms *
13 &#160;209.85.248.107 (209.85.248.107) &#160;77.722 ms 216.239.48.7 (216.239.48.7) &#160;42.099 ms 216.239.47.247 (216.239.47.247) &#160;91.400 ms
14 &#160;72.14.232.237 (72.14.232.237) &#160;42.776 ms &#160;41.530 ms &#160;42.184 ms
15 &#160;74.125.173.121 (74.125.173.121) &#160;42.009 ms &#160;42.167 ms *

EDIT2: Facebook photos are also ridiculously slow to download on fbcdn-sphotos-a-a.akamaihd.net; 7 seconds for a 92KB image:

Resolving fbcdn-sphotos-a-a.akamaihd.net (fbcdn-sphotos-a-a.akamaihd.net)... 77.67.11.40, 77.67.11.48, 77.67.11.50, ...
Connecting to fbcdn-sphotos-a-a.akamaihd.net (fbcdn-sphotos-a-a.akamaihd.net)|77.67.11.40|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 94107 (92K) [image/jpeg]
Saving to: &#8216;/dev/null&#8217;

100%[============================================================================>] 94,107 &#160; &#160; &#160;11.6KB/s &#160; in 7.9s &#160; 

2014-10-29 22:02:06 (11.6 KB/s) - &#8216;/dev/null&#8217; saved [94107/94107]

traceroute of above facebook photo server:

traceroute 77.67.11.40
traceroute to 77.67.11.40 (77.67.11.40), 30 hops max, 60 byte packets
 1 &#160;MitraStar.Home (192.168.1.254) &#160;4.278 ms &#160;4.285 ms &#160;4.416 ms
 2 &#160;95.45.62.1 (95.45.62.1) &#160;6.750 ms &#160;7.361 ms &#160;7.813 ms
 3 &#160;86.43.11.49 (86.43.11.49) &#160;7.992 ms &#160;8.083 ms &#160;8.196 ms
 4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;9.154 ms &#160;9.279 ms &#160;9.759 ms
 5 &#160;* * *
 6 &#160;83.71.115.181 (83.71.115.181) &#160;10.790 ms &#160;8.069 ms &#160;8.523 ms
 7 &#160;xe-1-1-0.dub20.ip4.gtt.net (77.67.64.161) &#160;7.189 ms &#160;7.578 ms &#160;7.592 ms
 8 &#160;xe-0-0-1.par70.ip4.gtt.net (89.149.186.157) &#160;26.290 ms &#160;26.670 ms &#160;26.670 ms
 9 &#160;77.67.11.40 (77.67.11.40) &#160;27.202 ms &#160;25.095 ms &#160;25.960 ms

EDIT3: Just like the googlevideo servers, one of the Facebook image servers is fast however; fbcdn-sphotos-h-a.akamaihd.net:

Resolving fbcdn-sphotos-h-a.akamaihd.net (fbcdn-sphotos-h-a.akamaihd.net)... 195.245.125.177, 195.245.125.179, 195.245.125.178, ...
Connecting to fbcdn-sphotos-h-a.akamaihd.net (fbcdn-sphotos-h-a.akamaihd.net)|195.245.125.177|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 94409 (92K) [image/jpeg]
Saving to: &#8216;/dev/null&#8217;

100%[================================================================================================================>] 94,409 &#160; &#160; &#160;--.-K/s &#160; in 0.08s &#160; 

2014-10-29 22:09:54 (1.20 MB/s) - &#8216;/dev/null&#8217; saved [94409/94409]

:~$ traceroute 195.245.125.177
traceroute to 195.245.125.177 (195.245.125.177), 30 hops max, 60 byte packets
 1 &#160;MitraStar.Home (192.168.1.254) &#160;3.023 ms &#160;3.370 ms *
 2 &#160;95.45.62.1 (95.45.62.1) &#160;8.299 ms &#160;9.417 ms &#160;11.214 ms
 3 &#160;* * *
 4 &#160;tenge-3-1-1.core1.prp.core.eircom.net (86.43.252.201) &#160;15.543 ms &#160;15.805 ms &#160;15.896 ms
 5 &#160;* * *
 6 &#160;tenge-2-2-1.pe1.the.the-thn.eircom.net (86.43.253.110) &#160;29.794 ms * *
 7 &#160;ge7-1-0.corea.the.london.eircom.net (86.43.244.190) &#160;33.391 ms &#160;35.149 ms &#160;35.145 ms
 8 &#160;195.66.236.168 (195.66.236.168) &#160;46.369 ms &#160;47.694 ms &#160;47.595 ms
 9 &#160;195.245.125.177 (195.245.125.177) &#160;33.556 ms &#160;36.761 ms &#160;36.313 ms

Here is mine to that server. Same again, various timeouts:

C:\Users\Cormac>tracert r20---sn-4g57kn6r.googlevideo.com

Tracing route to r20.sn-4g57kn6r.googlevideo.com [74.125.173.121]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 5 ms 4 ms 34 ms 95.45.80.1
3 5 ms 5 ms 5 ms 86.43.11.33
4 5 ms 5 ms 5 ms tenge-4-1-1.core1.dbn.core.eircom.net [86.43.252.205]
5 * * 7 ms 86.43.13.158
6 6 ms 6 ms 5 ms 83.71.115.181
7 27 ms 18 ms 41 ms 74.125.51.185
8 12 ms 6 ms 6 ms 209.85.252.198
9 20 ms 20 ms 20 ms 209.85.252.28
10 57 ms 39 ms 39 ms 209.85.241.229
11 39 ms 39 ms 39 ms 209.85.250.142
12 40 ms 40 ms 40 ms 209.85.241.111
13 * 41 ms 41 ms 216.239.46.117
14 40 ms 40 ms 40 ms 72.14.232.237
15 40 ms 40 ms 39 ms 74.125.173.121

Trace complete.

C:\Users\Cormac>tracert r20---sn-4g57kn6r.googlevideo.com

Tracing route to r20.sn-4g57kn6r.googlevideo.com [74.125.173.121]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 16 ms 4 ms 5 ms 95.45.80.1
3 5 ms 5 ms 5 ms 86.43.11.33
4 5 ms 5 ms 5 ms tenge-4-1-1.core1.dbn.core.eircom.net [86.43.252.205]
5 * * * Request timed out.
6 5 ms 5 ms 5 ms 83.71.115.181
7 38 ms 64 ms 68 ms 74.125.51.185
8 6 ms 32 ms 27 ms 209.85.252.198
9 20 ms 20 ms 20 ms 209.85.252.28
10 45 ms 39 ms 40 ms 209.85.241.229
11 39 ms 50 ms 40 ms 209.85.250.142
12 40 ms 40 ms 40 ms 209.85.241.111
13 41 ms 40 ms 41 ms 216.239.46.117
14 40 ms 40 ms 40 ms 72.14.232.237
15 51 ms 39 ms 39 ms 74.125.173.121

Trace complete.

C:\Users\Cormac>tracert r20---sn-4g57kn6r.googlevideo.com

Tracing route to r20.sn-4g57kn6r.googlevideo.com [74.125.173.121]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.254
2 11 ms 8 ms 4 ms 95.45.80.1
3 5 ms 5 ms 5 ms 86.43.11.33
4 6 ms 6 ms 6 ms tenge-4-1-1.core1.dbn.core.eircom.net [86.43.252.205]
5 * * 6 ms 86.43.13.158
6 6 ms 6 ms 6 ms 83.71.115.181
7 76 ms * 105 ms 74.125.51.185
8 6 ms 16 ms 6 ms 209.85.252.198
9 20 ms 20 ms 20 ms 209.85.252.28
10 39 ms 40 ms 39 ms 209.85.241.229
11 39 ms 39 ms 39 ms 209.85.250.142
12 53 ms 40 ms 40 ms 209.85.241.111
13 41 ms 41 ms 40 ms 216.239.46.117
14 40 ms 40 ms 40 ms 72.14.232.237
15 39 ms 39 ms 39 ms 74.125.173.121

Trace complete.

However, look at the results of a traceroute from my rented server in Germany (no issues):

[cormac@CentOS-60-64-minimal ~]$ traceroute r20---sn-4g57kn6r.googlevideo.com
traceroute to r20---sn-4g57kn6r.googlevideo.com (74.125.173.121), 30 hops max, 60 byte packets
1 static.225.5.40.188.clients.your-server.de (188.40.5.225) 1.440 ms 2.786 ms 2.838 ms
2 hos-tr1.juniper3.rz10.hetzner.de (213.239.236.65) 0.334 ms 0.294 ms hos-tr3.juniper3.rz12.hetzner.de (213.239.236.97) 0.341 ms
3 core21.hetzner.de (213.239.245.101) 0.300 ms 0.257 ms 0.324 ms
4 core4.hetzner.de (213.239.245.14) 4.975 ms core4.hetzner.de (213.239.245.18) 4.934 ms core4.hetzner.de (213.239.245.14) 4.894 ms
5 juniper4.ffm.hetzner.de (213.239.245.1) 4.979 ms 4.994 ms 4.952 ms
6 de-cix20.net.google.com (80.81.193.108) 8.309 ms 8.135 ms 8.063 ms
7 216.239.47.249 (216.239.47.249) 6.316 ms 216.239.48.3 (216.239.48.3) 6.457 ms 216.239.48.1 (216.239.48.1) 6.323 ms
8 72.14.232.237 (72.14.232.237) 6.505 ms 72.14.232.239 (72.14.232.239) 6.219 ms 5.944 ms
9 74.125.173.121 (74.125.173.121) 6.128 ms 6.402 ms 6.095 ms
[cormac@CentOS-60-64-minimal ~]$ traceroute r20---sn-4g57kn6r.googlevideo.com
traceroute to r20---sn-4g57kn6r.googlevideo.com (74.125.173.121), 30 hops max, 60 byte packets
1 static.225.5.40.188.clients.your-server.de (188.40.5.225) 1.162 ms 1.058 ms 0.981 ms
2 hos-tr4.juniper3.rz12.hetzner.de (213.239.236.113) 0.315 ms hos-tr3.juniper3.rz12.hetzner.de (213.239.236.97) 0.271 ms hos-tr2.juniper3.rz10.hetzner.de (213.239.236.81) 0.327 ms
3 core21.hetzner.de (213.239.245.101) 3.786 ms core22.hetzner.de (213.239.245.141) 0.461 ms core21.hetzner.de (213.239.245.101) 0.340 ms
4 core4.hetzner.de (213.239.245.18) 4.950 ms 4.941 ms core1.hetzner.de (213.239.245.218) 4.947 ms
5 juniper1.ffm.hetzner.de (213.239.245.5) 4.973 ms juniper4.ffm.hetzner.de (213.239.245.1) 4.941 ms juniper1.ffm.hetzner.de (213.239.245.5) 4.988 ms
6 de-cix20.net.google.com (80.81.193.108) 5.357 ms google.fra.ecix.net (62.69.146.14) 5.234 ms de-cix20.net.google.com (80.81.193.108) 5.316 ms
7 216.239.48.1 (216.239.48.1) 6.018 ms 6.313 ms 216.239.47.251 (216.239.47.251) 6.642 ms
8 72.14.232.237 (72.14.232.237) 6.483 ms 72.14.232.239 (72.14.232.239) 6.512 ms 6.590 ms
9 74.125.173.121 (74.125.173.121) 6.207 ms 6.409 ms 6.185 ms
[cormac@CentOS-60-64-minimal ~]$ traceroute r20---sn-4g57kn6r.googlevideo.com
traceroute to r20---sn-4g57kn6r.googlevideo.com (74.125.173.121), 30 hops max, 60 byte packets
1 static.225.5.40.188.clients.your-server.de (188.40.5.225) 1.409 ms 1.504 ms 1.376 ms
2 hos-tr2.juniper3.rz10.hetzner.de (213.239.236.81) 0.308 ms hos-tr1.juniper3.rz10.hetzner.de (213.239.236.65) 0.243 ms hos-tr4.juniper3.rz12.hetzner.de (213.239.236.113) 0.387 ms
3 core21.hetzner.de (213.239.245.101) 0.321 ms 0.377 ms 0.353 ms
4 core1.hetzner.de (213.239.245.177) 4.964 ms core4.hetzner.de (213.239.245.18) 4.984 ms core4.hetzner.de (213.239.245.14) 4.973 ms
5 juniper4.ffm.hetzner.de (213.239.245.1) 4.979 ms 5.191 ms 4.994 ms
6 de-cix20.net.google.com (80.81.193.108) 5.302 ms 5.294 ms 5.373 ms
7 216.239.48.3 (216.239.48.3) 6.516 ms 216.239.47.251 (216.239.47.251) 6.280 ms 216.239.48.3 (216.239.48.3) 6.219 ms
8 72.14.232.239 (72.14.232.239) 6.242 ms 6.578 ms 72.14.232.237 (72.14.232.237) 6.621 ms
9 74.125.173.121 (74.125.173.121) 6.436 ms 6.124 ms 6.428 ms
[cormac@CentOS-60-64-minimal ~]$

By the way, dalta5billion: 77.67.11.40, the slow FB pic server, is based in the US, whereas the "fast" one, 195.245.125.177, is based in the UK. That might be a factor. Other people have reported that in general, the bottleneck appears to be on US-based sites.

Either way, this is definitely a major routing and/or caching screw up. It wouldn't surprise me if some "smart throttling" has gone horribly wrong.

Eircom, I think we would all like a definitive update on this, sooner rather than later.

Bog Standard User · 29-10-2014 11:43pm

it is not just efibre affected adsl are also affected, it is eircom's inadequate links to the uk and usa that is the problem. NOT ENOUGH BANDWIDTH being paid for use of the one undersea cable (wexford to uk) that is the problem

irish sites load perfectly - anything else forget about it.

eircom need to stop being stingy and buy more bandwidth on the undersea cables or else risk mass cancellations

there are 3 under sea cables

1. dublin to holyhead
2. larne to stranrer
3. wexford to bude

dalta5billion · 29-10-2014 11:47pm

rat_race wrote: »

By the way, dalta5billion: 77.67.11.40, the slow FB pic server, is based in the US, whereas the "fast" one, 195.245.125.177, is based in the UK. That might be a factor. Other people have reported that in general, the bottleneck appears to be on US-based sites.

Either way, this is definitely a major routing and/or caching screw up. It wouldn't surprise me if some "smart throttling" has gone horribly wrong.

Eircom, I think we would all like a definitive update on this, sooner rather than later. You will keep many customers by admitting a screw up.

Hi Cormac,

I've edited my post to clarify the FB servers, however the traceroutes for the fast and slow googlevideo servers all show traffic going from the same eircom node to the same Google IP address. This could therefore be a google problem rather than an Eircom one... TBH only Eircom ops can tell use what is really going on.

rat_race · 30-10-2014 12:09am

Bog Standard User wrote: »

it is not just efibre affected it is eircom's inadequate links to the uk and usa that is the problem

irish sites load perfectly - anything else forget about it.

eircom need to stop being stingy and buy more bandwidth on the undersea cables or else risk mass cancellations

For myself and many others, however, this problem just started occurring. Any ideas why?

dalta5billion wrote: »

rat_race wrote: »

By the way, dalta5billion: 77.67.11.40, the slow FB pic server, is based in the US, whereas the "fast" one, 195.245.125.177, is based in the UK. That might be a factor. Other people have reported that in general, the bottleneck appears to be on US-based sites.

Either way, this is definitely a major routing and/or caching screw up. It wouldn't surprise me if some "smart throttling" has gone horribly wrong.

Eircom, I think we would all like a definitive update on this, sooner rather than later. You will keep many customers by admitting a screw up.

Hi Cormac,

I've edited my post to clarify the FB servers, however the traceroutes for the fast and slow googlevideo servers all show traffic going from the same eircom node to the same Google IP address. This could therefore be a google problem rather than an Eircom one... TBH only Eircom ops can tell use what is really going on.

I'm not sure that I'm following.

You're getting timeouts at node 5 for some reason, which shouldn't happen, and in general the hop speeds around the Eircom nodes are very slow and inconsistent. From my German server, a roundtrip to r20---sn-4g57kn6r.googlevideo.com takes 6ms -- from start to finish. In your examples, it's taking much longer, around 43ms, if you're lucky. The delay is occurring on the Eircom servers. It even took 64ms on one of the three times in a row, to get to node 7. So the speeds would vary greatly.

This will mess up streaming a video for sure.

For anyone wanting to understand traceroute a bit more, check this out:

http://networking.ringofsaturn.com/IP/traceroutedoc.php

Bog Standard User · 30-10-2014 12:11am

dalta5billion wrote: »

rat_race wrote: »

By the way, dalta5billion: 77.67.11.40, the slow FB pic server, is based in the US, whereas the "fast" one, 195.245.125.177, is based in the UK. That might be a factor. Other people have reported that in general, the bottleneck appears to be on US-based sites.

Either way, this is definitely a major routing and/or caching screw up. It wouldn't surprise me if some "smart throttling" has gone horribly wrong.

Eircom, I think we would all like a definitive update on this, sooner rather than later. You will keep many customers by admitting a screw up.

Hi Cormac,

I've edited my post to clarify the FB servers, however the traceroutes for the fast and slow googlevideo servers all show traffic going from the same eircom node to the same Google IP address. This could therefore be a google problem rather than an Eircom one... TBH only Eircom ops can tell use what is really going on.

yup dalta5billion you hit the nail on the head.

the problem is most definitely the way traffic is routed out of ireland.

it is so bad that it is usuable now between 5pm and midnight. yet if i vpn link to my friend's upc modem then go to facebook/youtube/netflix i dont get the same lag.

eircom bbtech were just as frustrated when i called in to report it. they know there is a problem but they cannot do anything to resolve it because it is way beyond their remit. As eircom bbtech (like most isp's bbtech is outsourced) they have no power to make the changes needed to resolve it. only eircom network operations (who deal with traffic management) can deal with it.

call eircom bbtech if u like but they are powerless to do anything about it.

if everyone here logs a fault with bbtech all they can do is track it and pass it on the eircom network operations. its upto eircom network operations to actually fix it.

i recommend ye do call in to report it cos the more cases logged means more pressure to resolve it.

johnobertie2 · 30-10-2014 12:19am

Bog Standard User wrote: »

it is not just efibre affected adsl are also affected, it is eircom's inadequate links to the uk and usa that is the problem. NOT ENOUGH BANDWIDTH being paid for use of the one undersea cable (wexford to uk) that is the problem

irish sites load perfectly - anything else forget about it.

eircom need to stop being stingy and buy more bandwidth on the undersea cables or else risk mass cancellations

there are 3 under sea cables

1. dublin to holyhead
2. larne to stranrer
3. wexford to bude

I have regular eircom 3 meg dsl

I can download files just fine in the evenings
(same 300kb/s as I get during day) but
streaming slows to a crawl

Is this local contention on the phone lines or is it the same issue as the efibre customers are having?

Bog Standard User · 30-10-2014 12:26am

johnobertie2 wrote: »

Bog Standard User wrote: »

it is not just efibre affected adsl are also affected, it is eircom's inadequate links to the uk and usa that is the problem. NOT ENOUGH BANDWIDTH being paid for use of the one undersea cable (wexford to uk) that is the problem

irish sites load perfectly - anything else forget about it.

eircom need to stop being stingy and buy more bandwidth on the undersea cables or else risk mass cancellations

there are 3 under sea cables

1. dublin to holyhead
2. larne to stranrer
3. wexford to bude

I have regular eircom 3 meg dsl

I can download files just fine in the evenings
(same 300kb/s as I get during day) but
streaming slows to a crawl

Is this local contention on the phone lines or is it the same issue as the efibre customers are having?

your on old adsl which is contented

on fibre your are not contended

johnobertie2 · 30-10-2014 12:41am

Bog Standard User wrote: »

your on old adsl which is contented

on fibre your are not contended

My question is do I have a contention issue or the same routing issue as the efibre customers

I was wondering as my download speed doesn't drop in evening only streaming

Bog Standard User · 30-10-2014 12:46am

johnobertie2 wrote: »

Bog Standard User wrote: »

your on old adsl which is contented

on fibre your are not contended

My question is do I have a contention issue or the same routing issue as the efibre customers

I was wondering as my download speed doesn't drop in evening only streaming

most downloading you are doing is likely peer to peer so no it wouldnt make much of a difference

try downloading a large file from a media site like itunes or microsoft. then see if it crawls

dalta5billion · 30-10-2014 12:49am

rat_race wrote: »

I'm not sure that I'm following.

You're getting timeouts at node 5 for some reason, which shouldn't happen, and in general the hop speeds around the Eircom nodes are very slow and inconsistent. From my German server, a roundtrip to r20---sn-4g57kn6r.googlevideo.com takes 6ms -- from start to finish. In your examples, it's taking much longer, around 43ms, if you're lucky. The delay is occurring on the Eircom servers. It even took 64ms on one of the three times in a row, to get to node 7. So the speeds would vary greatly.

This will mess up streaming a video for sure.

For anyone wanting to understand traceroute a bit more, check this out:

http://networking.ringofsaturn.com/IP/traceroutedoc.php

6ms from Germany to the US breaks the laws of physics, so unless Google is doing some routing magic (anycast?), I don't think it's a fair comparison.

Also, asterisks are completely normal in traceroutes. Many servers are configured not to respond to traceroutes. They do not indicate packet loss, but rather a hop along the way that does indeed decrement the TTL in the header but does not respond with its hostname when the TTL gets to low(which is how traceroute works in the first place).

What is more interesting is the route that is being taken, or reported to be taken.

johnobertie2 · 30-10-2014 12:50am

Bog Standard User wrote: »

most downloading you are doing is likely peer to peer so no it wouldnt make much of a difference

try downloading a large file from a media site like itunes or microsoft. then see if it crawls

Rapidshare, cnet download works perfect
is that p2p?

gramo · 30-10-2014 12:51am

Thank god I'm not alone. I've had terrible issues for months. It suddenly fixed itself last week and I was getting full 8-9Meg a second downloading files. Now I'm back to square one. Buffering problems and so on. Evision tv seems to be ok and I'm on the 100meg line. Speedtest always comes back good

rat_race · 30-10-2014 1:06am

dalta5billion wrote: »

rat_race wrote: »

I'm not sure that I'm following.

You're getting timeouts at node 5 for some reason, which shouldn't happen, and in general the hop speeds around the Eircom nodes are very slow and inconsistent. From my German server, a roundtrip to r20---sn-4g57kn6r.googlevideo.com takes 6ms -- from start to finish. In your examples, it's taking much longer, around 43ms, if you're lucky. The delay is occurring on the Eircom servers. It even took 64ms on one of the three times in a row, to get to node 7. So the speeds would vary greatly.

This will mess up streaming a video for sure.

For anyone wanting to understand traceroute a bit more, check this out:

http://networking.ringofsaturn.com/IP/traceroutedoc.php

6ms from Germany to the US breaks the laws of physics, so unless Google is doing some routing magic (anycast?), I don't think it's a fair comparison.

Also, asterisks are completely normal in traceroutes. Many servers are configured not to respond to traceroutes. They do not indicate packet loss, but rather a hop along the way that does indeed decrement the TTL in the header but does not respond with its hostname when the TTL gets to low(which is how traceroute works in the first place).

What is more interesting is the route that is being taken, or reported to be taken.

You're right regarding the 6ms, but that's what it is because simply it's not going to the US -- which is the right thing to do.

And asterisks are normal in traceroutes too, yep, BUT not when they sometimes occur and sometimes don't like in my examples (where sometimes 1 or 2 out of three requests didn't time out). And if you see the output where I tracerouted the servers you first mentioned, I wasn't getting ALL asterisks on node 5 for very similar routes. Seems strange that sometimes a server would respond, other times it wouldn't. I know we might be taking slightly different routes, but it doesn't look like it.

Additionally, I ran a lot more traceroutes than I pasted, and random timeouts and unusual times were popping up a lot.

Just had a friend with Vodafone BB do a traceroute to [font=arial, sans-serif]cnn-f.akamaihd.net[/font] (the one I originally tested)...6 node hops in total, no issues, no timeouts, an average of 30ms. With Eircom, I have 9 hops, higher average and random timeouts here and there.

dalta5billion · 30-10-2014 1:28am

rat_race wrote: »

You're right regarding the 6ms, but that's what it is because simply it's not going to the US -- which is the right thing to do.

And asterisks are normal in traceroutes too, yep, BUT not when they sometimes occur and sometimes don't like in my examples (where sometimes 1 or 2 out of three requests didn't time out). And if you see the output where I tracerouted the servers you first mentioned, I wasn't getting ALL asterisks on node 5 for very similar routes. Seems strange that sometimes a server would respond, other times it wouldn't. I know we might be taking slightly different routes, but it doesn't look like it.

Additionally, I ran a lot more traceroutes than I pasted, and random timeouts and unusual times were popping up a lot.

Just had a friend with Vodafone BB do a traceroute to [font=arial, sans-serif]cnn-f.akamaihd.net[/font] (the one I originally tested)...6 node hops in total, no issues, no timeouts, an average of 30ms. With Eircom, I have 9 hops, higher average and random timeouts here and there.

You're right, it is weird.

What I meants was if you look at the "fast" vs "slow" google trace routes the reported hand off point from an Eircom IP to a Google IP is the exact same. It makes no sense that one should be faster than the other if it is indeed a congestion issue caused by Eircom's poor peering arrangements.

Edit: never mind, they're not the same

Kazuma · 30-10-2014 3:38pm

This thread has been eye-opening, I've been experiencing the intermittent slow (or not even at all) loading of pictures in facebook recently - thought it very odd that it was only affecting specific things.

Simon Gruber Says · 30-10-2014 4:53pm

Had a similar problem with Three just before I got eFibre installed, although it was more specific to YouTube. They managed to sort it out very fast though but don't know what actually caused it.

http://touch.boards.ie/thread/2057294007/1

2012paddy2012 · 30-10-2014 4:57pm

major deegan wrote: »

Folks, this is the exact same computer generated response on the other eircom thread..As predicted it's the usual call the technical support number.The reason i'm on here is i have used that number till i'd be blue in the face and all to no avail,thought there might be help or advice available in this forum.No help to me to repetitively give me a useless phone number!

Did you ever use Vodafone ? Any difference if so? Thks

eircom: Alan · 30-10-2014 5:07pm

Hi All,

These issues remain under investigation at the highest level and as soon as I have more information I'll update this thread you right away.

Many thanks to everybody who have PM'd trace routes - it's greatly appreciated. Also if anybody is having specific issues with yourube can you try youtube.ie and see if the issues remain?

Thanks
Al

major deegan · 30-10-2014 5:32pm

2012paddy2012 wrote: »

Did you ever use Vodafone ? Any difference if so? Thks

Yeah was with Vodafone for 3 years until Eircom sales rep came to the door with the "next big thing". The vodafone router was installed in a central location of the house to ensure even coverage and worked perfect for the duration.When Eircom 'engineer' arrived he insisted their router HAD to go in living room?? Which is at end of house (hence good coverage out on the lawn) giving lots of dead spots within the house!!! Also well well shy of the 70 mbs promised during sales pitch.I've wasted hours on phone trying to get a decent service but all to no avail. Had 4 no shows by 'technician' callouts!!! Total pain in the arse.. With zero help from customer service!!! Anyway vodafone were spot on for my needs with no problems for my time with them. Dunno what they're like now for efibre but they have to be better than eircom.

trixiebust · 30-10-2014 6:55pm

Having the same problems since the switch to e fibre two months ago... Every day between 5 and 11.30 p.m the internet and wifi lights on my router constantly flash and its impossible to stream anything between those hours. Speedtest shows a 40 mb wifi connection but this can't be right because it takes about 1.5 hours to watch a 30min show, constantly buffering. After 11.30 p.m all the lights are a stable green, no flashing, and all works perfect. All the problems are between peak hours, every day, so annoying!!

_Whimsical_ · 30-10-2014 8:18pm

I really feel this sort of fault should be enough to cancel a contract with Eircom. Watching steaming tv services has become a basic requirement of an internet connection, lots of us use it as a primary tv service. We also will be paying a tv/entertainment licence to avail of these services instead of the traditional tv licence. It's just not an adequate service while an issue like this remains.

dalta5billion · 30-10-2014 8:40pm

UPDATE - Thursday 30th October

Having problems with Vimeo again tonight.

Some of the time the Vimeo/Akamai DNS returns an IP that eircom- (presumably correctly) -routes through INEX in Dublin directly to Akamai's network: See below

traceroute pdl.vimeocdn.com
traceroute to pdl.vimeocdn.com (92.123.72.102), 30 hops max, 60 byte packets
&#160;1 &#160;MitraStar.Home (192.168.1.254) &#160;4.604 ms &#160;4.682 ms &#160;4.789 ms
&#160;2 &#160;95.45.62.1 (95.45.62.1) &#160;12.848 ms &#160;13.713 ms &#160;14.154 ms
&#160;3 &#160;86.43.11.49 (86.43.11.49) &#160;7.640 ms &#160;7.745 ms &#160;8.666 ms
&#160;4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;8.779 ms &#160;8.903 ms &#160;9.010 ms
&#160;5 &#160;* * *
&#160;6 &#160;83.71.115.181 (83.71.115.181) &#160;9.969 ms &#160;8.842 ms &#160;9.537 ms
&#160;7 &#160;inex-dub1.netarch.akamai.com (193.242.111.55) &#160;11.193 ms &#160;11.004 ms &#160;11.320 ms
&#160;8 &#160;a92-123-72-102.deploy.akamaitechnologies.com (92.123.72.102) &#160;9.261 ms &#160;10.301 ms &#160;10.165 ms

However, other IPs returned by Vimeo/Akamai appear to route through gtt in London:

traceroute pdl.vimeocdn.com
traceroute to pdl.vimeocdn.com (77.67.21.48), 30 hops max, 60 byte packets
&#160;1 &#160;MitraStar.Home (192.168.1.254) &#160;4.324 ms &#160;5.279 ms &#160;5.370 ms
&#160;2 &#160;95.45.62.1 (95.45.62.1) &#160;6.985 ms &#160;7.929 ms &#160;7.931 ms
&#160;3 &#160;86.43.11.49 (86.43.11.49) &#160;8.212 ms &#160;8.341 ms &#160;8.453 ms
&#160;4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;9.486 ms * *
&#160;5 &#160;* * *
&#160;6 &#160;* 83.71.115.181 (83.71.115.181) &#160;7.250 ms &#160;6.884 ms
&#160;7 &#160;xe-1-1-0.dub20.ip4.gtt.net (77.67.64.161) &#160;7.383 ms &#160;7.375 ms &#160;7.932 ms
&#160;8 &#160;xe-3-0-5.lon10.ip4.gtt.net (141.136.106.253) &#160;21.815 ms &#160;22.294 ms &#160;22.289 ms
&#160;9 &#160;77.67.21.48 (77.67.21.48) &#160;22.866 ms &#160;22.862 ms &#160;23.784 ms

Note that Vimeo/Akamai also serve content via av.vimeo.com - this domain suffers from the same problems, with some IP's being routed more directly than others:

traceroute av.vimeo.com
traceroute to av.vimeo.com (159.134.172.153), 30 hops max, 60 byte packets
&#160;1 &#160;MitraStar.Home (192.168.1.254) &#160;3.924 ms &#160;4.060 ms &#160;4.412 ms
&#160;2 &#160;95.45.62.1 (95.45.62.1) &#160;12.397 ms &#160;13.062 ms &#160;13.061 ms
&#160;3 &#160;86.43.11.49 (86.43.11.49) &#160;8.710 ms &#160;8.823 ms &#160;8.946 ms
&#160;4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;9.097 ms &#160;9.213 ms &#160;9.336 ms
&#160;5 &#160;lag-1.core2.dbn.core.eircom.net (86.43.252.30) &#160;11.908 ms &#160;12.011 ms &#160;12.135 ms
&#160;6 &#160;tenge-1-2-1.pe2.crz.crz-crz.eircom.net (86.43.252.138) &#160;10.237 ms &#160;7.182 ms &#160;7.288 ms
&#160;7 &#160;159.134.172.153 (159.134.172.153) &#160;7.508 ms &#160;7.990 ms &#160;7.919 ms

traceroute 'av.vimeo.com'
traceroute to av.vimeo.com (77.67.21.64), 30 hops max, 60 byte packets
&#160;1 &#160;MitraStar.Home (192.168.1.254) &#160;5.052 ms &#160;5.070 ms &#160;5.191 ms
&#160;2 &#160;95.45.62.1 (95.45.62.1) &#160;7.893 ms &#160;8.628 ms &#160;8.627 ms
&#160;3 &#160;86.43.11.49 (86.43.11.49) &#160;9.684 ms &#160;10.071 ms &#160;10.158 ms
&#160;4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;10.284 ms * *
&#160;5 &#160;* * *
&#160;6 &#160;* * *
&#160;7 &#160;* xe-1-1-0.dub20.ip4.gtt.net (77.67.64.161) &#160;10.180 ms &#160;6.645 ms
&#160;8 &#160;xe-3-0-5.lon10.ip4.gtt.net (141.136.106.253) &#160;21.013 ms &#160;22.406 ms &#160;22.398 ms
&#160;9 &#160;77.67.21.64 (77.67.21.64) &#160;22.401 ms &#160;22.391 ms &#160;22.380 ms

EDIT: Akamai don't declare the gtt-routed IP's at INEX, so maybe this is an Akamai GeoDNS issue. This still doesn't account for why the London gtt link would be so congested.

EDIT2:
Here's a fast googlevideo server:

traceroute r3---sn-xpgjvh-q0ce.googlevideo.com
traceroute to r3---sn-xpgjvh-q0ce.googlevideo.com (86.43.63.14), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  4.899 ms  4.980 ms  5.603 ms
 2  95.45.62.1 (95.45.62.1)  6.661 ms  8.136 ms  11.443 ms
 3  86.43.11.49 (86.43.11.49)  8.700 ms  9.072 ms  9.193 ms
 4  tenge-3-1-1.core1.prp.core.eircom.net (86.43.252.201)  9.313 ms  9.437 ms  9.560 ms
 5  tenge-3-2-1.core1.bdt.core.eircom.net (86.43.252.9)  10.974 ms  11.986 ms  12.609 ms
 6  lag-1.core2.bdt.core.eircom.net (86.43.252.2)  14.155 ms  8.451 ms  8.455 ms
 7  tenge-1-2-1.pe1.cwm.cwm-cwm.eircom.net (86.43.252.174)  8.475 ms  8.598 ms  8.716 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

And here's a slow one:

traceroute r11---sn-q0c7dn76.googlevideo.com
traceroute to r11---sn-q0c7dn76.googlevideo.com (173.194.138.112), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  3.978 ms  4.589 ms  5.532 ms
 2  95.45.62.1 (95.45.62.1)  11.303 ms  24.001 ms  26.299 ms
 3  86.43.11.49 (86.43.11.49)  9.041 ms  9.225 ms  9.355 ms
 4  tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205)  9.479 ms  9.594 ms  9.727 ms
 5  * * *
 6  83.71.115.181 (83.71.115.181)  11.216 ms  10.496 ms  22.900 ms
 7  74.125.51.185 (74.125.51.185)  88.064 ms  88.065 ms  88.061 ms
 8  66.249.95.91 (66.249.95.91)  24.811 ms  24.822 ms  24.825 ms
 9  173.194.138.112 (173.194.138.112)  24.807 ms  24.810 ms  24.808 ms

Liamario · 30-10-2014 10:39pm

dalta5billion wrote: »

UPDATE - Thursday 30th October

Having problems with Vimeo again tonight.

Some of the time the Vimeo/Akamai DNS returns an IP that eircom- (presumably correctly) -routes through INEX in Dublin directly to Akamai's network: See below

traceroute pdl.vimeocdn.com
traceroute to pdl.vimeocdn.com (92.123.72.102), 30 hops max, 60 byte packets
&#160;1 &#160;MitraStar.Home (192.168.1.254) &#160;4.604 ms &#160;4.682 ms &#160;4.789 ms
&#160;2 &#160;95.45.62.1 (95.45.62.1) &#160;12.848 ms &#160;13.713 ms &#160;14.154 ms
&#160;3 &#160;86.43.11.49 (86.43.11.49) &#160;7.640 ms &#160;7.745 ms &#160;8.666 ms
&#160;4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;8.779 ms &#160;8.903 ms &#160;9.010 ms
&#160;5 &#160;* * *
&#160;6 &#160;83.71.115.181 (83.71.115.181) &#160;9.969 ms &#160;8.842 ms &#160;9.537 ms
&#160;7 &#160;inex-dub1.netarch.akamai.com (193.242.111.55) &#160;11.193 ms &#160;11.004 ms &#160;11.320 ms
&#160;8 &#160;a92-123-72-102.deploy.akamaitechnologies.com (92.123.72.102) &#160;9.261 ms &#160;10.301 ms &#160;10.165 ms

However, other IPs returned by Vimeo/Akamai appear to route through gtt in London:

traceroute pdl.vimeocdn.com
traceroute to pdl.vimeocdn.com (77.67.21.48), 30 hops max, 60 byte packets
&#160;1 &#160;MitraStar.Home (192.168.1.254) &#160;4.324 ms &#160;5.279 ms &#160;5.370 ms
&#160;2 &#160;95.45.62.1 (95.45.62.1) &#160;6.985 ms &#160;7.929 ms &#160;7.931 ms
&#160;3 &#160;86.43.11.49 (86.43.11.49) &#160;8.212 ms &#160;8.341 ms &#160;8.453 ms
&#160;4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;9.486 ms * *
&#160;5 &#160;* * *
&#160;6 &#160;* 83.71.115.181 (83.71.115.181) &#160;7.250 ms &#160;6.884 ms
&#160;7 &#160;xe-1-1-0.dub20.ip4.gtt.net (77.67.64.161) &#160;7.383 ms &#160;7.375 ms &#160;7.932 ms
&#160;8 &#160;xe-3-0-5.lon10.ip4.gtt.net (141.136.106.253) &#160;21.815 ms &#160;22.294 ms &#160;22.289 ms
&#160;9 &#160;77.67.21.48 (77.67.21.48) &#160;22.866 ms &#160;22.862 ms &#160;23.784 ms

Note that Vimeo/Akamai also serve content via av.vimeo.com - this domain suffers from the same problems, with some IP's being routed more directly than others:

traceroute av.vimeo.com
traceroute to av.vimeo.com (159.134.172.153), 30 hops max, 60 byte packets
&#160;1 &#160;MitraStar.Home (192.168.1.254) &#160;3.924 ms &#160;4.060 ms &#160;4.412 ms
&#160;2 &#160;95.45.62.1 (95.45.62.1) &#160;12.397 ms &#160;13.062 ms &#160;13.061 ms
&#160;3 &#160;86.43.11.49 (86.43.11.49) &#160;8.710 ms &#160;8.823 ms &#160;8.946 ms
&#160;4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;9.097 ms &#160;9.213 ms &#160;9.336 ms
&#160;5 &#160;lag-1.core2.dbn.core.eircom.net (86.43.252.30) &#160;11.908 ms &#160;12.011 ms &#160;12.135 ms
&#160;6 &#160;tenge-1-2-1.pe2.crz.crz-crz.eircom.net (86.43.252.138) &#160;10.237 ms &#160;7.182 ms &#160;7.288 ms
&#160;7 &#160;159.134.172.153 (159.134.172.153) &#160;7.508 ms &#160;7.990 ms &#160;7.919 ms

traceroute 'av.vimeo.com'
traceroute to av.vimeo.com (77.67.21.64), 30 hops max, 60 byte packets
&#160;1 &#160;MitraStar.Home (192.168.1.254) &#160;5.052 ms &#160;5.070 ms &#160;5.191 ms
&#160;2 &#160;95.45.62.1 (95.45.62.1) &#160;7.893 ms &#160;8.628 ms &#160;8.627 ms
&#160;3 &#160;86.43.11.49 (86.43.11.49) &#160;9.684 ms &#160;10.071 ms &#160;10.158 ms
&#160;4 &#160;tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205) &#160;10.284 ms * *
&#160;5 &#160;* * *
&#160;6 &#160;* * *
&#160;7 &#160;* xe-1-1-0.dub20.ip4.gtt.net (77.67.64.161) &#160;10.180 ms &#160;6.645 ms
&#160;8 &#160;xe-3-0-5.lon10.ip4.gtt.net (141.136.106.253) &#160;21.013 ms &#160;22.406 ms &#160;22.398 ms
&#160;9 &#160;77.67.21.64 (77.67.21.64) &#160;22.401 ms &#160;22.391 ms &#160;22.380 ms

EDIT: Akamai don't declare the gtt-routed IP's at INEX, so maybe this is an Akamai GeoDNS issue. This still doesn't account for why the London gtt link would be so congested.

EDIT2:
Here's a fast googlevideo server:

traceroute r3---sn-xpgjvh-q0ce.googlevideo.com
traceroute to r3---sn-xpgjvh-q0ce.googlevideo.com (86.43.63.14), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  4.899 ms  4.980 ms  5.603 ms
 2  95.45.62.1 (95.45.62.1)  6.661 ms  8.136 ms  11.443 ms
 3  86.43.11.49 (86.43.11.49)  8.700 ms  9.072 ms  9.193 ms
 4  tenge-3-1-1.core1.prp.core.eircom.net (86.43.252.201)  9.313 ms  9.437 ms  9.560 ms
 5  tenge-3-2-1.core1.bdt.core.eircom.net (86.43.252.9)  10.974 ms  11.986 ms  12.609 ms
 6  lag-1.core2.bdt.core.eircom.net (86.43.252.2)  14.155 ms  8.451 ms  8.455 ms
 7  tenge-1-2-1.pe1.cwm.cwm-cwm.eircom.net (86.43.252.174)  8.475 ms  8.598 ms  8.716 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

And here's a slow one:

traceroute r11---sn-q0c7dn76.googlevideo.com
traceroute to r11---sn-q0c7dn76.googlevideo.com (173.194.138.112), 30 hops max, 60 byte packets
 1  MitraStar.Home (192.168.1.254)  3.978 ms  4.589 ms  5.532 ms
 2  95.45.62.1 (95.45.62.1)  11.303 ms  24.001 ms  26.299 ms
 3  86.43.11.49 (86.43.11.49)  9.041 ms  9.225 ms  9.355 ms
 4  tenge-4-1-1.core1.dbn.core.eircom.net (86.43.252.205)  9.479 ms  9.594 ms  9.727 ms
 5  * * *
 6  83.71.115.181 (83.71.115.181)  11.216 ms  10.496 ms  22.900 ms
 7  74.125.51.185 (74.125.51.185)  88.064 ms  88.065 ms  88.061 ms
 8  66.249.95.91 (66.249.95.91)  24.811 ms  24.822 ms  24.825 ms
 9  173.194.138.112 (173.194.138.112)  24.807 ms  24.810 ms  24.808 ms

I have no clue what all that data means, but I can confirm that I too have been having problems with Vimeo, as well as YouTube lately. At least Eircom have acknowledged that there is something up. :-/

dub45 · 30-10-2014 10:51pm

eircom: Alan wrote: »

Hi All,

These issues remain under investigation at the highest level and as soon as I have more information I'll update this thread you right away.

Many thanks to everybody who have PM'd trace routes - it's greatly appreciated. Also if anybody is having specific issues with yourube can you try youtube.ie and see if the issues remain?

Thanks
Al

What exactly does "at the highest level" mean? Has the acting Chief Executive joined in or is it just a bland platitude?

Have Eircom not got proper network monitoring tools in place to prevent these sort of issues occuring?

flyingsnail · 30-10-2014 11:07pm

Glad I stumbled across this thread, I thought it was just me.

will56 · 31-10-2014 10:04am

I'm on "Up to" 7mbs Broadband
Last night recorded speeds of .3mbs with pings in the high hundred.

Some fantastic service right there :rolleyes:
Live chat with eircom rep boils down to "too many devices connected" "should be connected by cable to modem", "Modem needs to be moved" - Modem has been in the same spot for the last 2 years without this problem !

nemoisback66 · 31-10-2014 11:33am

I'm glad to see this thread. Its only been in the last week or so that I am having the same issues. Youtube, FB, Sky on Demand taking a full 12 hours to download a 500mb video and a speed test of 65mb + and 20mb down. I tried everything to fix it changing routers, dns, disconnecting any devices on the line and still the same.
Only thing that works is using a vpn on the laptop and everything loads perfectly. Hopefully this is sorted asap.

dave_t · 31-10-2014 12:08pm

Any update before the weekend, eircom? Even some idea of what the issue is, what steps are being taken to resolve it and when it is expected to be fixed?

Thanks

ED E · 31-10-2014 12:51pm

will56 wrote: »

I'm on "Up to" 7mbs Broadband
Last night recorded speeds of .3mbs with pings in the high hundred.

Some fantastic service right there :rolleyes:
Live chat with eircom rep boils down to "too many devices connected" "should be connected by cable to modem", "Modem needs to be moved" - Modem has been in the same spot for the last 2 years without this problem !

Up to 7 = legacey exchange. Thats a totally different issue ( your service will be even worse).

rat_race · 31-10-2014 12:55pm

ED E wrote: »

will56 wrote: »

I'm on "Up to" 7mbs Broadband
Last night recorded speeds of .3mbs with pings in the high hundred.

Some fantastic service right there :rolleyes:
Live chat with eircom rep boils down to "too many devices connected" "should be connected by cable to modem", "Modem needs to be moved" - Modem has been in the same spot for the last 2 years without this problem !

Up to 7 = legacey exchange. Thats a totally different issue ( your service will be even worse).

Why is it a different issue? This has nothing to do with exchanges or contention, in my opinion. This is about routing, much further downstream -- and Eircom doesn't have two networks for newer broadband vs. old broadband, it has one network for all broadband (and probably dialup too). So all broadband is on the same (bad) network. That's just my common sense speaking there, I could be wrong and will happily be corrected!

ED E · 31-10-2014 12:58pm

rat_race wrote: »

Why is it a different issue? This has nothing to do with exchanges or contention, in my opinion. This is about routing, much further downstream -- and Eircom doesn't have two networks for newer broadband vs. old broadband, it has one network for all broadband (and probably dialup too). So all broadband is on the same (bad) network. That's just my common sense speaking there, I could be wrong and will happily be corrected!

If his only issue was the london link crapping out his tests wouldn't be 0.3mb, they'd be where they should be. His connection is congested on a point to point radio miles before it even hits the core network. In a sense he's double congested, even when they fix the problem this thread is about his service will still crawl.

will56 · 31-10-2014 1:59pm

ED E wrote: »

rat_race wrote: »

Why is it a different issue? This has nothing to do with exchanges or contention, in my opinion. This is about routing, much further downstream -- and Eircom doesn't have two networks for newer broadband vs. old broadband, it has one network for all broadband (and probably dialup too). So all broadband is on the same (bad) network. That's just my common sense speaking there, I could be wrong and will happily be corrected!

If his only issue was the london link crapping out his tests wouldn't be 0.3mb, they'd be where they should be. His connection is congested on a point to point radio miles before it even hits the core network. In a sense he's double congested, even when they fix the problem this thread is about his service will still crawl.

I was hitting around 3mbs in the evenings, nothing to rave about but very useable. I would be willing to settle for that until such time as I get upgraded (fingers crossed for 2016 !)
Speeds in the last couple of weeks mean I can't use my laptop in the evenings at all, facebook won't open and other sites take an eternity to do anything.

Wold prefer Eircom to acknowledge the issue rather than tell me I'm not testing my speeds correctly

Many sites extremely slow/unusable (past week on eFibre)

Comments