Slow Internet Connection to randi.org

[SusanB-M1]

It really helps if you use NoScript and you don't allow javascript from randi.org unless you absolutely need it for something. In fact, it's a very fast forum that way. *shrug*

I have no idea what that means.

I'm afraid I do not understand either. Is it possible to put it very simply, please?! It sounds very sensible.

 

[my_wan]

I'm afraid I do not understand either. Is it possible to put it very simply, please?! It sounds very sensible.

Essentially it means turning javascript off. IE is a bit dumb. You have to either use "Custom Level" security or turn security up so high it's a pain.
Tools->Internet Options->Security (Tab).
The custom level button gets into setting most will not understand. I'm not sure what MS actually chose for the 3 levels of default security.

I also understand that it's possible to do interactively with the "Internet Explorer Developer Toolbar": http://www.microsoft.com/downloads/...64-672d-4511-bb3e-2d5e1db91038&displaylang=en

I use maxthon browser, which uses the IE engine, and can turn it and any other IE feature on/off with a click of a button. I can also carry by browser with favorites, addons, settings, etc. on a USB drive. Firefox user can use the NoScript addon: https://addons.mozilla.org/en-US/firefox/addon/722

It does speed up loads but can also occasionally break sites. forums.randi.org will still have periods of difficulty in my experience. Sometimes the forum goes offline for an hour or so for all practical purposes. I have grown accustomed to copying my post to clipboard before attempting to submit a post. I'm on a 5 meg service.

 

[rjh01]

For those intelligent people who use safari like me

Edit / preferences
click on security
Un tick the boxes as required.

 

[Boran]

For the peope using Opera:

Right click on any forum page
Edit Site preferences
Scripting tab
uncheck "enable java script".

I'm not entirely convinced as to the merits, this might be a "placebo" cure for the speed, still feels slow in loading threads.

edit: this change disables scripts only on the forums.

 

[SusanB-M1]

my_wan

Thank you. I just looked at the 'Security' tab page - which I have never done before! - but I'll have a word with Dolphin first in case altering something interferes with Supernova.

 

[A W Smith]

wreckspace

its very very bad tonight. as its been bad all week. the hosting service for randi (rackspace) is dropping packets

 

[petra10]

When you log on ensure that the box marked remember me is ticked. That way you stay logged on until you log off or delete cookies.

Thanks I didnt know that, it works

 

[Ron_Tomkins]

Maybe the forum isn't getting slower, but we're getting faster.

 

[Gord_in_Toronto]

I'm getting a very good response right now but apparently there are still a lot of packets being dropped at "dfw"

8. so-0-1-0.mpr2.dfw2.us.above.net 2%
9. xe-1-1-0.er1.dfw2.us.above.net 29%

 

[my_wan]

I was manually pinging the IPs listed in a tracert. The dropped packets for me was from att.com and att.net and raged from 50 to 75% lost packets.

