Aces High Bulletin Board
Help and Support Forums => Technical Support => Topic started by: Dowding on July 06, 2007, 07:24:12 PM
-
After months of variable internet connection speed and having recieved little help from my ISP technical support (apart from the usual do 5 consecutive days of tests on British Telecom's speedtest site - which never works at peak times by the way, scuppering any attempt to follow their advice), I posted some ping plots on their forum.
(http://www.whisperingdeath.pwp.blueyonder.co.uk/ping.JPG)
This is to one of the AHII servers. This was the reply I received:
"Hello
Please don't start posting traceroutes and pings again - we've covered this ground in previous posts, and ping results are pointless. They don't show anything at all; ICMP traffic is very low priority, so results are skewed right from the off."
Perhaps Skuzzy or another professional could comment here? Is what this guy is saying right? It seems to me there is major packet loss on their own network - hops 2-5 are my ISPs with 3 and 4 showing large packet loss. How can he say these results are garbage?
Thanks for any help.
-
Ping uses a different protocol (ICMP) to what AH uses (TCP and UDP) and they may well have different routing priorities.
-
That sounds like it might be the case. So, I have just switched pingplotter over to UDP and this is what I found:
(http://www.whisperingdeath.pwp.blueyonder.co.uk/udp.JPG)
Could there be a problem with ping plotter?
-
Oh boy. First of all, the ICMP protocol covers a wide variety of message types and your ISP does not (at least they better not) put all ICMP messages at low priority. If they ignore or put all ICMP messages at low priority, then they have no idea what they are doing as there are many critical messages in the ICMP protocol.
Pings and Trace routes make use of the "ECHO" message for testing. Some ISP's do indeed put that particular message at a low priority. Some even block it.
No, it is not the best message to use when running PingPlots. UDP is much better. There is nothing wrong with PingPlot. Your results are accurate. Your ISP is just trying to put out a fire by telling you the tools you use are worthless, in the hopes you will bite and back off.
Never trust any ISP who immediately gets defensive about their network.
As the route is asyncronous I did a trace back to your second hop IP address and the traceroute could not get passed IP address 194.72.20.246 in BT's network. It just died there.
NOTE: I did note one oddity. BT used to have their own connection and bandwidth to New York. I noticed they are handing off to Tiscali. Did BT buy Tiscali?
-
I'm on BT (for my sins), I'll do a pingplotter for comparision purposes for ya fella. Wont be for a couple of days tho, as working nights and being an old geezer aint too compatible lol...
Wurzel
-
Thanks for looking into this Skuzzy, much appreciated.
I'm not very knowledgeable about protocols and such like, that's why I switched pingplotter to UDP.
I trust your opinion more than theirs - you are much more independent afterall, besides your detailed knowledge. :) I was a little peeved about their offhand dismissal of my problems. They basically listed a standard response about ADSL filters and USB modems etc. I don't have a USB modem and I checked the filters. I also connected from the master BT socket and while the speed increased slightly, the packet loss on their network remained. From what you say and from what I can see, I still think they have a major issue on their network.
Anways, I've resolved to move to a different ISP. Zen Internet has a good reputation, and although they have a higher cost/bandwidth ratio, it actually works out cheaper because I don't use all the bandwidth I currently get with my ISP.
As for Tiscali and BT - I did an internet search and can only find speculation which was denied by BT. Perhaps they are outsourcing the link between the UK and US? Not sure if that happens. It's not a good sign though - I had the impression that Tiscali weren't very good.
gpwurzel - that will be interesting to see. Especially on how the signal gets over to the States. :)
-
What skuzzy said, if anything pingplots usually show a better than what you really get graph. Try bumping up the packet size in hops of 256bytes and see the difference.
-
Here is a ping plot from my end (on BT) for comparision purposes
I can see I've a 100% packet loss as well, but had no issues at all as yet. This is for udp btw...
(http://[IMG]http://i45.photobucket.com/albums/f80/wurzeluk/206.png)[/IMG]
HTH,
Wurzel
-
That PingPlot shows a route I expected. BT actually handling the handoff to New York, where Dowding's route goes through a couple of different ISP's before heading to New York.
Something up with the routing would be my guess.
-
Thanks guys. On the support forum, someone said the routing through other ISPs was 'peering'. Is this normal? Wikipedia doesn't really go into much depth about pros and cons. I suppose it exposes you to the vagries of other ISP quality.
-
Peering is not unusual. It is normally an arrangement between ISP's who have some common traffic to allow them to by-pass their normal gateways to lower the traffic on those connections.
In this case though, you both are going to the same place. The peering arrangement should not be in play, unless someone has mis-propagated a route change.
-
Thanks for the help Skuzzy. I think I will move ISPs; no-one from technical support over there seem to be willing to answer my questions about packet loss or routing.
-
Nildram used to be a pretty solid ISP over there. Not sure if they are still good or not.
-
so skuzzy with my packet loss will it benifit me to switch internet server
-
Nildram unfortunately were bought out by Pipex so avoid them. Rumoured to be a target by Tiscali (one of the worst).
I changed to Zen and am happy with them.
Although i have not played AH for a year due to rotator cuff problems in shoulder which an operation seems to be slowly improving.
Will try to post a pingplot later.
-
Thank you for the update Cavalear. Hope the shoulder is doing well.
kilz, I do not know what options are available to you. If you ISP is stonewalling fixing those problems at Level3, then if it were me, I would be looking for a new ISP.
-
Thanks for that Cavalier. Recover soon mate.
Would be great to see a pingplot from Zen - will be definitely moving to them at the end of the month.
NDO (my ISP) were bought by Namesco, and I think they have gone down hill. It seems to be the pattern - smaller ISPs that are successful with a smaller customer base are swallowed by the big boys and service suffers. Consolidation seems destined to offer only mediocrity.
Only thing is that I've seen rumours about Zen being bought out themselves (still privately owned by one individual). :( Let's hope that doesn't come true.
-
Here you go, sorry not pingplot format that would require me to set up my homespace, one day i might get off my bellybutton and do it :)
They seem to be using sprintlink which is the only bug on the horizon.
I am sure routing was totally different before, will power down router and see if it alters later.
Also this was taken at approx 10:00 am on a sunday.
Target Name: viborgDHCP-39.216-16-60.iw.net
IP: 216.16.60.39
Date/Time: 15/07/2007 09:59:05 to 15/07/2007 09:59:20
1 3 ms 3 ms 3 ms 3 ms 3 ms 3 ms 3 ms [192.168.0.1]
2 13 ms 13 ms 14 ms 14 ms 13 ms 14 ms 13 ms gandhi-dsl1.wh.zen.net.uk [62.3.83.5]
3 13 ms 13 ms 16 ms 14 ms 13 ms 14 ms 15 ms erazmus-ge-0-0-1-3.wh.zen.net.uk [62.3.80.197]
4 20 ms 23 ms 21 ms 20 ms 20 ms 23 ms 21 ms lorenz-so-0-1-0-0.te.zen.net.uk [62.3.80.45]
5 23 ms 20 ms 23 ms 20 ms 23 ms 20 ms 27 ms lorenz-ge-0-0-0-0.te.zen.net.uk [62.3.80.41]
6 23 ms 23 ms 23 ms 22 ms 23 ms 23 ms 23 ms sl-gw22-lon-2-1.sprintlink.net [213.206.158.57]
7 24 ms 21 ms 21 ms 21 ms 20 ms 21 ms 23 ms sl-bb22-lon-9-0.sprintlink.net [213.206.128.104]
8 89 ms 91 ms 88 ms 89 ms 88 ms 88 ms 88 ms sl-bb20-nyc-2-0.sprintlink.net [144.232.9.163]
9 88 ms 90 ms 91 ms 89 ms 87 ms 87 ms 90 ms sl-bb26-nyc-6-0.sprintlink.net [144.232.13.9]
10 88 ms 90 ms 88 ms 105 ms 116 ms 158 ms 90 ms sl-bb25-nyc-8-0.sprintlink.net [144.232.13.189]
11 114 ms 114 ms 110 ms 113 ms 113 ms 114 ms 110 ms sl-bb24-chi-13-0.sprintlink.net [144.232.20.118]
12 109 ms 110 ms 111 ms 110 ms 110 ms 161 ms 117 ms sl-bb22-chi-9-0.sprintlink.net [144.232.26.110]
13 120 ms 120 ms 120 ms 121 ms 123 ms 120 ms 123 ms sl-bb21-kc-3-0.sprintlink.net [144.232.20.129]
14 123 ms 120 ms 120 ms 120 ms 120 ms 123 ms 120 ms sl-gw9-kc-9-0.sprintlink.net [144.232.23.66]
15 130 ms 127 ms 130 ms 127 ms 130 ms 129 ms 127 ms [144.232.239.242]
16 131 ms 130 ms 131 ms 130 ms 131 ms 131 ms 130 ms 66-115-218-58.nextlevel.santel.net [66.115.218.58]
17 128 ms 128 ms 129 ms 131 ms 127 ms 128 ms 129 ms 66-115-196-186.hosts.sdnet.net [66.115.196.186]
18 129 ms 131 ms 128 ms 128 ms 129 ms 130 ms 129 ms L3two.bb2.iw.net [216.16.40.6]
19 131 ms 133 ms 131 ms 134 ms 133 ms 131 ms 134 ms viborg1.iw.net [216.16.29.91]
20 140 ms 142 ms 138 ms 145 ms 138 ms 138 ms 150 ms viborgDHCP-39.216-16-60.iw.net [216.16.60.39]
Ping statistics for viborgDHCP-39.216-16-60.iw.net
Packets: Sent = 7, Received = 7, Lost = 0 (0.0%)
Round Trip Times: Minimum = 138ms, Maximum = 150ms, Average = 141ms
-
Cheers Cav! :)
Yeah, I seem to remember Skuzzy mentioning sprintlink being bad to have in your routing, some time ago. Will check that out.
There doesn't seem to be any packet loss in your trace though.
{edit} After doing a quick search around the BBS for discussions on Sprint, the number of hops involving Sprint in your route is starting to put me off moving! :(