Folding Forum

CIElch wrote: ↑Wed Oct 01, 2025 2:50 am CPU folding seems unaffected.

It might be spreading. I only contribute CPU for F@h at this time, and I just encountered this at around 11:00 UTC.

I've only had a couple more instances of HTTP_SERVICE_UNAVAILABLE, one at 09:29:17 UTC and the other at 13:22:25 UTC, both on the same host. I also note the report of public jobs available steadily decreasing hour by hour. So I really think the reinstatement of vav22, even if there's still other wor...

That might be helping a bit, because I just had a task assigned without any 'no appropriate assignment' error: 05:16:55:I1:OUT460:> POST https://assign1.foldingathome.org/api/assign HTTP/1.1 05:16:56:I1:OUT460:< HTTP/1.1 200 HTTP_OK 05:16:56:I1:OUT461:> POST https://vav22.fah.temple.edu/api/assign H...

So no changes yet? I only ask because since around 01:30 UTC I've been noticing differing project IDs for the work being assigned - as well as shorter delays between requests and assignments - so I thought something might have changed already. Maybe it's just coincidental. Anyway, thanks for the upd...

...my GPUs are Radeons.

...my hosts are mostly Linux.

...I reiterate/clarify that I'm talking about non-F@h projects.

The GPU projects I run are heavily CPU-based - it depends on the nature of the GPU, of course. My fastest GPUs actually need a full core of a fast CPU - in other words, the tasks are somewhat CPU-bound (but still far more efficient than running on CPU alone). ...but this is irrelevant to the discuss...

Thanks for the update. A question: I notice you seem to use the terms CPU core and thread interchangeably. Does F@h really run that well with SMT? I tend to restrict my machines (not just for F@h) to account for CPU physical core counts, especially since I also run GPU tasks for other projects and t...

Just wondering, is there any news regarding possible improvement in task allocations with respect to CPU core counts? Or should we consider this to be the new situation? I'm just wondering if I should switch to other projects as the situation has been pretty bad for anything less than 20 cores for t...

Is it always about CPU core counts? My largest host allocates 20 cores and occasionally I see it unable to get any work assignments (during these periods of work shortages).

muziqaz wrote: ↑Mon Aug 25, 2025 3:33 pm There might not be enough CPU work for 4 threads.

Is there a place where we can look for information on what's available? A few days ago I noticed trouble getting CPU work (which is all I do for F@h) but then it seemed to stabilise, while today I notice the situation appears to have returned.

A traceroute would be more useful than a ping. I did that earlier today as well: traceroute to vav21.fah.temple.edu (129.32.209.204), 30 hops max, 60 byte packets 1 _gateway (192.168.1.1) 2.683 ms 2.711 ms 2.698 ms 2 [ISP] 13.294 ms 13.233 ms 13.318 ms 3 [ISP] 13.002 ms 13.037 ms 13.030 ms 4 [ISP] ...

What I found in my limited research is that the server's location may not be the in the same location as the institution represented. For example, I get 35 ms for washu.edu but its IP address is apparently in San Francisco. Western US is obviously closer to eastern Australia than eastern US. Anyhow,...

I was concerned mainly because I'd never seen this kind of issue so consistently for so long before (about 2 hours). Testing again just now, vav21 and vav23 are around 225 ms for me. I tried upenn.edu as a point of comparison, but it looks like that server is based in San Francisco, as I'm getting p...

Looks like it was a transient issue. I was able to download again from vav21.fah.temple.edu, but ping times are still very high, nearly 250 ms. But no dropped packets, so presumably that's why the downloads resumed.

This may be a regional issue, I'm located in Sydney, Australia. Internet connections seem to be working fine for everything else, but starting at least at ~05:00 UTC, 2025-05-23, my clients could not download tasks from vav21.fah.temple.edu or vav23.fah.temple.edu (there may be other temple.edu serv...