# MouseTester Software



## microe

I wrote this to be a simple mouse testing software that has built-in plotting, CSV save and load, and plot export to PNG capability.

Full source code can be found on GitHub, just search for MouseTester by microe1.

It uses an open source (MIT License) plotting library called OxyPlot that can also be found on GitHub.

Requires the Microsoft .NET 4 Framework. You will need to have this framework installed to run, can be found on Microsoft's site.

Built-in plotting includes:

Raw counts vs time = for detecting limited data paths and skipping counts (e.g. 8-bit reporting that caps at +/- 127)
Update time per report = for detecting unstable polling rates (on my system it can do 1 ms reliably, YMMV)
Velocity vs time (calculated based on cpi) = for tracking speed type measurements
Raw X-Y count plotting = for acceleration, jitter, and angle snapping testing, plots a path based on raw counts

MouseTester_v1.1.zip 147k .zip file


Changes in v1.1, February 15, 2015

Fix for log file save region decimal symbol
Added logging mode
Set processor affinity to core #2

MouseTester_v1.2.zip 148k .zip file


Changes in v1.2, July 29, 2015

Fixed up description handling for plot and save
Report total number of events collected
Report X/Y displacement from start in counts and distance
Report piece-wise linear total path length in counts and distance
Added line / stem options to plots

Last Updated January 28, 2021
Changes in v1.4

Updated to Visual Studio 2019 and .NET Framework 4.6
Modified RAWINPUT to work with x64
QueryPerformanceCounter replaces Stopwatch
Minor aesthetic changes to plotting
8ms time window average replaces 8 sample window average
Added keyboard shortcuts to Start/Stop/Plot
Modified RawInput handling
I couldn't upload the .zip, so grab it from GitHub: MouseTester_v1.4.zip


----------



## microe

*Basic Instructions*

First, specify the resolution of the mouse by either typing in a value or by clicking the Measure button and following the instructions in the text box at the bottom. Helpful hint, the program does not intercept clicks or movements from the system so I usually just click in the text box area when starting the data collection.

Second, collect some mouse data by clicking the Collect button (or the Log Start button) and following the instructions in the text box at the bottom.

After that you can Plot the data you have collected using the specified cpi for calculations.

You can also save and load your data to .csv for future reference or importing into other programs like excel or [R] etc...

As far as the plots are concerned, first thing I do is window the data (to hide the garbage at the beginning and end of the collection) using the Data Point Start and Data Point End. From there it depends on the movement that was recorded. Here are some examples:

Count vs. Time: This is for looking at the raw counts from the mouse. The line is a moving average of the data and is provided as a general reference to gauge the consistency of the reporting from the mouse. For a mouse that does not loose tracking you will see the counts generally bouncing above and below the line without much deviation. If the counts deviate too much from the line then the mouse tracking may not appear smooth. If the mouse looses tracking then you will see the counts go erratic. You can also sometimes see angle snapping / prediction here (the counts will go to zero and hold there even though you moved the mouse with a slight arc). You can also see data path clipping here if the data plateaus at a fixed value (e.g. 127 for 8-bit mice). If the mouse is performing some form of multiplication for cpi boosting then you may be able to see that here as skipped counting steps.

Velocity vs. Time: This uses the time interval between updates, the cpi, and the counts to calculate the velocity of the mouse movement. Using fast swipes you can try to get the malfunction rate of the mouse here. Just like Counts vs. Time going erratic, when the tracking is lost the velocity goes erratic as well.

Interval vs. Time: This is for checking the consistency of the update rate from the mouse (i.e. 1000 Hz mouse updates every 1 ms).

X vs. Y: This is just plotting the data that you collected as a path. Like paint testing you can draw arbitrary shapes and see the exact raw mouse reports (e.g. jitter, angle snapping, stair stepping, etc...). Arbitrary movements can be used for acceleration and accuracy testing using this kind of plot as well. For example accuracy can be tested by starting from some point "A", moving the mouse (e.g. varying speed / angles) and then returning to point A. You should see the path that you moved the mouse along with the start and end points being roughly the same. You can do fast swipe / slow swipe back to the same point movements for acceleration testing. You can also do things like move the mouse in a bunch of circles and seeing if the path drifts away.


----------



## microe

*FAQ*
Quote:


> OMG this is a virus!


Some anti-virus software will flag this program because it probably looks like a keylogger and/or because of the hooks into win32 libraries. Full source code is available in case you want to compile your own binary. All you need is the (as of this post still available and still free from Microsoft) Visual C# 2010 Express.


----------



## microe

*Known Issues*

Windows region settings can cause issues with import and export of log files when comma is used as the decmial symbol. *Fixed in v1.1*

Description not applied to save / plots. *Fixed in v1.2*


----------



## microe

*Other Notes*

Mice have some characteristics that we have in general classified using the following terms:

*Tracking Speed:* Moving the mouse quickly is reported correctly by the mouse. Some mice when you move them too fast will lose tracking and either stop reporting entirely or spaz out and give you random reports or cap out at some count.

Move the mouse very quickly and look at the velocity. In general you should see a curve that is unbroken and maybe has some jitter at high speeds. If the velocity drops to zero or there is some garbage then the mouse lost tracking. The highest velocity along the curve that still looks okay is in general the max tracking speed. Some mice the top of the curve is a plateau, this is indicative of internal data path saturation in the mouse sensor or firmware which results in negative acceleration. Others have used Enotus in the past, but without the data curve plotted you can't see if Enotus is falsely reporting because of some garbage or jitter from the mouse.

*Acceleration:* Moving the mouse the same distance fast results in different total reported counts than when we move it slow. Can be positive (moves farther the faster the mouse moves) or negative (moves less the faster you move the mouse).

Move the mouse fast in one direction and then move the mouse slow back to exactly the original position. If you plot the X-Y you should see the mouse counts return exactly back to the origin. You can also do this test in game and there are some youtube videos of in-game tests.

*Jitter:* Moving the mouse in a relatively straight line results in an inconsistent (random staircase) movement.

Move the mouse slowly in a diagonal motion and view the data in the X-Y plot. You are looking for big stair-step or non-linearity along the path. Look around for old Razer Abyssus paint plots.

*Angle Snapping/Prediction/Drift Control:* This one has been called a few things but in general it is the mouse reporting straight line movement even when the user might have meant to draw a slight angle or curve.

You can sometimes see this during the fast swipes for max tracking rate. The "Y" reports from the mouse will go to zero and hold there (which is highly unlikely from swiping your mouse fast). The other way is to draw a circle and see if the mouse "forces" a straight line. People have done this in paint or you can do this with the X-Y plot and capturing a circle. One of the nice things with my tool is you can draw the shapes in paint and then plot the corresponding raw data with my tool, as long as it is one complete motion and you hold the button down the entire time.

*Excessive Anti-Jitter:* Moving the mouse slightly or very slowly from a standstill may result in a delay or no movement registration. Move the mouse very slowly and see what the counts reports look like. This one is kind of hard to test.

