> Well, I tried setting Ghost up to do just full backups but the filesave
> threads stayed running, even after a reboot. So, guess that won't save me a
> thing.
>
> Guess I'm stuck at this point...

If you do figure this out, can you drop me a line? This should be added to the FAQ!

I know I mention background processes slowing things down ... but this may need a new question all by itself.

Have you thought of asking Norton about this?

---

> If you do figure this out, can you drop me a line? This should be added to the
> FAQ!
>
> I know I mention background processes slowing things down ... but this may
> need a new question all by itself.
>
> Have you thought of asking Norton about this?


I sure will, and yes, I have an open tech support ticket with Norton about this. That's as far as it's gotten to date, but I will get as much as I can for info and will keep this thread updated.

K

---

** UPDATE **

Well, I've done some more experimentation to try to figure out my WU slowdown and have discovered that it's not Norton Ghost slowing me down, after all. At least, not very much. Turns out the major reason for my WU slowdown is because I also crunch for ClimatePrediction.net. Apparently, with my HT computer, any SETI unit that crunches while the ClimatePrediction.net unit is crunching takes almost an hour longer to complete. Why? I have no idea. I guess the crunching of the two different type of WU's simultaneously just doesn't blend well together in a hyperthreaded CPU. I've detached from the ClimatePrediction.net project and now my SETI WU's are completing in 3 hours, again.

Is there any way to get BOINC to crunch the two different projects sequentially instead of simultaneously on a hyperthreaded or multiprocessor computer? My laptop (Centrino system) does just fine, but it crunches for one project or the other. That appears to work just fine...

K

---

> Is there any way to get BOINC to crunch the two different projects
> sequentially instead of simultaneously on a hyperthreaded or multiprocessor
> computer? My laptop (Centrino system) does just fine, but it crunches for one
> project or the other. That appears to work just fine...
>

Try setting your "On multiprocessors, use at most" to "1". See if that makes a difference.

> Try setting your "On multiprocessors, use at most" to "1". See if that makes
> a difference.

Hmm. I would think that would tell BOINC to only process on one half of the processor instead of both halves, wouldn't it? While that would eliminate simultaneous crunching it would also cut the work performed in half.

Is there a way to tell BOINC to run two threads of each project at a time? If not, can the BOINC software be modified to provide the option to run two of one project followed by two of another or the current way of one of each?

---

> Hmm. I would think that would tell BOINC to only process on one half of the
> processor instead of both halves, wouldn't it? While that would eliminate
> simultaneous crunching it would also cut the work performed in half.
>

Hyperthreading is sharing the CPU, not splitting it in two. Each "virtual" CPU gets whatever it can from the real one.


> Is there a way to tell BOINC to run two threads of each project at a time? If
> not, can the BOINC software be modified to provide the option to run two of
> one project followed by two of another or the current way of one of each?

You have that right now. But if you join multiple projects you're telling BOINC to split the work between the projects, using the seti@home preferences for resource sharing.

Maybe if you changed the resource settings you can get what you're looking for - like 75%seti, 25% climateprediction. Or 66/33. Experiment a bit and let it run for several cycles each time.

> Hyperthreading is sharing the CPU, not splitting it in two. Each "virtual"
> CPU gets whatever it can from the real one.

OK, I'll try setting it for one CPU and see what happens.

I'm not sure of the right terminology for the hyperthreading and how it works (I do know there is only one physical CPU), but I do know that running SETI with "2 CPU's" will net 2 completed WU's in about 3 hours. If dropping the CPU use down to 1 will change that work output, well, ClimatePrediction is gonna be SOL, I'm afraid... unless and until the BOINC software can be modified to optionally run WU's from one project at a time on all CPU's, virtual or real...

> You have that right now. But if you join multiple projects you're telling
> BOINC to split the work between the projects, using the seti@home preferences
> for resource sharing.
>
> Maybe if you changed the resource settings you can get what you're looking for
> - like 75%seti, 25% climateprediction. Or 66/33. Experiment a bit and let it
> run for several cycles each time.

