This seems a bit odd frankly!

[CaptainSlow]

Hello all,

I'm joining IDNet, and leaving Pipex today, as far as I can presently tell.

IDNet said I was to be connected today by 18:00 hrs. This has happened, and I can for now logon using either set of logon details as one might expect.

Only snag is this. IDNet is advertised as non throttled, Pipex is well known to have dreadful throttling in place, and was one of the reasons I wanted to leave.

I buy into a news service, and I checked out how that works with the new supply. Bad news! I've just done some checks and using Pipex I can get 80-115KBps on getting headers, using IDNet I get 5-7KBps for the same task. I've tried both providers, multiple times so far, and it's consistently the case. Oddly tracert and pings don't show anything wrong at all. Exactly what I would expect in fact. It looks like it does when pipex throttle, but since I'm not on Pipex at the time then it's pretty underwhelming to find that acting like it is.

Because the news server at the other end isn't changing, and neither is anything on my lan at this end, then it must be somewhere in between, I'd have to say.

Anyone got any thoughts about what it might be?

I've also had a few DNS issues with the DNS seemingly vanishing for some parts of the world. One or two complete logouts as well. I know about the issue earlier and I am hoping that is all that was. They came back from time to time but at best the DNS seems variable. Too variable to be all that useful.

I'm a bit bemused to be honest. I'm pretty sure it was not meant to go like it has! I can't think where to start as it's just so blooming weird!

I called tech but no one answered, must be gone for the week end I'd guess. So I seem a bit stuck and it's not exactly a flying start really.

[Rik]

What MTU & RWIN are you using? Have you set your router to get the DNS addresses automatically, or have you entered them manually? Can you ping www.idnet.net and paste your results here please.

[CaptainSlow]

What MTU & RWIN are you using? Have you set your router to get the DNS addresses automatically, or have you entered them manually? Can you ping www.idnet.net and paste your results here please.

MTU wide open at 1500, not sure about RWIN, but whatever it is, it's good enough to work on pipex. If it works on pipex it's likely to work anywhere since they are the worst case scenario.

Ping follows, did one to another place too, just so you can see for yourself it works fine on another one.

C:\Documents and Settings\Ian>ping www.ident.net

Pinging ident.net [24.156.31.120] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 24.156.31.120:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Documents and Settings\Ian>ping google.co.uk

Pinging google.co.uk [66.249.93.104] with 32 bytes of data:

Reply from 66.249.93.104: bytes=32 time=26ms TTL=245
Reply from 66.249.93.104: bytes=32 time=24ms TTL=245
Reply from 66.249.93.104: bytes=32 time=24ms TTL=245
Reply from 66.249.93.104: bytes=32 time=24ms TTL=245

Ping statistics for 66.249.93.104:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 24ms, Maximum = 26ms, Average = 24ms

C:\Documents and Settings\Ian>

Odd isn't it? 

[Adam]

C:\Documents and Settings\Ian>ping www.ident.net

Pinging ident.net [24.156.31.120] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 24.156.31.120:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Note that you are pinging ident.net, you should be trying to ping idnet.net (no e).

Adam

[Rik]

Mea culpa. My eyes don't work so well at this time of night...

[CaptainSlow]

Mea culpa. My eyes don't work so well at this time of night...

Mine neither, it's been a long and eventful day, mostly productive too.

You were right, typo! Here's the real deal:

C:\Documents and Settings\Ian>ping www.idnet.net

Pinging www.idnet.net [212.69.36.10] with 32 bytes of data:

Reply from 212.69.36.10: bytes=32 time=13ms TTL=61
Reply from 212.69.36.10: bytes=32 time=13ms TTL=61
Reply from 212.69.36.10: bytes=32 time=13ms TTL=61
Reply from 212.69.36.10: bytes=32 time=13ms TTL=61

Ping statistics for 212.69.36.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 13ms, Average = 13ms

C:\Documents and Settings\Ian>

[Rik]

Well, your pings suggest interleaving is off, and you clearly can reach the net, DNS is being resolved.

