Close
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Showing results 11 to 20 of 46

Hybrid View

  1. #1
    Member Ughmahedhurtz's Avatar
    Join Date
    Jul 2007
    Location
    North of The Wall, South of The Line
    Posts
    7169

    Default

    Quote Originally Posted by mbox_bob View Post
    there is a good 30 years (real years, not this man year tripe) of design gone into the Windows scheduler, so any decision it makes about CPU time slice allocation is going to be better than anything you can come up with (you have to remember it also has a shitload more information available to it during execution, rather than some fixed decision you make up front).
    All true but very misleading. In practice, this is excellent advice for normal users or someone running a single app that spawns tons of threads. For multiboxers that run lots of simultaneous apps, it relies greatly on the CPU model for how it hands things off and spreads the load around, sometimes resulting in spikes on single cores/TJs which actually can manifest as input/playback stutter.

    Personally, I have had much, much better luck not letting ISBoxer think for me. For example, the best performance on my i7 systems for 5-boxing looks like this:

    Slot 1 = cores 0, 1, 2, 3
    Slot 2 = cores 0, 1, 2, 3
    Slot 3 = cores 4, 5, 6, 7
    Slot 4 = cores 4, 5, 6, 7
    slot 5 = cores 2, 3, 4, 5
    dxNothing (slot 6) = cores 0, 1, 6, 7

    Any other "automatic" strategery I've used via the wizard results in one or two clients (usually the same client in the initial charset launch order) suffering lag spikes and generally poor performance. I cannot imagine that 10-boxing would be any better.

    *NOTE* You'll notice above that my setup basically agrees with mbox_bob's assertion that letting the OS handle things is generally good. The problem is letting the OS handle ALL instances; if you break them up a little, it drastically reduces the negative effects of spike-loading single cores until the system has time to move things around, which may or may (in my experience) never actually happen.
    Last edited by Ughmahedhurtz : 10-19-2015 at 12:39 PM
    Now playing: WoW (Garona)

  2. #2

    Default

    Quote Originally Posted by Ughmahedhurtz View Post
    All true but very misleading. In practice, this is excellent advice for normal users or someone running a single app that spawns tons of threads.
    If you show me a computer that is ONLY running a single application with tons of threads, then I'll show you something running on MSDOS4.0 (tons of threads is subjective to the era though).

    For the record, on "idle" my computer runs ~100 processes (applications, even if I didn't dbl click an icon to start it) with over 1800 threads. On average I get ~140 processes with ~2800 threads. This is without running any games at all. If I spawn a few game instances, then the numbers increase further.

    Setting processor (read: core) affinity limits the available cores that an application's threads can execute on. If those cores happen to be busy servicing some other thing with a higher priority (like sound/network packets/clock ticks etc), or one or more of those cores are Parked then any thread that has been limited to that core (or group) will potentially miss it's quantum (time slice of CPU time), or be delayed while the core is activated. If you set processor affinity on an application then all of that applications threads will be limited to those cores (processor means cores remember - the name processor affinity has not yet caught up with reality).
    This is the reason that I recommend you do not set processor affinity.
    I find it to be rare, even in an Enterprise installation, to be necessary to set processor affinity (although funnily enough with certain virtual setups it is needed despite it not being so if those same services ran on a shared physical server).

    If you were experiencing issues that required you to set processor affinity to resolve (that are not because the game is old enough to have not been compiled with flags to set multi-core aware, or is has race conditions under multicore so is flags as Uniprocessor), and thus limit the potential group of cores that a specific game instance could run on, then it is more than likely this was due to cores being Parked or in a sleep state to conserve electricity. Reduced energy usage is one of the design goals of CPU's these days, and the power management policy of client Windows (i.e. non server sku) aggressively enforces this. When a core is Parked, it is removed from the available pool for threads to execute on, until such time as the Power management policy awakens that core again due to high utilization of the active cores.
    Yes, this sucks, because it means your multicore processor, may not be actively using all it's available cores, because the power management policy is shutting several of them down. The Windows scheduler does not awaken Parked cores, it will only schedule threads to run on already active cores, so any Parked cores are reducing your potential computation power (and your electricity bill by a piddling few cents per day). The power management policy in turn requires a sustained spike in demand of resources (i.e. use of the active cores) before it will begrudgingly re-activate a Parked core, and then it will aggressively aim to Park it again at the earliest opportunity. This is obviously a counter strategy to the desire of having your multicore processor available to handle a spike in demand as soon as it occurs, and with all available cores.

    You can see if you have cores parking in the Windows Resource Manager. It shows cores in a Parked status. You might also notice the clockspeed changing too, which it is want to do depending on the selected power profile.

    In order to combat the core Parking, you can ensure Windows is set to a High Power profile, and in your BIOS/UEFI, make sure that the C6 CPU sleep state is disabled. You may also benefit from disabling the C1E, C3 and C State Support.
    If you don't want to change the BIOS/UEFI, you may be able to do this via the powercfg utility too as outlined on this site. The registry entry that is mentioned near the end of the post also works well and makes this item available in the Power profile settings. ***I am not affiliated, nor have I verified the utility offered there; I have used the registry entry to make the setting available in the Power profile and that works just fine.

    All that said, if you have set affinity, and this in turn forced activity on cores that would normally have Parked or moved to a sleep state, then fair enough, it is what works for you, and is a valid strategy, but it is essentially a workaround to an issue that can be resolved by setting the correct power management policy.
    I believe my recommendation still stands over and above any fixed decision you make up front, and if you removed the competing priorities of the OS, by disabling the core Parking feature you'd have a far better computing experience overall without needing to mess around and find the optimal core allocation strategy.


    *Note: If using a laptop, then disabling the Cx Sleep States will reduce battery runtime.




    edit: Made a couple of minor clarifications after going back and refreshing my memory on the Thread scheduling and Core Parking strategies in Windows (i.e. re-read the appropriate parts of Windows Internals).
    Last edited by mbox_bob : 10-20-2015 at 08:11 AM Reason: Need to type faster, otherwise it stuffs the continuum

  3. #3
    Member Ughmahedhurtz's Avatar
    Join Date
    Jul 2007
    Location
    North of The Wall, South of The Line
    Posts
    7169

    Default

    Quote Originally Posted by mbox_bob View Post
    then it is more than likely this was due to cores being Parked or in a sleep state to conserve electricity. Reduced energy usage is one of the design goals of CPU's these days, and the power management policy of client Windows (i.e. non server sku) aggressively enforces this. When a core is Parked, it is removed from the available pool for threads to execute on, until such time as the Power management policy awakens that core again due to high utilization of the active cores.
    Yes, this sucks, because it means your multicore processor, may not be actively using all it's available cores, because the power management policy is shutting several of them down. The Windows scheduler does not awaken Parked cores, it will only schedule threads to run on already active cores, so any Parked cores are reducing your potential computation power (and your electricity bill by a piddling few cents per day). The power management policy in turn requires a sustained spike in demand of resources (i.e. use of the active cores) before it will begrudgingly re-activate a Parked core, and then it will aggressively aim to Park it again at the earliest opportunity. This is obviously a counter strategy to the desire of having your multicore processor available to handle a spike in demand as soon as it occurs, and with all available cores.

    You can see if you have cores parking in the Windows Resource Manager. It shows cores in a Parked status. You might also notice the clockspeed changing too, which it is want to do depending on the selected power profile.

    In order to combat the core Parking, you can ensure Windows is set to a High Power profile, and in your BIOS/UEFI, make sure that the C6 CPU sleep state is disabled. You may also benefit from disabling the C1E, C3 and C State Support.
    If you don't want to change the BIOS/UEFI, you may be able to do this via the powercfg utility too as outlined on this site. The registry entry that is mentioned near the end of the post also works well and makes this item available in the Power profile settings. ***I am not affiliated, nor have I verified the utility offered there; I have used the registry entry to make the setting available in the Power profile and that works just fine.

    All that said, if you have set affinity, and this in turn forced activity on cores that would normally have Parked or moved to a sleep state, then fair enough, it is what works for you, and is a valid strategy, but it is essentially a workaround to an issue that can be resolved by setting the correct power management policy.
    I believe my recommendation still stands over and above any fixed decision you make up front, and if you removed the competing priorities of the OS, by disabling the core Parking feature you'd have a far better computing experience overall without needing to mess around and find the optimal core allocation strategy.


    *Note: If using a laptop, then disabling the Cx Sleep States will reduce battery runtime.




    edit: Made a couple of minor clarifications after going back and refreshing my memory on the Thread scheduling and Core Parking strategies in Windows (i.e. re-read the appropriate parts of Windows Internals).
    That, good sir, is an excellent point. I know I go in and try to disable all of the variable power/clock management where possible when setting up my gaming machines (I disable all of the C-states in BIOS if the option is exposed) to prevent this but it's possible I somehow ended up with it re-enabled again. And frankly, it's not something I usually keep an eye on as it isn't something I've ever had "spontaneously" change on me.
    Now playing: WoW (Garona)

  4. #4
    Member JohnGabriel's Avatar
    Join Date
    Oct 2008
    Location
    Seattle Washington, USA
    Posts
    2272

    Default

    The makers of Dimmdrive also sell a program called CPUCores, on sale now for $17.99

    Seems IsBoxer already does that and more, so you wont need both.


  5. #5
    Multiboxologist MiRai's Avatar
    Join Date
    Apr 2009
    Location
    Winter Is Coming
    Posts
    6815

    Default

    Quote Originally Posted by JohnGabriel View Post
    The makers of Dimmdrive also sell a program called CPUCores, on sale now for $17.99
    I think $18 is a bit much for something you can easily set yourself in the Task Manager, and I'll bet there's a free alternative out there for anyone who didn't want to deal with a few clicks. I'm also pretty sure that you can create a batch file to start a program up to use only a specific set of cores if it was really all that necessary to do so.

    Either way, that software is from the "author" of Pwnboxer. The same guy who was cast out of this community for lying to, and deceiving others, and then forced to start his own because he was not wanted here (by many people). The same "community" which now lies in ruin with spam posts and people asking for their money back because he still sells the software even though it no longer works (according to posts on his forum). His credibility—especially on /r/PCMasterRace—is gone because of the BS he has spewed out to everyone in order to sell them something they don't need (*cough*DIMMDrive*cough*). So, if you'd like to spend your money on his software, then by all means, go for it.

    And now back to the topic at hand...
    Do not send me a PM if what you want to talk about isn't absolutely private.
    Ask your questions on the forum where others can also benefit from the information.

    Author of the almost unknown and heavily neglected blog: Multiboxology

  6. #6

    Default

    Hi!
    just got home from work!

    Changed cpu strategy to all games select all cores, changed fps to 40/20, looked at the startup services and other services that might have been unnecisary (or how you spell it)
    looks like at this pointit got solved ... I'm in warspear now and cpu usage used to be 40 % here, now only 20-25 %

    Might be able to stream after all and rise the video settings a bit !


    A very very thank you is at its place I think! so Thank you very much for the info and reply's!
    Multiboxing 10 accounts!
    Outland-Europe
    2 mistweaver monks - 8 Elemental shamans

  7. #7
    Member Ughmahedhurtz's Avatar
    Join Date
    Jul 2007
    Location
    North of The Wall, South of The Line
    Posts
    7169

    Default

    Quote Originally Posted by tanknspanker View Post
    Changed cpu strategy to all games select all cores, changed fps to 40/20, looked at the startup services and other services that might have been unnecisary (or how you spell it)
    looks like at this pointit got solved ... I'm in warspear now and cpu usage used to be 40 % here, now only 20-25 %
    Outstanding! Of course, vids or it didn't happen.
    Now playing: WoW (Garona)

  8. #8

    Default

    Quote Originally Posted by Ughmahedhurtz View Post
    Outstanding! Of course, vids or it didn't happen.
    you could always follow my stream as this isnt a problem anymore!
    Www.twitch.tv/kstar161991 ;-)
    Multiboxing 10 accounts!
    Outland-Europe
    2 mistweaver monks - 8 Elemental shamans

  9. #9
    Member JohnGabriel's Avatar
    Join Date
    Oct 2008
    Location
    Seattle Washington, USA
    Posts
    2272

    Default

    Quote Originally Posted by tanknspanker View Post
    Hi!
    just got home from work!

    Changed cpu strategy to all games select all cores, changed fps to 40/20, looked at the startup services and other services that might have been unnecisary (or how you spell it)
    looks like at this pointit got solved ... I'm in warspear now and cpu usage used to be 40 % here, now only 20-25 %

    Might be able to stream after all and rise the video settings a bit !


    A very very thank you is at its place I think! so Thank you very much for the info and reply's!
    Glad you have it working for you. A quick comment, if I drop background FPS below 30 I start to notice slaves losing follow often.

  10. #10

    Default

    Quote Originally Posted by JohnGabriel View Post
    Glad you have it working for you. A quick comment, if I drop background FPS below 30 I start to notice slaves losing follow often.
    Strange..
    I've put mine on 20 fps en no follow lost..
    Just slaves stop following cause of obstacels.. xD
    Multiboxing 10 accounts!
    Outland-Europe
    2 mistweaver monks - 8 Elemental shamans

Posting Rules

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •