Testing of BOINC version of theSkyNet

[Dataman]

Is it showing only 22-27% total CPU Usage in Windows Task Manager for 8 tasks combined? Very strange, I'm running 7 cores and total CPU Usage is 87% as expected. Maybe running all 8 cores is bogging it down, especially if you are running a GPU project at the same time. Perhaps you could try 7 cores (87.5% of processors) and see if it improves.

You're not using BoincTasks to monitor CPU Usage are you? That will give incorrect CPU usage readings on this wrapper project in Windows as reported by JugNut here and Saenger on the project forum.

Yes, showing in BOINCTasks that's all I use. I got so use to remote viewing while we on our walkabout I almost never look at individual machines. After all I would have to stand up and walk 30 ft to the server room. 
I guess my point is POGS is too much bother right now. I will let these 8 finish though to see what other things pop up. Thanks Kashi.

[danhtruong]

Good morning everyone,

I'm running the Java version of theSkyNet from their website with a handful of credits.
With the BOINC version, will those credits automatically attach, or is the BOINC version different/separate altogther?  aka., theSkyNet POGS, as opposed to normal theSkyNet.

(The email address I use to register for both BOINC projects and theSkyNet are the same)

[Dingo]

Kevin has implemented his own wrapper for Windows and it now checkpoints.  Iturned my PC off last night when they were 80 odd % complete and this morning when I started it back up they all went back to where they finished.  I put a post HERE

Kevin has not announced that it is fixed yet but looks like it is ???

[danhtruong]

That's great!
Good to know our badges will carry over.

But yes, I'm sure the first Australian BOINC project will be warmly welcomed; most of all, by BOINC@Australia.

[Dataman]

Well, all finished "normally" whatever that is. About 9 hrs per. I'm thinking eFMer is going to have to make some changes. I saw a lot of strange stuff in BOINCTasks. When I looked at the machine via Task Manager the wu's were using in the high 80's to low 90's cpu. I'm going to see what asteroids@home does tomorrow before releasing any more of POGS. I am only running one machine with 8 cores and two cards ... hot Hot HOT ... getting to be annoying.  :furious:

:aus1: :US

[Dingo]

Testing Halted for a while whilr Kevin checks the data to see if all goes well with the science.  See this POST

[JugNut]

New WU's coming through "now".. (just when I have a huge bunch of SIMAP too  :cry2:)


EDIT: 1 machine got 50 the others none, no matter how many times I updated & increased cache. (but it's a start :-) )

EDIT 2: Coming again in dribs & drabs..   "TESTING -  Offically restarted"..

[Dingo]

Yes I have a bunch of BOINC Simap as well.  I have both projects available for work so it will sort itself out. 

[tazzduke]

On it nabbed about 30 tasks, which will do me for the time being, as I still have some LHC to do

Regards
tazzduke

[Dataman]

The project will be out of work for a week (or so) while they check the results that have been returned.

[danhtruong]

Hi Dingo,

Just wondering, for your personal BOINCstats (theSkyNet POGS of 17,000 cobblestones or so) was that a direct conversion from theSkyNet java applet or did you with zero credit on theSkyNet POGS?

I'm still running theSkyNet from their website and just wondering if i should start running the BOINC theSkyNet instead (if its the same thing?) or continue to run from their website.

[Dingo]

I started from Zero on the BOINC project.  When the project is ported over to the University site from Amazon they say that the Badges and points from the non BOINC project should be coming over.

[tazzduke]

Greetings All

Dingo or other Senior Member could we maybe suggest to Kevin over at POGS of a limit of workunits per core like they do at LHC@Home and other projects, that way he can expect quick turnaround of workunits, this would also alleviate the sucker problem, I would go at say 2 or 4 per core, in my case a max of 16 workunits at one time. 

This maybe lifted once into either Beta or Production, by that time more crunchers have jumped onboard.  I find it disheartening when I come across a cruncher who has amassed over a 100 workunits and take anywhere up to a week to process.  In other words very long time in PV jail.

Any thoughts???

Regards
Tazzduke

Crunching for the benefit of Humantiy 

[Mike Mitchell]

I find it disheartening when I come across a cruncher who has amassed over a 100 workunits and take anywhere up to a week to process.  In other words very long time in PV jail.

My pet peeve are the people who download a hundred or so and then do nothing with those work units (in any project).  :furious: Like the idea Tazz

[kashi]

Re my post at the POGS forum. Most Intel computers running Windows will complete each step much faster than Sajjad Imam's AMD FX-8120. I have looked at one of his recently completed tasks and something seems awry. It took over 20 hours for a task that would complete in about 5 hours on my computer. I know Bulldozer architecture is inefficient on some applications due to the shared floating point core per module but that difference seems too high. His times of 35-40 minutes or longer per step are very slow and not consistent. This indicates severe contention losses and/or possible CPU overcommitment. Some people get their back up if I suggest using less BOINC cores in an attempt to reduce contention losses, so I rarely mention it now but I will make an exception in this case. If my suggestion is not appreciated at least I have tried to help.

If Kevin is keen to get the results back quicker then an option is to reduce the deadline from the present 7 days to 4 or 5 days. One problem with limiting the number of tasks per core is the variability of task lengths. If you get a batch of tasks with only a small number of steps (fits, pixels) then these complete very quickly on a fast computer. It means if the project has a temporary server outage or break in work availability then you are out of work. Same if your own internet connection is unreliable. I would not recommend a deadline of less than 3 days unless the project really needs it, because that can interfere with sharing with other projects due to tasks going into high priority mode. It may also cause problems for those with slower computers who download a batch of longer tasks. 

Restricting the number of tasks does address extreme cache hogs to some extent, but it still only partially solves the problem of new members who download a full batch of tasks and complete only a few or none at all and do not abort unfinished tasks but just let them all time out. These anti-abortion hogs cause a longer delay than those with a large cache but a turnaround time of 2-3 days. With a restriction of 4 tasks per core, someone with an 8 core computer who downloads a batch of tasks then only completes 2, ties up 30 tasks for the full 7 days and then the potential 7 day cycle starts again when the tasks time out and are reissued. When batches are large,  sometimes it can take longer than 7 days for a task to be reissued because it can remain in unsent state for some time.

Not everyone reads a project forum and realises that a project wishes a quick turnaround time. If the deadline is 7 days then that's how long some will take to finish tasks.

When a batch of work needs to be checked before more work is released then a shorter deadline is a good way to reduce the total turnaround time of first issue and timeout reissue tasks.

If the project has an astronomical amount of data to process then attracting and keeping a decent size number of contributors is vital. I understand that the project is only new and batches need to be checked at this early stage so interruptions to work availability are currently unavoidable. However now that the project is open to all it is important that work is reliably and consistently available as soon as possible. Lack of work causes contributors to switch to other projects and if "no work available" is the introduction to a project any new contributors receive then some of those may not return. Lack of consistent work availability may also disqualify a project from being considered by teams as their special project for a time (like our Aussie Assaults).