Not selected will default back to 1 hour on Ralph w/ 4.85. It didn't with 4.83. I'll make it more obvious in the preferences page.

---

Not selected will default back to 1 hour on Ralph w/ 4.85. It didn't with 4.83. I'll make it more obvious in the preferences page.

THanks, I was editting my previous comment while you were typing your reply. Could you look at the last paragraph I wrote?

OK, It's done and successfully:

5134 4851 18 Feb 2006 13:42:21 UTC 19 Feb 2006 2:09:08 UTC Over Success Done 5,639.00 3.77 3.77

It stuck at 74.20% done from exactly 1:00:00 cpu time for 33 minutes and change it was at Model 5 and I keep seeing the steps move every so slowly. At 1:33:?? it jumped to 100% done and uploaded.

So with my preference at 2 hours a 4.85 barcode failed, at "not selected" it finished in 1:33:??. Does this help?

Changes to the preferences should carry over to currently running work units when you update the project. The scheduler does not use this value for work distribution and we are aware that there will be issues with having inaccurate run time estimates (which are based on the rsc_fpops_est value we give for each work unit), and with long target cpu run times possibly reaching the work unit's expiration depending on how much the computer is used and what the resource share is. We will be monitoring this and adjusting accordingly. We will also increase the delay bound (expiration) to two weeks instead of one for the next batch of work units.

---

I left my Ralph pref to "not selected". I let my next to last 4.85 Barcode run on host 103. From the start to 00:30:00 it displayed 1% then finished model 1, at 00:30:001 it started model 2 and jumped to 38.54%, where it stayed until 00:59:01 when it jumped to 100% and uploaded. I noticed it was at Model 2 step 23410.

This is that Wu:

5135 4852 18 Feb 2006 13:42:21 UTC 19 Feb 2006 3:12:34 UTC Over Success Done 3,541.00 2.37 2.37

For my last 4.85 on host 103 I changed my prefs from "not selected" back to "2 hours" at 07:16 after the start of the program. If finished successfully whereas the first 4.85 did not at the same setting, unless changing the setting midstream stopped the second from failing.

From start to somewhere between 22 and 28 minutes it stayed at 1%, then jumped to 18.20 and stayed there until Model 2 was finished at 01:19:36. It then jumped to 61.7% until completion at 01:37:?? cpu time.

Is it safe to assume that the program just places a 1% complete figure up at the start of every WU then successive % completion updates are triggered by an event, and that the event is the completion of a model?

If so then % completed update frequency would be completely dependent upon the speed of the host. Is this so?

If so, then are the people getting the "1% bug" ever getting past model 1?

tony

If so, then are the people getting the "1% bug" ever getting past model 1?

very doubtful

I feel I've run my hosts long enough on the 2 hour cpu time pref. Other than the problems listed about host 103, I've seen no issues with the 2 hour pref.

Here's the WUS done during that period:

Host 103
5136 4853 18 Feb 2006 13:42:21 UTC 19 Feb 2006 4:46:02 UTC Over Success Done 5,856.00 3.91 3.91
5135 4852 18 Feb 2006 13:42:21 UTC 19 Feb 2006 3:12:34 UTC Over Success Done 3,541.00 2.37 2.37
5134 4851 18 Feb 2006 13:42:21 UTC 19 Feb 2006 2:09:08 UTC Over Success Done 5,639.00 3.77 3.77
5133 4850 18 Feb 2006 13:42:21 UTC 19 Feb 2006 0:02:27 UTC Over Client error Computing 7,260.00 4.85 ---
5132 4849 18 Feb 2006 13:42:21 UTC 18 Feb 2006 23:11:22 UTC Over Success Done 4,855.00 3.24 3.24
5131 4848 18 Feb 2006 13:42:21 UTC 18 Feb 2006 23:11:22 UTC Over Success Done 8,773.00 5.86 5.86

Host 64
None done

Host 66
1527 1492 16 Feb 2006 0:37:25 UTC 19 Feb 2006 3:23:50 UTC Over Success Done 7,126.27 26.65 26.65
1526 1491 16 Feb 2006 0:37:25 UTC 19 Feb 2006 3:23:50 UTC Over Success Done 7,050.73 26.37 26.37
1525 1490 16 Feb 2006 0:37:25 UTC 18 Feb 2006 21:16:26 UTC Over Success Done 7,241.86 27.08 27.08
1524 1489 16 Feb 2006 0:37:25 UTC 18 Feb 2006 21:16:26 UTC Over Success Done 7,100.19 26.55 26.55
1523 1488 16 Feb 2006 0:37:25 UTC 18 Feb 2006 17:58:41 UTC Over Success Done 7,188.95 26.89 26.89
1463 1428 16 Feb 2006 0:37:25 UTC 20 Feb 2006 12:54:44 UTC Over Success Done 7,219.59 27.00 27.00
1462 1427 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,168.48 26.81 26.81
1461 1426 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,161.34 26.78 26.78
1458 1423 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,184.36 26.87 26.87
1457 1422 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,132.44 26.67 26.67
1456 1421 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,148.88 26.74 26.74
1455 1420 16 Feb 2006 0:37:25 UTC 19 Feb 2006 11:29:52 UTC Over Success Done 7,266.20 27.17 27.17
1454 1419 16 Feb 2006 0:37:25 UTC 19 Feb 2006 6:07:44 UTC Over Success Done 6,014.48 22.49 22.49
1453 1418 16 Feb 2006 0:37:25 UTC 19 Feb 2006 3:23:50 UTC Over Success Done 7,129.23 26.66 26.66
1407 1372 16 Feb 2006 0:37:25 UTC 18 Feb 2006 17:58:41 UTC Over Success Done 7,080.91 26.48 26.48

