I am pleased to report that the search over ℚ(√2), also known affectionately as "subfield 3", is now officially 100% complete.

This search has been in the works, off and on, for several years. It goes without saying that this is a major computational achievement. We couldn't have done it without all the volunteers, so I thank you all!

The batch status tables have been updated accordingly with subfield 3 moved to the archives. The results of the search can be found here.

Hi all.
I added an application for nvidia opencl to NumberFields-Gerasim.
Theoretically, everything works, but Gerasim does not send tasks for Nvidia.
This is my second unsuccessful attempt. :(
.
To find out what's going on, I need to run Gerasim under a debugger, and look at the scheduler request / replay .
My suggestion is to count the current set and start investigating after Eric has all the results from the current set.
.
Resume:
The sooner we finish Gerasim's work, the better. :)

Hello
if you want to continue using the Gerasim server, it would be better to keep applications for Linux and Mac.
thank you

With the help of SerVal I dropped a batch of tasks on the Gerasim server. Currently just for windows cpu. The tasks are for the remainder of the subfield 3 search. Those users that are more interested in sf3 can get tasks from Gerasim - the only caveat is that you get Gerasim credit instead.

I think of this as a trial period, to see how it goes. Numberfields is not going away anytime soon, and Gerasim can run the sf3 tasks in parallel to the sf7 tasks currently running on NF. I will keep this up for as long as Gerasim and/or SerVal allows.

Hi all.
I added an application for nvidia opencl to NumberFields-Gerasim.
Theoretically, everything works, but Gerasim does not send tasks for Nvidia.
This is my second unsuccessful attempt. :(
.
To find out what's going on, I need to run Gerasim under a debugger, and look at the scheduler request / replay .
My suggestion is to count the current set and start investigating after Eric has all the results from the current set.
.
Resume:
The sooner we finish Gerasim's work, the better. :)

Hello
why there is no Linux and Mac application on Gerasim ?
Thank you.

Thanks all for your comments. The problem is not the cost of the hardware, and I could even donate that myself to the University if it would help. I think the biggest issue is the server maintenance. I don't actually work for the University, so they need to get the IT department to do the install of any donated hardware (if they will even accept it), and that's a hassle for them. They had no problem doing it for a tenured professor, but now there is no one to fight that battle. If I was more of a people person and knew who's butt to kiss I might be able to make it happen, but that's not who I am. Anyways, I hope the hardware has several more years left in it, so this all becomes a mute point.

Short answer: Yes, credits are too small here.

Longer answer: Try doing come crunching with your own machines on other projects. PrimeGrid is a good baseline, a good place to start. Run your CPUs there against one of their LLR sub-projects, and run your GPUs on their PPS sub-project. That should give you a good benchmark to compare to what you generate against this project. Then consider offering bonus rates for unusual things that you may require for your project, for example large memory requirements, or long running times without checkpoints, etc.

I have been suspending jobs because there appears to be many of them all estimated to run at least 9 hours and all hogging the work from all other projects, Many of these other projects
have tasks running for less than 2 minutes.

One of the NumberFields@home jobs is even reporting that it will take
410 days 5 hrs. 22 mins and 45 seconds to complete (over a year!)

Every other job is showing 9 days 11 hours and 11 minutes estimated completion time

Surely this project should not be stopping other tasks (such as Coronavirus research) from running.

Personally I think you, like Seti, will come to regret that decision. Seti has by far the most number of people signing up to crunch for it, they do the most PR stuff so why wouldn't people start there? BUT they are also the project that most people then leave for other projects too!! Seti has numerous problems such as not being able to get the grants like they have in the past etc and are now shut down at least 2 days per week every week, this has also affected their ability to retain people who pay to crunch too. The people that do crunch there are aware of that and work around it but since people are leaving the project it also means they no longer have as many people doing the crunching and their time frame to analyze the data is reduced as a result. In short it's your decision and your project and your decisions will affect how long it keeps going at the current rate.

Some projects pay a lot of credits for the crunching power users bring, some projects pay much less, it all depends on your goals and your ability to keep people crunching and projects such as Collatz, they currently pay the most of any gpu project, sometimes struggle to keep things running smoothly and cheater free. If your desires are to get thru the data faster then pay more credits, if your ability to expand or keep your existing hardware running is reduced then reducing the amount of credits you pay is the easiest way to keep users away.

Mikey, I agree. A few months ago the team standings on this project were turned upside down due to a huge credit anomaly. It also had the effect of singlehandedly reordering a good portion of the DC-Vault standings. Now the credits are so low here that it's folly to even think that the credit totals can be brought back into reality. GPU credits are ridiculously low. Maybe it's partly due to an inefficient GPU application. Back on topic, the crazy high credits that were spewed out for a few days were never rolled back and that's a problem. I'm sure that the people/teams that benefited are happy but no one else is. The apparently unrealized upshot is that those teams that benefited can quit work here because no one can realistically ever catch them and the teams that missed the few days of insane credits have no reason to run this project anymore as the possibility of upward mobility is virtually nonexistent. Not rolling back those crazy credit days are akin to shooting oneself in the foot as far as project participation is concerned.

Yep, CreditNew. Seems to be the only way to fairly handle both CPU and GPU tasks.

You may have noticed the server scheduler has been very fickle of late.

I think part of the problem is related to how WUs have been segregated into batches (1 for normal app and 1 for GPU app). Since the GPU app has been relatively stable and has agreed with the CPU version on every WU tested (over 400), I have decided to remove the batch descriminator (this will open up the DS14x12 WUs to the GPU app).

I now have over 100 GPU WUs. Interestingly enough they are all of the DS14x12 variety (batch 0) and all have a higher priority (due to accelerated retry mechanism). Ironically, I think this points to the root cause of the scheduler problem...

I think this may have fixed the problem, at least for me it has. Please let me know if you still have problems receiving tasks.

Are there about equal numbers of both cpu and gpu workunits being created or you focusing on gpu workunits right now? I ask because I have some cpu cores that can't get work here right now and if I should be trying the gpu workunits instead.

The same WUs work on both cpu and gpu, so you should be able to get tasks for either.

Did this start working for you? I checked about half of your computers and they have tasks in progress. If there are specific hosts with problems let me know which ones and I can troubleshoot it.

I noticed earlier all my hosts had 2nd hand tasks. It seems like a ton of tasks expired simultaneously and were reissued at the higher priority - when this happens the scheduler will only give them to hosts it deems are "reliable". I think this may have been the problem, and you are probably not the only one affected.

You may have noticed the server scheduler has been very fickle of late.

I think part of the problem is related to how WUs have been segregated into batches (1 for normal app and 1 for GPU app). Since the GPU app has been relatively stable and has agreed with the CPU version on every WU tested (over 400), I have decided to remove the batch descriminator (this will open up the DS14x12 WUs to the GPU app).

I now have over 100 GPU WUs. Interestingly enough they are all of the DS14x12 variety (batch 0) and all have a higher priority (due to accelerated retry mechanism). Ironically, I think this points to the root cause of the scheduler problem...

I think this may have fixed the problem, at least for me it has. Please let me know if you still have problems receiving tasks.

Thanks for telling me that. I will run them when you have them.

I would run CPU wus except that I have heat problems that I can't overcome.

AT Hiker

Another thing to keep in mind is this app requires openCL 1.2, and it looks like your video driver only supports 1.1. You might be able to upgrade the driver.

Well I can't work out why my faster computer (by only 200 MHz, an AMD Phenom II 1100T @ 3.3 GHz, my other is AMD Phenom II 955 @ 3.2 GHz), is getting consistently much lower results than my slower machine.
...

I really don't understand how the credit system works but I gather is is all based on these benchmarks that run initially. Perhaps there was something else running during the benchmark phase which is lowering the scores on your Phenom. I believe you can force the manager to re-run them. Can you give that a try before you bail on your AMD?