C:\>tracert randi.org
Tracing route to randi.org [72.32.2.238]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 18 ms 18 ms 18 ms 172.21.76.69
4 19 ms 18 ms 18 ms 24-158-96-226.static.kgpt.tn.charter.com [24.158.96.226]
5 24 ms 24 ms 25 ms 12.86.91.73
6 45 ms 44 ms 44 ms tbr1.attga.ip.att.net [12.122.96.18]
7 41 ms 44 ms 44 ms cr1.attga.ip.att.net [12.122.17.41]
8 45 ms 43 ms 44 ms cr2.dlstx.ip.att.net [12.122.28.174]
9 45 ms 44 ms 44 ms tbr2.dlstx.ip.att.net [12.122.18.222]
10 44 ms 44 ms 44 ms gar10.dlstx.ip.att.net [12.122.100.97]
11 43 ms 44 ms 44 ms 12.87.41.178
12 45 ms 44 ms 44 ms vlan901.core1.dfw1.rackspace.com [72.3.128.21]
13 45 ms 43 ms 44 ms aggr3a.dfw1.rackspace.net [72.3.129.11]
14 45 ms 44 ms 44 ms mail.randi.org [72.32.2.238]
Trace complete.
C:\>ping 12.86.91.73
Pinging 12.86.91.73 with 32 bytes of data:
Reply from 12.86.91.73: bytes=32 time=24ms TTL=251
Reply from 12.86.91.73: bytes=32 time=24ms TTL=251
Reply from 12.86.91.73: bytes=32 time=25ms TTL=251
Reply from 12.86.91.73: bytes=32 time=22ms TTL=251
Ping statistics for 12.86.91.73:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 25ms, Average = 23ms
C:\>ping 12.122.96.18
Pinging 12.122.96.18 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 12.86.91.73: Destination net unreachable.
Ping statistics for 12.122.96.18:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping 72.3.128.21
Pinging 72.3.128.21 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 72.3.128.21:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping 72.3.128.21
Pinging 72.3.128.21 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 72.3.128.21:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>ping 24.158.96.226
Pinging 24.158.96.226 with 32 bytes of data:
Reply from 24.158.96.226: bytes=32 time=18ms TTL=252
Reply from 24.158.96.226: bytes=32 time=19ms TTL=252
Reply from 24.158.96.226: bytes=32 time=16ms TTL=252
Reply from 24.158.96.226: bytes=32 time=16ms TTL=252
Ping statistics for 24.158.96.226:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 19ms, Average = 17ms
C:\>

As you can see the loss starts at 12.86.91.73 which is the first IP from tracert belonging to AT&T WorldNet Services. I really don't think you can reliably say what servers after that one are dropping packets, excepts by statistical analysis, because any query of a router under that would necessarily include dropped packets from the routers above it.

Same thing exist with the NeoTrace posted above, except it is NTT.com in that case. If you will notice the big jump in packet losses once the trace hits NTT routers. The first NeoTrace image attempts to weight the losses against each other, giving error bars, showing the statistical primary losses in NTT routers. The second graph is showing raw data so anything after the NTT routers shows a fairly equivalent loss rate. It's hard to blame rackspace given the data showing up for me or the above NeoTrace data (almost).

It appears to be stress on the trunk itself. Yet that begs the question of why it's not systematic to the whole internet infrastructure. That points us back to the probable cause being that rackspace's bandwidth to the trunk is too narrow. That would explain why rackspace's servers are not directly responsible for dropping the packets. Instead they are being dropped upstream due to rackspace stressing the bandwidth to the backbone.

At least that's my read of the data as seen so far...

 

[rjh01]

Can someone please provide an plain English translation of the above post?

 

[my_wan]

I'm just guessing from the data. The question is why is the connection to randi.org (this forum) is so bad sometimes, apparently world wide. Why are packets (the things sent across the internet by computers to communicate) being lost apparently before they even get to randi.org or rackspace.com. For me the losses are occurring mainly in att.net routers and for Smith above it is ntt.net routers. Routers decide where to send the internet packets of information so you can load a webpage. A trunk is a main internet backbone connection across regions. If you start sending information across the internet faster than the routers can keep up then you start losing the packets used to send the information.

From the guess I made, the problem is the routers that tie rackspace.com (where this forum is hosted) to the main internet rather than the rackspace.com servers themselves. This guess is based on the fact that many people world wide appear to have intermittent connection problems to this forum. Yet a check of the connections to the routers is showing the problem, not at rackspace.com, but in connections in between. These problem connections are not even always the same connections for everybody having problems. The only commonality is the problem always seems to occur wherever rackspace.com is connected to the main internet trunkline.

I hope that makes more sense.

 

[Dancing David]

I think MyWan is very clear but then I sort of like computers:

Things to understand for the uninitiated.

