Posts by Vitaly

1) Message boards : News : 2021 Year in Review (Message 3210)
Posted 16 Jan 2022 by Profile Vitaly
Post:
It is interesting, what search is bigger: Search 3 or Search 6 or Search 7?
2) Message boards : News : New and improved apps coming soon (Message 2914)
Posted 13 Nov 2020 by Profile Vitaly
Post:
Yes, we should overcome somehow that 20 million tasks search.
3) Message boards : News : Should the fixed credits be higher? (Message 2901)
Posted 6 Nov 2020 by Profile Vitaly
Post:
It is interesting, when we back to Search 3?
Only two searches remained there.
4) Message boards : News : Expired SSL certificates in BOINC Client -- User Action Required (Message 2816)
Posted 8 Jun 2020 by Profile Vitaly
Post:
It looks like overall speed is reduced after this incident.
5) Message boards : News : Batch plan (Message 2571)
Posted 10 Oct 2019 by Profile Vitaly
Post:
Are DS13x271 tasks short (similar to DS13x270)?
6) Message boards : News : Entering Final Phase of Subfield 4 (Message 2564)
Posted 30 Sep 2019 by Profile Vitaly
Post:
It looks like this ugly head is getting to the end ))
7) Message boards : News : Subfield 5 almost complete (Message 2468)
Posted 18 Jun 2019 by Profile Vitaly
Post:
Almost all SoB projects use two different computers to calculate a WU (For example, Primegrid, yoyo etc).
Why do they do this? Because it looks like wasting of time.

Recently I found out that because of QUANTUM EFFECTS tipical user computer may commit an error even if the source code is absolutely correct and user does not attempt to cheat. The longer task the more probability to commit an error by a computer.

For example, a particle with high energy from the Sun or deep space may hit a CPU core while it is calculating a task.

For example, I also take part in SoB project:

https://www.primegrid.com/stats_sob_llr.php

Their tasks are quite long (up to 24 days). My computer is working continuously and some of my SoB tasks are calculated incorrectly because of unknown reason.

What do you think about this?
8) Message boards : News : GPU app status update (Message 2402)
Posted 15 Apr 2019 by Profile Vitaly
Post:
Yes, 2 millions tasks for ten days. This is cool.

God blessed this project )
9) Message boards : News : 2018 year in review (Message 2161)
Posted 28 Feb 2019 by Profile Vitaly
Post:
It looks like we need several decades to finish Search 6 )
10) Message boards : News : Server acting up (Message 2138)
Posted 18 Jan 2019 by Profile Vitaly
Post:
I watching this behaviour for about one month, espacially before the New Year.
11) Message boards : News : New record for the decic app (Message 2119)
Posted 15 Dec 2018 by Profile Vitaly
Post:
It looks like we will have time to finish DS13x11 search of 666667 WUs this year )
12) Message boards : News : Vacation (Message 2096)
Posted 27 Aug 2018 by Profile Vitaly
Post:
I want to notify that I have three erroneous WUs:

https://numberfields.asu.edu/NumberFields/workunit.php?wuid=27643537
https://numberfields.asu.edu/NumberFields/workunit.php?wuid=27638607
https://numberfields.asu.edu/NumberFields/workunit.php?wuid=27622803

Best Regards.
13) Message boards : News : 2017 year in review (Message 2077)
Posted 1 Jul 2018 by Profile Vitaly
Post:
25% of DS13x271 is completed )
14) Message boards : News : 2017 year in review (Message 1987)
Posted 6 Mar 2018 by Profile Vitaly
Post:
Although the list does not look impressive, much was accomplished in 2017. The sub-searches that were completed were some of the longest so far. In summary:
1. The search over Q(sqrt(2)) (subfield 3 of 7) completed several more tiers of the search. There are about 9 tiers left to go.
2. The search over Q(sqrt(-2)) (subfield 4 of 7) filled in a bunch more rows. This one has 7 tiers left to go.

