Strange WS assignment

[SkyFall]

I newly installed FAH 7.5.1 on some machines in order to participate in the LTT Folding Month.

I seem to not get any GPU workunits on my machines I connected via an android phone in tethering.

The log says:

Code: Select all

Connecting to 65.254.110.245:8080
Assigned to work server 192.0.2.1
Requesting new work unit for slot 01: READ gpu:0:RV830 [FirePro V3800 (FireGL V)] from 192.0.2.1
Connecting to 192.0.2.1:8080 
WorkServer connection failed on port 8080 trying 80
... 

And then it continues to cycle between port 80 and 8080 in order to get any WUs from 192.0.2.1....

Any ideas what bug I just encountered?

[Joe_H]

Welcome to the folding support forum.

Your Firepro V3800 while still whitelisted does not appear to support double precision calculations from the information I was able to look up relatively quickly. To the best of my knowledge, projects that would process on GPU's that support just single precision are not currently running, so there are no WU's to assign to your GPU. So you have not actually run into a bug.

Currently running projects use some double precision calculations for critical steps requiring the greater accuracy, the rest of the calculations are done in single. The question has been raised with the project runners whether or not any future projects might be released that only require single precision, as best as I know a final decision on that has not yet been made. If they decide to require mixed (single & double) precision support for all future GPU projects, then GPU's that don't will be moved to unsupported status in GPUs.txt.

[SkyFall]

Welcome to the folding support forum.

Your Firepro V3800 while still whitelisted does not appear to support double precision calculations from the information I was able to look up relatively quickly. To the best of my knowledge, projects that would process on GPU's that support just single precision are not currently running, so there are no WU's to assign to your GPU. So you have not actually run into a bug.

Currently running projects use some double precision calculations for critical steps requiring the greater accuracy, the rest of the calculations are done in single. The question has been raised with the project runners whether or not any future projects might be released that only require single precision, as best as I know a final decision on that has not yet been made. If they decide to require mixed (single & double) precision support for all future GPU projects, then GPU's that don't will be moved to unsupported status in GPUs.txt.

Thank you Joe,

I expected something around those lines, as I read the documentation about whitelisted GPUs and dp/sp capabilities.
However, I think it is very strange behaviour, that the Assignment Server assigns me my local gateway as the work server.

Shouldn't it just refuse to send workunits at all instead of just sending me into a loop?

[Joe_H]

Actually the IP number you were assigned to is not your local gateway. 192.0.2.n numbers are reserved for another purpose, you could be thinking of the 192.0.0.n block which is reserved for private networks behind a router. A future version of the client and server software may add a message as to the reason, the 192.0.2.n block is for "documentation".

[bruce]

The few cases that I've seen 192.0.2.* called were due to the lack of double precision support. Thats not necessarily the only reason it might be referenced, but it's a pretty good guess, especially since redwood chips don't support double precision.

I think that FAH should make a formal announcement that at least limited Double Precision (i.e.- Mixed Precision calculations) is now a requirement. I consider it unlikely that any more projects will be available for single precision hardware.

[JimboPalmer]

"The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

We will refer to the first block as "24-bit block", the second as "20-bit block", and to the third as "16-bit" block. Note that (in pre-CIDR notation) the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B network numbers, and third block is a set of 256 contiguous class C network numbers." https://tools.ietf.org/html/rfc1918

192.0.2.1 is not in any of these ranges, and is not Private.

[Joe_H]

This Wikipedia article has a nice table of the various reserved IP addresses - https://en.wikipedia.org/wiki/Reserved_IP_addresses. Some are "private" as defined in RFC's that came after RFC 1918.

[SkyFall]

Shame on me!
I should have known better about this IP address.

Although I do not agree on how FAH handles this situation server-side, this topic can be closed.

Thank you all for your input.

Best regards
SkyFall

[bruce]

How is my ISP supposed to route 192.0.2.1?

C:\Users\bruce>tracert 192.0.2.1

Tracing route to 192.0.2.1 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.1.1 (my router)
2 9 ms 8 ms 7 ms 10.80.44.1
3 8 ms 8 ms 8 ms ipxx-xx-xx-xx.oc.oc.cox. (my current global IP address)
4 * * * Request timed out.
5 * * * Request timed out.
6 ....