*Polling Rate Consistency:* Move the mouse and see if the report rate from the mouse is consistent at the supposed setting (125, 500, 1000 Hz). Some mice have had a problem with 1000 Hz in the past.

Just move the mouse around and plot the interval. It should be a relatively straight line at the desired report rate. 1ms = 1000 Hz of course. There are other report rate measuring tools out there.

*Interpolation:* Scaling the counts from a mouse to one that is not native to the sensor. Magnified counts is a form of interpolating CPI up, while halving counts can be seen as a form of interpolating down. Doesn't have to be a power of two, can be any factor since it's just math. Mouse driver sensitivity slider is a form of interpolation that runs on the PC.

This one you can't really see with my tool alone. If I had an oscilloscope and captured the communications from the sensor to the mouse microprocessor and compared that to the counts from the microprocessor reported to the PC then I could see if the mouse microprocessor is interpolating the data.

*Measuring CPI:* 400 DPI/CPI isn't necessarily 400 CPI! Due to manufacturing tolerance and other factors the CPI that you set may not be exact. You can use my tool to measure the "real" CPI and compare that to the "desired" CPI setting. Some mice are way off, others are dead on. Ruler + counts doesn't lie, but of course take into account human error and maybe do some averaging. Moving the mouse quickly is reported correctly by the mouse. Some mice when you move them too fast will lose tracking and either stop reporting entirely or spaz out and give you random reports or cap out at some count.

Move the mouse very quickly and look at the velocity. In general you should see a curve that is unbroken and maybe has some jitter at high speeds. If the velocity drops to zero or there is some garbage then the mouse lost tracking. The highest velocity along the curve that still looks okay is in general the max tracking speed. Some mice the top of the curve is a plateau, this is indicative of internal data path saturation in the mouse sensor or firmware which results in negative acceleration. Others have used Enotus in the past, but without the data curve plotted you can't see if Enotus is falsely reporting because of some garbage or jitter from the mouse.

*Smoothing/Frame-Induced Delay:*This is a new one that has come up recently but unfortunately it is very difficult to measure, the following is my somewhat simplified understanding of the process. The mouse sensor acquires images of the surface called "frames". The frame rate of the sensor may or may not be constant. There are signal processing algorithms that takes these frames and translates them into counts. Depending on the signal processing algorithm there is an inherent latency from when the movement occurs to when the sensor has the counts available in the motion registers (frame delay). These counts are acquired from the sensor by an external microcontroller which accumulates these counts, optionally does some additional processing, finally sending a value to the PC on the next USB poll. Measuring these delays would take specialized equipment.

It may be possible to test the relative mouse to PC delay with a modification to the software so that it captures data from two mice simultaneously and stores the results on a per mouse basis. There is some normalizing of counts so you can compare the movements accurately on the time scale. You can probably get relative time to within a millisecond or so before the PC / USB polling rate becomes the limiting factor.


----------



## povohat

Thank you for this invaluable utility


----------



## acid_reptile

Very informative. Thanks for the effort. Added for later read.


----------



## S02

Oh wow! with the x vs y plot, I can draw things! =P

Anyways, my update time only varied at the start where I drew triangles. But circles, figures of 8, horizontal and vertical, are all at 8. Update time 8 and Time has 8ms gaps. So my mouse is 8ms?


----------



## microe

8 ms between updates so 125 Hz polling rate (updates per second).


----------



## S02

Ahaha, I was wondering why my mouse seemed different the last month, was checking out the lazer version of this mouse. Classic, I started using the optical due to precision and being able to handle 500hz, could possibly do more, but 2ms is all good. Nice app, if it wasn't for this I wouldn't have known that it reset to 125hz, just proves it works.


----------



## HAGGARD

From looking at the source code, am I right in assuming the program relies on the raw input model (WM_INPUT messages) rather than fetching Windows input reports (WM_MOUSEMOVE)?


----------



## microe

Yes, it uses raw input.


----------



## HAGGARD

Great.

Something you might want to include in your guide is the possiblity to zoom in on the graphs. You can naturally do that using the start and end points, but I think many people will find it more comfortable clicking on the part they want to zoom in on and using the scroll wheel. I found out that you can do that and didn't see it mentioned here. Just hold down the mouse wheel (MOUSE3) and move your mouse to zoom in on a specific area or click with left mouse click and scroll up/down.


----------



## Boinz

This is my G400 (apparently its the angle snapping version, no enhanced pointer precision) with 400 dpi going through 1000-125hz polling rate. I tried some wild movements as well as a few moderate ones.


----------



## HAGGARD

Would it be possible for you to slightly change the OxyPlot implementation so that the graph style can be changed (dot, line, bar, etc.)?

Thanks!


----------



## thuNDa

it would be nice, if it could collect the mousedata without the need to keep the button pressed.
so it can record the movement while you are actually ingame.


----------



## Ino.

Quote:


> Originally Posted by *thuNDa*
> 
> it would be nice, if it could collect the mousedata without the need to keep the button pressed.
> so it can record the movement while you are actually ingame.


Someone already did that modification with the source code, I don't remember who though. But I have a version of the software that does just that.


----------



## HAGGARD

Mind uploading it some place?

Would definitely be nice to have.


----------



## Ino.

Quote:


> Originally Posted by *HAGGARD*
> 
> Mind uploading it some place?
> 
> Would definitely be nice to have.


I'll look into it, but not at my home PC now.


----------



## VolsAndJezuz

Love this program. Easily the most versatile and useful mouse program I have. Though I'm not sure about it's polling rate monitoring accuracy and prefer MouseMovementRecorder for that.

One other tweak I would recommend for the graphing is to allow for expanding the y-axis (x-axis can be adjusted with scroll wheel as someone else mentioned, or PgUp PgDn I discovered) because sometimes data points that coincide with the top minor y axis aren't plotted.

Also, maybe try a slightly less aggressive averaging calculation for 1000Hz because I find that the trend line is much more erratic with that many data points, which can be misleading in some situations, particularly to new users of the program.


----------



## microe

New version released, see OP.


----------



## VolsAndJezuz

Being the last post before the update announcement, I credit myself for providing the motivation to release a new version. You're welcome everyone









Testing out the new update now. Will report back shortly. Thanks for your hard work!


----------



## Azrael1111

Can you help me understand what is going wrong with my tests? Both have these clusters of repeated points which I don't see on other peoples tests.

logfile.csv 6k .csv file


(500 hz 1150 dpi on Zowie EC2 and 500 hz 1800 dpi on Razer Abyssus 2014)


----------



## thuNDa

Quote:


> Originally Posted by *Azrael1111*
> 
> Can you help me understand what is going wrong with my tests? Both have these clusters of repeated points which I don't see on other peoples tests.


that's because you move very slow, while you see the other tests showing rather fast swipes usually.


----------



## Aventadoor

How do you actually read the graphs in order to check wether its good sensor performance or not?
If the dots arent in line with the line, its not good?


----------



## Ino.

Quote:


> Originally Posted by *Aventadoor*
> 
> How do you actually read the graphs in order to check wether its good sensor performance or not?
> If the dots arent in line with the line, its not good?


I only use it to confirm the PCS.
To truly test for optimal performance you'd have to measure the actual movement and acceleration of the mouse and compare that to what the PC receives. Quite impossible for anyone without a real test bench.


----------



## HAGGARD

microe gives you hints as to how to interpret the readings in the opening posts.
But as Ino rightly says, it's impossible to draw definite conclusions when you don't have perfect control over the mouse movement itself. Without a proper setup you should read the graphs as something approximative or indicative.


----------



## thuNDa

FYI, after i disabled C2-state in BIOS, i now also get usefull plots in the "xVelocity vs. Time" section, where it often registered single counts at unrealistic high m/s before, which rendered the graph useless.


----------



## doomleika

Quote:


> Originally Posted by *Ino.*
> 
> I only use it to confirm the PCS.
> To truly test for optimal performance you'd have to measure the actual movement and acceleration of the mouse and compare that to what the PC receives. Quite impossible for anyone without a real test bench.


Smooth curve could mean high in-built smoothing aswell.


----------



## Ino.

Quote:


> Originally Posted by *doomleika*
> 
> Smooth curve could mean high in-built smoothing aswell.


But they can also mean highly accurate tracking... So in reality they don't tell much.


----------



## HAGGARD

I would be inclined to think overly smooth graphs with hand movement indicate data correction (anti-jitter/noise, prediction, averaging/smoothing etc.) especially in terms of high speed response while with controlled movements smooth graphs should be what you are looking for.

Recently took a record player apart to get it workable for tracking tests, screwed it in the process but not beyond repair. Need to invest some more time there and come up with a fixture for multiple mice as well. The logging feature helps with these tests, but it would be even better if we had the possibility to feed the plotter with data real-time @ microe


----------



## a_ak57

Quote:


> Originally Posted by *doomleika*
> 
> Smooth curve could mean high in-built smoothing aswell.


Are there actually examples of this or are you just theorizing? The tight curves I've seen have been from well-performing mice.


----------



## doomleika

Quote:


> Originally Posted by *a_ak57*
> 
> Are there actually examples of this or are you just theorizing? The tight curves I've seen have been from well-performing mice.


theorycrafting that is, it's not that hard to figure out.

Smooth curve is good became we can't cheat physics when we move. there will always wind up and slow in cursor movement down as our hand trying to move the mass of mouse. Test like this made easy for us to spot jitter because jitter essentially means spike in outputs

It goes the other side to smoothing since smoothing will try average out current value with past data. This guarantee a smooth curve.

The only was to detect smooth is compare time or outside position delta with cursor delta computer received at the same time. A feat impossible without precision machinery.


----------



## jubi

This is my KinzuV2.
Is it really that bad or am I misinterpreting what is bad and what is not bad?


----------



## qsxcv

check the polling rate stability


----------



## jubi

My polling rate differs rom ~5 to 1000 hz, but thats normal, right? (slow mouse movement = low hz, fast movement = high hz)
Starting from certain speed it is always between 900 and 1000 hz.


----------



## HAGGARD

Instead of willy nilly moving your mouse slow and fast for a few seconds, it is better for these measurements to just swipe fast once and plot that. You can also swipe fast right, fast left, fast right, fast left, etc. but then you have to adjust observation points for each swipe.


----------



## qsxcv

i did some tests slamming a dead g100s onto the wmo.

the interval is immediately 1ms, which suggests that it wakes up pretty much instantly.


----------



## HAGGARD

hm, didn't consider that I maybe don't hit required speeds for 1ms report rate instantly, but I also just slammed another mouse and still got 2ms at the start. Did you like, slam it in there at 2+m/s? I don't want to destroy my mouse ha.


----------



## qsxcv

no i just click with another mouse, and slam the wmo with a g100s shell at around 0.5-1m/s

given how stiff the shells are, the contact time is probably less than 1ms

if you slam it too hard it could malfunction immediately though


----------



## HAGGARD

you're right. Just hit it with my hand and it starts reporting at 1ms immediately. Welp, that means the 2ms readings I always get when I move the mouse are really because I'm not instantly fast enough.
Will do the same with the G400, because I drew preliminary conclusions about idle fps=buffer fill rate = report rate primarily from the 3090 spec.


----------



## HAGGARD

okay, the G400 reports at 1ms instantly as well. The very first input can still be delayed depending on time relation X initial movement Y subsequent frame, so a higher frame minimum could still be beneficial for that, but this confirms that at the latest the second input is generated <1ms after the first on initial motion.
Seems like power states don't matter after all, at least not when the usb hub and host are not also suspended.


----------



## HAGGARD

BTW.: You can just use UsbTreeView to get the current and supported power states *http://www.uwe-sieber.de/usbtreeview.html*:



The WMO does not exit D0 when it goes low strobe. Pretty strange seeing as how disabling the HID driver causes the LED to always be at full duty, but whatever. Use F5 to refresh, you can also look at the host to count interrupts, usbframes, bandwidth used. Or the hubs to see highspeed support etc.


----------



## Brightmist

Spoiler: Warning: Spoiler!



Quote:


> Originally Posted by *HAGGARD*
> 
> BTW.: You can just use UsbTreeView to get the current and supported power states http://www.uwe-sieber.de/usbtreeview.html:
> 
> 
> 
> The WMO does not exit D0 when it goes low strobe. Pretty strange seeing as how disabling the HID driver causes the LED to always be at full duty, but whatever. Use F5 to refresh, you can also look at the host to count interrupts, usbframes, bandwidth used. Or the hubs to see highspeed support etc.






If we had the means to see the raw data going back and forth between the mice and PC using an USB Bus Analyzer (be it hardware or software) would've been nice. That way we can comment more precisely if the power/suspend states are causing bit of input lag or not.

As I understand if the LPM for USB2.0 is working properly, the delay should be in double digit microsecond range but if it's not, we might be looking at double digit milliseconds of lag.


----------



## HAGGARD

Quote:


> As I understand if the LPM for USB2.0 is working properly, the delay should be in double digit microsecond range but if it's not, we might be looking at double digit milliseconds of lag.


Why? MSDN says changing states takes a few microseconds up to milliseconds, but changing power states only regulates supply, not polling. On the device side there's reduced framerates and those do indeed induce random latency up to frame interval (depending on what their idle framerate is fixed at). So that's currently the only reason I see why keeping the device in an active power state with higher base framerates could be beneficial.

Quote:


> If we had the means to see the raw data going back and forth between the mice and PC using an USB Bus Analyzer (be it hardware or software) would've been nice. That way we can comment more precisely if the power/suspend states are causing bit of input lag or not.


