Message boards :
News :
Subfield 5 almost complete
Message board moderation
Author | Message |
---|---|
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
As you may have noticed, subfield 5 is nearing completion. In the next few hours the last of the work units will be sent out. Of course it will still take ~2weeks for the final results to trickle in before it's officially complete. This is a huge milestone! This subfield was originally estimated to take over a year to complete. Due to the new optimized apps (including GPU apps), this was completed in just several months. We will be moving on to subfield 4. But first we will make a short detour and finish off subfield 6 DS7. Don't let the ~2.5mil work units scare you. These were generated for the old apps, and would have taken about 2 hours a pop, but with the newer apps they should be about 10x faster. That means we should blow through about 350k work units per day. If this turns out to be too much of a strain on the server, then we will jump straight to subfield 4 (and run sf6 DS7 in parallel). Thanks everyone for your contributions! We couldn't have done this without our volunteers. |
Send message Joined: 5 Jan 13 Posts: 43 Credit: 43,230,579 RAC: 26,392 |
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? |
Send message Joined: 25 Feb 13 Posts: 216 Credit: 9,899,302 RAC: 0 |
As you may have noticed, subfield 5 is nearing completion. In the next few hours the last of the work units will be sent out. Of course it will still take ~2weeks for the final results to trickle in before it's officially complete. Last 24h we finished 225K workunits; most of course from SF6. :) I expect to have slight larger runtimes for SF4 and SF5, is that correct? |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
Almost all SoB projects use two different computers to calculate a WU (For example, Primegrid, yoyo etc). I think this is off topic. Maybe you should start a new thread? But to answer your question, I think the probability of such things are relatively low in a typical desktop PC. Also, don't the high energy particles you mention actually damage the CPU, rendering it bad (or degraded) for all future tasks? I know they use rad hard components in space applications because of this, but I was under the impression that it was a non-issue for typical systems on the earth's surface. |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
As you may have noticed, subfield 5 is nearing completion. In the next few hours the last of the work units will be sent out. Of course it will still take ~2weeks for the final results to trickle in before it's officially complete. Yes, everything new that I generate will have longer runtimes (I try to target ~2hours per WU). Most of the previously generated faster WUs are in sf6. |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
We will be moving on to subfield 4. But first we will make a short detour and finish off subfield 6 DS7. Don't let the ~2.5mil work units scare you. These were generated for the old apps, and would have taken about 2 hours a pop, but with the newer apps they should be about 10x faster. That means we should blow through about 350k work units per day. If this turns out to be too much of a strain on the server, then we will jump straight to subfield 4 (and run sf6 DS7 in parallel). sf6 DS7 is coming to the end. The server has been handling the extra load very well, so I think we will stay on this detour a little longer and finish off more of the faster sf6 tasks. This will give us more bang for our buck (i.e. more fields per unit runtime) and will also clear out the secondary queues. |
Send message Joined: 25 Feb 13 Posts: 216 Credit: 9,899,302 RAC: 0 |
An other question about runtimes. As DS increases, will the runtimes increase a lil bit aswell; or are they stable and "only" the # of WU´s increases? Also. I am noticing the amount of decic fields found increases, can you already say how much fields we found so far in SF6? |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
An other question about runtimes. As DS increases, will the runtimes increase a lil bit aswell; or are they stable and "only" the # of WU´s increases? It should stay about the same as DS increases, but it is based on a noisy estimate, so it could go up or down, hopefully by a small amount. In case you are wondering, here is how I determine the number of WUs in a batch. First I use the total runtime (summed over all hosts) of a previous batch to estimate the time of the next batch. For example, say I estimate the total time will be 2 million hours - if I want each task to be 2 hours, then that means I will need 1 million tasks. The search is broken up over congruence vectors (CVs), and I break them up into equal sized pieces which will perturb the time even more. To continue the example, say there are 4.4 million CVs - to have equal tasks of 4 CVs each, I would get 1.1 million tasks, which would yield tasks that were slightly faster than the 2 hour target. Regarding your other question, so far we have found about 100 fields (up through DS6). Recall, the search algorithm finds "polynomial representatives" for the fields, and the fields have many representatives. So far in sf6, more than 10000 representatives have been found (this is the field count that you refer to). |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
Just a quick recap. Subfield 5 is now officially complete. The fields can be found here and have also been uploaded to the official database. We have finished the detour through the lower levels of subfield 6 and are now going back to finish off subfield 4. |
Send message Joined: 25 Feb 13 Posts: 216 Credit: 9,899,302 RAC: 0 |
Neat! I saw you also started to deliver some sf7 tasks; hope thats not all from sf7. :D |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
Neat! I saw you also started to deliver some sf7 tasks; hope thats not all from sf7. :D No, but just small batches for now. |
Send message Joined: 7 Jun 19 Posts: 2 Credit: 6,149,566 RAC: 2,905 |
How much is missing at the end of the project? |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
How much is missing at the end of the project? I'm not sure what you are asking. If you are asking how many rows are missing from the sf7 batch status table, then that can be determined from here. |
Send message Joined: 7 Jun 19 Posts: 2 Credit: 6,149,566 RAC: 2,905 |
Thank you!!An other question...What is the difference between the Cpu's WU and Gpu's WU? |
Send message Joined: 8 Jul 11 Posts: 1344 Credit: 540,543,818 RAC: 583,917 |
Thank you!!An other question...What is the difference between the Cpu's WU and Gpu's WU? The apps operate on the same WUs. So you should notice the GPU app running faster than the CPU app. |