Host 67
5339 3275 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,447.91 9.35 9.35
5338 3270 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,799.58 9.86 9.86
5337 3269 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,240.47 9.05 9.05
5336 3268 18 Feb 2006 20:57:47 UTC 20 Feb 2006 2:42:30 UTC Over Success Done 6,952.34 10.09 10.09
5335 3267 18 Feb 2006 20:57:47 UTC 20 Feb 2006 2:42:30 UTC Over Success Done 5,681.56 8.24 8.24
5334 3266 18 Feb 2006 20:57:47 UTC 20 Feb 2006 2:42:30 UTC Over Success Done 6,554.06 9.51 9.51
5333 3265 18 Feb 2006 20:57:47 UTC 19 Feb 2006 21:48:40 UTC Over Success Done 5,127.38 7.44 7.44
5332 3263 18 Feb 2006 20:57:47 UTC 19 Feb 2006 21:48:40 UTC Over Success Done 6,820.70 9.90 9.90
5331 3262 18 Feb 2006 20:57:47 UTC 19 Feb 2006 21:48:40 UTC Over Success Done 6,499.95 9.43 9.43
5330 3214 18 Feb 2006 20:57:47 UTC 19 Feb 2006 15:53:36 UTC Over Success Done 6,497.31 9.43 9.43
5329 3200 18 Feb 2006 20:57:47 UTC 19 Feb 2006 15:53:36 UTC Over Success Done 5,810.47 8.43 8.43
5328 3199 18 Feb 2006 20:57:47 UTC 19 Feb 2006 15:53:36 UTC Over Success Done 6,148.36 8.92 8.92
5327 3198 18 Feb 2006 20:57:47 UTC 19 Feb 2006 11:28:17 UTC Over Success Done 5,207.73 7.56 7.56
5326 3197 18 Feb 2006 20:57:47 UTC 19 Feb 2006 11:28:17 UTC Over Success Done 3,641.36 5.28 5.28
5325 3196 18 Feb 2006 20:57:47 UTC 19 Feb 2006 11:28:17 UTC Over Success Done 6,249.14 9.07 9.07
5320 3159 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,757.64 9.80 9.80
5319 3158 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,546.25 9.50 9.50

Note: all seems well with the 2 hour pref. I'm now switching to the 4 hour pref.

Continued note: It would be nice to see a message in the Messages tab telling users that the updated prefs were recognized. I still can't tell if it took and the only way to tell is after it runs a wu.

I have only recieved the following from my post to the mail list:

David Sutton to me, boinc_dev
More options Feb 19 (1 day ago)

From the looks of it BOINC only displays messages about preferences when you
change the default, home, school, works tabs. The setting to change CPU for
RALPH isn't contained within those settings probally because it would try to
effect all other BOINC projects running.

I've tried all preferences, the default (1 hour), the 2 hour, 4 hour, 8 hour, 16 hour, 1 day, 2 day, and 4 day.

The only workunit that has failed was due to the "leave application in memory=NO" bug, and crashed after 25 hours on the 4.84 application version while it was preempted due to benchmark running. (see the bug report section.)

Otherwise, this setting appears to be working flawlessly, and IMHO, the appmem=no bug is not dependant on the CPURuntime setting.

Notes :

1. Changing the preference to longer time "mid-work" will affect running workunits, if the BOINCMGR updates the project at that time.

2. Similarly, if the preference is changed to shorter time, this will also affect running workunits, even if the run-time is currently WELL over the new preference. I.E. If you have 2 workunits that have been running for 24 hours and switch the preference to "run work for 2 hours", it will finish the current model, then upload the work to the server without complaint after.

3. Users COULD theoretically push work WAY WAYYYYY PAST it's deadline by downloading a large batch of work at the 2 hour preference, and then changing the work to a 4 day preference after downloading 20-30 workunits. Some sort of safety measure should be put into place to keep this from happening. Perhaps changing the preference to a longer time should extend the deadline for work the user currently has downloaded accordingly, or it should flash some sort of warning message about how updating the client with large caches could make the workunits useless. {{{Please note : While it is easy and quick to say on this issue "Well, then don't keep large cache's" or "people need to use their heads" or "don't change and update mid-work" Those statements always look good on paper, but never quite work out in reality. You have to plan for the lowest common denominator, and you should assume that that person is a complete fool. (and knows nothing of cache management or EDF) }}}

---

machine 45 51hours then the other wu was 12 min
3457 and 3882

pref still set to 4 days no mo wu

p.s. there is no "last 20"/"previous 20" on the second &ct pages of results in user results link

---

My run-time pref was "not selected" and I noticed the first of my latest batch of Ralph wu's put in 5 hrs with, it claimed, about 3 to go. I just changed my pref to 2 hours and it finished, as I'd expect given the desciptions of behavior when changing the prefs mid-wu.

I read somewhere that Rosetta will use 8 hours for the default, so my question is are the tests set for production defaults now, else what happened to the 1 hr test default?

---

had that wu run 22 seconds long (4 days & 22 secs ) works on rosetta too.

---

My run-time pref was "not selected" and I noticed the first of my latest batch of Ralph wu's put in 5 hrs with, it claimed, about 3 to go. I just changed my pref to 2 hours and it finished, as I'd expect given the desciptions of behavior when changing the prefs mid-wu.

I read somewhere that Rosetta will use 8 hours for the default, so my question is are the tests set for production defaults now, else what happened to the 1 hr test default?

rosetta did use 8 hours as the default, but now it's using 2 hours

---

Want to search the BOINC Wiki, BOINCstats, or various BOINC forums from within firefox? Try the BOINC related Firefox Search Plugins