Look guys, we experimenting and working with our COLO to determine what exists in the way of issues with routers and switches of theirs, and we are also doing stuff with modules here. Some things we do take a while to propagate and be seen as a performance impacter, positive or negative, and other things take some system processes away from serving and appear to be slow downs. What would be helpful is some more PingPlotter graphs to confirm or prove that the router/switch adjacent to ours is a bottleneck or not.

Finally, it's much faster now. What was wrong with it before?

We are experimenting with different things. Please standby.

The slowness issue has been raised many times, I hope something can be fixed this time.

Much much faster for me now.

Just in response to my previous post, load times are now extremely fast (faster than I ever remember).

 

Can't install PingPlotter but here's a Terminal traceroute to the forums from my end:

 

It's been very slow here in So. CA. None of the other sites exhibit this. Flightsim loads in seconds. Avsim takes up to 15-20 sec. to load.Bob.

Disclaimer: Still reading the instructions on ping plotter not sure if this image helps.

 

The Site is lighting fast right now for me.

Current situation:

 

Target Name: forum.avsim.net

         IP: 205.252.89.43

  Date/Time: 2.7.2013 0:51:48 to 2.7.2013 0:56:28

 

Hop Sent Err  PL% Min Max Avg  Host Name / [iP]

...

 7    55   0  0.0  46  80  48  as0-0.bbr1.ffm1.de.eunetip.net [213.192.191.197]

 8    55   0  0.0  53 182  61  br02.frf02.pccwbtn.net [80.81.192.50]

 9    55   0  0.0 132 139 134  purple.servers.avsim.net [205.252.89.43]

 

 

So working quite good at the moment.

a lot faster here in Ireland

 

Richard.

wow, much much faster now....very good! (6:07pm Eastern)

Whatever may be said it its defence ,the fact remains , AVSIM  is significantly slower to respond than any other site I visit - FS related or not.

Yeah it's been "really" slow lately from here in NY.....

For those who still have slow loading times (20s or more):

 

What would be helpful is some more PingPlotter graphs

 

As the youth likes to say: JPEG or it didn't happen.

 

PingPlotter has a shareware version. You can use it if you want to help out (and still have problems).

Attached is a PingPlotter Test, its slow but better than at other times today.

Attached is a PingPlotter Test, its slow but better than at other times today.

 

A 65 millisecond (0.065 second) turn around time is not "slow". If that is "slow" to you, you need to dial back your expectations or send me a check for big bucks in order that we can meet your speed of response expectations. The second issue here is that you have a 70 percent PACKET LOSS at hop nine on your way to AVSIM's server. Get rid of the packet loss and you could conceivably be seeing at TAT of 30 MS or less. We have no control over the delays and losses on your way to our servers.

 

EDIT: I wanted to add this image of our server loading / bandwidth consumption over the last day.

 

 

I will let everyone do their own analysis.

If that is "slow" to you, you need to dial back your expectations or send me a check for big bucks in order that we can meet your speed of response expectations.

People just can't win with you, can they? You've asked for additional PingPlotter tests, and when people duly comply, they get their heads bitten off? Was that really necessary?

 

The second issue here is that you have a 70 percent PACKET LOSS at hop nine on your way to AVSIM's server. Get rid of the packet loss and you could conceivably be seeing at TAT of 30 MS or less.

No, you're drawing the wrong conclusion because that's not how things work in router land. An Internet router is typically divided into two functional sections, called the data plane and the control plane. The former is tasked with forwarding packets between interfaces as quickly as possible and is generally powered by purpose-built ASICs. The latter is typically handled by the router's CPU, and concerns the router's internal housekeeping, running routing protocols, providing network management functionality, and, most significantly in this context, transmitting ICMP replies in response to ICMP echo requests or other packets transmitted by traceroute and similar utilities (such as PingPlotter).

 

More often than not, the transmission of "ICMP destination unreachable / TTL expired" packets is performed on a best-effort basis, meaning that a router will forgo sending ICMP replies when its CPU is busy doing other, more important things. However, since packet forwarding through the router is handled by dedicated hardware, a deferred ICMP reply is not in of itself indicative of packet loss on an interface or directly connected network.

 

Only if PL occurs past a certain node, and the packet loss is present on every subsequent hop as well, can one safely conclude that this node is likely responsible for dropping transiting traffic. As this is clearly not the case in Tom Bergman's plot -- PL is zero percent at the next hop and at the trace's destination -- the 70% PL on hop 9 is a false positive and should be ignored.