This is how I discovered that the simultaneous running of SETI and ClimatePrediction was having a problem. I set SETI at 200 and left ClimatePrediction at 100, which sets up the 66/33 (or 2 to 1) scenario you mentioned. After a couple of days I'd get some SETI WU's at 3 hours and others almost 4. A definite change. So, yesterday I went all the way and detached from ClimatePrediction and voila, ALL the SETI WU's are finishing up at around 3 hours again.

There is some kind of work conflict going on with running ClimatePrediction and SETI together, which is causing SETI WU's (and perhaps ClimatePrediction WU's) to take longer to complete. This is inefficient and I'm looking for workarounds...

[EDIT]: I also still think Norton Ghost and True Image 8 have something to do with this conflict, too, because when either of them are installed and the two different projects are running is when this WU slowdown happens...

---

Well, I just set processors to 1 and checked out the situation. As I expected, BOINC ran one WU, only. CPU utilization was at 50%. System Idle was at 50%.

Crap.

---

> Well, I just set processors to 1 and checked out the situation. As I
> expected, BOINC ran one WU, only. CPU utilization was at 50%. System Idle
> was at 50%.
>
> Crap.

Thats because Windows doesn't distinguish between hyperthreaded and physical processors. It calculates those numbers thinking you have 100% of one processor, with the other processor idle.

Let it run for awhile and see how long it takes. When complete check its CPU time, bet it shows SETI got close to 100% of that processor.

EDIT: Use the message log to calculate elapsed time in hours, then compare it to result time.

> Thats because Windows doesn't distinguish between hyperthreaded and physical
> processors. It calculates those numbers thinking you have 100% of one
> processor, with the other processor idle.
>
> Let it run for awhile and see how long it takes. When complete check its CPU
> time, bet it shows SETI got close to 100% of that processor.

Will I still get 2 WU's done in 3 hours?

EDIT: I've reset both projects to 1 processor and will try it out for a day or two to see if what you're telling me is true, Walt... Thanks.

K

---

> Will I still get 2 WU's done in 3 hours?

If one WU runs in 1.5 hours then yes. Excepting time spent processing WU's from other projects that is.

> EDIT: I've reset both projects to 1 processor and will try it out for a day
> or two to see if what you're telling me is true, Walt... Thanks.
>
> K

Keep them message logs around, so you can check the start/stop and suspend/resume times for each WU. Thats the stdout.txt file in the BOINC directory. If you restart BOINC, the old one is stdout.old.

>
> > Will I still get 2 WU's done in 3 hours?
>
> If one WU runs in 1.5 hours then yes. Excepting time spent processing WU's
> from other projects that is.

Well, again, keeping in mind how this hyperthreading deal works, with 2 WU's running simultaneously I'm getting 2 SETI WU's in about 3 hours (+/- 10 minutes). So, if I set processors to 1 I'm still gonna be looking for 2 SETI WU's in about 3 hours, except now 1 in 1.5 hours and another right on it's heels in 1.5 hours. Is that what you're saying is going to happen here?

> Keep them message logs around, so you can check the start/stop and
> suspend/resume times for each WU. Thats the stdout.txt file in the BOINC
> directory. If you restart BOINC, the old one is stdout.old.

Won't I be able to just look at my results log onine and see the SETI WU's getting done with a CPU time of something around 5400 seconds instead of around 10,800?

---

> Well, again, keeping in mind how this hyperthreading deal works, with 2 WU's
> running simultaneously I'm getting 2 SETI WU's in about 3 hours (+/- 10
> minutes). So, if I set processors to 1 I'm still gonna be looking for 2 SETI
> WU's in about 3 hours, except now 1 in 1.5 hours and another right on it's
> heels in 1.5 hours. Is that what you're saying is going to happen here?

Edit: Not quite. Can't predict what one-by-itself will do.

> Won't I be able to just look at my results log onine and see the SETI WU's
> getting done with a CPU time of something around 5400 seconds instead of
> around 10,800?

Depends. Where do you get the 10,800 mumber from? Is it what each WU takes when you have hyperthreading turned on and run two WU's at the same time? If so, then running just one WU at a time (and without another CPU intensove task) will lower it but how much is just a guess.

> Where do you get the 10,800 mumber from? Is it what each WU takes
> when you have hyperthreading turned on and run two WU's at the same time?

Yeah, that's the number of seconds in 3 hours.

K

---

> Not quite. Can't predict what one-by-itself will do.

