Adelaide Solar campaign - slow


Really? Fifteen to forty second screen changes? Rebooted. Chrome? Nope. Firefox? Nope. IE? Nope.

No other software running. says everything is hot on my end. WIN 8.1

Can’t deal with it.

Adelaide: Solar Panels

In Copenhagen, Denmark, d27/m03/y2016 22:00 C. Europe summertime page switch is consistent 2½ sec ( on my [DOLMY] stopwatch !)

Try Is it down

Win XP, Firefox 45.0.1, Flush cache ?



Interesting. On some campaigns, the changes were flashing through as quickly as you say. Down here, this Adelaide one is running very slowly. When Ethiopia was still running, those were changing in 2 seconds or less; Ramadi was running very quickly; but if I switched to Adelaide, the changes slowed up dramatically.

It’s not cache since different campaigns will run fast and Firefox has only been on this machine for 48 hours. I have been using Chrome for everything. Thought I’d try Firefox to see if it made a difference. Nope.

Perhaps it is a grand conspiracy against us evil Costa Ricans.


I see you did not try the link to above .
Tomnod seems to use IP
You could try command:TRACERT and see where it takes you.



When I had trouble months ago, my Internet Provider had me run a TRACERT.

I’m in the NE USA and on the way to Tomnod, I hit a Spokane WA “hop” (cable-speak for where signals are handed off). That State of Washington hop was which apparently has some big problems with timing out. Nine out of 10 times, my inability to reach Tn was when failed to respond.

Now Washington is far NW of Colorado so this “hop” stuff makes NO sense to me. Give me a straight route roughly due West-SW! But that isn’t how the hops work-- you can be sent practically anywhere before arriving at an Internet destination. (To access a different website, I’m first sent East when the destination is West, before turning around and sent to the Midwest, then turned back again to the East, then South, then far NW, then finally arriving in California!) I learned that hops are like Air Traffic Control-- they can send “planes” to any elevation or descent and to any “hop” without necessarily explaining why. If one “airport” has a problem, they reroute around the problem and send to an airport that might not be as equipped to handle big traffic.

I suppose we could look at it as all our purposeful Nodding overloads all the usual routes? - LOL.

I wonder if @Tomnod had time to look at my report before about ? But Tomnod might not be able to do much about it, (other than to complain to the hop owners), since hops aren’t under their / our control.


I hate to be stupid but what does this mean. This is my tracert.


O.K. – right in the middle of s-l-o-w, the screen changes suddenly changed to the good old rapid 2 sec changes. No reboot. No F5. No nothing. This just proves that it is not this machine but either it’s the internet or it’s the servers. Wassup?


I’m not professional at this trade, but state that both and are registered to Amazon. To me that means that the bottleneck is in Amazon AWS. You could raise the max hops for “TRACERT -h 50” or higher to see if you get through (though “sombody (YouKnowWho)” might blame you for trying to further overload the system)

There are professionals here who push and bend Yahoo, they might be able to strong arm Amazon.



Thank you all for the details provided in this post. I scaled up some of our core services and things seem to be running faster now. Please let me know if they are still slow for you. Cheers!


Certainly seems much quicker for me! Thank you @Jon_Saints


Tile-switch time Copenhagen, Denmark unchanged at 2½ sec

Can you explain the time lag difference between Denmark and Puerto Rico ?




Here is your image again:

To explain, for future reference

Column 1 listing numbers 1,2, 3 etc. are just the list of the hand-offs. The last col shows where the hand-off occurred. Having 20-30 attempted handoffs is not completely uncommon, but when working smoothly, it’s usually far less than 20 lines.

Col. 2 shows the milliseconds “ms” of a packet of data going out. The best or quickest should hit between 30-45 ms but there can be surges or spikes, from 50+ or 80+. . Spikes should return to normal “quickly”. When it hits over 100-120, it is dragging for users but as long as they come down quickly, it’s fairly normal.

Col. 3 / 4 is for return packets-- how long does it take for data to go to the next leg / respond, and come back to you. Same details apply. Timing out is indicated by *. It means that leg or hop did not get or return data you sent and you’re still waiting for a handshake reply.

Col 5 Shows the IP address of the hop you were handed off to. I believe if Hop A doesn’t respond, it tries to hand off somewhere else, to get around the problem.

TRACERT is best if a Provider or Company uses the data to fix a problem. It gives useful clues to a user, but a user cannot fix any problem (unless the problem starts with your provider, such as having no Internet connection).


Haven’t a clue what that’s all about


Jon – The time between clearly visible polygon areas is still all over the board for me in Costa Rica. In the last 5 minutes, it has ranged from 1 instantaneous change up to 18 seconds and everything in between. If I had to guess, I’d say it is an average of maybe 9 or 10 seconds. This is not to say that no little tiles are coming into an image – only that the polygon tile(s) have not come in enough to vote. Again, the download speed is running a stable 6meg (that’s all we ever get here) on Chrome with WIN 8.1. Current “answered questions” is just above 2K.

Update: 19:25 local – Holy Cow! Whatever you did, keep it up. All hell just broke loose and I’m getting 1 second change times.

Update: 21:00 local – and … it ends. Suddenly went from flash-fast changes with about every 5th one taking as much as 5 secs, to suddenly going in the crapper. Nobody else in the house online and I’m suddenly getting 15 sec or slower changes, with an occasional return to flash-fast for one or two changes. I’m thinking that it is the fiber optic pipe serving us fools in Central America.


LOL, Em. I consider it something my IP Provider tells me about when they have no answer:: “Here is a rather meaningless tool that you can’t use to actually fix the problem (and neither can we), but it will keep you busy for a while figuring out it is of no direct help.” LOL But they, my cable provider, didn’t know I’d see that the Amazon leg-hand off was a big problem. About all Tracert does for users is give confirmation a problem exists and where.

Maybe DG as a company has a contact to help improve that specific hop response out in Washington State, but often companies don’t have much input either.


tracert’s ‘timed out’ is not necessarily a problem. I’d first use a basic ping instead of tracert to see connection response; even pinging intermediate spots that tracert shows are in your path to desired final destination.

Remember path to final destination can FREQUENTLY change