This is wierd...

Soldato
Joined
16 Dec 2005
Posts
14,443
Location
Manchester
I have two 116 point WUs crunching away at the moment.

One I started yesteday, and one I started earlier on today. The project numbers are 1718 and 1717 respectively.

Now, the 1718 project which has been running for over 24 hours already is at 50% and has another 24 hours to go...

The 1717 project on the other hand is at 5% and has less than 20 hours to go...

What gives? These are two very similar projects, at least points-wise, but one is taking twice as long as the other :confused:

SiriusB
 
They're on the same rig - 4400+ @ 2.6GHz and 2GB RAM

I have been playing games again this last few days since I borrowed COD2 off a mate but I doubt this would cause a WU to take twice as long - especially given my rig is on 24/7

SiriusB
 
Actually, gaming will seriously affect your WU times depending on how long you are playing.

I had a 2 hour session of Doom3 the other day and when I checked the F@H log, I hadn't finished a single frame on one of the cores during that time (the other core was unaffected) and that was on my 4400 (almost identical to yours - 2.6GHz, 2GB RAM).
 
I know it can all but stop a WU from crunching while you are gaming, but I don't see how a total of about 5 hours gaming in the last two days can increase a WUs ETA by a whole day.

If it said ETA: 24 hours before playing and still said 24 hours when I finished, then fine - I lost xxx number of hours to gaming...

However, I am in the situation where a WU appears to be taking an extra 24 hours even though at most 5 hours have been lost to gaming.

SiriusB
 
use task manager to see how much ACTUAL cpu time each has had, you'll probably find that the one that's taking longer has just had most of its cpu time nicked by other programs and as such is taking longer



otherwise check that it's showing the SSE/SSE2 message at the start (depending on type of core)
 
The times are based on the average time it takes to complete a WU are they not?

When playing a game the current WU will seem like it's taken an extra 5 hours to complete thereby throwing the average off hugely.

I think.
 
Okay just had at a look at my F@H log and it is running the WU with standard loops... the usual SSE Boost entry is not their either.

Okay, so it seems it is doing this WU the old fashioned way... question now is why :|

SiriusB
 
SiriusB said:
Okay just had at a look at my F@H log and it is running the WU with standard loops... the usual SSE Boost entry is not their either.

Okay, so it seems it is doing this WU the old fashioned way... question now is why :|

SiriusB
It can be as simple as the client not quite shutting down properly last time - it's worth checking back in the log as it should give you a clue.
To cure it all you need to do is restart the client and it should start with SSE, however it can happen again - the best solution is to add the -forceasm switch to the image path in registry as that'll stop it disabling the optimisations in the future
 
Okay so far so good, the log says SSE Boost OK... should know pretty soon if the 20+ hour ETA is shortened somewhat.

Still curious as to why it decided it wouldn't bother with optimisations when it started lol

EDIT: Ah, just spotted your post rich. I think I did see an improper shutdown entry in the log. Probably explains it :)

SiriusB
 
Back
Top Bottom