To be clear on this, we'd be looking at the figures for nHT vs HT, both @ 4 tasks?
Cheers, Mike.
It may require a click on the page reload button (I think Einstein does not set specially page expiry times), but the image of a portion of a spreadsheet in the second post should now include an "affinity" column not previously present.
And, yes, I'm speaking of comparing several entries with 4 in the tasks columns and both HT and nHT in the first column.
It may require a click on the page reload button (I think Einstein does not set specially page expiry times), but the image of a portion of a spreadsheet in the second post should now include an "affinity" column not previously present.
Done that, can't see any 'affinity' .... :-(
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
It may require a click on the page reload button (I think Einstein does not set specially page expiry times), but the image of a portion of a spreadsheet in the second post should now include an "affinity" column not previously present.
Done that, can't see any 'affinity' .... :-(
Cheers, Mike.
same, untill i cleared my cash and done a refresh, now its there :)
edit: aside, might wonna trim that image by one colum to prevent side scrolling :)
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
It may require a click on the page reload button (I think Einstein does not set specially page expiry times), but the image of a portion of a spreadsheet in the second post should now include an "affinity" column not previously present.
Done that, can't see any 'affinity' .... :-(
Cheers, Mike.
Odd, I see a new column after Thpt/Watt/HT_8 with the column label of "Affinity Restrictions" The Excel table fragment screen capture currently has 12 rows. How many rows do you see (including the header row)
Maybe there is a bit of network kit imposing caching between your browser and Photobucket? That could be a reason not to use this update method. If you say this is still a problem I shall pose the new capture to a new post with a new name.
Got it, a FireFox thingy. Cleared the cache, now I can see! ;-)
Yup, a clear-cut result there. In the context of the setup, roaming/loose-affinity has a not inconsiderable price of ~ 10% ... and with restriction nearby the nHT case.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
edit: aside, might wonna trim that image by one colum to prevent side scrolling :)
Gee, it was only 887 pixels wide. I've made an edit and it is down to 787 wide now.
err, sorry. i just had flashbacks of folks way back when complaining about wide signature images and was tryin to head that off :| didnt mean to offend.
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
ExtraTerrestrial Apes: The problem appears to be in the windows scheduler either not being able to detect that the boinc tasks are long running 100% load items to keep them separate, or that it bumps them deliberately because they're low priority tasks in favor of giving exclusive core use to a higher priority item that requested CPU time.
Nr. 1: possible.. but that seems like a really stupid mistake, as it should be ovious that they are essentially "long running 100% load items".
Nr. 2: I would expect this to happen occasionally, but in this case I'd be really surprised by the magnitude of the effect. In the nHT_4 case each task took 14800s, whereas in the full HT_8 config each one took 22300s. In the run in question the 3 tasks with presumably "unlucky assignment" needed 16900s. So I think it is safe to say that these tasks spent approximately 72% of the runtime alone on a core and 28% of the time on a shared core.
If this was intentional, as some other single task seemed more important, then this one would have been run 3*0.28 = 84% of the entire runtime. That means Archae would observe an average non-BOINC CPU load of about 10% (for this statement it does not matter if this was one or many important tasks).
Since Archae took care not to have excessive background tasks running and since on my Win 7 machines I do not normally observe such high background activity I don't think Nr. 2 is a likely explanation for the observed runtimes.
Nr. 3: what if the scheduler wasn't HT-aware? If it assigned tasks completely random? I just quickly tried to count the possibilities for scheduling 3 tasks over 3 HT cores and arrived at 24 lucky possibilities and 20 unlucky ones. If we assume the same probability for each one that would mean 20/(24+20) = 45% unlucky assignments. That's not exactly the 28% from the previous paragraph and I'd be surprised if I didn't make some mistake here. But in my opinion it's somewhat close.. and should be much further away if the scheduler worked remotely the way I'd imagine.
Quote:
In either case this is a Microsoft problem, and not something Intel could do anything about themselves.
Yes, but it's Intel's products which are suffering due to this, i.e. are getting worse benchmark scores and worse real world performance. That's why I think it would be in their best interest to look into this and, if confirmed, ask MS politely but firmly to change their scheduler.
DanNeely wrote:take a look at
)
100%, 100%
Yes it is locked
Mike Hewson wrote:To be clear
)
It may require a click on the page reload button (I think Einstein does not set specially page expiry times), but the image of a portion of a spreadsheet in the second post should now include an "affinity" column not previously present.
And, yes, I'm speaking of comparing several entries with 4 in the tasks columns and both HT and nHT in the first column.
RE: It may require a click
)
Done that, can't see any 'affinity' .... :-(
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: It may require a
)
same, untill i cleared my cash and done a refresh, now its there :)
edit: aside, might wonna trim that image by one colum to prevent side scrolling :)
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
RE: RE: It may require a
)
Odd, I see a new column after Thpt/Watt/HT_8 with the column label of "Affinity Restrictions" The Excel table fragment screen capture currently has 12 rows. How many rows do you see (including the header row)
Maybe there is a bit of network kit imposing caching between your browser and Photobucket? That could be a reason not to use this update method. If you say this is still a problem I shall pose the new capture to a new post with a new name.
Got it, a FireFox thingy.
)
Got it, a FireFox thingy. Cleared the cache, now I can see! ;-)
Yup, a clear-cut result there. In the context of the setup, roaming/loose-affinity has a not inconsiderable price of ~ 10% ... and with restriction nearby the nHT case.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: edit: aside, might
)
Gee, it was only 887 pixels wide. I've made an edit and it is down to 787 wide now.
Well, this is why we have
)
Well, this is why we have scroll bars. :-) :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: edit: aside,
)
err, sorry. i just had flashbacks of folks way back when complaining about wide signature images and was tryin to head that off :| didnt mean to offend.
seeing without seeing is something the blind learn to do, and seeing beyond vision can be a gift.
RE: ExtraTerrestrial Apes:
)
Nr. 1: possible.. but that seems like a really stupid mistake, as it should be ovious that they are essentially "long running 100% load items".
Nr. 2: I would expect this to happen occasionally, but in this case I'd be really surprised by the magnitude of the effect. In the nHT_4 case each task took 14800s, whereas in the full HT_8 config each one took 22300s. In the run in question the 3 tasks with presumably "unlucky assignment" needed 16900s. So I think it is safe to say that these tasks spent approximately 72% of the runtime alone on a core and 28% of the time on a shared core.
If this was intentional, as some other single task seemed more important, then this one would have been run 3*0.28 = 84% of the entire runtime. That means Archae would observe an average non-BOINC CPU load of about 10% (for this statement it does not matter if this was one or many important tasks).
Since Archae took care not to have excessive background tasks running and since on my Win 7 machines I do not normally observe such high background activity I don't think Nr. 2 is a likely explanation for the observed runtimes.
Nr. 3: what if the scheduler wasn't HT-aware? If it assigned tasks completely random? I just quickly tried to count the possibilities for scheduling 3 tasks over 3 HT cores and arrived at 24 lucky possibilities and 20 unlucky ones. If we assume the same probability for each one that would mean 20/(24+20) = 45% unlucky assignments. That's not exactly the 28% from the previous paragraph and I'd be surprised if I didn't make some mistake here. But in my opinion it's somewhat close.. and should be much further away if the scheduler worked remotely the way I'd imagine.
Yes, but it's Intel's products which are suffering due to this, i.e. are getting worse benchmark scores and worse real world performance. That's why I think it would be in their best interest to look into this and, if confirmed, ask MS politely but firmly to change their scheduler.
MrS
Scanning for our furry friends since Jan 2002