Indeed, treeview unfortunately does not precisely if at all respond to transfers in the 4-8byte range commonly seen with HID. Usb frame counter doesn't tell us all that much except that you have 1000 polls per second constantly (with only 1 1000Hz polled device connected of course), regardless of moving the mouse or not.

Not too sure if the current power state given by it can be trusted as I have yet to see any device with anything else than D0, but once we have at least 1 that changes states in there we can trust the value and then also look at usb frame count to see whether suspended device/hub/host change poll behaviour.


----------



## Brightmist

Because LPM might just not be working properly for USB2.0 mice on the early implementations of USB 3.0 ports considering it got changed for USB3.0 (extra low power states added to it)

And MLT04, which is praised by many here, was produced before LPM existed therefore might not be using any kind of power saving and Finalmouse which is obviously lacking power saving features is also favorited similiarly by the people here therefore makes me think it might be at the core of this responsiveness issue since it introduces a constant low power state just as the mouse stops moving.


----------



## jubi

Quote:


> Originally Posted by *HAGGARD*
> 
> Instead of willy nilly moving your mouse slow and fast for a few seconds, it is better for these measurements to just swipe fast once and plot that. You can also swipe fast right, fast left, fast right, fast left, etc. but then you have to adjust observation points for each swipe.





Still not good.
Maybe the kinzu v2's sensor is just bad?
I tried it also on different surfaces, still the same.


----------



## Nandorr10

Hi! What does these weird lines mean? Sensor problem or what? Only at small, fast moves. Actually it's wrong? Zowie ZA13


----------



## qsxcv

make sure you dont have another mouse connected


----------



## Nandorr10

Only this mouse connected and I have uninstalled the older mouses' drivers.


----------



## qsxcv

probably because two points are two close. if you look at xcounts it should be smooth

more likely to be an issue from your system than from the mouse


----------



## Nandorr10

Yes xcounts is smooth. So I shouldn't be worry about it? Or the sensor doesn't work perfectly?


----------



## microe

I wouldn't worry about it if your xcounts is smooth. Sometimes you get two counts that are very close in time and it causes these spikes in the velocity calculation.


----------



## Nandorr10

Okay thank you


----------



## dobragab

Hello everyone, hello microe,

I just registered to OCN, however, I've been reading mouse reviews for a long time. We use MouseTester in a hungarian IT forum, at *prohardver.hu* a lot. Awesome stuff! Thanks for letting us use it, and browsing the source.

But there's an annoying bug. You can enter Description on Form1 but the it doesn't appear on the Plot screen, or even at the PNG. However, the code is ready for that feature, but the setter of MouseLog.Desc is wrong, and needs adding one line in buttonPlot_Click().

I would push these changes to GitHub with pleasure, but as I saw, it isn't up-to-date, not the source of v1.1. Could you update it please?

