Multiple instance of FoH problem

[mk5652]

I've made a few posts about this in the 'Harassment and discussion' thread, but I'm still having problems, so I'm taking the liberty of opening my own thread

Recap:

I have a dual core Pentium D, and am running two instances of FoH, set up correctly (Machine ID 1 for the first client and, and Machine ID 2 for the second). The second instance seems to be progressing much slower then the first.

I originally noticed that the CPU time of the second instance was much less then the first, e.g. 1 hour 50 Min vs. 30 Min. I tried setting the priority for both instances to low, instead of idle, but it doesn't seem to have made any difference to the overall progress.

I suspected that each client wasn't actually getting a core to itself. When I closed one of the clients, the remaining one shows activity on both cores. I'm not sure that this isn't normal, but I figured that they were supposed to use a core each (hence the machine ID). I checked the Affinity via task manager, and each client was flagged as having access to core 0 and core 1. Again, I don't know if this is normal. I tried manually changing the setting, so one was assigned to core 0, and the other to core 1, but again, no change to the overall progress.

The difference in progress really doesn't seem right, but I've no idea what the problem could be, if indeed there is a problem.

I've attached a screenshot, what do you think?

Note: WU's:

Client 1 = Project: 3040 (Run 2, Clone 897, Gen 11)
Client 2 = Project: 3040 (Run 0, Clone 496, Gen 11)

Both WU's were started at the same time.

[Sparky]

When I kill one of my clients the total usage sticks around 50% but neither core is maxed out. For example right now core 0 is hovering around 85% and the other core is at 15%. No idea why.

Now looking at your pic one core is using 45% the other is 44%, so apparently you have something else that is eating up CPU cycles. Go through your list and see what it is. I'd suspect that realplayer that I see in your taskbar.

[mk5652]

It's actually limited to 90% overall, I stepped it down from 100 after changing the priority to low. That 1% loss could be just task manager I suppose, I don't have real player or anything installed. I think that might be the soundMax utility that you are mistaking for real player. It's basically a clean Windows install with the mobo/graphics drivers/utilities.

When left idle, both clients sustain 45% CPU, 90 total.

[Sparky]

Oh ok. Well both seem to be getting the same amount of CPU time. What it could be also is the one core is getting used for some windows stuff here and there, and maybe a good part of its cache is being used by Windows. Not sure really

[mk5652]

I don't know, unfortunately I have nothing to compare it to, so I don't know what's right and what's not.

I've attached a screenshot, which is three different examples of CPU activity. The first is the second client running only, the second is the first client running only, finally the third is opening the second client, after the first client is already working. Does the activity look correct? This is what I meant before, about it not looking as though each instance is getting it's own core, it looks like the workload is being shared between the cores.

Besides the Windows services etc. nothing other then FoH is running in these screenshots.

[Sparky]

What happens if you manually set the affinity of each FAHcore process to their own cores?

[mk5652]

If I set the affinity manually, it behaves how you would expect it to behave. With one instance running, the first core is fully utilized, leaving the second idle. With the second running as well, each instance appears to utilize it's own core.

[Sparky]

OK try this, have the first client run on a specific by itself for a bit, see how long it takes for each %. Then set it to use either core (like default) and see if that time changes noticeably or not. If you want, repeat with the second client. Then set both to their own specific cores and see if the slower client speeds up any.

[mk5652]

Okay, will do. I'll post back later with results.

Thanks for the help

[mk5652]

Okay, I've done some fairly thorough testing.

Instance 1 only
--------------

Single core: 32 minutes per frame
(set manually, via affinity)

Default: 32 minutes per frame

This really doesn't make sense to me, two cores are only doing the same amount of work that a single core was doing. The performance tab graph suggests that it's doing the equivalent of 1 core @ 90%, but with the work load shared between both cores.

The logs also show that it was also taking 32 minutes per frame when both instances were running.

Instance 2 only
---------------

I'm a bit ahead of myself here, but the result looks fairly predictable, three check points have passed (i.e. 45 minutes), and no frames completed yet. If memory serves, it was taking just over an hour a frame with both instances running.

I have made an observation, which doesn't explain the odd behaviour of the clients, core wise, but might explain why the second client is lagging behind. When the first client starts up, I see; "Extra SSE boost ok.", I don't get this on the second client...

[Sparky]

Hmmm... no SSE? That would REALLY impact your frame times by quite a lot. Do you have -forceasm in the command line for it?

Also, the client is only single threaded, so my guess is one data "stream" gets done by the first core, then the next data "stream" is done by the second core, then the next back to the first core, etc. Goes really fast so it just appears on the graph as both cores being used partially.

The windows SMP client might be a better choice for a dual core CPU though

[mk5652]

Yes, both start up short cuts have the same commands, so why it's not working on one of them, I have no idea.

It doesn't matter whether both instances are running, or just the second one, it never gets the SSE boost.

EDIT:

>> The windows SMP client might be a better choice for a dual core CPU though

I did have a look at the SMP client, but something put me off, I forget what. I might have a look at it again, this is a bit of a headache

[mk5652]

It would seem that my problems have been self inflicted. I checked over the advanced configuration settings of each client, and noticed that the use of advanced assembly optimisation was disabled on the second. I have no idea why, I have no recollection of disabling it, so I can only assume it was human error when I set it up.

Both clients show the "SSE boost" message now, so I presume that will fix the lagging issue.

The strange core behaviour seems to have had me barking up the wrong tree.

Also, the client is only single threaded, so my guess is one data "stream" gets done by the first core, then the next data "stream" is done by the second core, then the next back to the first core, etc. Goes really fast so it just appears on the graph as both cores being used partially.

That makes sense, and would explain what I'm seeing happen. I think that was the main problem, it didn't appear to function as I expected, so I assumed that was the issue

Anyway, thanks for taking the time to help me with this, it was appreciated.

[Sparky]

You're welcome, glad you have it sorted