no, lol.

why lol at me besides I saying I a lot :( I mighnt have put my point across the best but its still valid. I doubt cooller was using 500hz since it came out.

none of what you wrote makes any sense, i'm still not sure if you were being serious? besides we've been through all of this numerous times.

mouserate.exe and others will report proper hz only if you move the mouse (enough), that's common knowledge. the part about low and high sens players is utter nonsense.

why would the "russian" style need different usb hz, i mean what!? everyone needs tracking aim, no matter how they sit or where their keyboard lies.

do you realize what m_filter 1 does? do you even know of the benefits of high usb hz?
if you can answer the first question you will with a little thinking figure out how it relates to the second and why you claim "we" don't need high usb hz.

any program ive used - 4 reports low rates when using low sens accel. I do know what that other shit does. I'm throwing this out there not trying to rediscover america.

take sens 2/2 lexer style for example, its rare he flick railed as its very difficult to do its almost always using the accel to place cursor where target will appear. I'm thinking thats why m_filter 125hz etc may be beneficial - mouse isnt as responsive and it suitsa wait players.

a) you don't seem to understand what the program(s) you're using measure.

b) m_filter 1 was used before we knew about increasing usb hz. some still use it but i guess it's simply because they're so used to it.

no player exclusively sets up his/her shots (is a 'wait' player). everyone does it from time to time but in some situations it won't work to your advantage. with mg/lg it's mostly tracking aim but you know this.

see, you're wrong about two things.

*usb hz
high usb hz has advantages over 125hz: lower latency, smoother mouse cursor movement, more input samples.
it also removes the "jitterness" you're experiencing.

*m_filter
m_filter 0 is superior to m_filter 1-33. m_filter adds latency (waits for input to average it over x frames) and your input (mouse movement) won't be 1:1 to the cursor movement (because an average is taken over x frames).
noone's saying anything against using it out of habit or liking but it has known disadvantages.

I prefer it off myself and agree with what you say but i still find it odd every single russian player bar 1-2 who were top 10 back the days before polling rates used m_filter 1

Those who still doare - cooller cypher av3k etc. I'm sure they are ocing their mice but m_filter 1 on a high accel removes jitteriness that was my point. I think it may help LG battles as in avoiding overmoving the mouse.

I prefer m_filter with accel on myself but with no accel defo 0

m_filter has nothing to do with and no effect on cl_mouseaccel. you are borderline delusional.

no.

ok. :D

1. injx suggested that lexer played on a lower accel than rapha does today (insert link to accel-real accel etc... thread)

2. high usb port rate might increase perfect control speed. this is especially true for the 1.1 / 3.0 microsoft sensor (insert link to mouse charts from esr)

3. why not set it to 250/500 ? not a single reason. only thing you have to do with non-native oc'd mice is to override vista/7's driver authentification and install the custom driver for your mouse (hidusbf)

4. on the other hand the only advantage you sometimes get (with certain mice) is an improved mouse input delay. 1000/125 = 8 ms 1000/500 = 2 ms. but in addition to other tasks to improve your total input delay (anandtech did an article about it, insert link), like getting a CRT or good gaming TFT those milliseconds add up.

cba finding the links atm

"1. injx suggested that lexer played on a lower accel than rapha does today (insert link to accel-real accel etc... thread"

Uh what? I played with lexer 2/2 settings for years, and I'm playing with 3/1 occasionally now. They aim-style has to be exactly the same as his and nothing has changed. Ie, raphas settings can't possibly be nearly as high-accel/low-sense.

if you tell me lexers accel and yaw/pitch, i can explain

can't say much about their sens tho

lexer was sens 2 accel 2 ptich 0.018 yaw 0.016 in_mouse 1 m_filter accel patch on default windows drivers middle 6/11. Yes he told me so.

I find it hard to believe 4/0.5 or even 5/0.48 or whatever raphas sens is now has similar accel to lexers. From personal experience 4/1 is like 2/2 with the right yaw and pitch.

"4/1 is like 2/2 with the right yaw and pitch"

Not really. 2 accel is 2 accel, and there is a huge diffrence from 1, and it takes MUCH longer to get used to. The pitch/yaw(sensitivity) diffrences is a relatively small diffrence just letting you be even more precise when going already pretty slow.

