Page 1 of 2
Not sending
Posted: Sat Oct 15, 2011 1:06 pm
by mike.million
Sorry late for work now no time but to paste and run, but have two bigadv that are not sending. This one is over 14 hours in total the other is a couple of hours not sending. I did reload with verbosity 9 flag so I would have the most info.
Code: Select all
--- Opening Log file [October 15 12:36:19 UTC]
# Linux SMP Console Edition ###################################################
###############################################################################
Folding@Home Client Version 6.34
http://folding.stanford.edu
###############################################################################
###############################################################################
Launch directory: /home/erin/folding
Executable: ./fah6
Arguments: -smp -bigadv -verbosity 9
[12:36:19] - Ask before connecting: No
[12:36:19] - User name: mmillion (Team 111065)
[12:36:19] - User ID:
[12:36:19] - Machine ID: 1
[12:36:19]
[12:36:19] Loaded queue successfully.
[12:36:19] - Preparing to get new work unit...
[12:36:19] - Autosending finished units... [October 15 12:36:19 UTC]
[12:36:19] Cleaning up work directory
[12:36:19] Trying to send all finished work units
[12:36:19] Project: 6903 (Run 2, Clone 14, Gen 43)
[12:36:19] + Attempting to send results [October 15 12:36:19 UTC]
[12:36:19] - Reading file work/wuresults_07.dat from core
[12:36:19] + Attempting to get work packet
[12:36:20] (Read 222539687 bytes from disk)
[12:36:20] Passkey found
[12:36:20] Connecting to http://130.237.232.237:8080/
[12:36:20] - Will indicate memory of 32234 MB
[12:36:20] - Connecting to assignment server
[12:36:20] Connecting to http://assign.stanford.edu:8080/
[12:36:34] Posted data.
[12:36:34] Initial: ED82; - Successful: assigned to (130.237.232.237).
[12:36:34] + News From Folding@Home: Welcome to Folding@Home
[12:36:34] Loaded queue successfully.
[12:36:34] Sent data
[12:36:34] Connecting to http://130.237.232.237:8080/
[12:36:40] Posted data.
[12:36:40] Initial: 0000; - Receiving payload (expected size: 24866948)
[12:53:54] - Couldn't send HTTP request to server
[12:53:54] + Could not connect to Work Server (results)
[12:53:54] (130.237.232.237:8080)
[12:53:54] + Retrying using alternative port
[12:53:54] Connecting to http://130.237.232.237:80/
And there it will sit until the next try.
Re: Not sending
Posted: Sat Oct 15, 2011 1:24 pm
by xhuang
Hi mike.million,
I just check the server 130.237.232.237:8080 and it looks fine. It is possible that you are experiencing some network connectivity problem related to Internet provider (or computer settings, maybe). Please double check your connection and then try to upload your WU again.
Re: Not sending
Posted: Sat Oct 15, 2011 3:36 pm
by gwildperson
Have you tried disabling your security software?
Have you tried the steps in
Troubleshooting Server Connectivity Issues (Do This First)?
Re: Not sending
Posted: Sat Oct 15, 2011 4:28 pm
by drougnor
Where are you located? Someone in France just reported similar issues over on the EVGA forums, says he confirmed same with someone in UK. Could be a routing issue from Europe.
Re: Not sending
Posted: Sat Oct 15, 2011 4:33 pm
by Sleinous
Hello Drougnor.
Yes i've been folding all day here in France, without any issues up until recently, I refreshed my stats page quite a few times over the course of the day, was hoping to beat my record points in one day but now I have a total of 5 WUs queued for upload across 3 machines (soon to be 8 WUs waiting for upload).
I can also no longer access the stats page. All this occured about 40mins ago and im still experiencing said problems. WUs are a mix of GPU2 GPU3 and SMP.
The live stats below show you all GPUs that are now stopped due to connection issues. I also have a GT 340 and 1 out of 2 i7 930's stopped due to same issue.
Re: Not sending
Posted: Sat Oct 15, 2011 4:44 pm
by bruce
Try the old standby debugging tool (shown in Windows format)
tracert assign.stanford.edu . (That works for me.)
drougnor wrote:Where are you located? Someone in France just reported similar issues over on the EVGA forums, says he confirmed same with someone in UK. Could be a routing issue from Europe.
I'm pretty sure that mike.million is in the USA. That doesn't preclude him being routed through some node that's also used from Europe.
I can get to Sweden from California:
Code: Select all
3 12 ms 12 ms 12 ms lax1_cr1_gig_10_0_120.dslextreme.com [66.218.48.145]
4 12 ms 11 ms 11 ms 66.186.192.157
5 42 ms 23 ms 44 ms phx-ten2-1-la-ten3-3.bboi.net [64.127.128.146]
6 51 ms 56 ms 59 ms dal-ten2-4-phx-ten1-1.bboi.net [64.127.128.237]
7 60 ms 60 ms 60 ms nsh-ten1-4-dal-ten2-1.bboi.net [64.127.130.49]
8 68 ms 68 ms 68 ms atl-ten3-2-nsh-ten4-1.bboi.net [64.127.130.57]
9 81 ms 80 ms 80 ms ash-ten3-1-atl-ten3-1.bboi.net [66.216.1.158]
10 115 ms 82 ms 82 ms us-ash.nordu.net [206.223.115.230]
11 170 ms 167 ms 167 ms uk-hex.nordu.net [109.105.97.65]
12 187 ms 215 ms 188 ms dk-ore.nordu.net [109.105.97.30]
13 198 ms 198 ms 197 ms se-fre.nordu.net [109.105.97.5]
14 198 ms 197 ms 198 ms t1fre.sunet.se [109.105.102.10]
15 198 ms 197 ms 197 ms m1fre-ae1-v1.sunet.se [130.242.83.45]
16 197 ms 198 ms 198 ms ls-kth-br1.sunet.se [193.11.0.194]
17 198 ms 197 ms 197 ms pdc1-br1g-p2p.gw.kth.se [130.237.0.3]
18 197 ms 197 ms 197 ms pdc-juniper03-juniper01.pdc.kth.se [192.36.253.233]
19 198 ms 198 ms 198 ms folding-2.pdc.kth.se [130.237.232.237]
Trace complete.
Re: Not sending
Posted: Sat Oct 15, 2011 5:14 pm
by Sleinous
I can get to the stats from my phone but not from my router. Ive restarted it, rebooted all 3 PC's, no dice. Absolutely no clue why this is happening.
EDIT: I'm now connected through my VPN and am able to upload teh work units again. As I have moved out to France for a 1 year internship do you think stanford could have blocked the IP thinking I was someone else?
Re: Not sending
Posted: Sun Oct 16, 2011 1:27 am
by mike.million
Hi All,
I have tried nothing just got back from work and will start looking now.
Both machines are still not sending, the 6903 has now been trying to send for over 24 hours and the 6904 around 12 hours.
Ok, these machines have been folding in exact same set up for a long time now, on the same settings, same hardware, same Internet provider, etc.
The only thing strange about yesterday was a very brief power outage that reset all my computers, power was out for around 3 hours. No idea how that could do any damage.
Restarted all the clients and all started at the right % and folded to 100% completion.
I am using Ubuntu 10.10 on all of my folding rigs. I use the factory settings so to speak, have made no OS changes at all (except use Ext 3)
I will look at some the help topic's but will check back often to see if anyone has any ideas.
Thanks
Mike
OBTW yes US, Phoenix AZ, this morning and just now when I tried to sign in I got an error message saying could not find this forum, then when I say resend/reconnect it finds logs me in. Not sure if that indicates anything special or is normal. I never use the Internet much on my non windows folding machines.
Re: Not sending
Posted: Sun Oct 16, 2011 3:02 am
by mike.million
bruce wrote:Try the old standby debugging tool (shown in Windows format) tracert assign.stanford.edu . (That works for me.)
Ok so I tired resetting my modem and router, thought the power outage might have messed up, but no still the same.
So now trying Bruce's idea first as well he is the expert, doesn't look good, 3rd try was much better than the first two. Not sure exactly as when I pinged the servers in question seemd to be no problem getting to them, so here it is:
Code: Select all
Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\synanjin>tracert assign.stanford.edu
Tracing route to vsp10v-vz00.stanford.edu [171.67.108.200]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 9 ms 9 ms 10 ms ip68-2-11-37.ph.ph.cox.net [68.2.11.37]
4 24 ms 10 ms 11 ms 70.169.75.100
5 * 192.168.1.1 reports: Destination net unreachable.
Trace complete.
C:\Users\synanjin>tracert assign.stanford.edu
Tracing route to vsp10v-vz00.stanford.edu [171.67.108.200]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 11 ms 17 ms 9 ms ip68-2-11-37.ph.ph.cox.net [68.2.11.37]
4 9 ms 9 ms 9 ms 70.169.75.100
5 9 ms 11 ms 29 ms chnddsrj01-ae2.0.rd.ph.cox.net [70.169.76.229]
6 * * * Request timed out.
7 General failure.
Trace complete.
C:\Users\synanjin>tracert assign.stanford.edu
Tracing route to vsp10v-vz00.stanford.edu [171.67.108.200]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 9 ms 9 ms 9 ms ip68-2-11-37.ph.ph.cox.net [68.2.11.37]
4 24 ms 11 ms 13 ms 70.169.75.100
5 11 ms 13 ms 9 ms chnddsrj01-ae2.0.rd.ph.cox.net [70.169.76.229]
6 68 ms 24 ms 23 ms langbprj01-ae1.rd.la.cox.net [68.1.1.13]
7 30 ms 31 ms 33 ms xe-0-0-0.0.paix0.tr-cps.internet2.edu [64.57.20.
224]
8 35 ms 34 ms 36 ms 137.164.131.94
9 35 ms 34 ms 36 ms dc-svl-core1--svl-px1-10ge-1.cenic.net [137.164.
46.204]
10 47 ms 36 ms 36 ms dc-svl-agg1--svl-core1-10ge.cenic.net [137.164.4
7.120]
11 36 ms 43 ms 37 ms dc-stanford--svl-agg1-10ge.cenic.net [137.164.50
.158]
12 36 ms 34 ms 37 ms boundarya-rtr.Stanford.EDU [68.65.168.33]
13 * * * Request timed out.
14 General failure.
Trace complete.
C:\Users\synanjin>ping 130.237165.141
Ping request could not find host 130.237165.141. Please check the name and try a
gain.
C:\Users\synanjin>ping 130.237.165.141
Pinging 130.237.165.141 with 32 bytes of data:
Reply from 130.237.165.141: bytes=32 time=194ms TTL=51
Reply from 130.237.165.141: bytes=32 time=191ms TTL=51
Reply from 130.237.165.141: bytes=32 time=180ms TTL=51
Reply from 130.237.165.141: bytes=32 time=183ms TTL=51
Ping statistics for 130.237.165.141:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 180ms, Maximum = 194ms, Average = 187ms
C:\Users\synanjin>ping 130.237.232.237
Pinging 130.237.232.237 with 32 bytes of data:
Reply from 130.237.232.237: bytes=32 time=180ms TTL=49
Reply from 130.237.232.237: bytes=32 time=181ms TTL=49
Reply from 130.237.232.237: bytes=32 time=180ms TTL=49
Reply from 130.237.232.237: bytes=32 time=182ms TTL=49
Ping statistics for 130.237.232.237:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 180ms, Maximum = 182ms, Average = 180ms
C:\Users\synanjin>
Re: Not sending
Posted: Sun Oct 16, 2011 8:26 am
by Sleinous
I still cant access servers my end apart from if I connect through my university VPN.
EDIT: Did a tracert again on normal internet then on VPN, VPN worked, normal internet didnt, I was blocked somewhere at my ISP but before it crossed over into the US. So then I tried tracert stanford.edu and that connected! Then I tried tracert folding.stanford.edu and it worked again... for a few minutes. I then tried again and I was blocked again.... This is starting to be a bit of a pain.
Failed tracert through my ISP in France (SFR)
Successful tracert through my University VPN connection back in the UK
Re: Not sending
Posted: Sun Oct 16, 2011 2:32 pm
by gwildperson
Sleinous: You'll have to talk to sfr. They clearly have a problem.
Re: Not sending
Posted: Sun Oct 16, 2011 4:17 pm
by Sleinous
Hello, this is what Vijay also said. Ill try and contact SFR tomorrow. Maybe this is where the OP's issue lies too?
Re: Not sending
Posted: Sun Oct 16, 2011 5:18 pm
by mike.million
Well after seeing that tracer I thought it must be on the Cox cable side of things.
So we went through several things, they thought it was my router so I was going to get one this morning. But I thought it was more likely the modem so I do keep a backup modem and we installed it (no backup router this is like 10PM). Then I spent most of the night trying to get the linux system to connect direct to the modem. Would search and then say no connection to the Internet, my windows based machine did no problem.
I had changed the mac address and checked what little I know about Ubuntu 10.10 networking looked on line etc, so finally decided to reinstall the os so it would pick up the right settings, but no same thing.
So hooked the router back up, which I had unhooked, as cox seemed sure that was the problem (they got a good strong reading with quick times on the modem they were sure it wasn't the problem).
Only hooked up my windows machine and one 4P system, it worked but was very slow, the 6903 took 38 min to send (takes about 12-13 min most times) and the 6904 timed out around 50 minutes (didn't send). So thinking it was slow because of the router, I again tried to hook direct to the modem. Again no amount of messing around on my part could get the computer to recognise the direct connection to the Internet. Is there some secret to doing this on linux machines?
Hooked back up to router, i stopped and restarted the client to try and send the 6904. Everything seemed much faster but no luck, so I went to bed. I tried as above to send the 6904 early this morning but this time it acted more normal but indicated server was busy. So I went to work and just came home and tried to send again and it went through, about 14min to send and my internet seems very fast and the issues seem to have worked them selves out.
Hooked up the rest of my computer to the router (through two switches) and every thing, so far is working fine.
Thanks to everyone for their time and help, and in particular Bruce, as that set me on the right path.
Mike
Guess the power thing did something to damage but not break my modem.
Re: Not sending
Posted: Sun Oct 16, 2011 7:29 pm
by gwildperson
mike.million wrote:So hooked the router back up, which I had unhooked, as cox seemed sure that was the problem (they got a good strong reading with quick times on the modem they were sure it wasn't the problem).
I don't know about Cox, but my ISP will always blame something local, even if that's not really the problem. Later, after there are several calls about the same problem, they'll go check some upstream router and fix it's problem. In this case, my money is on them having fixed something at 70.169.75.100 or it's next upstream neighbor.
Code: Select all
4 24 ms 10 ms 11 ms 70.169.75.100
5 * 192.168.1.1 reports: Destination net unreachable.
Re: Not sending
Posted: Tue Oct 18, 2011 5:45 pm
by drvb
Sleinous wrote:Hello, this is what Vijay also said. Ill try and contact SFR tomorrow. Maybe this is where the OP's issue lies too?
Hi Sleinous,
Are you still struggling with the connexion to the assignment servers ?
My ISP is also SFR in France and I have not been able to reach the servers since Saturday
Even
http://folding.stanford.edu is unavailable with my browser