PrimeGrid
Please visit donation page to help the project cover running costs for this month
1) Message boards : Number crunching : Transit of Mercury Across the Sun Challenge (Message 134810)
Posted 10 hours ago by Profile Michael GoetzProject donor
The cleanup begins...

Cleanup Status:
Nov 11: Transit of Mercury Across the Sun: 4201 tasks outstanding; 3523 affecting individual (272) scoring positions; 3119 affecting team (71) scoring positions.
2) Message boards : Number crunching : Transit of Mercury Across the Sun Challenge (Message 134803)
Posted 13 hours ago by Profile Michael GoetzProject donor
We are done!


Challenge: Transit of Mercury Across the Sun
App: 8 (PSP-LLR)
(As of 2019-11-11 18:31:25 UTC)

30083 tasks have been sent out. [CPU/GPU/anonymous_platform: 30041 (100%) / 0 (0%) / 42 (0%)]

Of those tasks that have been sent out:

4486 (15%) were aborted. [4486 (15%) / 0 (0%) / 0 (0%)]
1946 (6%) came back with some kind of an error. [1946 (6%) / 0 (0%) / 0 (0%)]
18324 (61%) have returned a successful result. [18283 (61%) / 0 (0%) / 41 (0%)]
5277 (18%) are still in progress. [5276 (18%) / 0 (0%) / 1 (0%)]

Of the tasks that have been returned successfully:

4134 (23%) are pending validation. [4123 (23%) / 0 (0%) / 11 (0%)]
14026 (77%) have been successfully validated. [13996 (76%) / 0 (0%) / 30 (0%)]
74 (0%) were invalid. [74 (0%) / 0 (0%) / 0 (0%)]
90 (0%) are inconclusive. [90 (0%) / 0 (0%) / 0 (0%)]

The current leading edge (i.e., latest work unit for which work has actually been sent out to a host) is n=21821837. The leading edge was at n=20981446 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 4.01% as much as it had prior to the challenge!


18324 tasks were returned. That's 18 times what I would normally expect to see in ten days. Great job everyone!
3) Message boards : Number crunching : Transit of Mercury Across the Sun Challenge (Message 134789)
Posted 17 hours ago by Profile Michael GoetzProject donor
Regarding the transit, I look up and all I can see are clouds everywhere :(


I've got clear skies (NYC area), and eclipse glasses for protection, but as expected it's too small to see.
4) Message boards : Aggie The Pew message board (Message 134781)
Posted 18 hours ago by Profile Michael GoetzProject donor
Amazingly, it's a bright sunny day here. Time to go and stare at the sun!
5) Message boards : Number crunching : RunTime vs CPUTime (Message 134775)
Posted 21 hours ago by Profile Michael GoetzProject donor
Hello Michael,

thank you for the long and detailed answer.
My Goal is to check if multi-threading during LLR tasks is worth it.