i can play with any accel at this stage but i find 2/2 nicest however not the best for ql. 2.5/1 is better

yes, I agree. something in QL is diffrent enough, and I use 3/1 myself. 2/2 also wasn't as good for anything but duel in Q3 either.

agreed 100% I had a great aim in tdm/ctf with sens 11cm/360 but too much for duel.
2/2 is great for 1v1 i cannot figure out why it doesnt work in QL I think maybe the lesser rail damage and lg is more used nowadays. Faster pace maybe.

we are brothers comrade =) what pitch and yaw do you like with 2/2 and filter hz etc? I find 250hz on mx518 with pitch 0.018 and yaw 0.02 filter 0 best. fov 110

I like this setup best on my mx518:

500hz; no setpoint installed; standard dpi (which is 800 afaik); sens 3.5; accel 0.01; standard pitch/yaw; m_filter 1 because im used to it!

shaft = 40%

Hmm i thought the standard dpi was 1800dpi unless you happen to own an old mx518 - easily spotten by either mousefeet or 1600dpi max.

tell me how I can find out exactly? :) It has these mousefeet that are black -_- and they are huuuge and cover the whole front and back of the mouse.

@ ischju

http://enotus.at.tut.by/Files/MouseTest.exe

Enotus Mouse Test v0.1.4
Mouse: @msmouse.inf,%hid.mousedevice%;HID-compliant mouse
Model: MX518
Resolution: 2000 dpi \excellent\
Polling speed: 492 Hz
Max speed: 0.20 m/s (15410 points/s) \bad\
Precision: n/a (n/a)
Smoothness: n/a
Debug data: [('9', '2.00'), ('52', '2.00'), ('10', '2.02'), ('50', '1.99'), ('10', '1.98'), ('53', '2.01'), ('9', '1.99'), ('54', '2.03'), ('10', '1.98'), ('51', '1.99')]

that cant be right....

thats the mx518 then1800dpi edition, old edition had smaller and more than the 3 big mouse feet.

its all about shaving the milliseconds off, 125 to 500hz is a good improvement, 1000hz is a bit pointless though :>

added benefit is my mx518 has less strange accel at higher usb rates, or so people say.

good to know as i also have a logitech - mx518

I removed my IE3 from usb port and plugged it to other accidentally, I played like 30 seconds of game and thought "fuck I didn't turned of Antivirus.... checked.... it's turned off... " next "I broken my mouse, it's shakes a lot".
it was 125 hz... I use 500hz. It's like DAY AND NIGHT, It's like compare 60hz 24ms LCD, with 120hz CRT..

Agreed.

yes guard but you are using high/medium accel which i already mentioned - m_filter 1 one stops it.

m_filter 0 (i dont know what it doing..)
and 0.5 accel.
Maybe it depends much on these settings..
BUT IT'S UNPLAYABLE FOR ME @ 125hz.

don't listen to him, he doens't seem to know what m_filter does either.

http://www.team5150.com/~andrew/carmack/johnc...#d19980608

I knew there were some sampling quantization issues early on, so I added the "m_filter 1" variable, but it really wasn't an optimal solution. It averaged together the samples collected at the last two frames, which worked out ok if the framerate stayed consistantly high and you were only averaging together one to three samples, but when the framerate dropped to 10 fps or so, you wound up averaging together a dozen more samples than were really needed, giving the "rubber stick" feel to the mouse control. (c) carmack

in ql m_filter became a float, valid values are 0-33. otherwise it works the same way.

m_filter 1 will stop a usb mouse working at 125hz from jitteriness/shakiness. check any old q3 cfg with accel 0.5 or over when we didnt have usb polling overclocking.

how does m_filter achieve this? what is the side-effect of averaging the input samples over multiple frames?

as far as i understand it increasing the usb hz does the opposite (more samples over a shorter time) and that is the far better solution to the "jitterness" experienced at 125hz.

besides as someone else already pointed out it happens to increase the max perfect control speed with some sensors.

simply try it yourself. m_filter 1 on a decent 125hz mouse as used by everyone here stops any mouselag/screen jitters etc.