My first thought would be that RWIN maybe causing an issue - but I have been at this keyboard for 12 hours now.

If you don't already have a tool to make the adjustments, get hold of TCP Optimizer here, see what it tells you. Try changing MTU to 1458 and see if that helps.

I'm off to scratch my head...

[Adam]

Just out of interest; what news service provider are you using?

Adam

[CaptainSlow]

Just out of interest; what news service provider are you using?

Adam

It's forte inc, and that's a badge resell of supernews.

C:\Documents and Settings\Ian>ping news20.forteinc.com

Pinging forte.vsrv-sjc.supernews.net [216.168.3.64] with 32 bytes of data:

Reply from 216.168.3.64: bytes=32 time=159ms TTL=120
Reply from 216.168.3.64: bytes=32 time=158ms TTL=120
Reply from 216.168.3.64: bytes=32 time=159ms TTL=120
Reply from 216.168.3.64: bytes=32 time=157ms TTL=120

Ping statistics for 216.168.3.64:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 157ms, Maximum = 159ms, Average = 158ms

C:\Documents and Settings\Ian>

And it's well within limits currently.

Fact is, it does work absolutely fine if I log into Pipex, but not if I log into IDNet.

The difference being 120KBps and about 5KBps respectively. I'm scratching me head to see how it can be anything but IDNet issue, but having said that, what the heck can it be, it seems like there could not be such an issue on the face of it.

MTU and RWIN stuff makes a difference sometimes, sure, but I've never see it make one that size, much less over a suspected RWIN issue alone. Especially when it does work solidly by going another route. Those two are more about how much and how complete the data you'd see is, and not as much about seeing it but very very slowly. Well, I say that, but that's only in my experience to date of course.

Every other aspect of the connection seems fine as far as I can tell so far too.

It's a real stumper.

[CaptainSlow]

Just a thought, there is one difference now I think about it a bit more;

Since I've only just joined, I was told I'd be on the new central, so I can only guess that I must be on it, rather than know for sure. That's got this slightly questionable router on it that we've heard a bit about in the last few days. When setting up a router part of that involves setting up how protocols are handled. Since IDNet don't have a news server I would have to guess it could have been overlooked? If anyone knows they are on the new central for sure and also does news, then that might be able to tell us one way or another I guess. 

I'm thinking that we've so far tested for protocols that are set up and the one giving the trouble might not be quite as it should be yet? Ping and Tracert are one thing, but it's not nntp!

Can't think of anything else. Here's the route I'm seeing, it's a lot shorter than the pipex equivalent too from memory. Should have the potential to be better as it's tidier.

tracert news20.forteinc.com

Tracing route to forte.vsrv-sjc.supernews.net [216.168.3.64]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  192.168.0.1
  2    19 ms    16 ms    13 ms  telehouse-gw3-msdp.idnet.net [xxx.xxx.xxx.xxx]
  3    14 ms    13 ms    13 ms  x-s-1.lon1.arbinet.net [213.232.64.54]
  4   160 ms   159 ms   158 ms  lon-sb1.LON.GB.net.DTAG.DE [62.154.15.153]
  5   116 ms    88 ms    88 ms  was-e4.WAS.US.net.DTAG.DE [62.154.5.138]
  6   162 ms   157 ms   162 ms  217.239.40.53
  7   158 ms   157 ms   159 ms  217.239.40.14
  8   159 ms   157 ms   157 ms  sjp-brdr-01.inet.qwest.net [205.171.1.45]
  9   158 ms   158 ms   158 ms  svx-core-02.inet.qwest.net [205.171.214.137]
10   158 ms   158 ms   161 ms  svx-edge-01.inet.qwest.net [205.171.214.126]
11   158 ms   158 ms   158 ms  208.46.207.6
12   159 ms   160 ms   159 ms  forte.vsrv-sjc.supernews.net [216.168.3.64]

Trace complete.

<head in hands>

[Adam]

  4   160 ms   159 ms   158 ms  lon-sb1.LON.GB.net.DTAG.DE [62.154.15.153]

