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.![]()
Connect With Us