Sluggish mouse response while certain operations are taking place

  • Thread starter Thread starter Rebel1
  • Start date Start date
R

Rebel1

My mouse response (i.e., simply moving the pointer around) gets very
sluggish if certain other operations are going on at the same time. E.g.:

1. If I copy a large file (250 MB) from my hard drive to a USB flash drive.
2. If my antivirus program is downloading updates, especially just after
the system boots.

Also, trying to select or close various open windows on the taskbar
takes many, many seconds as long as the other operation is still going
on. Then the response is generally okay. (Sometimes right-clicking on a
function in Cool Edit is sluggish, but it's been that way for a long time.)

It's like the other operations have a higher priority than the mouse. Is
there a way to increase the priority of the mouse with XP, SP3?

Thanks,

R1
 
Rebel1 said:
My mouse response (i.e., simply moving the pointer around) gets very
sluggish if certain other operations are going on at the same time. E.g.:

1. If I copy a large file (250 MB) from my hard drive to a USB flash drive.
2. If my antivirus program is downloading updates, especially just after
the system boots.

Also, trying to select or close various open windows on the taskbar
takes many, many seconds as long as the other operation is still going
on. Then the response is generally okay. (Sometimes right-clicking on a
function in Cool Edit is sluggish, but it's been that way for a long time.)

It's like the other operations have a higher priority than the mouse. Is
there a way to increase the priority of the mouse with XP, SP3?
Click to expand...

Move the mouse to a different USB port, one that isn't shared with the
USB hard disk or other high-traffic USB device.

One, a USB mouse should *not* be connected to a USB hub. It should be
connected to a case USB port that goes to a USB controller on the
motherboard. Two, each pair of USB ports share the same controller so
their bandwidth is shared. Put the USB keyboard and USB mouse on the
same pair of USB ports (since it's not likely you could ever generate a
high-volume of traffic with your keyboard). Put the USB drives,
printers, and other high-volume devices on different USB ports from the
USB mouse and keyboard.
 
Rebel1 said:
My mouse response (i.e., simply moving the pointer around) gets very
sluggish if certain other operations are going on at the same time. E.g.:

1. If I copy a large file (250 MB) from my hard drive to a USB flash drive.
2. If my antivirus program is downloading updates, especially just after
the system boots.

Also, trying to select or close various open windows on the taskbar
takes many, many seconds as long as the other operation is still going
on. Then the response is generally okay. (Sometimes right-clicking on a
function in Cool Edit is sluggish, but it's been that way for a long time.)

It's like the other operations have a higher priority than the mouse. Is
there a way to increase the priority of the mouse with XP, SP3?

Thanks,

R1
Click to expand...

If you want to test whether it's the OS doing it, you could boot
a Ubuntu CD, then practice copying a large file from the hard drive
to the USB flash. The storage devices are in the "Places" menu, up
near the top. It helps if the partitions on your storage devices, have
labels so you can tell them apart.

If the problem doesn't happen in Ubuntu, but happens in Windows,
then it could be a Windows problem.

(Download the 10.04LTS one, as it has a "normal" desktop interface...
Use Nero or Imgburn, to convert the ~700MB ISO9660 file, into a boot CD.
Don't just try to copy the file to the CD, it needs to be converted,
to make a boot sector and so on. Then boot from the CD and test.
*Don't* select the install option!)

http://www.ubuntu.com/download/ubuntu/download

I had one other dumb suggestion, but I doubt you have the hardware
for it. In a previous post, you asked about a M3A76-CM motherboard,
and it has a COM1 port on the surface of the motherboard. You could
connect a serial RS232 mouse to that connector. It would take
an adapter plate and ribbon cable to do it. But the odds of you
actually owning a serial RS232 mouse to test with, are pretty
low, and you also can't buy those new anymore. Ebay or Amazon
may have old stock ("deletes") from some store they're trying
to get rid of. I own a serial mouse I got about ten years ago,
and I found it in the "junk barrel" at my local computer store.
I was quite pleased to get such a relic for my collection :-)
Otherwise, I'd have never got to see one. Those mice would have
a nine pin connector on the end (D-sub).

It's too bad your motherboard doesn't have a PS/2 mouse port. That
would likely have fixed it. My current motherboard doesn't
have a PS/2 mouse port either, but it hasn't given me any grief.

http://images17.newegg.com/is/image/newegg/13-131-376-S02?$S640W$

Paul
 
Move the mouse to a different USB port, one that isn't shared with the
USB hard disk or other high-traffic USB device.

One, a USB mouse should *not* be connected to a USB hub. It should be
connected to a case USB port that goes to a USB controller on the
motherboard. Two, each pair of USB ports share the same controller so
their bandwidth is shared. Put the USB keyboard and USB mouse on the
same pair of USB ports (since it's not likely you could ever generate a
high-volume of traffic with your keyboard). Put the USB drives,
printers, and other high-volume devices on different USB ports from the
USB mouse and keyboard.
Click to expand...

The receiver for my wireless mouse and the USB flash drive were both
plugged into a pair of adjacent USB connectors on the front of my
desktop tower computer. I moved the mouse receiver to one of the rear
USB connectors and when I repeated the transfer of a large file to the
flash drive on the front of the computer, the rest of the system
performed at its usual speed.

As an aside, I do not use a USB keyboard.

Thanks.

R1
 
VanguardLH offered simple advice that solved the problem without having
to change the OS or using a RS232 mouse, which I don't have. Thanks
anyway for the feedback.

R1
 
Rebel1 said:
VanguardLH wrote:
....


The receiver for my wireless mouse and the USB flash drive were
both plugged into a pair of adjacent USB connectors on the front
of my desktop tower computer. I moved the mouse receiver to one
of the rear USB connectors and when I repeated the transfer of a
large file to the flash drive on the front of the computer, the
rest of the system performed at its usual speed.
Click to expand...

Are you trying to say that the advice you were given worked?

--
 
Rebel1 said:
VanguardLH offered simple advice that solved the problem without having
to change the OS or using a RS232 mouse, which I don't have. Thanks
anyway for the feedback.

R1
Click to expand...

I'm really surprised it's a USB sharing problem.

*******

USB sharing occurs at two different ratios. Devices running at USB2
rates, they're shared over as many as six ports. My chipset has two
USB2 masters for a total of 12 ports for example. If I had a conflict
between two USB2 devices, I'd have to move them so they were on
different masters.

USB2_host USB2_host
| | | | | |
/ \ / \ / \ / \ / \ / \

Traditionally, USB1.1 sharing is in pairs of two. And also, the pairs
of two are arranged in stacks. So if you're looking at the back of the
computer, the ports in twos, they could be sharing when tun at USB 1.1
rates. On my machine, the mapping would look like this

USB1.1_host USB1.1_host USB1.1_host USB1.1_host USB1.1_host USB1.1_host
| | | | | |
/ \ / \ / \ / \ / \ / \

If you placed a USB keyboard and USB mouse, one above the other,
I would not have expected enough bandwidth usage from those two,
to interfere with one another. If you placed a USB key above the
USB mouse, and the USB key only supported USB 1.1 rate transfers,
then that could cause a sharing problem.

But normally, a USB key would support USB 2.0. And in a sense, if
you placed a USB 2.0 key above a USB 1.1 mouse, they'd be on different
masters, and there shouldn't be a sharing issue. (When a device is
plugged in, the negotiation sequence moves the device to the
appropriate tree. Either the top row or the bottom row.)

USB2_host USB2_host
| | | | | |
/ \ / \ / \ / \ / \ / \
|
key(2.0)

USB1.1_host USB1.1_host USB1.1_host USB1.1_host USB1.1_host USB1.1_host
| | | | | |
/ \ / \ / \ / \ / \ / \
|
mouse(1.1)

To complicate matters, AMD, in some of the more recent chipsets,
changed the ratio on USB 1.1 ports, to three ports per master.
So if you had a USB 1.1 sharing problem, there is no longer a
simple mapping between "masters" and "stacks". You'd need to use
UVCView to tell which master was controlling which port - and
the port mapping would only be apparent as you plugged a test
device into each port, and watched where it showed up in the
UVCView window.

(Modern AMD chipset, 4 USB 1.1 masters for 12 ports)

USB1.1_host USB1.1_host USB1.1_host USB1.1_host
|___________ ___________| |___________ ___________|
/ \ / \ / \ / \ / \ / \
1 2 3 1 2 3 1 2 3 1 2 3

So all in all, I wouldn't have suspected that sharing was the
problem. Storage devices tend to be USB 2.0 capable, and
they should only really interfere with other USB 2.0 capable
devices. You'd have to be doing an external USB disk to
external USB disk transfer, to notice that moving one of the
disks to the other set of six ports, made a difference.

And on USB 1.1 devices, generally there isn't enough traffic
to get even near to the 1MB/sec transfer rate. You'd need a
USB 1.1 webcam to bollox up the works. Or an ancient USB 1.1
key (there were some of those). There are also some USB 2.0
keys with less than 1MB/sec transfer rates, but such a device
wouldn't count (it only gives the impression it is running
at USB 1.1, when in fact the flash chip is slowing down the
USB 2.0 transfers - UVCView will tell you what it is really
doing).

On very old motherboards and chipsets, we used to see interrupt
sharing issues. USB masters use interrupts too, to alert the
processor when service is required (i.e. the last command to
send a polling packet, has come back). In my Device Manager
resource view, I have lots of sharing going on, and I've never
seen an impact from sharing. For example, reading or writing
my SATA drives, doesn't upset my audio (which is on the same IRQ).
Being on the same IRQ, means that the IRQ chain must be
checked in software, until the interrupting thing is
identified. That means there is some serialization, and the
second thing checked might see a slightly longer delay before
it gets serviced. But I've never seen any evidence here,
that it makes a difference. That would be down in the microsecond
range. It might, if the processor was a lot slower, or if there
wasn't an IOAPIC to steer the interrupts to different cores.

(You'll notice only five USB1.1 masters are listed here. And
only five pairs of ports are accessible in total on the motherboard
PCB. So the BIOS must have turned the sixth unused one, off.)

http://img521.imageshack.us/img521/2216/devman.gif

Here, you can see my UVCView, with some USB devices visible. Entries
for devices only appear, if you have a peripheral plugged in. I have
two USB to RS232 converters and a USB mouse. Physically, they're
all on different stacks on the back (purely by accident). I haven't
used the RS232 converters in some time, so they're normally quiet.

http://img41.imageshack.us/img41/8439/uvcviewed.gif

You can have sharing issues, but it would take careful planning
to get just the right combination of USB stuff, to do it. Maybe
plugging a USB 2.0 webcam, into the same "master of six" as
a USB 2.0 external hard drive, would be enough to do it (cause
dropped frames on the webcam, if the disk was storing the
stream - the webcam stream is generally compressed now as it's
travelling over the wire, which helps reduce the impact). But
finding enough ancient USB 1.1 devices to screw things up, would
take a lot of luck to get just right.

Paul
 
Paul,

Thanks for the excellent tutorial. Maybe I inadvertently did something
else, but right now everything is working fine.

Ray
 
Back
Top