The increased pings appear to be happening off IDNet's broadband network; so it's fairly safe to assume it isn't IDNet's network problems or problems with your local configuration. The actual problem could be the connectivity IDNet uses to get to that specific server/network. It would be interesting to see, if possible, what a traceroute to that server while on Pipex returns.

[CaptainSlow]

The increased pings appear to be happening off IDNet's broadband network; so it's fairly safe to assume it isn't IDNet's network problems or problems with your local configuration. The actual problem could be the connectivity IDNet uses to get to that specific server/network. It would be interesting to see, if possible, what a traceroute to that server while on Pipex returns.

There you go. Can't do this too often as it disrupts some other machines here!

C:\Documents and Settings\Ian>tracert news20.forteinc.com

Tracing route to forte.vsrv-sjc.supernews.net [216.168.3.64]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2    17 ms    16 ms     *     l1.ar02.gs1.dsl.pipex.net [xxx.xxx.xxx.xxx]
  3    16 ms    13 ms    12 ms  ge-1-1-0-0.cr01.gs1.dsl.pipex.net [62.241.161.102]
  4    14 ms    14 ms    14 ms  pc24.cr05.tn5.bb.pipex.net [62.72.141.21]
  5    14 ms    14 ms    14 ms  195.66.224.185
  6   156 ms   155 ms   159 ms  t3-2.mpd01.bos01.atlas.cogentco.com [130.117.0.185]
  7   157 ms   157 ms   157 ms  t2-2.mpd01.ord01.atlas.cogentco.com [154.54.7.81]
  8   155 ms   155 ms   157 ms  t2-2.mpd02.sfo01.atlas.cogentco.com [154.54.6.38]
  9   156 ms   156 ms   156 ms  t2-2.mpd01.sjc01.atlas.cogentco.com [154.54.1.26]
10   157 ms   155 ms   155 ms  v3493.mpd01.sjc03.atlas.cogentco.com [154.54.6.110]
11   161 ms   157 ms   173 ms  supernews.demarc.cogentco.com [38.112.30.94]
12   158 ms   156 ms   155 ms  forte.vsrv-sjc.supernews.net [216.168.3.64]

They sure have tidied up their act on that lately, used to be nearer 20 hops not that long ago.

[CaptainSlow]

This makes for grim reading too.

C:\Documents and Settings\Ian>ping s163.photobucket.com

Pinging s163.photobucket.com [66.11.56.69] with 32 bytes of data:

Reply from 66.11.56.69: bytes=32 time=725ms TTL=244
Reply from 66.11.56.69: bytes=32 time=727ms TTL=244
Reply from 66.11.56.69: bytes=32 time=733ms TTL=244
Reply from 66.11.56.69: bytes=32 time=726ms TTL=244

Ping statistics for 66.11.56.69:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 725ms, Maximum = 733ms, Average = 727ms

Seems UK stuff is largely fine, but anything on the US continent is really quite poor. I use this place all the time, so this will get old pretty quick I'd imagine. I've tried quite a few other places now and this is starting to look quite widespread.

Here's a tracert:

C:\Documents and Settings\Ian>tracert s163.photobucket.com

Tracing route to s163.photobucket.com [66.11.56.69]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2    21 ms    25 ms    20 ms  telehouse-gw3-msdp.idnet.net [xxx.xxx.xxx.xxx]
  3    21 ms    22 ms    20 ms  x-s-1.lon1.arbinet.net [213.232.64.54]
  4    21 ms    20 ms    20 ms  LINX-gw13.LON.GB.net.DTAG.DE [194.25.6.206]
  5    27 ms    20 ms    21 ms  g1-15.mpd01.lon02.atlas.cogentco.com [130.117.14.29]
  6    26 ms    55 ms    59 ms  v3490.mpd01.lon01.atlas.cogentco.com [130.117.2.217]
  7    30 ms    21 ms    20 ms  t2-1.mpd02.lon01.atlas.cogentco.com [130.117.2.18]
  8   710 ms   695 ms   707 ms  t3-2.mpd01.bos01.atlas.cogentco.com [130.117.0.185]
  9   852 ms   907 ms   869 ms  t2-2.mpd01.ord01.atlas.cogentco.com [154.54.7.81]
