weird. most of my 2nd post is missing.
i guess that's what i get for making fun of Admin's internet connection...
so there are a few problems with using Traceroute for this sort of problem diagnosis.
Traceroute by default uses ICMP packets rather than TCP packets on port 80 like your web browser.
ICMP packets are used for passing debug and error messages between connected computers.
TCP is used to pass actual data.
one of the problems is the various routers along the path between your PC and (in this case) http://robotics.pixiq.ca/
might route ICMP and TCP packets by completely different paths.
it is common practice to drop ICMP packets completely rather than send them on. (this is why a Traceroute to societyofrobots.com never gets to the final server.)
also ICMP packets are much smaller than most TCP packets.
large packets get fragmented and reassembled at the destination. ICMP packets are almost always too small to need fragmented.
this means that for some transmission errors and MTU size configuration issues ICMP packets will traverse a network with no problems but a large TCP packet can still fail.
so what tools to use instead?
looking at the options on http://support.microsoft.com/kb/162326
this isn't going to work with the Windows default Traceroute but
on some versions of Traceroute you can force them to use a set protocol and port number.
forcing TCP:80 will make Traceroute more similar to your browser traffic. now at least you can be sure Traceroute's outgoing packets take the same path as those from your web browser. the return packets to Traceroute can still fall prey to the same issues as they are still ICMP.
another thing you can do is see if your version of Traceroute lets you change the packet size.
the default MTU (Maximum Transmission Unit) of ethernet is 1500 bytes so if you force traceroute to send a packet larger than this you can guarantee it will be fragmented as it leaves your computer to be reassembled at the destination host.
you can also see a lot using a packet sniffer on your PC when you try to to connect to a problem website.
see what ICMP errors are coming back. see what delay between outgoing packets and their response.
Wireshark is good. for anyone interested in this stuff i recommend playing with a good packet sniffer.
sometimes the problem cannot be diagnosed from just one end station though.
you would need access to logs on the various routers along the path. time to cross your fingers and hope you ISP is working on the problem.
I think there are two problems, one the server is hosted from my house... so I only get 1mb/s upload speeds.
1Mb upload should be more than enough as long as you aren't getting loads of simultaneous hits.
the other thing to think about is maybe you are using your connection for bandwidth intensive tasks when Admin is trying to connect, blocking his incoming TCP request.
probably not though as it sounds like he's tried on more than one occasion.
your site certainly loads ok for me.
today it's ~1 second for everything.
yesterday it was ~1 second for text and formatting with the images taking ~5 seconds.