PrimeGrid
Please visit donation page to help the project cover running costs for this month
1) Message boards : Number crunching : VPN stalls uploads only to some projects (Message 161314)
Posted 6 hours ago by Profile Michael GoetzProject donor
Politics leads to the Dark Side. Or at least discussing politics leads to heated discussions getting out of control, resulting in lots of hidden posts and locked threads and many angry people.

No more talking about politics, please. I'd hate to have to shut down a thread where someone is asking for assistance because people are yelling at each other over politics.
2) Message boards : Number crunching : VPN stalls uploads only to some projects (Message 161263)
Posted 2 days ago by Profile Michael GoetzProject donor

I use Ivacy, I have it on automatic for picking a country. I'll try right now.

According to Duckduckgo, my external address is "Your IP address is 188.72.98.109 in Amsterdam, Noord-holland, Netherlands (1101)"

Tried a test with loads of debug options on in Boinc and as is typical when you test something, it works. I was downloading a torrent when it didn't work, so I'm thinking even more now it has something to do with a timeout.


If I had to guess, it’s a combination of two problems, a network problem that causes a timing problem that causes the transfers to fail, combined with a random VPN destination that’s VERY distant from both you and the server. Think Australia. Long delay to get there from you, and long delay to get back to the server. The long round trip delay causes a problem in some device along the way.
3) Message boards : Number crunching : VPN stalls uploads only to some projects (Message 161262)
Posted 2 days ago by Profile Michael GoetzProject donor
[quote]If there's a network problem, the location can definitely make a difference. And, yes, for 'reasons'

What reasons?

When someone says something like that it’s because they don’t want to explain what the reasons are.
4) Message boards : Number crunching : VPN stalls uploads only to some projects (Message 161260)
Posted 2 days ago by Profile Michael GoetzProject donor
When I have my VPN switched on, Rosetta and Primegrid have difficulty uploading (transient HTTP error), but other projects like Asteroids are fine. Anyone know why?

Where does your pc think it's at when the VPN is turned on, ie Hungary, the Maldives, the US it might be the hops that's getting you because of where your pc thinks it's at when the VPN is turned on. My suggestion would be to pick another place and see if the same thing happens, Rosetta is based in the US but PG's Servers are hosted someplace else.

Should it care where it is? Surely it should be exactly like anyone running Boinc in that country. The VPN (Ivacy) doesn't stop any websites working. Admittedly webpages are slower (ping, not speed) through the VPN, would a slow response affect Boinc? Is Boinc more impatient than my browser?

Do some projects check the IP is the same as it knows my Boinc client to be?


If there's a network problem, the location can definitely make a difference. And, yes, for 'reasons', sometimes a website will block IP addresses or subnets.

Since you're the first person to ever report a problem with a VPN, the more information we have, the more likely it is that an explanation will be forthcoming.
5) Message boards : Number crunching : How to optimize the number of threads (Message 161176)
Posted 9 days ago by Profile Michael GoetzProject donor
When running LLR, LLR2, or Genefer CPU tasks, you can specify how many threads each task should use. The website's project preferences page gives general hints about whether or not multithreading is recommended, but doesn't tell you how many threads is optimal because that will depend on your CPU.

Specifically, it depends on the amount of cache on your CPU, which varies greatly.

In general, there's two rules:

1) More threads per task decreases efficiency, sometimes very significantly, because the threads have to wait to synchronize with each other. So you want to use the fewest number of threads per task as possible. If you can, 1 thread per task is best. However...

2) Because CPU cache is MUCH faster than main memory, when possible you want to make sure all of the tasks' data fits in the CPU cache. This is more important than the first rule, and implies that running fewer tasks with more threads per task will be better if the tasks are large and/or your CPU has a small cache.

To make it easier for you to figure out the optimal number of threads, the project preferences page now tells you the cache requirements for each sub-project.

LLR/LLR2 tasks show it like this:
Sierpinski/Riesel Base 5 LLR (SR5)
k·5n±1 for 86 specific values of k

Supported platforms:
...

Recent average CPU time: 27:53:271
FFT sizes: 864K to 1120K (uses up to 8960K cache per task)


Ignoring hyperthreads, my CPU has 8 cores and 32 MB of L3 cache. If I want to run SR5, each task uses just over 8MB of cache. If I run 8 single threaded tasks, or 4 two-threaded tasks, it won't fit in L3 cache. That will significantly slow down the tasks.

The best choice for me would therefor be either running three tasks with two threads each, or two tasks with 4 threads each. Running three tasks would only utilize 6 of the 8 cores, so it might not be the best choice, although 2 threads per task is more efficient than 4 threads per task. I probably would want to test it both ways and see which completes more tasks per day. If I had to guess, I'd go with running two tasks with 4 threads each (i.e., -t4).

Genefer tasks look like this:


Generalized Fermat Prime Search n=16 (GFN-16 or Genefer 65536)
b65536+1 (or b216+1)

Deadline: 4 days (up to 30 days)

Recent average CPU time: 0:23:05
Recent average GPU time: 0:04:03
CPU tasks use 1.19M cache per task


GFN-16 tasks use only slightly more than 1 MB of cache, so running 8 single-threaded tasks will easily fit in my CPUs 32 MB L3 cache, so running 8 single threaded tasks is the optimal way to run GFN-16 CPU tasks on my computer.

Note that GFN-21 and GFN-22 require a minimum of 4 threads per task.

