Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Total core number seems erronous #17

Open
jairbubbles opened this issue Jun 21, 2017 · 6 comments
Open

Total core number seems erronous #17

jairbubbles opened this issue Jun 21, 2017 · 6 comments

Comments

@jairbubbles
Copy link

My PC is working for another one and sharing 6 cores:
image

But on the other pc fastbuild monitor displays 7 cores:
image

But the total he's 18 as expected (12+6).

The weird thing is that the monitor displays 7 cores correctly (each one with its own jobs).

@jairbubbles
Copy link
Author

After discussing with a colleague here is @ffulin aswer:

The workers request 1 additional job in order to parallelize network traffic vs compilation. They only actually start the correct number of jobs at the same time. Without this, one CPU core would always be idle for some portion of the time. On the FASTBuild side we unfortunately don't have enough information to differentiate this extra job versus the "normal" ones, and so when we write the monitor log, we we just have to write the same info.  So everything is actually working correctly under the hood, but the monitor is "wrong".

It will likely require changes to the network protocol to have enough information to differentiate this "extra" job in the monitor UI.

@yass007
Copy link
Owner

yass007 commented Jun 21, 2017

Yup! That's right :)
Something to fix in the future. BTW you seem to have some interesting timeouts...

@jairbubbles
Copy link
Author

Now I know what orange means :-)

@yass007
Copy link
Owner

yass007 commented Jun 21, 2017

If you hover the cursor on top of it, it should say "Timeout" instead of Success of Fail.

@ffulin
Copy link

ffulin commented Jun 22, 2017

I do still think the way to fix this is a protocol change. The worker could request an "extra"
job explicitly (instead of just a normal nth job), and would also need to notify the client when it actually starts the job. Probably not that tricky to do.

The current dev branch has several fixes that might improve your network timeouts (due to be released in v0.94)

@yass007
Copy link
Owner

yass007 commented Jun 24, 2017

That's what I was thinking too.
I deliberately wanted to minimize the changes to FASTBuild to get the first version in :).

If you agree, I'll take a look into it and do a second pass with the protocol changes as you mention. This will potentially allows to add more useful info to the viewer like transfer time in/out vs real cpu time. etc...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants