Mouse stutter problem in Winows 7 64 bit

Would develope this problem a couple minutes after startup. Restarting
would remove the problem but only for another couple minutes etc. Saw
this in a Logitech forum :

1. Click the Windows start button.

2. Type msconfig.exe in the "Search programs and files" box.

3. It will require the administrator password to run.

4. Click on the "Boot" tab at the top.

5. Click on the "Advanced Options" button.

6. Make sure that the "Number of processors" is checked. Most
importantly make sure the number of processors matches what your CPU
has! (Dual core = 2, Tri=3, Quad=4, etc. etc.)

7. Hit Ok, and then reboot.

My Number of processors was NOT checked and the number was set to only
1 instead or the correct 2.

This fix worked beautifully !

PS - My mouse is a Microsoft wireless and NOT a Logitech ...

On Mon, 16 Feb 2015 13:53:09 -0500, Stephen G. Giannoni
wrote:

Would develope this problem a couple minutes after startup. Restarting
would remove the problem but only for another couple minutes etc. Saw
this in a Logitech forum :

1. Click the Windows start button.

2. Type msconfig.exe in the "Search programs and files" box.

3. It will require the administrator password to run.

4. Click on the "Boot" tab at the top.

5. Click on the "Advanced Options" button.

6. Make sure that the "Number of processors" is checked. Most
importantly make sure the number of processors matches what your CPU
has! (Dual core = 2, Tri=3, Quad=4, etc. etc.)

7. Hit Ok, and then reboot.

My Number of processors was NOT checked and the number was set to only
1 instead or the correct 2.

This fix worked beautifully !

Stephen G. Giannoni wrote:
PS - My mouse is a Microsoft wireless and NOT a Logitech ...

On Mon, 16 Feb 2015 13:53:09 -0500, Stephen G. Giannoni
wrote:

Would develope this problem a couple minutes after startup. Restarting
would remove the problem but only for another couple minutes etc. Saw
this in a Logitech forum :

1. Click the Windows start button.

2. Type msconfig.exe in the "Search programs and files" box.

3. It will require the administrator password to run.

4. Click on the "Boot" tab at the top.

5. Click on the "Advanced Options" button.

6. Make sure that the "Number of processors" is checked. Most
importantly make sure the number of processors matches what your CPU
has! (Dual core = 2, Tri=3, Quad=4, etc. etc.)

7. Hit Ok, and then reboot.

My Number of processors was NOT checked and the number was set to only
1 instead or the correct 2.

This fix worked beautifully !

But item (6) happens to be normal.

Number of processors unchecked, number set to 1.
That is the default.

What that default means is the "core count is unconstrained".
The OS detects as many cores as possible (up to the OS core
limit). Task Manager has a maximum number of cores it can handle,
which varies from OS to OS. (You would need the supercomputer
that Stephen Hawking was given, to blow that limit.)

In a normal situation, your dual core would have two processors
detected. Task Manager, if you set the CPU display to "one graph
per core" kind of thing, you'd see two panes, one for each
core. That would be an easy way to verify
the unchecked "Number of Processors" box and the grayed
out value of 1, had no effect. And that two cores were detected.

What you may have, is an AMD processor, with more cores than
are officially recognized, and one of the switched off
cores is getting used. That's about the only thing I can
think of. With the right motherboard, the turned off core
can be turned on again (whether it is stable or not).

As an alternative test, you could boot a Linux LiveCD, and
see how many "Penguin Icons" appear during the boot process.
This isn't foolproof, but it's another way to see what
the BIOS is telling the OS in terms of detected cores, and
seeing if this situation is a BIOS bug or something.

The Penguin Icons aren't foolproof. On a 6C/12T processor,
there is only room on the screen for 11 icons, and the 12th
is off the screen. And some LiveCD distros, they actually
only recognize a maximum of 8 virtual cores (not 12 or more).
But for the test case of any "ordinary" processor, like
up to a 4C/8T eight virtual core CPU, the penguin count
should work. (4C/8T = 4 cores, 8 threads, or in English,
an Intel quad core with Hyperthreading.)

In terms of what your CPU supports, you can use
Sysinternals.com "Coreinfo" program. (Sysinternals was
bought by Microsoft...)

https://technet.microsoft.com/en-us/...rnals/cc835722

What you'd do, is temporarily turn off the "Number of processors"
tick box, reboot, immediately run Coreinfo and see how many
cores it is detecting, to see if somehow more than two
is detected. You would look at the section like this,
to see if there is an anomaly in the count.

Logical to Physical Processor Map:
*--- Physical Processor 0
-*-- Physical Processor 1
--*- Physical Processor 2
---* Physical Processor 3

Anyway, keep up the good work :-)

Paul

WOW, you sure know youe stuff !

Not quite sure how it all relates to the mouse stutter thing ...

On Mon, 16 Feb 2015 14:19:01 -0500, Paul wrote:

Stephen G. Giannoni wrote:
PS - My mouse is a Microsoft wireless and NOT a Logitech ...

On Mon, 16 Feb 2015 13:53:09 -0500, Stephen G. Giannoni
wrote:

Would develope this problem a couple minutes after startup. Restarting
would remove the problem but only for another couple minutes etc. Saw
this in a Logitech forum :

1. Click the Windows start button.

2. Type msconfig.exe in the "Search programs and files" box.

3. It will require the administrator password to run.

4. Click on the "Boot" tab at the top.

5. Click on the "Advanced Options" button.

6. Make sure that the "Number of processors" is checked. Most
importantly make sure the number of processors matches what your CPU
has! (Dual core = 2, Tri=3, Quad=4, etc. etc.)

7. Hit Ok, and then reboot.

My Number of processors was NOT checked and the number was set to only
1 instead or the correct 2.

This fix worked beautifully !

But item (6) happens to be normal.

Number of processors unchecked, number set to 1.
That is the default.

What that default means is the "core count is unconstrained".
The OS detects as many cores as possible (up to the OS core
limit). Task Manager has a maximum number of cores it can handle,
which varies from OS to OS. (You would need the supercomputer
that Stephen Hawking was given, to blow that limit.)

In a normal situation, your dual core would have two processors
detected. Task Manager, if you set the CPU display to "one graph
per core" kind of thing, you'd see two panes, one for each
core. That would be an easy way to verify
the unchecked "Number of Processors" box and the grayed
out value of 1, had no effect. And that two cores were detected.

What you may have, is an AMD processor, with more cores than
are officially recognized, and one of the switched off
cores is getting used. That's about the only thing I can
think of. With the right motherboard, the turned off core
can be turned on again (whether it is stable or not).

As an alternative test, you could boot a Linux LiveCD, and
see how many "Penguin Icons" appear during the boot process.
This isn't foolproof, but it's another way to see what
the BIOS is telling the OS in terms of detected cores, and
seeing if this situation is a BIOS bug or something.

The Penguin Icons aren't foolproof. On a 6C/12T processor,
there is only room on the screen for 11 icons, and the 12th
is off the screen. And some LiveCD distros, they actually
only recognize a maximum of 8 virtual cores (not 12 or more).
But for the test case of any "ordinary" processor, like
up to a 4C/8T eight virtual core CPU, the penguin count
should work. (4C/8T = 4 cores, 8 threads, or in English,
an Intel quad core with Hyperthreading.)

In terms of what your CPU supports, you can use
Sysinternals.com "Coreinfo" program. (Sysinternals was
bought by Microsoft...)

https://technet.microsoft.com/en-us/...rnals/cc835722

What you'd do, is temporarily turn off the "Number of processors"
tick box, reboot, immediately run Coreinfo and see how many
cores it is detecting, to see if somehow more than two
is detected. You would look at the section like this,
to see if there is an anomaly in the count.

Logical to Physical Processor Map:
*--- Physical Processor 0
-*-- Physical Processor 1
--*- Physical Processor 2
---* Physical Processor 3

Anyway, keep up the good work :-)

Paul

Stephen G. Giannoni wrote:
WOW, you sure know youe stuff !

Not quite sure how it all relates to the mouse stutter thing ...

I'm trying to figure out whether there is a mismatch
between the number of cures you think you have, and
what the BIOS has done.

Do you have an AMD processor ? The theory I propose is
far-fetched, but I don't happen to have any other theories
to suit.

Stuttering is not exactly unknown. There are plenty of
old games (maybe ten years old), you try to run them,
they stutter. If you use "runfirst" program,
which sets the affinity of the program to run on
Core0, that usually fixes the problem. It's
because the game was never designed to be
"thread safe". It wasn't prepared for a
multi-core computer. There are a couple of
launcher programs like "runfirst", which were
used to make the older games happy.

It's unlikely that a mouse driver would be designed
like that. And I don't think you can set affinity
on a driver anyway. Affinity (a setting also available
in Task Manager), is generally for user space problems.

There are yet other ways to cause or stop stuttering.
The power state (ACPI based) sometimes plays a role.
Say you're watching a movie on an AMD processor, and
you notice a bit of jitter or flutter in the video.
If you select the "Always On" power schema in the Power
control panel, sometimes that stops the problem. In that
case, the processor goes between a high-power and
low-power state, 30 times a second, which has an impact
on video decoding.

But if I try to align your observation, that fooling
with the BCDedit programming of core detection "fixes"
your problem, then it's probably not an ACPI problem.
And the only thing that comes to mind, is maybe
if you had more cores actually detected by the OS,
then were supposed to be there. AMD made some
processors, where for yield reasons they turn off
cores that are "bad" in testing. And some BIOS
are equipped with the means to turn them back
on (so you can test and see if you get a "free"
core out of it or not). This was a technique to
buy a cheap processor, and make a more worthy
processor out of it. If the core really is defective
(which doesn't happen too often), the user would then
turn the "free core" off again.

*******

On Linux, I can get stutter problems, if all of the
available clock sources in the hardware, aren't working
right. If I type a letter on the keyboard, it can
"repeat" multiple times. Sometimes this problem
is bad enough, I can fill a text document with the same
letter typed over and over again, and not be able
to stop it. I haven't run into a situation yet, where
that happened to me in Windows. On Windows, keyboards
"hesitate", and I can have stuff stored in a typeahead
buffer for like five seconds. That's more the style of
Windows problems. Still not your mouse problem though.

You might also check Device Manager in Windows, visit
the mouse, and under the Power Management tab, make
sure both options are turned off. On my current OS,
the option to turn off the mouse to save power, is
grayed out, so I cannot tick it by accident. If such
an option was enabled, that would likely have side
effects.

While you're in Device Manager, have a look around
for anomalies. For example, maybe you see two mice
detected, when only one piece of hardware is present.

I'm just having trouble accepting the solution, as
drivers are relatively high quality, and this
**** works for a *lot* of other people...

And it's a wireless mouse, and I didn't even go
down the fault tree for one of those. Try moving
the mouse receiver, away from any USB3 cabling.

Paul

Stephen G. Giannoni wrote:

Would develope this problem a couple minutes after startup. Restarting
would remove the problem but only for another couple minutes etc. Saw
this in a Logitech forum :

1. Click the Windows start button.

2. Type msconfig.exe in the "Search programs and files" box.

3. It will require the administrator password to run.

4. Click on the "Boot" tab at the top.

5. Click on the "Advanced Options" button.

6. Make sure that the "Number of processors" is checked. Most
importantly make sure the number of processors matches what your CPU
has! (Dual core = 2, Tri=3, Quad=4, etc. etc.)

7. Hit Ok, and then reboot.

My Number of processors was NOT checked and the number was set to only
1 instead or the correct 2.

This fix worked beautifully !

Sounds like a problem with their software. I remember, in the past,
that I stuck with their Mouseware program instead of using their bloated
and flaky SetPoint program. Nowadays, I still use a Logitech mouse but
I don't need any software from Logitech to use their mouse. I just use
the HID (human interface device) embedded driver that comes in Windows.
However, I only get and use 3-buttoned wheeled mice so I don't need
ancilliary event monitoring or macro software to make use of more
buttons on the mouse.

Did you try uninstalling their software (and reverting the processor
option you mentioned back to deselected) and retesting the behavior of
your Logitech mouse?

I see you updated your post by saying you use a Microsoft mouse.
Several years ago, I had to go through Logitech, IBM, Microsoft, and
other mice trying to get rid of stuttering problems with mouse movement
mostly within video games. The auto-sleep feature was causing the
problem. Even for wired mice, the manufacturers have their mice go into
low-power mode when not used for awhile. I don't remember the timeout
intervals but Logitech was a lot longer than either IBM or Microsoft.
Also, Logitech was a LOT faster to wake up plus it was intelligent not
to go into sleep mode based solely on when it was last awoken but when
it was last used (active). Since then, I've stuck with Logitech mice.

The Microsoft and other mice also came with ancilliary software to add
features to their mice or to support macros or more buttons (recognize
more events). So uninstall that ancilliary software, if not really
needed, deselect the processor count option you mention, and retest.

Such great reservoirs of info !

Many thanks to Paul & VanguardLH !

On Mon, 16 Feb 2015 13:53:09 -0500, Stephen G. Giannoni
wrote:

Would develope this problem a couple minutes after startup. Restarting
would remove the problem but only for another couple minutes etc. Saw
this in a Logitech forum :

1. Click the Windows start button.

2. Type msconfig.exe in the "Search programs and files" box.

3. It will require the administrator password to run.

4. Click on the "Boot" tab at the top.

5. Click on the "Advanced Options" button.

6. Make sure that the "Number of processors" is checked. Most
importantly make sure the number of processors matches what your CPU
has! (Dual core = 2, Tri=3, Quad=4, etc. etc.)

7. Hit Ok, and then reboot.

My Number of processors was NOT checked and the number was set to only
1 instead or the correct 2.

This fix worked beautifully !

Just a very "vanilla" Dell system, about 3 years old ...

On Mon, 16 Feb 2015 18:06:10 -0500, Paul wrote:

Stephen G. Giannoni wrote:
WOW, you sure know youe stuff !

Not quite sure how it all relates to the mouse stutter thing ...

I'm trying to figure out whether there is a mismatch
between the number of cures you think you have, and
what the BIOS has done.

Do you have an AMD processor ? The theory I propose is
far-fetched, but I don't happen to have any other theories
to suit.

Stuttering is not exactly unknown. There are plenty of
old games (maybe ten years old), you try to run them,
they stutter. If you use "runfirst" program,
which sets the affinity of the program to run on
Core0, that usually fixes the problem. It's
because the game was never designed to be
"thread safe". It wasn't prepared for a
multi-core computer. There are a couple of
launcher programs like "runfirst", which were
used to make the older games happy.

It's unlikely that a mouse driver would be designed
like that. And I don't think you can set affinity
on a driver anyway. Affinity (a setting also available
in Task Manager), is generally for user space problems.

There are yet other ways to cause or stop stuttering.
The power state (ACPI based) sometimes plays a role.
Say you're watching a movie on an AMD processor, and
you notice a bit of jitter or flutter in the video.
If you select the "Always On" power schema in the Power
control panel, sometimes that stops the problem. In that
case, the processor goes between a high-power and
low-power state, 30 times a second, which has an impact
on video decoding.

But if I try to align your observation, that fooling
with the BCDedit programming of core detection "fixes"
your problem, then it's probably not an ACPI problem.
And the only thing that comes to mind, is maybe
if you had more cores actually detected by the OS,
then were supposed to be there. AMD made some
processors, where for yield reasons they turn off
cores that are "bad" in testing. And some BIOS
are equipped with the means to turn them back
on (so you can test and see if you get a "free"
core out of it or not). This was a technique to
buy a cheap processor, and make a more worthy
processor out of it. If the core really is defective
(which doesn't happen too often), the user would then
turn the "free core" off again.

*******

On Linux, I can get stutter problems, if all of the
available clock sources in the hardware, aren't working
right. If I type a letter on the keyboard, it can
"repeat" multiple times. Sometimes this problem
is bad enough, I can fill a text document with the same
letter typed over and over again, and not be able
to stop it. I haven't run into a situation yet, where
that happened to me in Windows. On Windows, keyboards
"hesitate", and I can have stuff stored in a typeahead
buffer for like five seconds. That's more the style of
Windows problems. Still not your mouse problem though.

You might also check Device Manager in Windows, visit
the mouse, and under the Power Management tab, make
sure both options are turned off. On my current OS,
the option to turn off the mouse to save power, is
grayed out, so I cannot tick it by accident. If such
an option was enabled, that would likely have side
effects.

While you're in Device Manager, have a look around
for anomalies. For example, maybe you see two mice
detected, when only one piece of hardware is present.

I'm just having trouble accepting the solution, as
drivers are relatively high quality, and this
**** works for a *lot* of other people...

And it's a wireless mouse, and I didn't even go
down the fault tree for one of those. Try moving
the mouse receiver, away from any USB3 cabling.

Paul

After a time, the problem seemed to be returning. I had also tried the
following also from the Logitech forum :

" This worked for me. I noticed when my mouse studdered I would here
the hard drive, so it lead me to this area. change virtual memory to
'system manage size'. ........Start , right click computer,
properties, adv sys set, performance settings advanced, vertual memory
change, set system manage size. Hope this works for you. good luck. "

Not sure what will really work.
Any further help would be most welcome & thanks ...

On Mon, 16 Feb 2015 13:53:09 -0500, Stephen G. Giannoni
wrote:

Would develope this problem a couple minutes after startup. Restarting
would remove the problem but only for another couple minutes etc. Saw
this in a Logitech forum :

1. Click the Windows start button.

2. Type msconfig.exe in the "Search programs and files" box.

3. It will require the administrator password to run.

4. Click on the "Boot" tab at the top.

5. Click on the "Advanced Options" button.

6. Make sure that the "Number of processors" is checked. Most
importantly make sure the number of processors matches what your CPU
has! (Dual core = 2, Tri=3, Quad=4, etc. etc.)

7. Hit Ok, and then reboot.

My Number of processors was NOT checked and the number was set to only
1 instead or the correct 2.

This fix worked beautifully !

Stephen G. Giannoni wrote:
After a time, the problem seemed to be returning. I had also tried the
following also from the Logitech forum :

" This worked for me. I noticed when my mouse studdered I would here
the hard drive, so it lead me to this area. change virtual memory to
'system manage size'. ........Start , right click computer,
properties, adv sys set, performance settings advanced, vertual memory
change, set system manage size. Hope this works for you. good luck. "

Not sure what will really work.
Any further help would be most welcome & thanks ...

Again, absolutely no reason for that to make a difference.

First of all, the system would have to be under memory
pressure, to even go near the pagefile. On a daily basis
here, most of the time the pagefile is idle.

If you had 128MB of RAM, and a 6GB page file, I might believe
there was some relationship. But with typical modern
systems (like a Windows 7 system), you're likely to
have a decent amount of RAM. And you haven't described a
particularly stressful (for a computer), set of operating
conditions where the mouse stutter shows up. If it
stutters when no programs are running, and the system
is relatively idle, we need to look elsewhere.

Just going on my recollections here, when the pagefile
unwinds on my WinXP machine, the mouse remains buttery
smooth. The computer continues to service interrupts.
The only way it wouldn't play nice, is if a driver in
control of hardware, was forced to consult a hard drive
that was very busy. And the mouse driver should not
be reading or writing the disk drive, right ? Only when
two processes (say File Explorer and pagefile unwinder)
go at the drive with hammer and tongs, do you notice
things aren't working as well as they should. My current
computer, I can even get the occasional "raspberry buzz"
out of the head assembly, as it makes rapid transitions
from one area of the disk to another. But as a user,
you should recognize when you're forcing the hard drive
to do "two things at once", and it does a poor job of
both of them.

Are the batteries in the mouse in good shape ?

Have you tried the mouse receiver on a USB
extension cable, then wave the extension cable
around a bit and try different positions ?

Have you recently acquired any 2.4GHz appliances ?
There is lots of 2.4GHz emissions out there now.
And the other day when I mentioned the USB3 cable
thing - Intel has a report where they show broadband
emissions coming from poorly shielded USB3 cables
and hardware devices. Intel recommends moving the
cable, if some wireless thing isn't working right.
Because the emissions from USB3.0 cables cover
2.4GHz mice/keyboards rather nicely from
a spectral perspective. The 2.4GHz band is
smack-dab in the middle of the USB3 cable
emissions. The company Intel used to do the
study, recommend better shielding on things
like USB3 hard drive enclosures, as a means
to reduce the level of emissions.

Soon, USB 3.1 standard will be out, and the
frequency will rise again. And then the emissions
will be smack-dab on top of the 5GHz Wifi band :-)
Good times.

Paul