Also, you should note that on WinXP you need to install the patch for .NET 4 March, 2011 for proper working. (An unhandled exception occurs at plotting, because it can't find System.Core 2.0.5.0, the patch fixes the missing DLL.)

Thanks,

dobragab


----------



## microe

Thanks for the feedback. I had already planned some minor tweaks and fixed the description stuff while I was at it. Will update the source soon, enjoy.


----------



## thrillhaus

So is the DPI calculator using 10cm or 4 inches?

You should probably edit the text to one or the other since they aren't the same thing and I don't know anybody who doesn't have a ruler with both units.


----------



## dobragab

Quote:


> Originally Posted by *thrillhaus*
> 
> So is the DPI calculator using 10cm or 4 inches?
> 
> You should probably edit the text to one or the other since they aren't the same thing and I don't know anybody who doesn't have a ruler with both units.


Code:



Code:


this.mlog.Cpi = Math.Round(Math.Sqrt((x * x) + (y * y)) / 4.0);

Measured counts are divided by 4. Thus, you should move 4 inches, which is 10,16 cm. If you move 10 cm, you move only 98,43% of the desired distance, so for example you will measure 787 DPI instead of 800. I think this is acceptable error, since your hand is not so perfect. I think little rotating of the mouse can lead to similar amount of inaccuracy. Actually, the text should be fixed indeed.


----------



## daunow

Anyone willing to explain how to use this, do I need to have windows default settings like Pointer Enhancement?

or do I just run the program and move my mouse?


----------



## qsxcv

it reads motion counts using raw input, so windows settings don't matter


----------



## softskiller

Click collect, draw fast circles, click plot, chose interval vs. time, remove strange data points at beginning and end, try to minimize the deviation with Windows and BIOS settings and retry. Things with strong influence: different C-States in BIOS and activation/deactivation of USB3.0.


----------



## dobragab

Thanks microe! Saw the v1.2 in first post, useful new features.

Could you update the source on github as well?

Thanks!


----------



## dobragab

Thanks for the updated source, too!

Before you updated the source, I found your notes:
Quote:


> *Smoothing/Frame-Induced Delay:*This is a new one that has come up recently but unfortunately it is very difficult to measure, the following is my somewhat simplified understanding of the process. The mouse sensor acquires images of the surface called "frames". The frame rate of the sensor may or may not be constant. There are signal processing algorithms that takes these frames and translates them into counts. Depending on the signal processing algorithm there is an inherent latency from when the movement occurs to when the sensor has the counts available in the motion registers (frame delay). These counts are acquired from the sensor by an external microcontroller which accumulates these counts, optionally does some additional processing, finally sending a value to the PC on the next USB poll. Measuring these delays would take specialized equipment.
> 
> It may be possible to test the relative mouse to PC delay with a modification to the software so that it captures data from two mice simultaneously and stores the results on a per mouse basis. There is some normalizing of counts so you can compare the movements accurately on the time scale. You can probably get relative time to within a millisecond or so before the PC / USB polling rate becomes the limiting factor.


So I had the v1.0 source, I implemented it. The new code, and GUI modification is ****ty actually, I didn't care much because it worked just for checking if method is possible to implement. I will make these changes on v1.3 soon, but I needed to do some code cosmetics. Already sent a pull request for those.

So I'll create a nice GUI for the input lag measurement on v1.3 soon, but here's a preview of that, what it's capable of. I moved G100s and Salmosa together, clamped them while Collecting, this is the result.

Don't forget: this is also capable of measuring positive acceleration: just hold them together, and you will see accel in the graphs


----------



## qsxcv

are you doing something like this:
*http://asawicki.info/news_1533_handling_multiple_mice_with_raw_input.html*
?


----------



## dobragab

Exactly, however, it is in C# so looks a lot different 

Winapi usage is implemented by microe, raw input handling was ready for this feature.

_deviceHandle is a handle that lets you distinguish which mouse generated this event._

Even deviceHandle was collected properly.


----------



## daunow

anyone willing to tell me how to use this thing, want to see if my deathadder is running good, because it feels like I have a rock on my hand, can't barely move to the sides or do a 180 on some games, making the sense or dpi higher just makes me it feel like its too high. tl;dr there is just no consistency


----------



## dobragab

The graph is OK since you moved the mouse really slowly. Try moving it really fast.

What DA is that? Use them on following DPI:

3G: 800
3.5G / BE: 1800
2013 / 4G / Chroma: 800 (I recommend)

For 3.5G / BE use Legacy driver, not Synapse.


----------



## daunow

I am using Death Adder Chroma

Higher speed.


----------



## TriviumKM

Quote:


> Originally Posted by *daunow*
> 
> I am using Death Adder Chroma
> 
> Higher speed.


Still looks like you're swiping a tad too slow; Do 1 fast swipe left to right.
Post the xvelocity vs time graph rather than the count vs time one.


----------



## 1conu59

Hi !

I made a comparaison from the "famous" *Newmen GX1-Pro* and the *KANA V2*. For those who don't know Newmen is a chinese mouse manufacturer who simply copy the Kana V2 from steelseries, promissing the same performance with a much lower price.

The two mouses are suppose to be the same except few outside improvement for the Newmen (new buttons, new color) but the sensor should be the same : The Avago A3090.



So I made 10 realy fast left/right movements and check for some irregularity. Let's see what the result here with this software :

*STEELSERIES KANA V2*



*NEWMEN GX1-PRO*



So what I noticed is some spikes just after the curve went down for the Newmen. Does it indicate some tracking lose ?


----------



## qsxcv

can you post a log file with that phenomena


----------



## 1conu59

Sure ! Hope I did it right..









Newmen_GX1.csv 85k .csv file


Newmen_GX1_2.csv 76k .csv file


----------



## 1conu59

Quote:


> Originally Posted by *qsxcv*
> 
> can you post a log file with that phenomena


So what about them ?


----------



## qsxcv

the dips line up with skipped usb reports (see the interval plot in mousetester)

the fact that it doesn't drop completely to 0 but always halfway and then rises back up smoothly indicates it has mcu filtering/smoothing like the finalmouse,azio exo1, and some others

in other words, the firmware sux


----------



## 1conu59

Quote:


> Originally Posted by *qsxcv*
> 
> the dips line up with skipped usb reports (see the interval plot in mousetester)
> 
> the fact that it doesn't drop completely to 0 but always halfway and then rises back up smoothly indicates it has mcu filtering/smoothing like the finalmouse,azio exo1, and some others
> 
> in other words, the firmware sux


The firmware from the newmen mouse ?


----------



## qsxcv

ya


----------



## navjack27

so is everything working right? i know thats a dumb question. but i just got a g303. everything feels okay. but here are my results with making quick circles.

400dpi 1000hz tracking enabled and tuned (might disable that tuning thing)


----------



## 7onoff

When i move mouse quicker than 0.2m/s i have perfect update time


----------



## Twiffle

Pictures of me testing my ZA12 and EC2-A is this bad?


----------



## Melan

No. You're just doing it wrong.

First of all, for xCounts and velocity do a fast long swipe.
For polling, move mouse in circles for about 3 seconds and then change graph start position from 0 to 50 or 100.


----------



## DrSebWilkes

Could someone explain to me how to interpret count graphs? I can't figure them out ...


----------



## rivage

Hi guys, C-states enabled, USB 3.0 disabled, Synapse uninstalled. DA 2013.

Was wondering whether my results are ok.


----------



## Ufasas

Is it possible to have this feature: you turn on mouse tester and turn on game, for example quake 3, how to register all speeds in app during 10-15-45mins of gaming without pressing mouse1, just launch app to log the speeds?


----------



## qsxcv

yes. download the latest version in op. just click log start


----------



## dobragab

MouseTester v1.3 is ready.

MouseTester_v1.3.zip 146k .zip file


It is capable of displaying two devices, and there's an option to display them with some delay. Thus, you can *measure input lag!*

Also added a graph: Frequency vs. Time.


----------



## FreeElectron

Quote:


> Originally Posted by *dobragab*
> 
> MouseTester v1.3 is ready.
> 
> MouseTester_v1.3.zip 146k .zip file
> 
> 
> It is capable of displaying two devices, and there's an option to display them with some delay. Thus, you can *measure input lag!*
> 
> Also added a graph: Frequency vs. Time.


Can you find a topic where the software is explained?


----------



## qsxcv

you know there's this right?
http://www.overclock.net/t/1570462/mousecomparator/0_100


----------



## dobragab

Quote:


> Originally Posted by *FreeElectron*
> 
> Can you find a topic where the software is explained?


Do you mean I should start a new thread for this?

(Sorry, I'm new to OCN.)

*qsxcv*

Check release dates, I posted beta a while ago, I was first...


----------



## agsz

What would be the best Plot Type to test a sensor you believe is defective?


----------



## qsxcv

xcounts


----------



## agsz

Quote:


> Originally Posted by *qsxcv*
> 
> xcounts


Thanks. Can you check out my latest post in the Zowie EC1-A/EC2-A thread and tell me what you think?


----------



## detto87

Quote:


> Originally Posted by *dobragab*
> 
> MouseTester v1.3 is ready.
> 
> MouseTester_v1.3.zip 146k .zip file
> 
> 
> It is capable of displaying two devices, and there's an option to display them with some delay. Thus, you can *measure input lag!*
> 
> Also added a graph: Frequency vs. Time.


Quote:


> Originally Posted by *qsxcv*
> 
> you know there's this right?
> http://www.overclock.net/t/1570462/mousecomparator/0_100


I'm scared.
So far microe posted only version 1.2.
And I found the comparator from qsxcv.

Where does this version 1.3 come from?


----------



## uaokkkkkkkk

poor dobragab


----------



## qsxcv

well now there's 1.4
*http://www.overclock.net/t/1286992/mouse-fetish-club/300_100#post_24769659*


----------



## agsz

Quote:


> Originally Posted by *qsxcv*
> 
> well now there's 1.4
> http://www.overclock.net/t/1286992/mouse-fetish-club/300_100#post_24769659


Does this indicate there's something wrong? Test done on 800 DPI @ 500Hz (DeathAdder Chroma). It hits 1000Hz multiple times.


----------



## m0uz

What am I doing wrong?


----------



## softskiller

You should use your mouse on the mousepad, not throw it in your room at 60m/s


----------



## microe

It looks like you are logging almost 20 seconds worth of data consisting of multiple flicks. If you are testing max velocity then you will typically only collect a single flick, taking one second or less. That should produce the curves that you see elsewhere on this forum. The jumps to very high velocities are usually caused by the timestamp on two mouse polls being much less than 1ms apart.


----------



## qsxcv

make sure to plug in only 1 mouse at a time, or at least flip the stationary mouse upside-down so that it doesn't move from vibrations when you swipe


----------



## m0uz

I see. Doing multiple flicks caused it, I think.

Using a G303 at "400" cpi. Graph looks a bit messy to me but I don't really understand what the dots and lines mean.


----------



## softskiller

The dots are the actual measured points with the values of the X and Y axis.
The line is the average value and the goal is to have a smooth line without much jitter or that large nose that goes downward.


----------



## DrSebWilkes

Quote:


> Originally Posted by *softskiller*
> 
> The dots are the actual measured points with the values of the X and Y axis.
> The line is the average value and the goal is to have a smooth line without much jitter or that large nose that goes downward.


Thank you!


----------



## cookieboyeli

Quote:


> Originally Posted by *microe*
> 
> I wouldn't worry about it if your xcounts is smooth. Sometimes you get two counts that are very close in time and it causes these spikes in the velocity calculation.


Same mouse seeing same results with the spikes once in a while. Glad to know it's normal. (I thought looking at other charts, it just seemed like it added in an extra count in between two, not a problem, as long as it's not skipping them.

However I'm not so sure about this variation. I read the first post but you didn't specify HOW MUCH variation is bad...
Tested with MouseTester v1.4:


Spoiler: Zowie ZA13: Reasonably fast swipe











I wish I understood this better...

Is that a reasonable deviation on the Hz?

Also, when I draw a circle using my wrist to stay in place without looking, after 10 seconds or so it creeps diagonal down and right to the bottom of the page... Razer Deathadder 2013 does that with software installed, but Zowie HAS no software. AFAIK Zowie doesn't ever update firmware though. They literally re release new mice and recall old ones... (ouch!)

I am plugged into a USB 3.0 port and I have selective suspend disabled.
My keyboard is polling at 1000hz. I heard (from r0ach) that that can mess up mouse movement. Ducky Shine 5 RGB.
I run very little on my machine. It's extremely clean and optimized like only someone with a hobby for it could. DPC latency is "alright" at 18-37us with spikes to 80us occasionally and topping out at 150us spikes.
It won't go any lower on average, no really. That's just the minimum average that can be achieved with this hardware.

Is there anything I can do to improve the situation mouse wise? I'm moving to a 144Hz monitor soon and play a lot of FPS games so I want everything to be working right.

I heard it's possible to overclock the polling rate. Perhaps I should do that and set my keyboard down at 500Hz.

I'm not adverse to getting a new mouse. The low weight of the ZA13 is so, so nice though and shaves miliseconds off of my reaction time vs the Zowie EC1-A. Shapewise... THe EC1-A now feels too big, but the ZA13 is FAR from perfect. Perhaps not wide enough or tall enough. I have an average claw grip with large hands but it works pretty great anyway.


----------



## Mx518

Hello, with original MouseTester (v 1.0) I get very stable polling (0.998 / 1.002 ms range), but with new Mouse Tester v1.4, I get some polls within 1.15 and 0.85ms range...

I have a G303 and a new desktop computer with every Power Saving feature turned OFF...









Why this difference between two versions of same program?


----------



## nidzakv

Why do i get this error ?


----------



## microe

Make sure you have the latest release of the correct version of .NET framework installed.


----------



## Huzzaa

Quote:


> Originally Posted by *microe*
> 
> Make sure you have the latest release of the correct version of .NET framework installed.


Installed the "full" net framework 4 and am having the same thing after upgrading to windows 7.

Which package did you have in mind?

EDIT: I got the proper one with the LGS software suit. Which seems to be the .NET framework 4.5.2 suite. MouseTester is up and running.


----------



## cookieboyeli

The latest .NET is actually 4.6.2 which was released August 2nd and can be found here:



https://www.microsoft.com/en-us/download/details.aspx?id=53344


----------



## James N

Which one is the latest version? I am using 1.5.3


----------



## Arizonian

Quote:


> Originally Posted by *James N*
> 
> Which one is the latest version? I am using 1.5.3


I believe so.....

*http://www.overclock.net/t/1590569/mousetester-software-reloaded#post_24873089*

Most important changes from v1.2:
Dual device mode with built-in supprort for measuring input lag
PNG export features: non-transparent, not only 800×600
Automatic saving of several settings
Hotkey for collecting
Sum vs. Time plot type, just like in MouseComparator
Frequency vs. Time plot type


----------



## James N

Quote:


> Originally Posted by *Arizonian*
> 
> I believe so.....
> 
> http://www.overclock.net/t/1590569/mousetester-software-reloaded#post_24873089
> 
> Most important changes from v1.2:
> Dual device mode with built-in supprort for measuring input lag
> PNG export features: non-transparent, not only 800×600
> Automatic saving of several settings
> Hotkey for collecting
> Sum vs. Time plot type, just like in MouseComparator
> Frequency vs. Time plot type


Thank you!


----------



## Curleyyy

Little confused with how to use this program still, tried to give it ago a few times... All 3 images are from the same swipe test.

Mouse: EC2A - 1000hz

When I swipe fast from left to right multiple times, I get the following graph



...but as soon as I clip the Data Point start/end for the slower movements, the graph changes and shows a lot more deviations...



... and when I simply zoom in without changing Data Point start/end there's no deviations at all????


----------



## Calypto

at least 2 characters


----------



## Drgc01

*count vs time*

Concerning counts vs time graph: what does the y-axis display? I can see a dot every 1ms (1000 Hz mouse) which is good. The graph looks like a hyperbola. What does this mean, there is no unit on the axis. What exactly goes up and down. The amount of counts stay the same, namely 1 count every ms.


----------



## TranquilTempest

1 report every ms, a count is a unit of distance traveled, sensitivity is counts per inch.


----------



## the1freeMan

Curleyyy said:


> Little confused with how to use this program still, tried to give it ago a few times... All 3 images are from the same swipe test.
> 
> Mouse: EC2A - 1000hz
> 
> When I swipe fast from left to right multiple times, I get the following graph
> 
> 
> ...but as soon as I clip the Data Point start/end for the slower movements, the graph changes and shows a lot more deviations...
> 
> 
> ... and when I simply zoom in without changing Data Point start/end there's no deviations at all????


I'm sincerely astonished.


----------



## jayfkay

Calypto said:


> at least 2 characters


eh looks pretty good


----------



## Aniela

Perfect tool to measure my mouse real dpi(the one in Logitechs software is pure bull****) before switching to the next one, thx u rock


----------



## SmashTV

Aniela said:


> Perfect tool to measure my mouse real dpi(the one in Logitechs software is pure bull****) before switching to the next one, thx u rock


Well, very little mice will ever have exact-as-advertised CPI.


----------



## TranquilTempest

And CPI changes significantly with mouse pad, pressure, skate thickness, etc. half a millimeter difference in distance in height off the surface might be a CPI difference of ~5%.


----------



## Melan

Not to mention the CPI difference scales with the step as well. To a point where on some mice around 6000 step you might have a whooping extra 400 CPI.


Edit: Or mice like G402 and G302 where CPI steps not what they are labeled in LGS.


----------



## hwanzi

Is collect or log start more accurate? because i get different results when using each one...


----------



## Prashant28

Thank you for this invaluable utility


----------



## ucode

hwanzi said:


> Is collect or log start more accurate? because i get different results when using each one...


Collect may interact with what's under the cursor adding extra overhead while Log should be relatively free of that so personally I would prefer log. However I would say both are as accurate as each other regarding the results obtained but different for reasons mentioned.


----------



## mdrejhon

Founder of Blur Busters / TestUFO here.

Does MouseTester support windows hooks? Such as HOOKPROC LowLevelMouseProc via SetWindowsHookEx()

*PURPOSE: By having optional window hook support, one can MouseTester simultaneously on a 2nd monitor while playing a game on a primary monitor. Testing mice under real-world full-throttle operating conditions.*

In rare cases, we found that individual mouse performance sometimes degrade ONLY when the computer is at CPU100%/GPU100%, because of various factors such as OS overheads, inefficient drivers, EMI interference on USB cables (error correction latencies), etc. A mouse that works perfectly consistently (1ms intervals between polls) on a mostly idling PC, can go very inconsistent on a full throttle PC from a lot of unanticipated factors that only happens at full-throttle situations. 

Near-identical setup looks massively worse than the other, for unanticipated reasons. So some gamers need to be able to MouseTester at full gaming load.

Also, ideally during hook mode, the MouseTester will need to run in Admin mode at raised process & thread priority level (higher priority than all the game threads) to minimize game-activity interferences percentage, and maximize system flaw interference percentages (OS/driver/EMI/etc factors). 

MouseTester can be the low-CPU-utilization realtime-priority app to analyze mouse during a real-world gaming situation. It won't be perfect, but we've found some situations where unexpected mouse flaws emerge on some system configs but not on others (different mice / different drivers / different OS builds / etc).


----------



## Timecard

Agreed, people should be testing more under real world scenarios or similar simulated cpu/network loads. Might lead to some interesting findings.


----------



## klunka

How can I zoom x axis of plot without zooming y axis and vice versa? Plz help


----------



## microe

I've made some updates to the software to address some things that came up while testing the Razer Avalon (Razer Viper 8K) mouse.

Some under the hood changes that hopefully improve the timestamping accuracy.
I removed the priority and core affinity since they didn't seem to affect things that much, at least on my system.

Aesthetic changes to plotting to help with the visualization of a much higher volume of reports compared to 1,000 Hz

Plots will look different because the smoothing lines use an 8ms time window average instead of a fixed 8 sample average. This is most noticeable at inflection points like the peak of a fast flick.

I added keyboard shortcuts to Start/Stop/Plot. The hold button to collect method still works but I've noticed the timing performance is worse than the Log Start/Stop method.










The average holds at a fairly steady 0.125ms which is 8,000 Hz in this short segment. I do get some timing blips in longer captures but I feel that is because of the software/Windows 10 more than the mouse itself.


----------



## kiriakos

It seems that windows mouse control settings they do influence the results. 
My Logitech MX510 this is 800dpi , Windows offer two settings:
1) pointer acceleration as it moves .. I have disable this.
2) pointer speed movement.. I have set this at full. 

