Computation errors

[Neil Polson]

mitrichr, I think you'll find that the app doesn't have a progress bar. On my host it goes straight from 0% to 100%. ie no steps along the way. No need to abort.

[mitrichr]

Sorry, I am not hanging around. I detached. When you guys are sure of what you are doing, you should send out an email to all of your past contributors letting us know it is safe to go back in the water.

I like your project. I like to contribute to Biology, Chemistry, Physics, Cosmology. But, I want thing to work. WCG just brought on a Clean Water project based in China. No problems, WU's just work.
If you need time in beta, then that is what you should do.

[mitrichr]

Neil-

I will take you at your word, it makes no sense that this project should work differently, but I will re-attach. But I will be looking at my results.

>>RSM

[mitrichr]

Just another little note, if you want the 100,000 or so crunchers you might attract, it is not good to be idiosyncratic.

>>RSM

[Sorceress]

I show a whole bunch of WU's completed successfully. But when ever I check my tasks running in BOINC Manager, I see tasks with time spent and 0% work done. This is a waste of my time. My computers run 24/7, I do not, can not watch them all of the time.

You have been given precious space and on my new i7-840QM. If I cannot know that I can go away for 10-12 hours and things are going to be O.K., I cannot afford the waste of time and electricity.

>>RSM

mitrichr, from the tone of your past few post, your *ENLARGED EGO* will get irritating rather quickly if continued.

There was no RED CARPET rolled out for any of us, including you. You volunteered to attach to this project and, if you are unhappy with their MODUS OPERANDI,
feel free to unvolunteer as you are want to do. This nor any other project is not here to entertain or babysit you.

This project is in Alpha testing and is subject to many variables. If this poses a problem, in that you feel constrained to let the project run as it will, then I would
suggest that you look elsewhere for your peace of mind. Most of us here accept the issues involved. If a work unit bombs, it bombs. We live and move on. Comprendi?

[mitrichr]

Sorceress-

This project is listed on the BOINC project page, which implies it is full release, not alpha or beta. If it is not ready to go, then it should be listed as an alpha or beta.

[Sorceress]

Sorceress-

This project is listed on the BOINC project page, which implies it is full release, not alpha or beta. If it is not ready to go, then it should be listed as an alpha or beta.

So what is your point, mitrichr? The BOINC project page doesn't designate ANY project as alpha, beta, or otherwise. Any impications it may confer is an assumption on your part. eOn is listed on BOINCstats as alpha. As is several other new ALPHA projects that are listed on the BOINC project page.

[mitrichr]

Sorceress-

BOINCStats - as valuable a resource as it is - is to BOINC as chocolate sprinkles are to vanilla ice cream, a decoration, an embellishment.

>>RSM

[Sorceress]

Sorceress-

BOINCStats - as valuable a resource as it is - is to BOINC as chocolate sprinkles are to vanilla ice cream, a decoration, an embellishment.

>>RSM

Yes, BOINCstats is a valuable resource. I use it all the time. But using your ice cream analogy, I must say, I greatly prefer the embellishments. They delightfully enhance the taste and enjoyment of the ice cream. Otherwise, all you have plain vanilla. Now really, isn't that all BOINC is? Plain vanilla? (And not a very good one at that!)

[mitrichr]

Sorceress-

Yup, I agree. I use BOINCStats every day, and I sometimes don't actually visit Berkeley for weeks. But, for doing this work, BOINC software is pretty much all we have. I am not a scientist or I/T person, so i am not qualified to be judgmental. But people can cite all sorts of stuff that is wrong with the BOINC. I mean, you know, you can do folding@home. But, that is so monothematic to the point of boring.

I have been smitten with this work since I discovered a Cancer project at Oxford University running on UD. That was with one desktop and one laptop, a "cool" screen saver, I was off to the races. Then WCG on UD, WCG on BOINC, and the rest of whatever else I crunch. I consider this the most important and satisfying work I have ever done with a computer. And, that's beyond my active passion of music and video.

I am crunching 24/7 on 1 i7-920 hyper threaded quad desktop, 1 i7-840QM hyper threaded quad laptop, 1 i5-520M hyper threaded dual core, and 2 Core 2-Duos. That's 24 threads.