Why i dont know but every q3 player always used m_filter with accel 0.5 or greater. check unkind cooller lexer cherya and all those guys who played then.

yes, i know what m_filter does. i'm still not sure if you do :p

you observed something with a minimal samplesize, maybe your correlation is just a coincidence.

a coincidence that has a lot to do with a small (lan based) community and some rather mindless copying of what the 'pro's' do than anything else?

m_filter 1 was almost a must back in the day with ps2 mice running at 40 hz. If you used 0 you were doomed to a choppy mouse. Still I often used 0 because it was more 'truthful'.

So, if you experience _some_ jitters at 125hz m_filter 1 could help smooth them out at the cost of some precision, after all the interpolated frames are not what is actually being inputted.

Some people simply prefer the feel of m_filter 1 regardless of polling rate, it's got nothing to do with being 'old school'. Technically, the preferred setting _should_ be 0, but because humans are imperfect creatures we have to consider what works in practice, and for some m_filter 1 helps them to play better.

However, it really is an improvement to use >125 hz, at least 250 and preferably 500. At 1000 many mice fluctuate too much producing an inconsistent feel.

The key reason that > 125 hz is better is because 8 ms is a large enough amount of time to have made tiny aim corrections with the mouse. Setting it to 4 ms, or 2 ms is a substantial gain in input coherence, and will always pick up those tiny movements.

why did you use ps2 at 40hz? everyone i knew used 200hz or whatever the highest possible value was.

you're replying to the wrong person btw, i agree with everything you said.

Was before the ps2rate craze : )

m_filter is the biggest piece of shit and should never be used unless you're using a ps/2 ball mouse and/or it is 1999.

cooller says no.

Opionions!

I was hoping for it but slightly better pic tbh!

I can imagine but I am truely not the person to shoop it in a very catchy way :)

If someone feels he is, be my guest ;p

they make people cry?

you're missing the fact that mouserate.exe and other programs are trying to MEASURE the usb rate, not just show it.
if you set it to 500hz for example you should move it fast enough for cursor to pass at least 1 pixel every 2ms otherwise it will show less because the mouse just doesn't report any cursor changes every 2ms between some polls
USB rate itself is stable as fuck.

tbh you always know your shit and more importantly make sense without trying to look like a jamerio (i know ur nick from crossfire and here). thanks. I thought the usb rate fluctuated when overclocked as all 4 apps indicated.

Calling it polling _frequency_ is misleading anyway, because although the USB controller indeed polls the mouse at a constant rate, it will only trigger an interrupt when there is actual data to report (mouse movement, button click, etc.). Anything else would unnecessarily waste CPU cycles for a device that is idle most of the time. Therefore, polling _interval_ is a more appropriate term.

I understand "polling" is right, and it is not an actual interrupt:
Interrupts and USB

"An interrupt transfer is not equivalent to an interrupt at one of the IRQ inputs of the host processor. As is the case with all transfers over USB the host must initiate the interrupt transfer.
The device can make the interrupt transfer data available when a system event occurs, but the transfer does not start until the host requests the data. The way that interrupt transfer latency is guaranteed is that the host is obligated to poll for interrupt transfer data at a requested periodic interval. This interval is determined during enumeration and the host polls the device at this interval continuously after enumeration is complete.
...
Depending on many factors the host processor may not be able to transfer the interrupt data at the requested interval. OS design, driver design, application software, CPU speed, and bus bandwidth may all limit the host’s ability to meet the obligation to poll for interrupt transfer data within the required interval."

That last paragraph wouldn't read like it does if USB actually created an IRQ that the processor could respond to.

Also:
Windows Development>Windows Driver Kit>Device and Driver Installation>Bus and Port Drivers>Buses>USB>USB Design Guide>USB Device I/O>USB Bulk and Interrupt Transfer:

"USB devices use interrupt transfer for small packets of data that arrive asynchronously. Because all I/O is under direct control of the driver, the driver must poll the device at the frequency specified in the Interval member of the USBD_PIPE_INFORMATION structure for the pipe."

So yes, a high USB polling interval can and does waste CPU cycles for a device that is mostly idle.