I can already tell that working a single WU by itself on this HT system is not going as efficiently and as well as working with 2 WU's using "2 processors". I've got one WU right now at an hour and 12 minutes and it's only 57% done. And, my system has just been sitting here getting the occassional e-mail message every 10 minutes and nothing else. It needs to be at 80% complete to be on track for one WU in 1.5 hours.

Setting the processor for 1 is inefficient. I'm resetting back to 2.

K

---

> > Not quite. Can't predict what one-by-itself will do.
>
> I can already tell that working a single WU by itself on this HT system is not
> going as efficiently and as well as working with 2 WU's using "2 processors".
> I've got one WU right now at an hour and 12 minutes and it's only 57% done.
> And, my system has just been sitting here getting the occassional e-mail
> message every 10 minutes and nothing else. It needs to be at 80% complete to
> be on track for one WU in 1.5 hours.
>
> Setting the processor for 1 is inefficient. I'm resetting back to 2.
>
> K
>
The normal gain for running 2 processes on a HT processor is about 30%. This is a thouroughput gain, each individual workunit will take longer.

To put it into understandable numbers; in the time it takes to do 10 workunits with HT off (or only running 1 at a time) you can do about 13 workunits running 2 with HT on.

On a true dual processor system the gain is about 90%. Or 19 workunits in the same time as 10 if only using 1 CPU.

There are occasionally drawbacks to running 2 at a time on a HT processor. Since the OS thinks there are 2 real processors a low priority task can steal cycles from higher priority tasks resulting in a sluggish system. This is especially true with any windows prior to XP or 2003. I am not sure which *nix version actually works with HT but just like in windows there are some multiprocessor versions that will appear to work even though they do not.

---

BOINC WIKI

BOINCing since 2002/12/8

> Is there a way to tell BOINC to run two threads of each project at a time? If
> not, can the BOINC software be modified to provide the option to run two of
> one project followed by two of another or the current way of one of each?

That won't make much difference in throughput, because Climateprediction is also slower when running together with another copy of itself than when running together with Seti.

---

> That won't make much difference in throughput, because Climateprediction is
> also slower when running together with another copy of itself than when
> running together with Seti.

One of the most likely causes is that the CPDN is causing "thrashing" in the cache ... this will cause a significant slow down in the processing speed.

Secondly, they could be competing for the same internal resource in the FPU ...

---

** UPDATE **

OK, as for Symantec Tech Support and their answer for Ghost's hand in these things I'm experiencing:


"Welcome to Symantec Online Technical Support.

I understand from your message that after installing the product on your system, the network has slowed down.

Kindly be aware that this issue can happen if Windows Service Pack 2 is installed on your system. Please be aware that Norton Ghost 9.0 is compatible with Windows XP Service Pack 2. However, you need to modify the Data Execution Prevention (DEP) policy to allow Norton Ghost 9.0 to launch its services during startup. Please refer to the document linked below for more information on resolving this issue:

Title: 'Norton Ghost 9.0 compatibility with Windows XP Service Pack 2'
Document ID: 2004101410380862
> Web URL: http://service1.symantec.com/Support/powerquest.nsf/docid/2004101410380862

Please let us know if the issue is resolved. Thank You for contacting Symantec Online Technical Support.

Regards,

Shanal George
Symantec Authorized Technical Support"


The document tells you to set the DEP to "Turn on DEP for all programs and services except those I select:" instead of the standard "Turn on DEP for essential Windows programs and services, only".

I'm not sure this will do anything because Ghost and it's services started just fine with the standard DEP setting, and this document I was referred to says it won't. I've gone ahead and made the change and rebooted as the document instructs and will wait and see if this does anything for system speed.

Anyone have any input on all this???

K

---

> I'm not sure this will do anything because Ghost and it's services started
> just fine with the standard DEP setting, and this document I was referred to
> says it won't. I've gone ahead and made the change and rebooted as the
> document instructs and will wait and see if this does anything for system
> speed.
>
> Anyone have any input on all this???

Just a guess, but perhaps Ghost tried to install itself by modifying data areas and putting executable code there. It has to hook into the system somehow. When that failed, it dropped back to using traditional system hooks which are slower. Although they do tend to be more reliable.