Hi there
What you sent through to me looked perfect. Packet loss is only a problem if it happens consistently, if your unable to repeat the loss its probably not the cause of this.
regards
Printable View
Network Timeout
The operation timed out when attempting to contact www.woodworkforums.com.
The requested site did not respond to a connection request and the browser has stopped waiting for a reply.
* Could the server be experiencing high demand or a temporary failure? Try again later.
* Are you unable to browse other sites? Check the computer's network connection.
* Is your computer or network protected by a firewall or proxy? Incorrect settings can interfere with Web browsing.
* Still having trouble? Consult your network administrator or Internet provider for assistance.
This using Firefox, ADSL2 on Vista.
soth
Steve, from one of the error messages, this is a DNS server problem.
Comms with the DNS server or the server itself are failing.
Different people may be seeing different replicas of the dns sever, depending on their service provider. ?????????
mine is back up to normal seed but if i click a link in a subscribed thread notiforcation it comes up with the dsn server error among others and i have the refresh and the page loads.
it seams to be ok ow ill give it another go in the morning.
To whoever (Steven ?) did whatever - thanks, all is now well.
soth:2tsup:
No idea if anything was done to fix it but its all good on my end now:2tsup:
Error message still here at 4.15 this arvo, seems ok atm.
Seems to have improved this afternoon, at last.
Everything appears fine again!
As someone with an IT background I would be interested to know the cause, if it is known, but like many problems in computing, it may not be able to be explained. :confuzzled:
Yep, seems OK on this & the other forum. I suspect it was nothing to do with the forums, but I'd be interested in hearing what did cause it if anyone knows.
So far so good. Like others, I would be interested in what the problem was if there is an answer available.
Apologies for not replying earlier, I missed this one. :-
FWIW, I use Optus and have the same problems. It's not just BigPond and definitely not just these forums.
Facts on these filters are remarkably slim on the ground and the few queries I've had answered neither confirm nor deny. :sigh: All I know is that it's still in legislation, although by reading between the lines I've come to believe the infrastructure is already being implemented and undergoing preliminary testing.
Perhaps I'm being paranoid, I certainly hope I'm wrong, but if these slow-downs are due to something else (limited bandwidth, etc.) imagine how much slower the 'net will be when the filters are enforced?
Sorry, but no idea. I'm assuming that the encrypted tunnels are working faster because any filters being tested are parsing for HTML, etc. and bypass binary data streams.Quote:
Do you know how you can test if your going through a filter?
Recently did an upgrade of Firefox to 3.05 on a powerbook G4 mac running 10.4.11, and started to get intermittent network timeout errors just in the last day or two like those reported. All other websites I visited were OK, just WWF giving trouble. At the same time SWMBO had no problems getting on to WWF with her powerbook running Firefox 2. through our LAN. (we're using bigpond cable) ping and traceroute from both machines showed similar results, not a DNS problem, but some slow connections. I did a google search and found a lot of people experiencing similar probs with firefox 3 on both mac and pc. Some more searching found this might resolve the problem: (DID resolve my problem)
* Open a new tab, and type about:config in the address bar of Firefox
* Click “I’ll be careful, I promise!”
* Search for the value: network.http.keep-alive
* Double click on this value to “toggle” to change it to false
* Restart FireFox
I also found the default for MTU was OK too.
sthandy$ ping -c 4 74.55.90.114
PING 74.55.90.114 (74.55.90.114): 56 data bytes
64 bytes from 74.55.90.114: icmp_seq=0 ttl=42 time=251.018 ms
64 bytes from 74.55.90.114: icmp_seq=1 ttl=42 time=249.893 ms
64 bytes from 74.55.90.114: icmp_seq=2 ttl=42 time=250.528 ms
64 bytes from 74.55.90.114: icmp_seq=3 ttl=42 time=249.850 ms
--- 74.55.90.114 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 249.850/250.322/251.018/0.483 ms
sthandy$ traceroute 74.55.90.114
traceroute to 74.55.90.114 (74.55.90.114), 64 hops max, 40 byte packets
1 xxx 18.041 ms 24.284 ms 10.243 ms
2 xxx 10.107 ms 25.316 ms 10.114 ms
3 xxx 29.091 ms 13.768 ms 8.961 ms
4 xxx 10.750 ms 10.707 ms 15.053 ms
5 tengigabitethernet6-3.woo4.brisbane.telstra.net (203.45.3.213) 9.767 ms 28.349 ms 10.754 ms
6 tengige0-8-0-2.woo-core1.brisbane.telstra.net (203.50.51.129) 8.688 ms 8.927 ms 9.486 ms
7 bundle-pos2.chw-core2.sydney.telstra.net (203.50.6.201) 21.351 ms 21.447 ms 21.993 ms
8 bundle-ether1.oxf-gw2.sydney.telstra.net (203.50.6.90) 19.789 ms 21.564 ms 21.406 ms
9 tengigabitethernet14-0.sydo-core01.sydney.reach.com (203.50.13.42) 23.390 ms 43.240 ms *
10 i-4-1.sydp-core02.net.reach.com (202.84.144.249) 28.299 ms 24.123 ms 22.533 ms
11 static.net.reach.com (202.84.140.246) 206.079 ms 204.986 ms 208.507 ms
12 static.net.reach.com (202.84.251.234) 173.140 ms 172.530 ms 173.207 ms
13 * * *
14 hagg-03-ge-0-0-0-540.hsto.twtelecom.net (66.192.246.206) 265.149 ms 267.939 ms 267.605 ms
15 po1.car07.hstntx2.theplanet.com (74.55.252.86) 250.578 ms 250.516 ms 249.741 ms
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
^C
Cheers
Michael