10   694 ms     *        *     t7-2.mpd01.den01.atlas.cogentco.com [154.54.2.173]
11   685 ms   684 ms   659 ms  vl3490.mpd01.den02.atlas.cogentco.com [154.54.5.146]
12   677 ms   666 ms   668 ms  photobucket.demarc.cogentco.com [38.99.217.162]
13   848 ms   979 ms   688 ms  66.11.56.69

Trace complete.

Those are some of the highest figures I've ever seen!

[Adam]

That is most definitely a problem on Cogent's network; I'm getting OK pings to many other US locations such as digg.com and youtube.com.

One thing I will note is US connectivity did seem somewhat better when I used Pipex, not that I've noticed any speed decrease since moving; perhaps it's just because my previous ISP used more well known connectivity providers such as Level3 and Above.net directly. Another thing I have noticed is IDNet seems to go through arbinet.net before reaching other major providers such as Sprint and Savvis; perhaps the mix of providers used by IDNet isn't as extensive as other large ISPs.

Adam

[CaptainSlow]

Yes, I tend to agree on where the trouble might lay. It's pretty astonishing, as I've just never seen numbers like that before. I guess if were both on line and checking the same places at the same time it would be good to see & compare what we both got at the same time too. If the numbers were similar, then we could get a more meaningful comparison perhaps, actually if they were to differ too I guess.

Hard to say what could be done about it all though, it does seem largely to be outside my sphere of influence.

Oh well, shall keep an eye on it and see if anything further develops. It did ease up to some fair numbers on nttp just a while back, right on the border of adequate in fact, so there must be some hope! Best one can say is that it seems the settings here must have been OK for that to happen at all, and for that much I am grateful. I guess if it's really cold in the USA, then they stay home in greater numbers, and maybe this is what can happen as a result!

[Rik]

It would be worth dropping an email to support@idnet.net (I suggest email so you could include your tracert tests). I know that, yesterday, they did find a bug in the Cisco software on the new router, and this might have other consequences that, as yet they are not aware of. The new router, btw, doesn't just affect customers on the new central.

[CaptainSlow]

Yes, agreed, that would probably be best. Not much point until Monday then I guess.

I did all the other stuff you suggested like messing about with MTU and RWIN, made no discernable difference at all. Most likely thing it did was to make the optimiser happier with the numbers, and that was about it.

Anyway, I did track down a few interesting rout logging programs and using them, I found numbers like 1300 and above getting involved!

All it serves to show is Pipex routing running rings around IDNet routing. I bet you can imagine how impressed I am to see that.<sigh>

[Rik]

Most people are happy with the service here, so I do think you should let support have a look at your problem and see if they can fix it for you. It may be one of those trivial settings that just hasn't 'taken', but I know they will do their best to resolve the issue for you.

[CaptainSlow]

Most people are happy with the service here,

Yes, agreed, and I'm happy for them too of course.

so I do think you should let support have a look at your problem and see if they can fix it for you.

Yes, quite the most sensible approach, and with that in mind would you mind posting a tracert to  photobucket.com too please? Sorry to impose like that, but we could rule some things in and rule things out if we had a few more examples, certainly doing that would give support more information to work with while trying to sort it out. If anyone else would care to add a tracert like that then that would make it even more helpful for support. It would be greatly appreciated.

It may be one of those trivial settings that just hasn't 'taken', but I know they will do their best to resolve the issue for you.

Yes, quite possibly, just one of those things, and I've seen many here say that support do their best so I can see absolutely no reason at all to doubt that, especially with so many all saying the same thing!

Hopefully armed with a few more tracerts it'll be fixed in a jiffy!

[Glenn]

Hop  IP Address       Host Name                              Sent   Recv      RTT   Av RTT  Min RTT  Max RTT   % Loss