This is my results ... which I can not evaluate.
Question: Should we set Windows ( pointer acceleration as it moves .. & pointer speed movement..) at very specific settings ?


----------



## microe

kiriakos said:


> This is my results ... which I can not evaluate.
> Question: Should we set Windows ( pointer acceleration as it moves .. & pointer speed movement..) at very specific settings ?


Neither of those Windows settings are supposed to affect Raw Mouse Input, which is what the software is using to collect the counts.

To confirm you should log the same movement (can skip the measure part) with the settings changed and there should be a distinct difference in the counts if the pointer speed settings are actually affecting the data collection.


----------



## kiriakos

microe said:


> Neither of those Windows settings are supposed to affect Raw Mouse Input, which is what the software is using to collect the counts.
> To confirm you should log the same movement (can skip the measure part) with the settings changed and there should be a distinct difference in the counts if the pointer speed settings are actually affecting the data collection.


Well in my case the pointer speed movement setting, it does affect your software, by minimizing speed movement setting I get variable results, as low as 200 up to 400 and 1700 at full. 
Additionally, you software download refer to Ver 1.4 , but the software itself this mention Ver 1.3. 
I am guessing that *Logitech SetPoint software* this using NET. , this is capable to *by pass* your work.


----------



## microe

Thank you, I fixed the title bar.