Here are the goals for the new year:
1. Develop a GPU app. I have enlisted the help of a fellow user for this. This is a lofty goal and it could be many months before the GPU app is available. This app will be critical in completing the search over Q(sqrt(2)).
2. Complete the search over Q(sqrt(-2)).
3. Start the search over Q(sqrt(-5)) (subfield 5 of 7).


Wow, 4760579 tasks )
It looks like we won't finish it this year.
15) Message boards : News : Server Maintenance This Friday. (Message 1964)
Posted 7 Feb 2018 by Profile Vitaly
Post:
It is interesting why

https://numberfields.asu.edu/NumberFields/workunit.php?wuid=21414417

is cancelled?

I aborted it because my Windows shut down abnormally.
That WU has only two participants.

Regards.
16) Message boards : News : 2017 year in review (Message 1952)
Posted 21 Jan 2018 by Profile Vitaly
Post:
I noticed that DS14x270 jumps.

Recently there were 20000 completed WUs. But now is 9000.

Is it OK?

Regards.
17) Message boards : News : Database crash (Message 1947)
Posted 10 Jan 2018 by Profile Vitaly
Post:
You will notice that all those errors are "download errors". As Richard mentioned above this means the file does not exist anymore on the server. I also checked a few of these, and the server has the data, which means it got returned at some point. My best theory as to what happened is that while the database was crashing (which could have been over a period of hours), these results got returned, validated, assimilated, and then marked for deletion. The file_deleter did its job and deleted the file. During restoration of the database, some wus/results got put back to an earlier state. So the server is resending these results but the corresponding data file has already been deleted.

Also note that the server has to go through 8 of these download errors before it gets flagged as bad and then subsequently removed from the queue. I would reduce the 8 if I could, but it's part of the WU template which means the value is already set in the database.

I hope that helps explain things.

Also, I was able to fix the create_work script, so new work is being generated.


Does this mean that such tasks lost forever?
Or they will be recalculated somehow?

Regards.
18) Message boards : News : Database crash (Message 1943)
Posted 9 Jan 2018 by Profile Vitaly
Post:
I just discovered something else... although all the project daemons are working as expected, the create_work script cannot connect to the database, so it looks like we missed something when reinstalling mysql.

So just a heads up, we may run out of work until I get this fixed.


Some WUs can be loaded successfully but the others cannot be loaded - "Error while loading"

For example,

https://numberfields.asu.edu/NumberFields/workunit.php?wuid=20780713

I have two dozens such WUs.
19) Message boards : News : New subfield search (Message 1891)
Posted 21 Jun 2017 by Profile Vitaly
Post:
It looks like we move forward faster for "Search 4" than for "Search 3"
20) Message boards : News : New subfield search (Message 1841)
Posted 29 Mar 2017 by Profile Vitaly
Post:
I don't do double checking because that would mean the project would have to wait twice as long to complete a search. The most likely reason for someone returning a faulty result would be deliberate maliciousness; do you know of any studies that show what percentage of users do that? Most of the "cheaters" find ways to artificially increase their FLOPS and/or compute time (like running many VMs in parallel) without compromising the results themselves.

With that said, my combiner scripts have checks in place to flag suspicious results. It has flagged numerous results, which I then run again, but so far none of these have been fallacious.

Also, the algorithm itself has some built in redundancy in the sense that it finds about 100 times as many polynomial representatives as there are actual fields. The theorems that the algorithm uses guarantee that there exist polynomial representatives within certain coefficient bounds, these bounds are sufficiently large that it picks up the field 100 times (on average). As a side note, finding tighter bounds would be one way to speed up the algorithm, as this would reduce the search space.

In addition to all that, once a search is complete, there are relationships between the numbers of fields of various Galois groups. This would most likely detect a missing field. For example, the number of decic fields with Galois group 10T17 must be even. But like a parity bit, the check can fail if there are multiple errors.



So do you mean that it is impossible for an incorrect result to be accepted for the project?


Next 20


Main page · Your account · Message boards


Copyright © 2022 Arizona State University