1    192.168.0.1      [Unknown]                                 1      1     0 ms     0 ms     0 ms     0 ms   0.000%
2    xxx.xxx.xxx.xxx     telehouse-gw3-msdp.idnet.net              1      1    20 ms    20 ms    20 ms    20 ms   0.000%
3    213.232.64.54    x-s-1.lon1.arbinet.net                    1      1    20 ms    20 ms    20 ms    20 ms   0.000%
4    194.25.6.206     LINX-gw13.LON.GB.net.DTAG.DE              1      1    30 ms    30 ms    30 ms    30 ms   0.000%
5    130.117.14.29    g1-15.mpd01.lon02.atlas.cogentco.com      1      1    30 ms    30 ms    30 ms    30 ms   0.000%
6    130.117.2.221    v3491.mpd01.lon01.atlas.cogentco.com      1      1    50 ms    50 ms    50 ms    50 ms   0.000%
7    130.117.2.26     t1-1.mpd02.lon01.atlas.cogentco.com       1      1    30 ms    30 ms    30 ms    30 ms   0.000%
8    130.117.0.185    t3-2.mpd01.bos01.atlas.cogentco.com       1      1   141 ms   141 ms   141 ms   141 ms   0.000%
9    154.54.6.154     t7-2.mpd01.ord01.atlas.cogentco.com       1      1   141 ms   141 ms   141 ms   141 ms   0.000%
10   154.54.5.173     t8-2.mpd01.mci01.atlas.cogentco.com       1      1   151 ms   151 ms   151 ms   151 ms   0.000%
11   154.54.2.173     t7-2.mpd01.den01.atlas.cogentco.com       1      1   151 ms   151 ms   151 ms   151 ms   0.000%
12   154.54.5.150     vl3491.mpd01.den02.atlas.cogentco.com      1      1   151 ms   151 ms   151 ms   151 ms   0.000%
13   38.104.32.2      photobucket.demarc.cogentco.com           1      1   161 ms   161 ms   161 ms   161 ms   0.000%
14   66.11.50.5       [Unknown]                                 1      1   151 ms   151 ms   151 ms   151 ms   0.000%

[Rik]

Tracing route to www.photobucket.com [66.11.50.5]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  www.routerlogin.com [192.168.0.1]
  2    21 ms    21 ms    21 ms  telehouse-gw3-msdp.idnet.net [212.69.63.51]
  3    22 ms    22 ms    22 ms  x-s-1.lon1.arbinet.net [213.232.64.54]
  4    22 ms    23 ms    24 ms  LINX-gw13.LON.GB.net.DTAG.DE [194.25.6.206]
  5    23 ms    28 ms    22 ms  g1-15.mpd01.lon02.atlas.cogentco.com [130.117.14.29]
  6    23 ms    26 ms    22 ms  v3491.mpd01.lon01.atlas.cogentco.com [130.117.2.221]
  7    22 ms    23 ms    22 ms  t1-1.mpd02.lon01.atlas.cogentco.com [130.117.2.26]
  8  1137 ms  1288 ms  1067 ms  t3-2.mpd01.bos01.atlas.cogentco.com [130.117.0.185]
  9  1326 ms  1228 ms  1228 ms  t3-4.mpd01.mci01.atlas.cogentco.com [154.54.7.77]
10     *     1113 ms  1125 ms  t7-2.mpd01.den01.atlas.cogentco.com [154.54.2.173]
11  1306 ms  1228 ms  1228 ms  vl3491.mpd01.den02.atlas.cogentco.com [154.54.5.150]
12  1204 ms  1228 ms  1228 ms  photobucket.demarc.cogentco.com [38.104.32.2]
13  1203 ms  1228 ms  1228 ms  66.11.50.5

[CaptainSlow]

Thanks muchly, that does seem to confirm it's at cogentco now! That should make it a lot easier for support to act on I'd imagine.

Thanks very much indeed for all your help in all this. It's appreciated.

[Adam]

