|
1)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4152)
Posted 3 days ago by Grant (SSSF) Post: I wouldn't worry about overall credit as long as it is fixed going forward as you mentioned.Yep. I'm not overly fussed about the Tasks that have already been done with the lower Credit, just glad it's been sorted and all new Tasks are resulting in a more appropriate level of Credit. You're one of the most communicative and responsive Admins of Projects aroundActually, in a league of your own. A great example for all the other projects IMHO. |
|
2)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4146)
Posted 4 days ago by Grant (SSSF) Post: That does sound like a problem. I do know that the WUs for the new batch should take longer, so the credits should be higher. I might have inverted the scale factor.Hope you've had a good break, looking forward to your return- RAC has been in freefall for the last few days. |
|
3)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4141)
Posted 5 days ago by Grant (SSSF) Post: Has there been a hiccup with the system? The current work going through is taking way, way, way longer to process (what were approx 3hr CPU Tasks, are now taking 4-5+hrs), yet the amount of Credit per Task has been reduced? The reduced throughput of the previous batch resulted in a big drop in RAC (301k dropped to 265k for one system), but this will be even larger again. |
|
4)
Message boards :
Number crunching :
FP64
(Message 4129)
Posted 15 days ago by Grant (SSSF) Post: So my 4070 ti, which takes 3, 4 minutes per task, runs about the same number of tasks per hour?Roughly. I'm using the Remaining (estimated time) for unstarted Tasks for comparisons- you're running BOINC 8.2.8 which from memory that got broken and no longer updates as Tasks are returned. So based on my current numbers RTX 4080 Super 10min 17sec, 3 at a time = 420 per day. RTX 4070TI Super 7min 56sec, 2 at a time = 363 per day. RTX 2060 Super 11min 26sec, 1 at a time = 126 per day.I worked out what gave the best output per 24hrs ages back, before these much longer running Tasks. So running one less Task may give better throughput, but it probably wouldn't be much of an increase. If i get bored and have some time i might have a play and see if it is worth it or not. Basically download a day or more's worth or work, then turn off the BOINC network connection. For 1 Task at a time do at least 40 Tasks, manually work out their average processing time, then change the number of Tasks to two, do at least 80 Tasks, manually work out their average processing time, etc,etc (making use of GPUz to see what the GPU load is- if it's sustained over 90%, then there's no point running more Tasks, a bit less than 90%, might as well try it and see. Less than 70% is almost always worth running another Task. Less than 60%, it's always worth running another Task). |
|
5)
Message boards :
Number crunching :
FP64
(Message 4127)
Posted 16 days ago by Grant (SSSF) Post: If I buy a high-performance FP64 graphics card, such as an Nvidia Tesla V100 or P100, will there be a big difference in performance?It was high performance 10 years ago, roughly equivalent to the GTX 3070, and pulls 250W max. It is barely faster than my RTX 2060 Super, which is flat out processing 1 Task at a time. My RTX 2060 Super is averaging 11min 30sec per Task, while running 1 Task. My RTX 4080 Super is averaging 10min 15sec per Task, while running 3 at a time. |
|
6)
Message boards :
Number crunching :
boincstats
(Message 4066)
Posted 7 Nov 2025 by Grant (SSSF) Post: Can someone explain why my work at NumberFields@Home is not showing up in boincstats (https://www.boincstats.com/)?In your account here, under "Preferences" "Preferences for this project NumberFields@home preferences", have you selected "Do you consent to exporting your data to BOINC statistics aggregation Web sites?" and Updated preferences? Once done, it can still take a day or two for them to show up. |
|
7)
Message boards :
News :
NumberFields Is Back
(Message 4041)
Posted 23 Oct 2025 by Grant (SSSF) Post: Glad to hear it was nothing major. |
|
8)
Message boards :
News :
Finally recovering from hard drive crash.
(Message 4038)
Posted 23 Oct 2025 by Grant (SSSF) Post: After being MIA for 24hrs i see we're back. Just wondering what happened this time??? |
|
9)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4019)
Posted 26 Sep 2025 by Grant (SSSF) Post: Further thoughts on why the Initial Remaining (estimated) times have dropped down as much as they have- Statistics is definitely not my thing, but i did remember some of it, and found the info i was looking for on the BoM (Bureau of Meteorology) web site in relation to rainfall. Mean rainfall (mm)The Initial Remaining (estimated) times are based on the average (arithmetic mean) of previous completed Tasks. And as that information with regards to rainfall points out- one extreme value will have an outsized impact on the average. So the even though they are only very, very occasional, those extremely short runtime Tasks skews the average down much lower than it would be without those outliers in there. |
|
10)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4010)
Posted 20 Sep 2025 by Grant (SSSF) Post: It's probably still worth doing a pre-release run; little to no change in times then all is good. If there is a significant bump or drop in runtimes, then you've got advance warning that you'll need to take a closer look once the batch is being returned in large numbers. |
|
11)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4005)
Posted 20 Sep 2025 by Grant (SSSF) Post: Overall, my RAC has dropped by 11,000- which is only 2% but looking at it on a graph, it looks so much larger. Prior to this batch, since i joined up here back in early January the variation in RAC (other than issues with the project or my systems) has been around 0.6% which is very good IMHO (and probably why the present change in RAC stands out so much). And with the initial Tasks over the first few days may more of them were completing much sooner than the present ones, so if the Credit per Task hadn't changed then the boost in RAC while significant, wouldn't have been as much as it first looked as though it would be. Splitting any difference between the two ratios, with a weighting towards the more affected of the two (the bigger the difference, the greater the weighting) should result in a similar RAC with different batches, even if one compute resource is affected more than the other (either up or down). |
|
12)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4004)
Posted 19 Sep 2025 by Grant (SSSF) Post: I think I figured out the root cause of what you are seeing. I am basing the credit on the ratio of average CPU times from one batch to the next. So the RAC for just the CPU will be almost dead on. However, it appears the efficiency of the GPU app went down a little bit for this latest batch compared to the previous batch.That makes sense. Going forward, after the current batch, I will use the better of the two ratios to determine credit. That way, if the RAC changes it will increase instead of decrease. It would be best to have different credits for CPU and GPU, but I can't do that since the same WUs are interchangeable between the two platforms and hence a single credit is associated with the WU.Or even split the difference between the two, with a bias towards the one most affected. That way with the change in batches, even if one Compute resource is affected more than another, the RAC should still end up being relatively steady with just a small boost or cut instead of getting a larger boost or cut. |
|
13)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4002)
Posted 19 Sep 2025 by Grant (SSSF) Post: Around the time the new batch came out, we had a city-wide power outage for several hours, which caused a big drop. In the past, over the next few weeks the RAC slowly makes it's way back to around where it was. This time the RAC dropped, and it's been dropping even further since then- its' been dropping more on my RTX 4080 system (that card runs 3 Tasks at a time; the new ones might be loading it more than the earlier batch and reducing it's output). However, the other system (RTX 4070 Ti Super with 2 Tasks running) and it too is dropping it's RAC- just not as much or as quickly. When things get funny i always check Task Manager in case something's going on that shouldn't be, and both systems show no signs of other processes sucking up CPU time. The RTX 4070 Ti Super has gone from 254,000 to 248,000. The RTX 4080 has gone from 300,600 to 295,000 (i've set my stats so that in the BOINC Manager it keeps them for several years so i can see how thing are on the Statistics tab over a long period of time). I have noticed a lot of resends over the last couple of days, but they're often processing faster overall than the current initial release Tasks. The current case has a larger standard deviation than usual, so you will see greater fluctuations in your run times and RAC, but it should not be a huge difference. The remaining time on an unstarted WU in the manager will give you an idea of what the average runtime is.Yeah, the initial Remaining (estimated) times have dropped for both the CPU and GPU Tasks, although for the RTX 5080 just over the last day or two they have climbed back up to almost where they were before. And the CPU & other GPU times are higher than what they were after the initial release of the batch, but still much lower than what they were with the previous batch. I'll just see how things go over the next couple of weeks. |
|
14)
Message boards :
Number crunching :
Reduced credit per work unit
(Message 4000)
Posted 18 Sep 2025 by Grant (SSSF) Post: Could you re-check the current value of Credit for completed Tasks? When this batch first came out, there were a lot of very short running takes, and quite a few extremely short running Tasks. So RAC would have jumped up noticeably, but i saw that you trimmed back the amount of Credit per Task. Since then, the number of shorter running Tasks has declined significantly, the number of extremely short running Tasks has dried up completely, and i'm getting more & more much longer running Tasks. End result- My RAC has fallen noticeably, and is continuing to fall; quite steeply now. |
|
15)
Message boards :
Number crunching :
CPU HT and batch
(Message 3979)
Posted 13 Sep 2025 by Grant (SSSF) Post: I'm not sure what they were testing in those graphs, but every app will be different.That's the average of dozens of programmes, on a Zen 5 CPU. eg With my AMD Ryzen9 7950X: my CPU temps were about 90C with HT on, and about 80C with it off. I don't like stressing my CPU that much so I leave it off.Yeah, apparently they do tend to run hot- even with very good cooling. Even though AMD officially say that they are OK with then running 24/7 at 95°c, 80°c the absolute limit for me with a CPU for extended periods. |
|
16)
Message boards :
Number crunching :
CPU HT and batch
(Message 3977)
Posted 13 Sep 2025 by Grant (SSSF) Post: While there are some edge case where Hyperthreading off will improve performance, in most case having it on results in better performance. In many cases it actually results in much better performance- how long it takes to process a Task isn't the best way to determine how productive your system is, how many Tasks you can do in 24 hrs is what matters. Even if it takes longer to process each Task, doing 100 Tasks in 24 hours is way better than only doing 75 in 24hrs. And as for heat- the increase in power consumption and in heat is generally negligible. SMT Performance Benchmarks Continue To Show Benefit With AMD Zen 5/5C |
|
17)
Message boards :
Number crunching :
Running slow on Intel GPU
(Message 3936)
Posted 23 Aug 2025 by Grant (SSSF) Post: From Phoronix's B580 review One of the compute driver bugs with the Intel Compute Runtime on Battlemage appears to be around having much higher latency than Alchemist and the NVIDIA/AMD competition. Here's a look at the OpenCL kernel latency being many times higher on the Arc B580 than the Alchemist A-Series. Hopefully this Intel Compute Runtime issue can be quickly worked out. While these are LINUX benchmarks, there's a very high likelyhood that this issue is shared with the Windows drivers as well. If so, it would appear that Intel have yet to sort out this issue, even though it's been over 9 months since it's release. |
|
18)
Message boards :
Number crunching :
No support for NVidia 5000 series?
(Message 3928)
Posted 15 Aug 2025 by Grant (SSSF) Post: In Windows i've only ever seen the driver expressed as xxx.xx I've never seen more than 2 digits after the . EDIT- I'm running v566.36 In Device manager, the driver version is listed as 32.0.15.6636, but it's always been referred to in the xxx.xx format (Nvidia settings, GPU-Z shows the full number, then in brackets (xxx.xx). |
|
19)
Message boards :
Number crunching :
No support for NVidia 5000 series?
(Message 3919)
Posted 10 Aug 2025 by Grant (SSSF) Post: More importantly, the error is that it can't "set the device", so it's probably some kind of environment problem, maybe a permission or SElinux thing.It's trying to set Device number 0, but the OS considers it Device number 1? Something, somewhere is confused. |
|
20)
Message boards :
Number crunching :
No support for NVidia 5000 series?
(Message 3917)
Posted 10 Aug 2025 by Grant (SSSF) Post: So there are only 2 linux hosts with a 5000 series card (database only keeps last 5 days of results). The one mentioned earlier with successful results and this one with failures: Driver 575.64, GNOME 48 (Flatpak runtime) [6.8.0-71-generic|libc 2.40] Same Video driver, same libcurl version. And while it is also GNOME 48, the working one is based on 6.15.9-gentoo-dist, the failing one 6.8.0-71-generic process exited with code 1 (0x1, -255) Setting GPU device number 0. Cuda Error: failed to set the device. Error: Failed to initialize Cuda. So the issue appears to be with how the new hardware, with the same driver, interacts with the OS/Kernel. It works on one OS/Kernel version, but not on another. |