kiriakos said:


> I am guessing that *Logitech SetPoint software* this using NET. , this is capable to *by pass* your work.


It is possible that this Logitech software is affecting the Raw Mouse data. Google search indicates certain versions will. This also means any game that uses Raw Input to collect mouse data, not just my program, will be similarly affected. In general this is not a good thing, it is better to have 1:1 mouse reports to Raw Input counts.

The settings that I was referring to are the OS Mouse Properties Motion settings and assumes the OS mouse drivers are being used.


----------



## kiriakos

microe said:


> The settings that I was referring to are the OS Mouse Properties Motion settings and assumes the OS mouse drivers are being used.


This is good to know, but OS mouse driver this is very poor for my mouse. But I will use one more time your software so to bring mouse data to 800 cpi and inspect performance / tracking repeat ability.

According my book, it is unwise to overload the mouse driver if you care for tracking precision.


----------



## vf-

Am I blind? Where is the Hz graph on the plot window.... I don't see it on 1.2 or 1.4.


----------



## empl

vf- said:


> Am I blind? Where is the Hz graph on the plot window.... I don't see it on 1.2 or 1.4.


First choose in Plot Type "Interval vs Time".

You have to check how far appart are dots on the horizontal graph (which is hard to check for a whole second). But it should be approx 1-2 ms, or less depending on your mouse polling rate. I Am not sure, if you can zoom even that far enough to check on scale of us. But should be enough for polling stability: try to check for any missing dots in your polling rate range. So for example 500hz = every 2ms packet from a mouse. So check if dots are each 2 ms from each other, when you max polling rate. Do quick circles!

I also recommend you to set Data Point Start and End, which should filter period when polling isn't maxed. And read tutorial how to use it to make sure, you are doing it right!

For quick polling test: you can try this: Mouse Rate Checker
*Note:* if you are not doing quick circles, it doesn't enough data, so don't worry your polling isn't maxed.

Also vertical placement of dots tells you: how fast DPC (interrupts) are handled by your OS.

*QUESTION: I can't zoom to more than scale of 100 hundreds of us. Then it gives me some memory exception. Anyone idea why? I selected start and end period. While I saw other people had it zoomed down to 1 us!!!