To clarify my original post, "it" is the USB host controller that triggers the interrupts, not the attached devices themselves:
http://www.freebsd.org/doc/en/books/arch-handbook/usb-hc.html

I'm mostly out of my depth here, but it seems the answer might be : "it depends".

(At least some) Host controllers do have the ability to trigger hardware interrupt requests (and I also suppose that some do not). Whether a particular setup used IRQs or not would, I guess, depend upon model/make of USB Host Controller (EHCI/OHCI/UHCI?) and how well the OS supported that hardware.

So I think I take back my "can and does" comment and say instead "can or could, depending upon..." ;-)

As far as I understand it, OHCI and EHCI controllers are pretty much autonomous, that is, they only need software drivers for setup tasks and when there is actual data to process. Any chip that adheres to these specs must behave this way, and this is a necessity for generic drivers to work.
On the other hand, UHCI, which seems to be limited to Intel and Via chips only, requires "the host controller driver to supply a complete schedule of the transfers for each frame [1 ms]." I guess this means that a UHCI host controller driver has to manually instruct a UHCI controller each and every millisecond even when none of the attached devices require such granularity.

I'm not that familiar with the intricacies of USB host controllers either, and feel a bit uncomfortable speculating, but interrupts are signaled on transfer completion in both cases.

Forget what I wrote about UHCI controllers. I think I completely misread that quote. That both UHCI and OHCI controllers use interrupts for transfer completion is true, though.

You are partly right though, because UHCI does impose stress on the processor no matter what.

I followed the instructions for win7 but somehow wouldn't work on my mx518. The mouse doesn't work at all anymore at that usb port, other ports work fine, same with testmode disabled. Any one got an idea how to fix this?

boot pc hit F8 after bios msgs, select ignore driver verification, and you should be good to go

cheers mate!

edit: so when I boot and do what you said it works fine on 500hz, is there a way not to have to go through that with every reboot though? might have to try around a bit with testmode

there are at least 2 possibilities I know of, tested only one of them myself:

1. proven to work: a program that automatically selects that option on boot (I used it to make some peerguardian beta to work on W7)

2. an application or commandline (has to do smth with testmode) that does the same thing, but under windows, this option might be found under ngohq.com

ok got it to work, there were several files for 64 bit and I must have chosen the wrong one of those initially. Checking my mouserate though I don't get a stable 500hz average, more like 450. Friend of mine gets 500 stable with his WMO - should I rather not use it then?

you should use it i guess


do you move the mouse fast enough?

do you look at the average value or on the max's?

yeah fast enough I guess, looking at average mainly - with 250 hertz I get a stable 249 average. But I'll probably change to a lighter mouse anyway, thanks for the answers!

http://www.ngohq.com/news/15043-how-to-increa...a-7-a.html
do it EXACTLY step by step, some ppl click wrong buttons at hidusbf utility, dont like rebooting or fail at step 6 pointing to the wrong .inf
To fix ports, plug your mouse into whichever ports dont work, then use your keyboard (as your mouse wont work) to navigate to the device manager. uninstall the drivers for mouse, then unplug the mouse and plug it back in, it should work again.

Its day and night for me as well. It doesn't matter what sense/accel you're using, the mouse is just more responsive. Cutting down any latencies, be it milliseconds of ping or in controls, is a good thing, and we notice it.

when i'm not able / cba to do double blind tests, i just use the comparativly "best" (THERE IS NO "BEST"!!!) solution, factoring in scientificly proven pros and cons

LAME v2
80-100W graphics card
shaving every second day
500 Hz WMO
....list goes on

you are right but you are wrong, and if you think you're wrong, that's cuz you are right.

the truth is elsewhere.

"I have been a fool—yes that’s it exactly on the nose—
and you’ve made me see—my mistake is clear to me now—
I had thought I was right—it seemed like a good idea at the time—
to think that I just might be wrong."

Only if it relieve an issue with the width of the data path so as the hz raise the, for example, negative accel vanishes. In a nutshell, if the mouse is good, you should never have to worry about usb tweaking. Hi MS WMO.

Makes a big difference for me with my WMO. 125hz is ew.