Free memory is about 77% I reloaded the seti client and for the present I have 4 cpu's running. now to see why this vista machine is only getting about 100 a day. my XP machine gets at least 500 a day.

The logging flags that have to do with how BOINC decides what to do might be helpful in troubleshooting. There is a full listing of them here. With the right ones enabled you would be ableto go back through the history and see when things started going wonky. I would think <cpu_sched>, <cpu_sched_debug>, <sched_op_debug>, and/or <state_debug>.

Unfortunately, the logging flags don't work restrospectively - they only control what is logged, from the point where they are enabled, going forwards.

If the problems are ongoing, they can be a great help in analysing what's going on each time a problem - especially, any repeat of the earlier problems - happens from here on, but you won't see any more about the past than you can see already.

Speaking of which, the message/event log in BOINC Manager only displays events since the last time the BOINC core client was restarted. But there are files, stdoutdae.txt and stdoutdae.old, in your BOINC data directory which hold old messages going back before the last restart - up to 2MB by default, which for a standard installation can reach back several weeks or months. That may be enough to help you track things down. But if you need to enable the extra flags HAL9000 suggested, some - especially the _debug ones - are very verbose, and you would probably need to increase the size of the log files. Instruction for doing that are in the same listing HAL linked.

Free memory is about 77% I reloaded the seti client and for the present I have 4 cpu's running. now to see why this vista machine is only getting about 100 a day. my XP machine gets at least 500 a day.

The logging flags that have to do with how BOINC decides what to do might be helpful in troubleshooting. There is a full listing of them here. With the right ones enabled you would be ableto go back through the history and see when things started going wonky. I would think <cpu_sched>, <cpu_sched_debug>, <sched_op_debug>, and/or <state_debug>.

Unfortunately, the logging flags don't work restrospectively - they only control what is logged, from the point where they are enabled, going forwards.

If the problems are ongoing, they can be a great help in analysing what's going on each time a problem - especially, any repeat of the earlier problems - happens from here on, but you won't see any more about the past than you can see already.

Speaking of which, the message/event log in BOINC Manager only displays events since the last time the BOINC core client was restarted. But there are files, stdoutdae.txt and stdoutdae.old, in your BOINC data directory which hold old messages going back before the last restart - up to 2MB by default, which for a standard installation can reach back several weeks or months. That may be enough to help you track things down. But if you need to enable the extra flags HAL9000 suggested, some - especially the _debug ones - are very verbose, and you would probably need to increase the size of the log files. Instruction for doing that are in the same listing HAL linked.

Unfortunately I knew what I meant, but it didn't all come out right. EBKAC it would seem. lol Good thing you pointed that out.
I had meant once they were enabled and BOINC restarted that once the behavior was occurring again that it could be scrolled back through to hopefully find the cause.
With the standard limit of 2MB like you mentioned it could need increased with the <max_stdout_file_size> option. If 2MB wasn't enough I would hope something like 10MB would be enough.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

It looks as if I need to do some learning about the flags etc. unfortunately no tome at present. I did note that when the system drops to 1 cpu , if i suspend the working task (always milky way) it starts 4 new tasks or picke up and continues previous work units on all 4 and keeps on all 4 when i unsuspend the task that i stopped.

Free memory is about 77% I reloaded the seti client and for the present I have 4 cpu's running. now to see why this vista machine is only getting about 100 a day. my XP machine gets at least 500 a day.

The logging flags that have to do with how BOINC decides what to do might be helpful in troubleshooting. There is a full listing of them here. With the right ones enabled you would be ableto go back through the history and see when things started going wonky. I would think <cpu_sched>, <cpu_sched_debug>, <sched_op_debug>, and/or <state_debug>.

Unfortunately, the logging flags don't work restrospectively - they only control what is logged, from the point where they are enabled, going forwards.

If the problems are ongoing, they can be a great help in analysing what's going on each time a problem - especially, any repeat of the earlier problems - happens from here on, but you won't see any more about the past than you can see already.

Speaking of which, the message/event log in BOINC Manager only displays events since the last time the BOINC core client was restarted. But there are files, stdoutdae.txt and stdoutdae.old, in your BOINC data directory which hold old messages going back before the last restart - up to 2MB by default, which for a standard installation can reach back several weeks or months. That may be enough to help you track things down. But if you need to enable the extra flags HAL9000 suggested, some - especially the _debug ones - are very verbose, and you would probably need to increase the size of the log files. Instruction for doing that are in the same listing HAL linked.

Unfortunately I knew what I meant, but it didn't all come out right. EBKAC it would seem. lol Good thing you pointed that out.
I had meant once they were enabled and BOINC restarted that once the behavior was occurring again that it could be scrolled back through to hopefully find the cause.
With the standard limit of 2MB like you mentioned it could need increased with the <max_stdout_file_size> option. If 2MB wasn't enough I would hope something like 10MB would be enough.

---

It looks as if I need to do some learning about the flags etc. unfortunately no tome at present. I did note that when the system drops to 1 cpu , if i suspend the working task (always milky way) it starts 4 new tasks or picke up and continues previous work units on all 4 and keeps on all 4 when i unsuspend the task that i stopped.

I believe that others have said that the current MilkyWay application is multithreaded, using all four cores for a single task. If so, it should show something about (mt) in the application column in BOINC Manager, and tell you how many cores are being used in the Status column when Milkyway is running.

Apart from that, Boinc only shows you haw many tasks are running - use operating system tools like Task Manager or third-party utilities to check CPU usage.

Using the system monitor or task manager is what I use to determine how many cores are being used

It looks as if I need to do some learning about the flags etc. unfortunately no tome at present. I did note that when the system drops to 1 cpu , if i suspend the working task (always milky way) it starts 4 new tasks or picke up and continues previous work units on all 4 and keeps on all 4 when i unsuspend the task that i stopped.

I believe that others have said that the current MilkyWay application is multithreaded, using all four cores for a single task. If so, it should show something about (mt) in the application column in BOINC Manager, and tell you how many cores are being used in the Status column when Milkyway is running.

Apart from that, Boinc only shows you haw many tasks are running - use operating system tools like Task Manager or third-party utilities to check CPU usage.

---

Using the system monitor or task manager is what I use to determine how many cores are being used

It looks as if I need to do some learning about the flags etc. unfortunately no tome at present. I did note that when the system drops to 1 cpu , if i suspend the working task (always milky way) it starts 4 new tasks or picke up and continues previous work units on all 4 and keeps on all 4 when i unsuspend the task that i stopped.

I believe that others have said that the current MilkyWay application is multithreaded, using all four cores for a single task. If so, it should show something about (mt) in the application column in BOINC Manager, and tell you how many cores are being used in the Status column when Milkyway is running.

Apart from that, Boinc only shows you haw many tasks are running - use operating system tools like Task Manager or third-party utilities to check CPU usage.

Maybe there is something not working right in the version of BOINC you are running. Where an app like MW that can use multiple threads tells BOINC "I can run several threads", but doesn't tell it how many it is using. So BOINC just suspends all other tasks to give it what it thinks it needs. Also it could be when the MW tasks starts up it uses all the cores and then drops down to 1 or something along those lines.

It might be worth looking though the release notes to see if anything like this was mentioned for the linux version of BOINC. If not then it sounds like something that should be submitted to be fixed.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I got it back to 4 cores by disabling milky-way. so now it is running on all 4 cpu's. funny how now that all 4 are running the average number of units on the daily log is lower than when only 1 was running. Weird as one would expect it to go up.

---