I checked you out. you are doing really good work on a very nice array of projects.

My problem with this project started when I looked at Statistics in BOINC Manager and saw this project's work units running with seemingly no progress. No one else has WU's running with no progress showing. What was I to think? I simply will not waste my time. When it was explained to me that this was a feature not present, I said, O.K., I will try for a while. but they cannot have to address each and every cruncher who comes here with his/her own personal note of "Hey, we do not tell you of work in elapsed time". I raised the issues publicly. Most crunchers will simply turn away.

And, BTW, I am an arrogant elitist, I work very hard at it, and, I am worth it.

>>RSM

P.S., where is my darned avatar, my signature my BOINCStats bloc???

[matt]

To clear some things up:
- Our work units can encounter computation errors due to edge-cases and numerical error. Currently, our client gives a non-zero error code when this happens, which BOINC interprets as a failed work unit. We'll get this fixed so you get credit.
- We don't yet have progress bars for work units.
- Our work units can take different amounts of time (by a factor of about 5). Once progress bars are implemented, it should be easier to tell how long a particular WU will take. When we create WUs, we do specify a predicted time, but I'm not sure if you guys can see this number in the interface.

[mitrichr]

Thanks, Matt, sounds like you are headed in the right direction.

>>RSM

[mitrichr]

maybe I should post a question asking about it?"

That's sure more productive than making (bad) assumptions and ranting about it.

I did sorta kind ask about it, which is. quite frankly, more than most people would do. They would just leave. And, I got my answer. And, I am with the project. And, I posted positively about it in BOINC Message Boards, suggesting others check it out. I did point out that there is no progress indication in BOINC Manager, also, no signatures or avatars on the forums. Many crunchers are in love with their avatars and their signatures.

And, if you think what I wrote was a rant, then you may possibly - I want to pick my words judiciously - not have spent much time in forums.

Yours with respect,

>>RSM

[Slave_Mac]

Greetings,
I have eOn running on a BOINC dedicated XP machine with no problems.
I am trying to supplement eOn production with my daily machine Macbook Pro running eOn only.
On the Macbook, every task with the name starting with 1391006163 fails, all with log entries as appears here of course with appropriate name.
The fail is instantaneous.

Mon Nov 1 22:05:28 2010 eon2 Starting 1391006163_333_5763125_0
Mon Nov 1 22:05:28 2010 eon2 Starting task 1391006163_333_5763125_0 using eonclient version 100
Mon Nov 1 22:05:29 2010 eon2 Computation for task 1391006163_333_5763125_0 finished
Mon Nov 1 22:05:29 2010 eon2 Output file 1391006163_333_5763125_0_0 for task 1391006163_333_5763125_0 absent

Task results appear here;

http://eon.ices.utexas.edu/eon2/result. ... id=1815148

I have read elsewhere of some issues with the OS X client and wonder if this may be a result.
It really isn't operational issue here, it's just not pretty in my stats. Would it be better that I not crunch till this is fixed?
Or should i crunch away?

Thanks
Slave_Mac

[nullcoding]

I was about to make a post identical to Slave_Mac's. Just so we know it's not an isolated incident, I too am having problems where all 139###### workunits result in immediate computation errors due to absent output files, a problem similar to that exhibited by the i386 MacBook running Tiger which I tried to use on eOn (only that wouldn't crunch anything and now eOn's application requirements reflect this incompatibility).

My XP machine is crunching all eOn tasks just fine in the meantime (although with its 3.0GHz Pentium 4 HT, it takes about 10 times longer than my 2.53GHz i5) - if a machine from 2005 running an OS from 2002 can do it, then I wonder what the issue is with these specific workunits.

Perhaps (and I believe this has been a problem before) it is a memory access exception in which the computation executable attempts to allocate or access some space or node for which the user "boinc_project" does not have write permission. I'm a bit unclear on the fundamentals/mechanics of workunit computation, but it seems logical enough...just, why this specific simulation, and why would it be an issue relegated to OSX?

Gonna keep crunching for eOn, but at a reduced rate. I'll give WCG some much-needed CPU time.