-there is a network of computers and cross country connections called :the Internet (I assume you know that). Actually it is more than that, there are servers, data storage and routers and all sorts of connections.
-when you open a web page some amazing things happen, first your computer checks itself for an open internet connection (to do this it has to have an assigned value or ‘internet address’ which is given to it by the gateway server.
-then the request to open the web page (IE get data from the source for the web page) goes out onto the network. It has find a path to the host and then get the data back. Each time , both ways.
- there is a command in the hidden area of your computer called ‘tracert’, this will show the machines that the computer sends data to get to the host you are contacting
-there is another command called ‘ping’ that sends a group of data packets to a source and then measures the response time and the state of the data when it gets back.
-A frequent problem in the internet is data loss, say in your work building, the Ethernet cables in the walls have a limit of about 250 ft. , the data loss at that point is tremendous, or if you have a twisted Ethernet cable that is broken, or interference next to the cable some where. That is just in the building, then you have data loss all along the way to your host.

(If you want to try this , I am not sure how to do it on the MAC OS, but in PC windows you go to Start and then open the Run window, type in the letters ‘cmd’, this then opens a window to the hidden level of your machine.
Here you can type in ‘tracert mail.randi.org’ and it will show you this gobbledy gook of places that your request went. Or you can type ‘ping’ and a specific address to see what the data transmission looks like.)

This is what people are talking about and some other fancy variations, the issue seems to be the connection before the data goes to the host for Randi.org.



This am I have done the tracert and pings and the problem seems to be with the last two parts of the link but as MyWAN has pointed out when there is a break in the chain it can take some analysis to understand where the break actually is.

 

[UnrepentantSinner]

My situation probably isn't like many but a handful of is here, but I've been experiencing some slowness at work (T-1, coporate firewall, etc.) that hasn't been evident at home on dial-up. I've been using these two different bandwidth situations long enough to tell the difference between slowness due to dial-up and when the forum is running slow... especially when I can access other websites, especially graphics intensive forums and have them load almost instantaneously at work and fairly quickly at home while JREF has lagged or failed to load at times.

In the past two weeksish, I've timed out on trying to access the JREF forum at work but have been able to access, say, Wikipedia, Netflix or other sites almost instantaneously.

I have no IT professsional comment on this issue, but as I have experienced it, in the past and over the last two weeksish, I can confirm that it is not in the imagination of those others who have commented on it.

 

[Wudang]

Can someone please provide an plain English translation of the above post?

Read this - it's a nice tutorial http://www.redbooks.ibm.com/abstracts/gg243376.html

 

[rjh01]

Thanks for those that answered my question. I am sure many others, like me found it educational.

What you appear to be saying is that even if the forum upgrade their servers to be super fast it would do nothing to resolve the problem. The forum needs to do something about the hardware further down the line.

 

[Blue Mountain]

Here's something to keep in mind, from the mtr man page:

BUGS: Some modern routers give a lower priority to ICMP ECHO packets than to other network traffic. Consequently, the reliability of these routers reported by mtr will be significantly lower than the actual reliability of these routers.

 

[Gord_in_Toronto]

Here's something to keep in mind, from the mtr man page:

. . .

Rule 6. Everything, anywhere, at all times is only an approximation.

Rule 7. There is no Rule 7.

. . .

 

[mgidm86]

This thread has gotten pretty technical, but I just wanted to say that for myself here in California, this is consistently the slowest forum that I visit. It has been for years. It is never fast.

<This has been my non-technical 2 cents worth>

 

[A W Smith]

Here's something to keep in mind, from the mtr man page:

BUGS: Some modern routers give a lower priority to ICMP ECHO packets than to other network traffic. Consequently, the reliability of these routers reported by mtr will be significantly lower than the actual reliability of these routers.

Some routers are configured to ignore ICMP ECHO packets. what you perceive to be problem when pinging those routes is actually the router ignoring those packets. I have examined the timing tab in neotrace for every non responsive router in that path above. and in every case. they did not lose some of the packets. they lost all but the first trace. therefore i can assume those routers are set to ignore ICMP ECHO packets.


http://www.codeidol.com/csharp/csharp-network/ICMP/The-TraceRoute.cs-Program/

By examining the source of the Time Exceeded packets, you can see what routers are in the network path to the destination device. It is possible that some routers in the network path are configured to ignore ICMP packets. They will produce the “no response from host” error message, but the TTL value will be increased and the next router will be queried. Typically, you’ll run across several routers in a network path that ignore ICMP packets. However, it is also possible that the destination host either won’t respond to the ICMP packet or won’t even be active. In that case, to prevent an endless loop of packets, after five no responses, the program assumes that the remote host cannot be reached.