It's most definitely a problem between the Cogent London-USA link. I suspect the most IDNet can do is let their provider know and hopefully they'll get Cogent to fix it or send traffic another route.

A traceroute just for your information:

traceroute: Warning: photobucket.com has multiple addresses; using 66.11.50.5
traceroute to photobucket.com (66.11.50.5), 30 hops max, 40 byte packets
1  xxx.xxx.xxx (212.69.xx.xx)  3.697 ms  0.605 ms  0.478 ms
2  telehouse-gw3-msdp.idnet.net (212.69.63.51)  41.619 ms  42.003 ms  47.726 ms
3  x-s-1.lon1.arbinet.net (213.232.64.54)  42.188 ms  44.549 ms  41.582 ms
4  LINX-gw13.LON.GB.net.DTAG.DE (194.25.6.206)  44.138 ms  43.280 ms  42.548 ms
5  g1-15.mpd01.lon02.atlas.cogentco.com (130.117.14.29)  42.941 ms  42.708 ms  42.113 ms
6  v3490.mpd01.lon01.atlas.cogentco.com (130.117.2.217)  42.443 ms  42.325 ms  41.280 ms
7  t2-1.mpd02.lon01.atlas.cogentco.com (130.117.2.18)  42.948 ms  42.204 ms  43.803 ms
8  t3-2.mpd01.bos01.atlas.cogentco.com (130.117.0.185)  1101.064 ms  1145.316 ms  1154.832 ms
9  t2-4.mpd01.ord01.atlas.cogentco.com (154.54.6.22)  1091.079 ms  1065.942 ms  1127.159 ms
10  t9-3.mpd01.mci01.atlas.cogentco.com (66.28.4.185)  1172.439 ms  1120.034 ms  1006.990 ms
11  t7-2.mpd01.den01.atlas.cogentco.com (154.54.2.173)  978.513 ms  1118.850 ms  1185.345 ms
12  vl3490.mpd01.den02.atlas.cogentco.com (154.54.5.146)  1143.743 ms  1163.124 ms  1114.982 ms
13  photobucket.demarc.cogentco.com (38.99.217.162)  1131.432 ms  1145.892 ms  1149.925 ms
14  * * *

[CaptainSlow]

Thanks very much for the numbers Adam.

I hope that's not how it turns out though, if it did I'd have to request a MAC. After less than 3 days with IDNet, that's just not funny.

I use photobucket everyday, and so do the majority of the users on a forum I frequent, full to busting with firm net friends all over the world, and since it's a photographic forum then that's no big surprise. However since we all link our pics to that forum then photos and avatars take till forever to arrive, and some in fact don't even make the trip at all. People will not switch from that source easily, if at all. This situation is affecting use of that forum as well as photobucket. Which forums you want to use is not usually an ISP choice decision.

If it's a choice between that forum with all those friends and an ISP, you can easily see who's going to loose, if it did continue as bad as it is right now. And that's clearly not an unreasonable point of view either.

I can't imagine any ISP getting away with what would effectively be a destination CAP for very long. That would be absurd beyond measure. I note from another forum it is affecting one or two of IDNet's "you tube" users quite badly as well. I don't use that service but I can easily see that becoming quite an issue. I mean, "you tube" is hardly an internet backwater is it?

I do truly hope we are wrong to have any kind of pessimism here, as Rik said, so very many are happy with the service here and really rate the service element of IDNet very highly indeed, and have also said this to so many others on forums elsewhere. It would be terrible, bordering on criminal, to see all that effort go to waste for something so fundamental to any ISP as basic connectivity issues; ISPs who are truly solid and have a good reputation are becoming fewer, and farther between them, of late. They really are a very precious commodity indeed.

[AvengerUK]

It looks to me to be a Cogento issue. IDnet's network part is fine, including cogneto's UK network...its the link between there UK network and USA network that seems to have the connectivity issue?

[Simon_idnet]

We've set some prepends on the routes that our routers hear to YouTube and PhotoBucket so that Cogent is no longer preferred (while they fix their problems). We are now seeing that traffic flow through our peering with Level3 instead.

