Posts by GeneM

Message boards : Number crunching : Docking Schedule

Message boards : Number crunching : Invalid results reported thread [Use Here]

Let me get my arms around this: so you are seeing that cpu time is not updated when boinc is started manually from a terminal window, but when started by the system, it does show cpu time correctly? If that's the case we should maybe post this on the boinc_projects mailing list and see if anybody there understands what's going on.

Thanks
Andre

Andre,

I just started boinc as user process in a terminal window like I was doing before when I was having trouble booting my machine correctly. I then opened boincmgr and looked at what was going on in the tasks tab. The "Progress" was being updated but the "CPU time" was not being updated. So I think that the run time will not be reported to the server when the work unit completes. I will let this work unit and several more run to completion just to be sure. When I started boinc as a user process I used the same command line arguments that I use when I start it as a daemon process.

Gene

Message boards : Number crunching : Invalid results reported thread [Use Here]

So here is the story. When I reboot my linux machine, if I hit "esc" to cancel the memory check then Ubuntu gets the disks wrong when booting. If I let the bios do its thing, then the disk are mapped correctly and everything boots fine. This behavior just started because I almost always cancel the memory check. I just don't want to wait for it. The good news is that Docking is now being started by the startup process and is running correctly again. I mean it is reporting the run times correctly again. I have not checked to see if I stopped Docking from running as a deamon and run it manually from the Boinc directory if it will give those 0.xx second run times. I will do that if someone thinks it is worth the effort.

Gene

Gene, please do the experiment to see if that could be a cause.

Regarding the memory check, you should be able to disable it in the bios, so you never have to press escape again. That's what I do.

Andre

Message boards : Number crunching : Invalid results reported thread [Use Here]

Did you change anything on this computer between 9 April and 11 April?

It appeared to be running correctly on 9 April (judging from your results) and it seems it hasn't run correctly since 11 April.

Don't remember what I did yesterday, let alone a month ago. But if you look at my results page, the result reported on Apr 11 used charmm 5.04, whereas the result reported on Apr 12 used charmm 5.05. So the answer to your question is: __I__ did not change anything on this computer between 9 April and 11 April. However, the __boinc environment__ "automatically" downloaded a new Docking application version to my system when I connected 11 April. This is confirmed by my post 12 April UTC (11 April local time) in which I described my experiences with the newly downloaded Linux charmm 5.05 -- including the fact that now a 'Suspend' of the charmm task did not work.

Interesting that you want answers from me. I'm a user. Why expect *me* to know how come 5.05 behaves differently in the boinc environment than 5.04 ?

I don't understand how your results are called valid (with a crunch time of less than one second) and granted credit.

That too was a "feature" introduced by the update to 5.05 (this "feature" has so far been carried forward to all subsequent Docking application releases). Note that the boinc client I was using on 9 April was 5.8.17, and the boinc client I was using on 12 April was 5.8.17 -- it was the new charmm 5.05, upon being "tracked" by the __same__ boinc client, that now showed up as taking less than one second of execution. [In actuality, Docking workunits need more than two hours of crunching each on my system. I have no control over what gets to be reported.]

My own problem with Docking applications on Linux from 5.05 on is that they use up to 40% of one CPU for "system services". Versions prior to 5.05 did not do this. I suspect that this is "unproductive" overhead, which eats up CPU cycles better spent on crunching the actual applications.
.

I didn't mean to ruffle your feathers. I was only trying to figure out what things changed to cause your Opteron to report such a short crunch time.

It arouses my curiosity when I notice things like that. The fact is that at least your Linux Opterons ran 5.05, even if that is when the short time showed up. My Linux Opterons (single-core) crashed every 5.05, but then started running 5.06 with normal times (pretty much same as 5.04).

There may be more Linux Opterons running, but I didn't find any yet.

I noticed this evening that my linux box is reporting really short crunch times and the work units are validating ok. Yesterday early I stopped the computer because the chip set cooling fan and another fan had failed and I needed to replace them. I did it and started up the computer. Now the drives (3) in the system a mapped differently and I have not figured out why yet. They are all sata drives and connected to the same ports as before. Anyway, I have to mount most of the partitions manually and start boinc in a terminal window manually. I just use "./boinc" in the boinc directory to start it. That is the only difference that I can figure out. When I know more I will post more.

Gene

Message boards : Number crunching : Invalid results reported thread [Use Here]

Did you change anything on this computer between 9 April and 11 April?

It appeared to be running correctly on 9 April (judging from your results) and it seems it hasn't run correctly since 11 April.

Don't remember what I did yesterday, let alone a month ago. But if you look at my results page, the result reported on Apr 11 used charmm 5.04, whereas the result reported on Apr 12 used charmm 5.05. So the answer to your question is: __I__ did not change anything on this computer between 9 April and 11 April. However, the __boinc environment__ "automatically" downloaded a new Docking application version to my system when I connected 11 April. This is confirmed by my post 12 April UTC (11 April local time) in which I described my experiences with the newly downloaded Linux charmm 5.05 -- including the fact that now a 'Suspend' of the charmm task did not work.

Interesting that you want answers from me. I'm a user. Why expect *me* to know how come 5.05 behaves differently in the boinc environment than 5.04 ?

I don't understand how your results are called valid (with a crunch time of less than one second) and granted credit.

That too was a "feature" introduced by the update to 5.05 (this "feature" has so far been carried forward to all subsequent Docking application releases). Note that the boinc client I was using on 9 April was 5.8.17, and the boinc client I was using on 12 April was 5.8.17 -- it was the new charmm 5.05, upon being "tracked" by the __same__ boinc client, that now showed up as taking less than one second of execution. [In actuality, Docking workunits need more than two hours of crunching each on my system. I have no control over what gets to be reported.]

My own problem with Docking applications on Linux from 5.05 on is that they use up to 40% of one CPU for "system services". Versions prior to 5.05 did not do this. I suspect that this is "unproductive" overhead, which eats up CPU cycles better spent on crunching the actual applications.
.

I didn't mean to ruffle your feathers. I was only trying to figure out what things changed to cause your Opteron to report such a short crunch time.

It arouses my curiosity when I notice things like that. The fact is that at least your Linux Opterons ran 5.05, even if that is when the short time showed up. My Linux Opterons (single-core) crashed every 5.05, but then started running 5.06 with normal times (pretty much same as 5.04).

There may be more Linux Opterons running, but I didn't find any yet.

Message boards : Cafe Docking : PING Phoenix

I posted some info about your work cache problem to our team forum.

-- David

Message boards : Cafe Docking : Second issue of the newsletter: feedback

Message boards : Number crunching : work queue

Glad I don't have dual quad hosts.......they'd still be hungry.

Message boards : Number crunching : Who is overclocking their machine?

Message boards : Number crunching : Returned wu piling up in pending queue