GPU inactive [FAH from China is off-line]

vmzy · Post by **vmzy** » Thu Sep 06, 2012 9:19 am

I`m a user in CHINA .I can`t download WU from yesterday.And all of my fah friends here have encounter this problem.
I paste tracert log below, alough I don`t known if it can do any help.

Code: Select all

Microsoft Windows [版本 6.1.7601]
版权所有 (c) 2009 Microsoft Corporation。保留所有权利。

C:\Users\Administrator>tracert 171.67.108.59

通过最多 30 个跃点跟踪
到 VSP12.SUNet [171.67.108.59] 的路由:

  1     1 ms     2 ms    <1 毫秒 172.16.1.253
  2  1449 ms  1184 ms  1275 ms  182.151.192.1
  3  1243 ms  1289 ms  1009 ms  222.213.14.157
  4  1035 ms   759 ms  1164 ms  202.97.43.205
  5     *      935 ms  1020 ms  202.97.35.194
  6  1046 ms   755 ms   902 ms  202.97.60.46
  7  1557 ms  1319 ms  1473 ms  202.97.50.102
  8  1065 ms  1330 ms     *     202.97.49.193
  9  1179 ms  1108 ms     *     137.164.130.253
 10  1510 ms  1276 ms  1087 ms  137.164.131.94
 11  1289 ms  1185 ms  1548 ms  dc-svl-core1--svl-px1-10ge-2.cenic.net [137.164.
46.12]
 12  1321 ms  1545 ms  1080 ms  dc-svl-agg1--svl-core1-10ge.cenic.net [137.164.4
7.120]
 13  1141 ms  1787 ms  1301 ms  dc-stanford--svl-agg1-10ge.cenic.net [137.164.50
.158]
 14  1308 ms     *      801 ms  boundarya-rtr.Stanford.EDU [68.65.168.33]
 15     *        *        *     请求超时。
 16  1062 ms     *        *     VSP12.SUNet [171.67.108.59]
 17   807 ms  1222 ms   991 ms  VSP12.SUNet [171.67.108.59]

跟踪完成。

C:\Users\Administrator>tracert 171.67.108.58

通过最多 30 个跃点跟踪
到 VSP12.SUNet [171.67.108.58] 的路由:

  1    <1 毫秒    2 ms     1 ms  172.16.1.253
  2   809 ms   426 ms   216 ms  182.151.192.1
  3   367 ms   475 ms   404 ms  222.213.14.165
  4   713 ms  1264 ms  1364 ms  202.97.43.66
  5  1403 ms  2032 ms  1585 ms  202.97.35.246
  6   794 ms  1366 ms  1176 ms  202.97.60.146
  7   815 ms   564 ms   803 ms  202.97.58.210
  8  1435 ms  1265 ms  1120 ms  202.97.90.10
  9  1516 ms  1130 ms   811 ms  137.164.130.129
 10   832 ms   829 ms  1173 ms  64.57.20.227
 11  1349 ms  1714 ms  1895 ms  dc-lax-core2--lax-px1-10ge-2.cenic.net [137.164.
46.152]
 12  1702 ms  1669 ms  2163 ms  dc-svl-core1--lax-core2-10ge-1.cenic.net [137.16
4.46.97]
 13  2357 ms     *        *     dc-svl-agg1--svl-core1-10ge.cenic.net [137.164.4
7.120]
 14  1672 ms  1280 ms  1429 ms  dc-stanford--svl-agg1-10ge.cenic.net [137.164.50
.158]
 15  1755 ms  1937 ms  2096 ms  boundarya-rtr.Stanford.EDU [68.65.168.33]
 16     *        *        *     请求超时。
 17  1587 ms  2018 ms  1859 ms  VSP12.SUNet [171.67.108.58]

跟踪完成。

C:\Users\Administrator>tracert 171.67.108.60

通过最多 30 个跃点跟踪
到 VSP12.SUNet [171.67.108.60] 的路由:

  1     1 ms    <1 毫秒   <1 毫秒 172.16.1.253
  2  1495 ms  1507 ms  2300 ms  182.151.192.1
  3  1488 ms  1990 ms  2001 ms  171.208.202.125
  4  1360 ms  1728 ms  1980 ms  202.97.43.205
  5  1279 ms  1371 ms  1318 ms  202.97.35.194
  6  1305 ms   982 ms  1106 ms  202.97.60.142
  7  2510 ms  2169 ms  2160 ms  202.97.58.238
  8  1688 ms     *     2004 ms  202.97.49.197
  9  1244 ms  1039 ms  1441 ms  137.164.130.253
 10  1932 ms  2240 ms  1427 ms  xe-1-1-0.482--2152.paix0.tr-cps.internet2.edu [1
37.164.131.62]
 11   934 ms     *     1995 ms  dc-svl-core1--svl-px1-10ge-2.cenic.net [137.164.
46.12]
 12  1889 ms  1966 ms  2339 ms  dc-svl-agg1--svl-core1-10ge.cenic.net [137.164.4
7.120]
 13  2018 ms  2087 ms  2368 ms  dc-stanford--svl-agg1-10ge.cenic.net [137.164.50
.158]
 14  2641 ms  1904 ms  2753 ms  boundarya-rtr.Stanford.EDU [68.65.168.33]
 15     *        *        *     请求超时。
 16  2140 ms     *     1770 ms  VSP12.SUNet [171.67.108.60]

跟踪完成。

C:\Users\Administrator>tracert 129.64.95.82

通过最多 30 个跃点跟踪
到 fhkern.nmr.brandeis.edu [129.64.95.82] 的路由:

  1    <1 毫秒    1 ms    <1 毫秒 172.16.1.253
  2  1021 ms  1138 ms  1146 ms  182.151.192.9
  3  1264 ms     *      427 ms  171.208.202.113
  4  1345 ms  1015 ms  1282 ms  202.97.66.25
  5   890 ms     *      972 ms  202.97.53.82
  6   945 ms   771 ms  1217 ms  202.97.53.206
  7     *     1277 ms  1127 ms  202.97.52.182
  8   781 ms   789 ms  1017 ms  202.97.49.193
  9  1322 ms  1015 ms   867 ms  137.164.130.253
 10  1288 ms  1328 ms  1277 ms  xe-1-0-0.0.sttl0.tr-cps.internet2.edu [64.57.20.
223]
 11  1181 ms  1006 ms  1169 ms  xe-1-3-0.0.chic0.tr-cps.internet2.edu [137.164.1
29.3]
 12     *        *     1606 ms  64.57.21.206
 13  1481 ms     *     1549 ms  nox300gw1-vl-539-nox-brandeis.nox.org [207.210.1
42.97]
 14     *     1397 ms  1349 ms  nox300gw1-peer--207-210-142-98.nox.org [207.210.
142.98]
 15     *        *        *     请求超时。
 16     *        *        *     请求超时。
 17  1211 ms  1370 ms  1362 ms  fhkern.nmr.brandeis.edu [129.64.95.82]

跟踪完成。

C:\Users\Administrator>tracert 171.64.65.101

通过最多 30 个跃点跟踪
到 vspg14a.Stanford.EDU [171.64.65.101] 的路由:

  1    <1 毫秒   <1 毫秒    1 ms  172.16.1.253
  2   856 ms   730 ms   927 ms  182.151.192.1
  3   989 ms  1093 ms  1170 ms  222.213.14.165
  4   899 ms  1171 ms  1074 ms  202.97.43.205
  5   677 ms   631 ms   742 ms  202.97.35.194
  6  1188 ms   707 ms   780 ms  202.97.60.146
  7  1217 ms  1682 ms  1872 ms  202.97.58.210
  8  1368 ms  1225 ms  1495 ms  202.97.52.202
  9  1212 ms  1322 ms  1562 ms  137.164.130.129
 10  1750 ms  1824 ms  2144 ms  64.57.20.227
 11     *     1549 ms  1383 ms  dc-lax-core2--lax-px1-10ge-2.cenic.net [137.164.
46.152]
 12  1266 ms  1824 ms  1961 ms  dc-svl-core1--lax-core2-10ge-1.cenic.net [137.16
4.46.51]
 13  1618 ms  1567 ms     *     dc-svl-agg1--svl-core1-10ge.cenic.net [137.164.4
7.120]
 14  1501 ms  1730 ms  1621 ms  dc-stanford--svl-agg1-10ge.cenic.net [137.164.50
.158]
 15  1315 ms  1639 ms  1604 ms  boundarya-rtr.Stanford.EDU [68.65.168.33]
 16  1523 ms  1489 ms  1325 ms  bbra-rtr.Stanford.EDU [171.64.255.129]
 17  1628 ms  1470 ms  1627 ms  yoza-rtr-a.Stanford.EDU [171.64.255.144]
 18  1549 ms  1845 ms  1990 ms  vspg14a.Stanford.EDU [171.64.65.101]

跟踪完成。

C:\Users\Administrator>

hisui · Post by **hisui** » Thu Sep 06, 2012 10:10 am

Hello eveyone I'm a china F@H user,this morning I found my client cant get new wu and cant connect to server status page.
later I found I cant connect to any stanford.edu domian,not 100% blocked or connection get reset(typical censorship behavior here)just very slow,pages dont load completely stuck somewhere.
Both ping and trace are fine.
This isn't a single case, ppl all over the china on different networks report similar problem,this has lasted for at least 8 hours
here is a link to a local distribute computering froum confirm my report
http://www.equn.com/forum/thread-35157-1-1.html

According to my knowledge .edu never get blocked by china network censorship system,special famous university like stanford
and I can still get some data form http://www.stanford.edu/.I think it's a network issue so I'm here to inform network administer to look into this matter,thx a lot!

below are trace and ping results
Pinging vspm27.stanford.edu [171.65.103.94] with 32 bytes of data:

Reply from 171.65.103.94: bytes=32 time=445ms TTL=46
Reply from 171.65.103.94: bytes=32 time=1146ms TTL=46
Reply from 171.65.103.94: bytes=32 time=1546ms TTL=46
Reply from 171.65.103.94: bytes=32 time=1668ms TTL=46
| Hop | Graph | % Loss | IP Address | Node Name | Location | | | Network |
---------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | | | 192.xxx.x.x | cxbe1xx | ... | | | (private use) |
| 1 | -x- | | 124.74.12.235 | - | | | | 124.74.12.0 |
| 2 | x- | | 124.74.12.235 | - | | | | 124.74.12.0 |
| 3 | -x- | | 124.74.226.93 | - | | | | 124.74.226.0 |
| 4 | -x | | 124.74.215.25 | - | | | | 124.74.215.0 |
| 5 | x-- | | 61.152.86.54 | - | ?Shanghai, China | | | CHINANET Shanghai province network |
| 6 | x-- | | 202.97.50.242 | - | ?(China) | | | FSKWC NET |
| 7 | x- | | 202.97.34.50 | - | ?(China) | | | CHINANET backbone network |
| 8 | -x- | | 202.97.52.178 | - | ?(China) | | | CHINANET backbone network |
| 9 | x-- | | 202.97.50.46 | - | ?(China) | | | FSKWC NET |
| 10 | -x | | 137.164.130.129 | - | | | | 137.164.130.0 |
| 11 | x- | | 64.57.20.227 | - | | | | 64.57.20.0 |
| 12 | x- | | 137.164.46.119 | dc-lax-core2--lax-peer1-10ge.cenic.net | | | | 137.164.46.0 |
| 13 | x----- | | 137.164.46.95 | dc-svl-core1--lax-core2-10ge-1.cenic.net | | | | 137.164.46.0 |
| 14 | -x--- | | 137.164.47.120 | dc-svl-agg1--svl-core1-10ge.cenic.net | | | | 137.164.47.0 |
| 15 | -x--- | | 137.164.50.158 | dc-stanford--svl-agg1-10ge.cenic.net | | | | 137.164.50.0 |
| 16 | x--- | | 68.65.168.33 | boundarya-rtr.Stanford.EDU | 37.42 N, 122.17 W | | | 68.65.168.0 |
| 17 | | 100 | | | | | | |
| 18 | | 100 | | | | | | |
| 19 | -x--- | | 171.65.103.94 | fah-web.stanford.edu | 37.42 N, 122.17 W | | | 171.65.103.0

Post by **bruce** » Thu Sep 06, 2012 4:45 pm

I agree ... I see no evidence that China is blocking anything. You are successfully connecting to both of those servers. The question I cannot answer is why your client is trying to get work from those servers rather than trying some other server. To determine that, I need to see FAH's log.

According to serverstat, there is no listing for 171.65.103.94, which may mean that it has been removed from service. The Assignment Server should redirect your client to another server within a few minutes. The servers 171.67.108.58, 171.67.108.59, 171.67.108.60, 129.64.95.82, and 171.64.65.101 all seem to be successfully assigning WUs.

If it was a temporary issue that has been resolved, fine. If it's still a problem, please post the logs showing at least 15 minutes of attempts to download a WU.

7im · Post by **7im** » Thu Sep 06, 2012 4:54 pm

Make sure SMP client is version 6.34 or newer.

Nicolas_orleans · Post by **Nicolas_orleans** » Thu Sep 06, 2012 11:35 pm

Dear all

I live in Shanghai and can confirm this issue. See log below. Right now, I have to use a VPN connection to resolve Stanford's assignments servers with v7.1.52. My PS3 that has no VPN and is waiting for WU since yesterday, I rebooted one time then waited 12 hours, no WU dowloaded. My Internet connexion is fine except for FAH.

Code: Select all

13:32:07:</config>
13:32:07:Switching to user fahclient
13:32:07:Trying to access database...
13:32:07:Successfully acquired database lock
13:32:07:Enabled folding slot 00: READY smp:2
13:32:07:Started thread 3 on PID 1028
13:32:07:Started thread 6 on PID 1028
13:32:07:Started thread 7 on PID 1028
13:32:07:WU00:FS00:Connecting to assign3.stanford.edu:8080
13:32:07:Started thread 5 on PID 1028
13:32:07:Started thread 4 on PID 1028
[93m13:32:07:WARNING:WU00:FS00:Failed to get assignment from 'assign3.stanford.edu:8080': Could not get IP address for assign3.stanford.edu: Name or service not known[0m
13:32:07:WU00:FS00:Connecting to assign4.stanford.edu:80
[93m13:32:07:WARNING:WU00:FS00:Failed to get assignment from 'assign4.stanford.edu:80': Could not get IP address for assign4.stanford.edu: Name or service not known[0m
[91m13:32:07:ERROR:WU00:FS00:Exception: Could not get an assignment[0m
13:32:07:WU00:FS00:Connecting to assign3.stanford.edu:8080
[93m13:32:07:WARNING:WU00:FS00:Failed to get assignment from 'assign3.stanford.edu:8080': Could not get IP address for assign3.stanford.edu: Name or service not known[0m
13:32:07:WU00:FS00:Connecting to assign4.stanford.edu:80
[93m13:32:07:WARNING:WU00:FS00:Failed to get assignment from 'assign4.stanford.edu:80': Could not get IP address for assign4.stanford.edu: Name or service not known[0m
[91m13:32:07:ERROR:WU00:FS00:Exception: Could not get an assignment[0m

bollix47 · Post by **bollix47** » Thu Sep 06, 2012 11:47 pm

Not sure if it's related but have you tried Prefer IPv4 over IPv6 ?

vmzy · Post by **vmzy** » Fri Sep 07, 2012 1:34 am

my client is 7.1.52 using ipv4.All chinese people encounter this problem now.
here are logs:

Code: Select all

01:08:58:WU00:FS00:Connecting to assign3.stanford.edu:8080
01:09:00:WU00:FS00:News: Welcome to Folding@Home
01:09:00:WU00:FS00:Assigned to work server 171.67.108.59
01:09:00:WU00:FS00:Requesting new work unit for slot 00: READY smp:4 from 171.67.108.59
01:09:00:WU00:FS00:Connecting to 171.67.108.59:8080
01:09:01:WU00:FS00:Downloading 559.44KiB
01:09:02:Server connection id=1 on 0.0.0.0:36330 from 127.0.0.1
01:12:39:Lost lifeline PID 660, exiting
01:12:40:Server connection id=1 ended

Code: Select all

01:13:00:WU00:FS00:Connecting to assign3.stanford.edu:8080
01:13:00:WU00:FS00:News: Welcome to Folding@Home
01:13:00:WU00:FS00:Assigned to work server 171.67.108.59
01:13:00:WU00:FS00:Requesting new work unit for slot 00: READY smp:4 from 171.67.108.59
01:13:00:WU00:FS00:Connecting to 171.67.108.59:8080
01:13:02:Server connection id=1 on 0.0.0.0:36330 from 127.0.0.1
01:13:38:WU00:FS00:Downloading 559.52KiB
01:26:05:Lost lifeline PID 2868, exiting
01:26:06:Server connection id=1 ended

Code: Select all

01:26:26:WU00:FS00:Connecting to assign3.stanford.edu:8080
01:26:27:WU00:FS00:News: Welcome to Folding@Home
01:26:27:WU00:FS00:Assigned to work server 171.67.108.59
01:26:27:WU00:FS00:Requesting new work unit for slot 00: READY smp:4 from 171.67.108.59
01:26:27:WU00:FS00:Connecting to 171.67.108.59:8080
01:26:28:Server connection id=1 on 0.0.0.0:36330 from 127.0.0.1
01:26:29:WU00:FS00:Downloading 559.11KiB
02:12:29:Lost lifeline PID 6096, exiting
02:12:31:Server connection id=1 ended

7im · Post by **7im** » Fri Sep 07, 2012 2:11 am

There seems to be fundamental problems with either internet routing or internet cabling. I am reading in gaming forums how players in China cannot play because of very slow ping times or very high packet loss to game servers.

I play from the east coast of China and was getting 80-100ms. Now its 350-400ms. To play at your potential you need a ping in double digits, minimum. 400ms is useless. Perhaps things will settle down later, fingers crossed.

So the problems are not FAH related as far as I can tell.

vmzy · Post by **vmzy** » Fri Sep 07, 2012 3:36 am

Thanks.I agreed with 7im.It's a problem of China international connection.
I have reslove this problem by using proxy now.

Post by **bruce** » Fri Sep 07, 2012 4:51 am

This was mentioned above and I don't see that anybody tried it. http://support.microsoft.com/kb/2533454

Since the world-wide IPV6 roll-out, a lot of things have changed and probably a lot of things still need to be changed. FAH has had trouble downloading a new FahCore unless IPV6 is disabled or unless you run the Fix It for "Prefer IPV4 over IPV6" I have seen no reports that this changes anything associated with downloading a new WU but it's certainly not clear to me what might be happening between a client in China and a Server in California or elsewhere. It's just one more thing that you might try.

Nicolas_orleans is having a problem with DNS locating assign3.stanford.edu and assign4.stanford.edu which are used by V7.

vmzy seems to be having a problem connecting to 171.67.108.59 and a tracert (without the proxy) might show something interesting.

Neither of these problems seem to be related to the IPV6 issue, but it's really difficult to diagnose since we don't see the problem from here and as 7im says, it's being reported by gamers and others who do not connect to FAH so I doubt that we can help.

hisui · Post by **hisui** » Fri Sep 07, 2012 9:42 am

I'm one of the original poster,I think problem is much serious than u expect
Seems without using proxy or vpn I have no problem in uploading the finished wu but cant get new WU
I'm also having problem with http://www.stanford.edu/ cant get the page load completely(or any stanford page I know)
(tried on other network same problem)
I think something wrong on our end which have blocked down stream from the server(all stanford server)

From what I can think of The only solution to this problem is ppl form ur end contact(as stanford facultys or authority)our ISP or other related government department,if this problem persists

error log
[03:21:49] + Attempting to send results
[03:22:23] + Results successfully sent
[03:22:23] Thank you for your contribution to Folding@Home.
[03:22:23] + Number of Units Completed: 2856

[03:22:27] - Preparing to get new work unit...
[03:22:27] + Attempting to get work packet
[03:22:27] - Connecting to assignment server
[03:22:28] - Successful: assigned to (171.67.108.52).
[03:22:28] + News From Folding@Home: Welcome to Folding@Home
[03:22:28] Loaded queue successfully.
[04:24:22] + Could not get Work unit data from Work Server
[04:24:22] - Error: Attempt #1 to get work failed, and no other work to do.
Waiting before retry.
[04:24:32] + Attempting to get work packet
[04:24:32] - Connecting to assignment server
[04:24:33] - Successful: assigned to (171.67.108.52).
[04:24:33] + News From Folding@Home: Welcome to Folding@Home
[04:24:34] Loaded queue successfully.
[05:24:47] + Could not get Work unit data from Work Server
[05:24:47] - Error: Attempt #2 to get work failed, and no other work to do.
Waiting before retry.
[05:25:02] + Attempting to get work packet
[05:25:02] - Connecting to assignment server
[05:25:04] - Successful: assigned to (171.67.108.52).
[05:25:04] + News From Folding@Home: Welcome to Folding@Home
[05:25:04] Loaded queue successfully.
[06:25:38] + Could not get Work unit data from Work Server
[06:25:38] - Error: Attempt #3 to get work failed, and no other work to do.
Waiting before retry.

Nicolas_orleans · Post by **Nicolas_orleans** » Fri Sep 07, 2012 1:08 pm

I do agree with hisui. I have been folding in China for more than two years, and for sure, downloading/uploading WUs is pretty slow due to deep packet analysis. However, I NEVER experienced any download error as it started this thursday.

I can confirm hisui's findings : since thursday it's impossible to download WU, but it's possible to upload WU results.

From what I see in FAH log :
- downloading WU relies on adresses that have to be resolved by DNS into IP Adresses
- uploading WU results relies on a direct connexion to collection server IP Adress

So I would guess there is a DNS resolving issue in China on some parts of stanford.edu domain since thursday.

On http://tracert.com I can sometimes resolve assign3.stanford.edu and assign4.stanford.edu. Sometimes it does not resolve.

Could people in charge of keeping the worldwide DNS records / MX records of Stanford have a look at it ? Once again, during two years of folding, I never get this kind of issues.

vmzy · Post by **vmzy** » Fri Sep 07, 2012 1:27 pm

I used AIPU ISP before.It can not download WU(upload is correct) from June this year.So I changed my ISP to China-Net.And download back to normal until thursday.
Now almost all ISP in China can`t download(upload is correct).
In the tracert log I post you can see it often timeout after boundarya-rtr.Stanford.EDU [68.65.168.33].So does it mean there is something wrong with your network?
As far as I know all Stanford WS server have this problem.WS out of Stanford (like BigAdv) didn`t have this problem.

Post by **bruce** » Fri Sep 07, 2012 6:02 pm

Nicolas_orleans wrote:I do agree with hisui. I have been folding in China for more than two years, and for sure, downloading/uploading WUs is pretty slow due to deep packet analysis. However, I NEVER experienced any download error as it started this thursday.

I can confirm hisui's findings : since thursday it's impossible to download WU, but it's possible to upload WU results.

From what I see in FAH log :
- downloading WU relies on adresses that have to be resolved by DNS into IP Adresses
- uploading WU results relies on a direct connexion to collection server IP Adress

So I would guess there is a DNS resolving issue in China on some parts of stanford.edu domain since thursday.

On http://tracert.com I can sometimes resolve assign3.stanford.edu and assign4.stanford.edu. Sometimes it does not resolve.

Could people in charge of keeping the worldwide DNS records / MX records of Stanford have a look at it ? Once again, during two years of folding, I never get this kind of issues.

I believe that all downloads start by contacting one DNS name assign*.stanford.edu on port 8080 and if that fails, it contacts a secondary DNS name on port 80. Either of those servers wil assign an IP address of a work server and the download proceeds using the assigned address. During an upload, the first attempt is to that stored IP address and if that fails, to a Collection Server (also by IP Address). Downloading an updated FahCore is processed entirely by a DNS name and the IPV4/IPV6 problem I mentioned earlier depends on which type of IP address is delivered by DNS since http://www.stanford.edu has both an IPV4 and an IPV6 address.

Facts:
* The client only uses DNS rarely: once or twice per connection.
* Stanford supports IPV6 with some servers but if IPV6 fails, there is no procedure to fall-back to IPV4.
>>> (Disabling IPV6 forces the client and servers to use the "old" methodology which has not changed.)
* All servers can still work with IPV4 except if DNS provides IPV6 addresses.

I don't think having Stanford contact your ISP is going to be helpful, even if we ask them to (and asking them doesn't assure that they will).

I suspect that the techniques of deep packet inspection for IPV4 have been in place for a long time and they probably do what they were designed to do. My first guess is that the technological challenges of extending deep packet inspection to IPV6 is causing the problems you are seeing and I don't think anything can be done from the USA to help China with those problems. We'll just have to wait for it to be fixed. Of course I could be wrong about this; like I already said, this is a guess.

If it is a problem with the world-wide IPV6 roll-out, the most promising approach may be temporarily avoiding IPV6.

If your OS runs a dual-stack, Linux has a local file called /etc/hosts which can be used to bypass DNS -- and in this case, to provide IPV4 addresses instead of receiving IPV6 addresses from DNS. I don't have a detailed explanation of how to do that on Windows but I believe that Windows can do the same thing.

SMP 171.67.108.200 assign.stanford.edu assign3.stanford.edu
SMP 171.64.65.121 assign2.stanford.edu assign4.stanford.edu
GPU 171.67.108.201 assign-GPU.stanford.edu
171.67.215.200 www.stanford.edu
The PS3 might be using 171.67.108.202 or 171.65.103.102 or 171.67.215.65.145. I'm not sure which.

By forcing these addresses, you will loose a certain amount of redundancy so it's not a permanent fix, but if it happens to work temporarily, that's better than what you have now.

RMouse · Post by **RMouse** » Sat Sep 08, 2012 6:56 am

Help! My GPU finished a WU and now sits idle as there is no work assigned to it. It says download under work que but has stayed at 0% for over 10 hours. How to get a WU assigned to my GPU? My CPU continues to fold away without a problem.

Might there not be any WU's available now? I see nothing in the log to indicate any problems.

Folding Forum

GPU inactive [FAH from China is off-line]

can`t download WU from yesterday

Unbale to connect stanford network and dl workunite

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

Re: can`t download WU from yesterday

GPU inactive [FAH from China is off-line]