Yoyo,

Back in December, I asked how much longer the project will run. You said, "I think at least 6 more month[...]" Can we please get an updated projection?

Thanks!

---

Reno, NV
Team: SETI.USA

Hello,

I will decide it if we reach C110 here http://factorization.ath.cx/stat_1.php. I think with C110 the runtimes are very long, to long for most of the crunchers. But we will see.

yoyo

Okay. When do you anticipate we will reach C110?

---

Reno, NV
Team: SETI.USA

According to this list http://factorization.ath.cx/stat_1.php we will reach C110 in the next days. There are 15k composites which are 110 digits long.
yoyo

According to this list http://factorization.ath.cx/stat_1.php we will reach C110 in the next days. There are 15k composites which are 110 digits long.
yoyo

This is all beyond me. "we will reach C110 in the next days" How many days is that? 2? 10? 50? I don't understand.

Also, do you mean "reach", meaning that is when we start 110? Or when we complete 110? I am really confused here.

---

Reno, NV
Team: SETI.USA

C110 are already in the system and distributed to user.
Back in December I thought the runtime of C110 will be so long, that it is not acceptable for the user. So let us finish after C110 is completed and issue new workunits only if numbers <=C110 needs to be factored.

But at this time only the single threaded app was available.

Now we have the MT app available. So things changed a bit.

Therefore I first want to see how long C110 workunits are running to decide further.

yoyo

Got my first 2 C110 results, one was a short runner.

---

Matthias

I got a couple of C110's that ran about 20 hours cpu time. I wish we could see the actual cpu time, I guess it's mostly a Boinc issue not handling multi-thread tasks too well yet. Also, I have 6.58(?) because it's the last Ubuntu version that works, so maybe the new ones version 7 does better. I would be interested in hearing what response you're getting from Boinc about how to see accurate cpu time.

I am manually feeding tasks one at a time, which I think is generally a good procedure for an alpha project. I just got new ones, apparently using a corrected 130.3 app and with deadline 2 days with 3+ days cpu estimated. These run immediately when downloaded in high priority. Presumably the long ones will need a full day on my 4 cores if they run as estimated, and will stay active continuously unless I push them out for a while on purpose.

I just got the third of these, it turned out the first two ran quickly. This could turn out to be a nuisance unless I open up the spigot. I suspect it will never try to run more than one, and will quit downloading them soon if I let the long-term debt accumulate.

Incidentally, I use BoincTasks on a Linux system.

I now have three "relatively" long run-time C110s. All I know is the elapsed time, apparently because Boinc (my version at least) doesn't capture the cpu time of the multiple threads.

I had two long-running C110's with the 130.2 application. They ran 18k and 20k seconds, respectively which I figure is 16 to 20 cpu hours. My new (130.3) tasks only ran 11k and 12k seconds. If these are typical, there may be a huge improvement in performance. Of course you would need more examples to be sure, but it looks like the new ones are quite tolerable -- maybe you can push it a little farther?

PS. Pardon my sentence structure in the prior post. I noticed they don't parse well, and I apparently can't edit posts.

Hello,

the C110 doesn't run as long as expected. Therefore I'll keep the project a bit longer running, lets say until C115. I guess the run time will double.

yoyo

I have now had two C112's that ran 27,000 + seconds; presumably 30 total processor-hours. Other C112's have been 15k - 18k seconds.

I did notice at one point that an excessive number of threads were activated during processing. I saw a single yafu thread, 4 shell threads, and 27 gnfs-lasieve threads active at one time.