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. ::)
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.
Quote from: rikbean on Mar 09, 2007, 18:48:10
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? :o
Quote
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
Mea culpa. :( My eyes don't work so well at this time of night...
Quote from: rikbean on Mar 09, 2007, 19:09:50
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. :D
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>
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 (http://www.speedguide.net/downloads.php), see what it tells you. Try changing MTU to 1458 and see if that helps.
I'm off to scratch my head... :(
Just out of interest; what news service provider are you using?
Adam
Quote from: Adam on Mar 09, 2007, 20:07:41
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.
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>
Quote
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.
Quote from: Adam on Mar 09, 2007, 21:55:24
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.
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! :o
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
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! :D
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.
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. ::) ;D
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>
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.
Quote from: rikbean on Mar 11, 2007, 01:49:10
Most people are happy with the service here,
Yes, agreed, and I'm happy for them too of course.
Quote from: rikbean on Mar 11, 2007, 01:49:10so 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.
Quote from: rikbean on Mar 11, 2007, 01:49:10It 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!
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%
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
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. :)
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:
Quote
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 * * *
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.
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?
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
Hopefully that will sort the problems!
Quote from: lance on Mar 12, 2007, 12:06:59
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. ::)
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
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! ;)
Quote from: CaptainSlow on Mar 12, 2007, 17:01:42
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. :)
Quote from: rikbean on Mar 12, 2007, 17:04:25
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. ;D
Persevere, it's worth it. :angel:
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%
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. :-\
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?
Quote from: Glenn on Mar 12, 2007, 20:49:35
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.
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. :D
Quote from: CaptainSlow on Mar 17, 2007, 23:44:19
Credit where it's due; Nice job IDNet. :D
We told you you'd like it here. :)