Cheers
Simon

[Lance]

Hopefully that will sort the problems!

[MoHux]

Hopefully that will sort the problems!

Pinging s163.photobucket.com [66.11.56.69] with 32 bytes of data:

Reply from 66.11.56.69: bytes=32 time=1224ms TTL=244
Reply from 66.11.56.69: bytes=32 time=1215ms TTL=244
Reply from 66.11.56.69: bytes=32 time=1179ms TTL=244
Reply from 66.11.56.69: bytes=32 time=1158ms TTL=244

Ping statistics for 66.11.56.69:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1158ms, Maximum = 1224ms, Average = 1194ms

Nope!  'pears not. 

[Rik]

Similar result here, Mo, but the routing has clearly changed from last night:

  1    <1 ms    <1 ms    <1 ms  www.routerlogin.com [192.168.0.1]
  2    26 ms    22 ms    20 ms  telehouse-gw3-msdp.idnet.net [212.69.63.51]
  3    27 ms    23 ms    23 ms  redbus-gw.idnet.net [212.69.63.1]
  4    24 ms    25 ms    30 ms  213.228.216.33
  5    43 ms    40 ms    59 ms  ae-19-53.ebr1.London1.Level3.net [4.68.116.94]
  6    27 ms    32 ms    33 ms  ae-1-100.ebr2.London1.Level3.net [4.69.132.118]
  7    99 ms    93 ms   107 ms  ae-4.ebr1.NewYork1.Level3.net [4.69.132.109]
  8    93 ms   108 ms   111 ms  ae-1-100.ebr2.NewYork1.Level3.net [4.69.132.26]
  9   136 ms     *        *     ae-2.ebr1.Chicago1.Level3.net [4.69.132.65]
10   141 ms   137 ms   146 ms  ae-3.ebr2.Denver1.Level3.net [4.69.132.61]
11   143 ms   161 ms   166 ms  ae-21-56.car1.Denver1.Level3.net [4.68.107.166]
12  1141 ms  1176 ms  1221 ms  PHOTOBUCKET.car1.Denver1.Level3.net [4.79.80.142]
13  1196 ms  1216 ms  1184 ms  66.11.50.5

[CaptainSlow]

Yes, Simon has had a good go at improving it, had some good effect on it already too, and I've got to get some more figures for him later, who knows what he might find he can do once he's had a look over them.

He's done as much as he can and then some. It's not all fixed yet, but there is some serious progress being made. Much better than things were over the last few days in all respects.

It's a pretty daft situation really, I've been done some sniffing around in other places and found out that cogentco do have a bit of a rep for getting a lot out of their hardware before investing in enough of it, so it's not something trivial to be up against! 

I'll maybe get onto the news provider and photbucket and rattle their cages about it too in the next 24 hours as pressure on cogentco from that end too would do no harm at all. If those finding You Tube service similarly poor went that route as well then Cogentco would probably find themselves having a note or two sent to them by You Tube and quite possibly Google too, and that really could not hurt in getting some further remedial action going either!

Oh well, we must just wait and see where it goes apart from all that.

I have to say I was impressed by IDNet's part in all this, it was quite reassuring. Not used to seeing that from an ISP. Feels weird but so much better! 

[Rik]

I have to say I was impressed by IDNet's part in all this, it was quite reassuring. Not used to seeing that from an ISP. Feels weird but so much better! 

After a while, you get used to it, but it explains why we're generally such a happy lot.

[CaptainSlow]

After a while, you get used to it, but it explains why we're generally such a happy lot.

Hehe, yeah, what I have become used to is refusal to be interested at all and where ever possible, and, when doing something about it is contractually unavoidable, delay to the point of making it all as painful as possible for the customer or better still, for all concerned. 

All of which is some distance away from this situation!

It may well take a bit of getting used to.

[Rik]

Persevere, it's worth it. 

[Glenn]

I get similar speeds to what I got yesterday

Hop  IP Address       Host Name                              Sent   Recv      RTT   Av RTT  Min RTT  Max RTT   % Loss