EDIT: for polling rate stability, you can use Frequency vs Time and check for vertical spikes in graph! BTW this is available only in a newer version - 1.53 (which I don't think is official). It was accused to have malware somewhere, but it has even source code available I think. I have one 1.53 version - don't remember from where, but Bitdefend didn't report any detections.*


----------



## NotThat

Would it be possible to remember the last graph type used and display the next collected data using the same graph type?

Also apparently my razer 8k is refusing to run at above 1000 hz. hmmm


----------



## empl

NotThat said:


> Would it be possible to remember the last graph type used and display the next collected data using the same graph type?
> 
> Also apparently my razer 8k is refusing to run at above 1000 hz. hmmm


Try different test: Mouse Rate Checker

Check this post, maybe there will be something useful *I have the new Razer 8000 Hz prototype gaming mouse on my desk. - Blur Busters Forums*
Try other USB, not sure if you don't need USB 3 for 8khz. Also try disable Legacy USB support in bios and check bios features. I would also recommend to disable USB selective suspend in power plan, also for USB 3! You can use this great utility for managing power settings: *Windows power plan settings explorer utility*

Also make sure in device manager uncheck allow to wake computer using mouse and keyboard, unless you use it.

And uncheck allow to turn device off to save power for all: hid/mouse/keyboard/usb devices you see there!

You can also benefit from reducing mouse buffer size, this is probably from Windows 2000 times, when CPU would crap out from anything and 1ms+ DPC latency times... 





Also make sure you disable dynamictick and use 0.5ms timer resolution - check ISLC. Also you will wanna test your computer for DPC latency with 8khz mouse, download latencymon...


----------



## p1r4nh4

Is it possible to test two mice at the same time?


----------



## scottysace

hey guys you seem to know alot about this stuff and was wondering if you could help me as my g pro wireless seems to dip right down to 500hz when set to 1000hz for some reason i dont know why here is the link to the post i made about it as not to clog up this thread but any help would be very appreciated *G PRO WIRELESS dips to 500hz when set to 1000hz*


----------



## Marctraider

edit nvm


----------



## Layead ttv

microe said:


> I wrote this to be a simple mouse testing software that has built-in plotting, CSV save and load, and plot export to PNG capability.
> 
> Full source code can be found on GitHub, just search for MouseTester by microe1.
> 
> It uses an open source (MIT License) plotting library called OxyPlot that can also be found on GitHub.
> 
> Requires the Microsoft .NET 4 Framework. You will need to have this framework installed to run, can be found on Microsoft's site.
> 
> Built-in plotting includes:
> 
> Raw counts vs time = for detecting limited data paths and skipping counts (e.g. 8-bit reporting that caps at +/- 127)
> Update time per report = for detecting unstable polling rates (on my system it can do 1 ms reliably, YMMV)
> Velocity vs time (calculated based on cpi) = for tracking speed type measurements
> Raw X-Y count plotting = for acceleration, jitter, and angle snapping testing, plots a path based on raw counts
> 
> MouseTester_v1.1.zip 147k .zip file
> 
> 
> Changes in v1.1, February 15, 2015
> 
> Fix for log file save region decimal symbol
> Added logging mode
> Set processor affinity to core #2
> 
> MouseTester_v1.2.zip 148k .zip file
> 
> 
> Changes in v1.2, July 29, 2015
> 
> Fixed up description handling for plot and save
> Report total number of events collected
> Report X/Y displacement from start in counts and distance
> Report piece-wise linear total path length in counts and distance
> Added line / stem options to plots
> 
> Last Updated January 28, 2021
> Changes in v1.4
> 
> Updated to Visual Studio 2019 and .NET Framework 4.6
> Modified RAWINPUT to work with x64
> QueryPerformanceCounter replaces Stopwatch
> Minor aesthetic changes to plotting
> 8ms time window average replaces 8 sample window average
> Added keyboard shortcuts to Start/Stop/Plot
> Modified RawInput handling
> I couldn't upload the .zip, so grab it from GitHub: MouseTester_v1.4.zip


Hello, i got some trouble to find what is f*cking my graph, i have debloat win 10, Stabilise GPU, try on the CPU, uninstall all i don't need and do it now on a fresh install, but stil have this graph with 20/35+ HZ wave: 








Someone can help me ? I set affinities on DMW CRSS cpu 8 and the same for mouse USB. This is the better graph i can have with my knowledge..


----------



## Timecard

These were my findings for win10.









What contributes to variance in MouseTester plots and...


Cross-posting my research on Github https://github.com/djdallmann/GamingPCSetup/blob/master/CONTENT/RESEARCH/SOFTWARE/README.md#q-what-contributes-to-variance-in-mousetester-plots-and-how-can-you-improve-it These changes can also give you a boost in mouse input response by reducing overall time...




www.overclock.net


----------



## Layead ttv

microe said:


> I wrote this to be a simple mouse testing software that has built-in plotting, CSV save and load, and plot export to PNG capability.
> 
> Full source code can be found on GitHub, just search for MouseTester by microe1.
> 
> It uses an open source (MIT License) plotting library called OxyPlot that can also be found on GitHub.
> 
> Requires the Microsoft .NET 4 Framework. You will need to have this framework installed to run, can be found on Microsoft's site.
> 
> Built-in plotting includes:
> 
> Raw counts vs time = for detecting limited data paths and skipping counts (e.g. 8-bit reporting that caps at +/- 127)
> Update time per report = for detecting unstable polling rates (on my system it can do 1 ms reliably, YMMV)
> Velocity vs time (calculated based on cpi) = for tracking speed type measurements
> Raw X-Y count plotting = for acceleration, jitter, and angle snapping testing, plots a path based on raw counts
> 
> MouseTester_v1.1.zip 147k .zip file
> 
> 
> Changes in v1.1, February 15, 2015
> 
> Fix for log file save region decimal symbol
> Added logging mode
> Set processor affinity to core #2
> 
> MouseTester_v1.2.zip 148k .zip file
> 
> 
> Changes in v1.2, July 29, 2015
> 
> Fixed up description handling for plot and save
> Report total number of events collected
> Report X/Y displacement from start in counts and distance
> Report piece-wise linear total path length in counts and distance
> Added line / stem options to plots
> 
> Last Updated January 28, 2021
> Changes in v1.4
> 
> Updated to Visual Studio 2019 and .NET Framework 4.6
> Modified RAWINPUT to work with x64
> QueryPerformanceCounter replaces Stopwatch
> Minor aesthetic changes to plotting
> 8ms time window average replaces 8 sample window average
> Added keyboard shortcuts to Start/Stop/Plot
> Modified RawInput handling
> I couldn't upload the .zip, so grab it from GitHub: MouseTester_v1.4.zip


Hello, i love you're software, you made a very good job thanks a lot.
I use it synce many years, and i love know if my mouse work correctly, can you help me with this please ? I got good hertz with no apps like first screen, and *** on the second i was thinking it's nothing but i am not steping up in game about some years... I am in trouble i want to make sure this is a default or maybe not, and resolve it or search away.
(I got a z390 pro carbon gaming motherboard... Who intell stop driver, so i have no usb driver too)...

01/04/2022 Edit: Add a new .Jpeg to show my polling on G pro wireless again...


----------

