PrimeGrid
Please visit donation page to help the project cover running costs for this month

Toggle Menu

Join PrimeGrid

Returning Participants

Community

Leader Boards

Results

Other

drummers-lowrise
11) Message boards : Generalized Fermat Prime Search : Important Upcoming Genefer Changes (Message 118349)
Posted 1945 days ago by axn
you may read this thread
helped me on my ubuntu installation

i did check that thread -- looks like a workaround. I was under the impression that the latest genefer fixed this high cpu bug once and for all (similar to ppsieve / ap27).
12) Message boards : Generalized Fermat Prime Search : Important Upcoming Genefer Changes (Message 118346)
Posted 1945 days ago by axn
One nice new "feature" (actually a bug fix) of the new GPU version of Genefer is that you probably no longer need to keep a CPU core free to feed the GPUs.

On Ubuntu, Genefer OCL is chewing up a full CPU core. Is that expected? I thought the change was that it will no longer use up CPU
13) Message boards : Number crunching : Badge suggestion - Probably not going to be a popular opinion... (Message 117830)
Posted 1970 days ago by axn
Here is a proposal of mine from Proposed badge level adjustment
14) Message boards : Seventeen or Bust : The SoB Double Check is DONE!!! (Message 116928)
Posted 2000 days ago by axn
Simple question.

Horribly complicated answer.

Yes, we do -- as long as you're running a computer with the exact same XEON CPU as our BOINC server AND inhibit LLR from using AVX. And you don't mind a very complicated answer. And you don't also mind if the answer is sometimes wrong.

LLR's choice of FFT depends on a lot of different factors. The obvious one is the size of the candidate being tested. The value of K affects the choice, too, so it's going to depend on which of the 5 K's is being tested. The type of CPU matters. Some CPUs will switch FFTs at different places. Some CPUs will use certain FFT sizes that other CPUs will never, ever use.

It's incredibly hard to predict which FFT size LLR will use. Since we need to know which FFT will be used in order to assign credit, we do the prediction ... by having the server run LLR on every candidate individually in order to see which FFT it uses. We don't run the calculations, of course. Just the part where LLR chooses the FFT. The FFT selection is then recorded with the candidate.

So, in theory, I could tell you when each of the 5 K's will switch to the next FFT, right? Nope, it's still more complicated. Just because one candidate uses the next larger FFT doesn't mean that all larger candidates with the same k will also use the larger FFT. Some of them may use the smaller FFT size.

And, of course, it's likely that with some candidates your particular CPU will run a different FFT than the server would, so for you, any information I have would be wrong anyway at least some of the time.

And to top it all off, sometimes LLR chooses the wrong FFT, meaning it's too small. Rounding errors start happening, LLR detects the errors, and reruns the calculation with a larger FFT.

Put it all together and it's so convoluted that I've never bothered looking to see when the FFT is going to change. Any information I get is likely to be badly misleading.

As a prelude to an answer, this is a good explanation, but I notice that you didn't actually answer the question. Is it really that complicated to do something like:

select k, fft, min(n), max(n)
where project = sob
group by k, fft

15) Message boards : Problems and Help : Another Question about multi-threading (Message 116851)
Posted 2003 days ago by axn
By moving to 2 * 4 it looks like I'll be able to do 50% more if the run times continue to hold up.

eg
1 * 8 9357 secs on average per WU ~ 64 per week
2 * 4 140633 secs on average per WU ~ 86 per week

If my admittedly hazy math is correct.


86/64.5 = 1.33 so about 33% more.
16) Message boards : Problems and Help : Noob question about multithreading (Message 116605)
Posted 2009 days ago by axn
Use:

<app_config>
<app_version>
<app_name>llrESP</app_name>
<cmdline>-t 4</cmdline>
<avg_ncpus>1</avg_ncpus>
</app_version>
</app_config>

And set BOINC to use 25% CPU.

1) Using HT on 2c/4t setup has shown _minor_ performance improvement over not using HT.
2) Sometimes, if you run out of work (say, due to n/w connectivity issue), and BOINC finally fetches task, it will fetch 'n' number of tasks (where n is the number of CPUs you told BOINC to use. To avoid that, tell BOINC that you're only planning to use 1 CPU, and also lie to BOINC that your app only needs 1 CPU.
There was a recent thread where some people experienced this exact situation.

Finally, unrelated to BOINC setup, but are you running RAM in dual channel mode? (If you're running two matching sticks, you probably are. If you're running only one stick, you're not -- get a matching stick ASAP).
17) Message boards : Seventeen or Bust : The SoB Double Check is DONE!!! (Message 116575)
Posted 2010 days ago by axn
http://www.mersenneforum.org/showpost.php?p=476379&postcount=341

Aware: yes. Working on it: don't know.
(actually, I think there were two different error checking mechanisms talked about over there, I don't know which one does what, so it might not necessarily be this one)

Ah, yes. I overlooked that exchange. George does mention the specific test (Gerbicz error check) that I was talking about. The other check (Jacobi check) is very specific to Mersenne numbers.
18) Message boards : Seventeen or Bust : The SoB Double Check is DONE!!! (Message 116567)
Posted 2010 days ago by axn
There has been recent development of a bullet-proof error check that will detect virtually all errors. This error check should be implemented post-haste into LLR so that SOB/ESP/PSP/PPS projects can become virtually error-less. (We'll still need adaptive/full double checks since cheating could still be an issue).

Count our overclocks in for that round of testing!

Oh, no. I don't mean "should" as in "it is coming soon", I mean "should" as in "must". No idea whether Jean Penne is even aware of this test, let alone working on implementing it :-(
19) Message boards : Seventeen or Bust : The SoB Double Check is DONE!!! (Message 116564)
Posted 2010 days ago by axn
2. Waste less work when a task would be invalid

I want to speak on this side of the equation. There has been recent development of a bullet-proof error check that will detect virtually all errors. This error check should be implemented post-haste into LLR so that SOB/ESP/PSP/PPS projects can become virtually error-less. (We'll still need adaptive/full double checks since cheating could still be an issue).
20) Message boards : Number crunching : Consolidated challenge results? (Message 116425)
Posted 2014 days ago by axn
Is there a page that shows the condolidated challenge standings for each year? If not, can we get one?


Next 10 posts
[Return to PrimeGrid main page]
DNS Powered by DNSEXIT.COM
Copyright © 2005 - 2023 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 1.28, 1.46, 1.99
Generated 29 Sep 2023 | 13:34:57 UTC