1    192.168.0.1      [Unknown]                                 1      1    40 ms    40 ms    40 ms    40 ms   0.000%
2    xxx.xx.xxx.xx     telehouse-gw3-msdp.idnet.net              1      1    40 ms    40 ms    40 ms    40 ms   0.000%
3    212.69.63.1      redbus-gw.idnet.net                       1      1    40 ms    40 ms    40 ms    40 ms   0.000%
4    213.228.216.33   [Unknown]                                 1      1    40 ms    40 ms    40 ms    40 ms   0.000%
5    4.68.116.158     ae-19-55.ebr1.London1.Level3.net          1      1    40 ms    40 ms    40 ms    40 ms   0.000%
6    4.69.132.118     ae-1-100.ebr2.London1.Level3.net          1      1    40 ms    40 ms    40 ms    40 ms   0.000%
7    4.69.132.109     ae-4.ebr1.NewYork1.Level3.net             1      1   110 ms   110 ms   110 ms   110 ms   0.000%
8    4.69.132.26      ae-1-100.ebr2.NewYork1.Level3.net         1      1   110 ms   110 ms   110 ms   110 ms   0.000%
9    4.69.132.65      ae-2.ebr1.Chicago1.Level3.net             1      1   110 ms   110 ms   110 ms   110 ms   0.000%
10   4.69.132.61      ae-3.ebr2.Denver1.Level3.net              1      1   160 ms   160 ms   160 ms   160 ms   0.000%
11   4.68.107.166     ae-21-56.car1.Denver1.Level3.net          1      1   160 ms   160 ms   160 ms   160 ms   0.000%
12   4.79.80.142      PHOTOBUCKET.car1.Denver1.Level3.net       1      1   100 ms   100 ms   100 ms   100 ms   0.000%
13   66.11.56.99      [Unknown]                                 1      1    90 ms    90 ms    90 ms    90 ms   0.000%

[MoHux]

When I do a tracert this is what I get, is it my routers firewall stopping it?;

Tracing route to s163.photobucket.com [66.11.56.69]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  mygateway1.ar7 [192.168.1.1]
  2    19 ms    17 ms    17 ms  telehouse-gw3-msdp.idnet.net [212.69.63.51]
  3    20 ms    19 ms    19 ms  redbus-gw.idnet.net [212.69.63.1]
  4    25 ms  mygateway1.ar7 [192.168.1.1]  reports: Destination protocol unreachable.

Trace complete.

It will ping it right through. 

[CaptainSlow]

I'd try it to just the raw photobucket.com, the s163 is just one of their servers I think, I used that as it's the one my photos are, for linking to another forum (very handy too, just click and paste as it adds the forum tags for you, when it copies it to the clipboard)

Anyway, it would remove one layer of complication, so maybe that would help?

[Rik]

I get similar speeds to what I got yesterday

I got very similar speeds to you, Glenn, despite the obviously different routings. I sent Simon my tracerts so he could see what was happening.

[CaptainSlow]

Just a quick update;

Looks like Simon has finally prevailed and found something that was having a dreadful effect on my experience, and changed it.

Not yet able to be certain it's a total fix, but it's mighty impressive in some areas already. Next two days should tell if it's the full monty as fixes go though.

First thing that happened was I set an absolute all time speed record for my connection!

Bear in mind I am on a 1Mb fixed connection, I made a request for headers on a 3rd party news server, and just chose some busy looking groups to test on, NewBinPro showed a DL rate of 123KBps for the headers and then went on to show off on a bunch of 1000 files grabbed at random, and turned in 124.1KBps during that! For a longish 1Mb line that is not all that common. It's certainly 4.1KBps more than I had ever expected to see.

Got to hand it to Simon for sheer perseverance despite how it looked a few times. I'd not have blamed him if he thought it was my end, but it already seems quite clear that it was not ultimately.

Credit where it's due;  Nice job IDNet.

[Rik]

Credit where it's due;  Nice job IDNet.

We told you you'd like it here.