If you're not sure how much cache your CPU has, Google your CPU. The number listed in BOINC isn't always accurate.
6) Message boards : General discussion : Late returning (Message 161170)
Posted 9 days ago by Profile Michael GoetzProject donor
thank you for your reply
1 has completed and the other 2 should be finished this week
another one is however showing timed out on the site and is at at 21 hours to go 19/03/2023 10:51:33 | PrimeGrid | Task genefer20_83979525_1 is 2.54 days overdue;


It's not "timed out", it's "aborted". It's dead.
7) Message boards : Number crunching : International Women's Day Challenge (Message 161161)
Posted 10 days ago by Profile Michael GoetzProject donor
And the challenge results are final!

Congrats to Nick and TeAm AnandTech for winning the individual and team competitions, respectively!

Next up is the 7 day Gotthold Eisenstein's Birthday Challenge on the PSP project, starting on April 16th at 16:00:00 UTC.

Hope you all had as much fun during this crazy one day challenge as we did!
8) Message boards : Number crunching : Proof Task Not Available (Message 161143)
Posted 12 days ago by Profile Michael GoetzProject donor
Are more crunches required to help process the roughly half million tasks? If so what subproject is this


Dates are important. This is old news and is no longer relevant.

Also, the backlog was on the server side, and not something users could help with.
9) Message boards : General discussion : Late returning (Message 161064)
Posted 19 days ago by Profile Michael GoetzProject donor
I have the following messages
10/03/2023 10:03:26 | PrimeGrid | Task llrSOB_420665536_0 is 31.72 days overdue; you may not get credit for it. Consider aborting it.
10/03/2023 10:03:26 | PrimeGrid | Task llrWOO_437145920_1 is 16.75 days overdue; you may not get credit for it. Consider aborting it.
10/03/2023 10:03:26 | PrimeGrid | Task llrESP_440996017_0 is 1.54 days overdue; you may not get credit for it. Consider aborting it.

I use my computer only during the day and the first task when I got it estimated 40 days and the deadline was 20 days it has been running so far 29 days with an estimate of 9 days left so running for half a day is 18 days
The second one has been running for 14 days with 20 hours to go
the 3rd one has been running 3 days with 12 days to go which I i am suspending to check if i get credit from the first 2
should i not get credit I will delete boinc from my computer and abort all other tasks you should allow much more time yo complete long cpu tasks


What your BOINC client tells you doesn't necessarily reflect reality. In many ways. Consider it "fake news", if you will.

As long as your computer is actively working on a task (so do NOT suspend them!!!), the server will extend the deadline for your task. It won't time out unless it's REALLY REALLY REALLY overdue. However, your BOINC client won't reflect the extended deadline. It only knows about the original deadline.

Your SoB task *currently* has a deadline of March 17th, but the server will happily keep extending its deadline until May 22nd as long as your computer keeps working on the task. If it stops working on the task, the deadline won't be extended, and the task will timeout and be sent to someone else.

Your Woodall task currently has a deadline of March 16th, but can be extended as far as April 4th.

Your ESP task currently has a deadline of March 16th and can be extended as far as April 1st. It's the only one of the three that might not make the deadline. It's progressing very slowly and is only at 21% done after 8 days.

Note that even if your tasks timeout, that doesn't necessarily mean you don't get credit. As long as you return the task, with the correct result, before the work unit is purged from the database, you will get credit. I think most other BOINC projects don't grant credit when you're late, but we think you should get the credit if you did the work, as long as it's still possible to grant credit for a task.

It's a shame that BOINC is actually advising you to abort the task. You definitely shouldn't.
10) Message boards : Number crunching : International Women's Day Challenge (Message 161032)
Posted 20 days ago by Profile Michael GoetzProject donor
If we sustain the SGS challenge rate, how many days would remain before exhausting the sieve file?

select count(*) from result where appid=2 and received_time between unix_timestamp("2023-3-8 15:0:0") and unix_timestamp("2023-3-9 15:0:0") and server_state=5 and outcome=1 and validate_state in (0,1,4); +----------+ | count(*) | +----------+ | 2696625 | +----------+
Tasks per day: 2696625
Candidates per day: 1348312.5
select max(k) from result_llr where project="SGS" and appid=2 and server_state>2 and n=1290000; +---------------+ | max(k) | +---------------+ | 7908597656115 | +---------------+
Leading edge: k=7908597656115
grep -n 7908597656115 /hdd/sieving/sgs/current.txt 28956694:7908597656115 1290000
Position of leading edge in sieve file: 28956694
wc /hdd/sieving/sgs/current.txt 54843178 109686356 1206549916 /hdd/sieving/sgs/current.txt
Candidates in sieve file: 54843178

Remaining candidates in sieve file: 25886484

Days remaining at challenge rate: 19.1992

Normally, we do about 20K tasks (10K candidates). The challenge therefore ran at a rate of about 130 times time normal rate.

The last time we ran an SGS challenge it was three days long, and the server struggled because of the resulting size of the database. If we ran a 20 day SGS challenge, yes, we would theoretically finish off the current sieve file, but...

Normally the database has about 1.5 million tasks in the result table. Right now, after the 1 day challenge, it has about 5.7 million tasks. If we ran out the sieve file, it would have in excess of 50 million tasks. The database is currently close to its maximum all time size. Certain processes get very slow when the database gets large. It's unclear at what point the server would break.


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.30, 1.68, 1.93
Generated 29 Mar 2023 | 20:43:28 UTC