So i will test this using CPU-Time and number of WU`s running simultaneously, to evaluate if i got more WU's done in a given time using Multi-Threading or not.


Actually, what you're interested in is the run-time, not the CPU-time.

If you're trying to see how many tasks you can complete in a given amount of time, look at the run time per task. For reasons that are sort of arcane (thread synchronisation, CPU cache speed vs. main memory speed, etc.) the CPU time numbers are going to be deceptive and will give you misleading information. What you want to do is measure the run time required to complete tasks in each configuration you're testing.
6) Message boards : Number crunching : Transit of Mercury Across the Sun Challenge (Message 134774)
Posted 21 hours ago by Profile Michael GoetzProject donor
So, we're nearing about 4 % increase in the leading edge. Since higher n require more work, what would be the work % increase in the project? This would be an interesting statistics to also see for the challenges.

I would guess it could easily be double than the increase in the leading edge? So could we have work-wise advanced the project something like over 10 %?


Yes, that would be an interesting number. The first way is to guess about the actual numbers tested, assume an even distribution of numbers, and use some algebra to come up with that number. Anyone can do that with a calculator.

The second, slightly more accurate way of doing it is to use the actual candidates for that calculation. When we are doing a double check, that's what I do because I have a list of all the candidates being checked. Normally, however, I only have access to a recent subset of candidates. After a short while, the data is purged from the database to make space and are only available offline.

In the case of PSP, I have data going back to n=500220, so I can give you numbers for right now, but this isn't something that is normally available. It can't be done for all projects.

If you go just by leading edge, and only counting from k=500220, the leading edge has increased by 9.8% when you take into account the size of each candidate.
7) Message boards : Number crunching : Transit of Mercury Across the Sun Challenge (Message 134765)
Posted 1 day ago by Profile Michael GoetzProject donor
With less than a day remaining in the challenge, it's time to remind everyone...

At the Conclusion of the Challenge

When the challenge completes, we would prefer users "moving on" to finish those tasks they have downloaded, if not then please ABORT the WU's (and then UPDATE the PrimeGrid project) instead of DETACHING, RESETTING, or PAUSING.

ABORTING WU's allows them to be recycled immediately; thus a much faster "clean up" to the end of a Challenge. DETACHING, RESETTING, and PAUSING WU's causes them to remain in limbo until they EXPIRE. Therefore, we must wait until WU's expire to send them out to be completed.

Likewise, if you're shutting down the computer for an extended period of time, or deleting the VM (Virtual Machine), please ABORT all remaining tasks first. Also, be aware that merely shutting off a cloud server doesn't stop the billing. You have to destroy/delete the server if you don't want to continue to be charged for it.

Thank you!
8) Message boards : Number crunching : Transit of Mercury Across the Sun Challenge (Message 134764)
Posted 1 day ago by Profile Michael GoetzProject donor
It's the last day! There's less than 21 hours remaining.


Challenge: Transit of Mercury Across the Sun
App: 8 (PSP-LLR)
(As of 2019-11-10 21:32:24 UTC)

28717 tasks have been sent out. [CPU/GPU/anonymous_platform: 28677 (100%) / 0 (0%) / 40 (0%)]

Of those tasks that have been sent out:

3811 (13%) were aborted. [3811 (13%) / 0 (0%) / 0 (0%)]
1930 (7%) came back with some kind of an error. [1930 (7%) / 0 (0%) / 0 (0%)]
16179 (56%) have returned a successful result. [16140 (56%) / 0 (0%) / 39 (0%)]
6797 (24%) are still in progress. [6796 (24%) / 0 (0%) / 1 (0%)]

Of the tasks that have been returned successfully:

4414 (27%) are pending validation. [4401 (27%) / 0 (0%) / 13 (0%)]
11655 (72%) have been successfully validated. [11629 (72%) / 0 (0%) / 26 (0%)]
60 (0%) were invalid. [60 (0%) / 0 (0%) / 0 (0%)]
50 (0%) are inconclusive. [50 (0%) / 0 (0%) / 0 (0%)]

The current leading edge (i.e., latest work unit for which work has actually been sent out to a host) is n=21790046. The leading edge was at n=20981446 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 3.85% as much as it had prior to the challenge!


9) Message boards : Number crunching : RunTime vs CPUTime (Message 134748)
Posted 1 day ago by Profile Michael GoetzProject donor
Hello, i am not sure if this is the right board to ask this question.
But can anybody tell me what difference between runtime and cpu-time is, regarding cpu tasks and gpu tasks?



I was REALLY hoping someone else would give you a good answer, because this is going to be a rather complex question with a lot of parts.

Your question, in itself, was too small. To get a meaningful answer, you need to ask, "What are run time, cpu time, and gpu time?" In addition, you need to also be asking "What is multi-tasking?" and also "What is multi-threading?" Only by answering all of those do you get the full picture. Let's start with the simple definitions:

Run time is the wall-clock time (also called elapsed time) between when the calculation starts and when it ends.

CPU time is the number of CPU seconds a CPU core is running during the calculations. Note that if two CPU cores are running that calculation at a given moment, two CPU seconds are accumulated during each second of run time.

GPU time is the number of GPU seconds a GPU device is running during the calculations. This is analogous to "CPU time", except it's for GPU apps. Note that if two GPU devices are running at a given moment, two GPU seconds are accumulated during each second of run time. Also note that we generally lack the tools to measure GPU time, which is why you don't see it used anywhere. Also, we have no apps that are capable of using more than one GPU.

Multi-tasking is the computer science concept of having a computer (actually a single computer core) *appear* to be doing more than one thing at once. In reality, at any instant in time, it can only be doing one thing, but it can switch back and forth so quickly that to humans it appears to be doing multiple things at once.

Multi-threading, in the context of this explanation, is the ability to use multiple CPU cores simultaneously to perform a single calculation.

Now let's put all of that together:

Imagine, if you will, (or remember, if you're old enough) a simple DOS computer with a single-core 8088 CPU. There's just one core, and there's only one thing running at a time. If you tell the computer to run a computation, and it runs for 1 minute, both the run time and the CPU time are 60 seconds.

Now jump forward in time a little bit, and the CPU is a more powerful, but still single core, 486-DX2 CPU, and you're running an early version of Windows. You run that same calculation, but there's a lot of Windows stuff going on in the background and those background tasks (probably "Minesweeper") are consuming about 50% of the CPU cycles doing other stuff. The one minute calculation therefore takes 2 minutes to complete because the CPU is busy half the time. The CPU time is still 60 seconds, but the run time is 120 seconds.

Finally, let's jump forward to today, and let's run multi-threaded LLR on a PSP-LLR task on a Linux server. Background overhead from other tasks is negligible, and there's 4 CPU cores. It takes 1 day to run the calculation on a quad core CPU. That's 1 day (86400 seconds) of run time, and 4 days (345600 seconds) of CPU time.

That takes care of the examples without GPUs. For GPU tasks, run time is simply the wall clock time from the start to the end of the calculation. GPU time -- which we can't really measure -- is the amount of time the GPU is actually running. If the GPU is running at 100% utilization, then GPU time would be equal to run time. If it's running at 50% utilization, then GPU time would be half of run time., etc.

Even GPU apps, however, require some CPU cycles to feed the GPU. In an efficient app, very little CPU is used, and we can't see the actual GPU time, so the only relevant number is the run time. The CPU time value should be very low.

Less efficient apps tend to use a lot of CPU time, and in extreme cases will need an entire CPU core. You'll see that the CPU time for inefficient tasks is high, sometimes even equal to the run time.
10) Message boards : Number crunching : Transit of Mercury Across the Sun Challenge (Message 134730)
Posted 2 days ago by Profile Michael GoetzProject donor
Eight days done!

Two to go.


Challenge: Transit of Mercury Across the Sun
App: 8 (PSP-LLR)
(As of 2019-11-09 20:10:39 UTC)

26268 tasks have been sent out. [CPU/GPU/anonymous_platform: 26232 (100%) / 0 (0%) / 36 (0%)]

Of those tasks that have been sent out:

3102 (12%) were aborted. [3102 (12%) / 0 (0%) / 0 (0%)]
1815 (7%) came back with some kind of an error. [1815 (7%) / 0 (0%) / 0 (0%)]
13964 (53%) have returned a successful result. [13930 (53%) / 0 (0%) / 34 (0%)]
7387 (28%) are still in progress. [7385 (28%) / 0 (0%) / 2 (0%)]

Of the tasks that have been returned successfully:

4431 (32%) are pending validation. [4419 (32%) / 0 (0%) / 12 (0%)]
9433 (68%) have been successfully validated. [9411 (67%) / 0 (0%) / 22 (0%)]
48 (0%) were invalid. [48 (0%) / 0 (0%) / 0 (0%)]
52 (0%) are inconclusive. [52 (0%) / 0 (0%) / 0 (0%)]

The current leading edge (i.e., latest work unit for which work has actually been sent out to a host) is n=21727832. The leading edge was at n=20981446 at the beginning of the challenge. Since the challenge started, the leading edge has advanced 3.56% as much as it had prior to the challenge!


Next 10 posts
[Return to PrimeGrid main page]
DNS Powered by DNSEXIT.COM
Copyright © 2005 - 2019 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 1.33, 1.49, 1.54
Generated 12 Nov 2019 | 7:39:13 UTC