Blur Busters Forums

These forums (Blur Busters) are still quite new, but I've been happy to note that egos, bullying, trolling and other annoyances have been minimal to non-existent so far. And I hope it stays that way...

Black Octagon wrote:These forums (Blur Busters) are still quite new, but I've been happy to note that egos, bullying, trolling and other annoyances have been minimal to non-existent so far. And I hope it stays that way...

In my experience, smaller forums stay a lot more focused and friendly. You might get a troll every once in a while, but without a big audience they get bored quickly.

lexlazootin wrote:He doesn't want to know all of his work is for nothing, I kinda feel sad for him sometimes.

I try to not be pitiful in general, but yeah the picture of r0ach's world slowly crumbling as he fails to successfully blind test his claims over and over is both funny and sad.
I don't think his way of thinking deserves support, he clearly lacks a sense and understanding of scientific reasoning and methodology and near religiously ignores everything that could make him reflect on his beliefs. He actually thinks a lack of evidence supports his ideas, and if he is confronted with evidence suggesting otherwise, goes on to say all kinds of crap including they are not looking for the right things - without ever saying what should be looked for. If the effects would be so obvious as they apparently are to him, he should have no problem describing what those effects are.

And let's be real, apart from input lag the system has really no way of affecting mouse behaviour.
System-side, input lag, acceleration and polling variance are the only things capable of directly altering cursor behaviour and those all are easily described, measured and tested.
Thinks like system microfreezes that can be measured with DPC execution times don't affect the mousing directly, and in order for those to be in the perceivable range you'd have to have ridiculous spikes and that would be measureable and describeable as well.

On the other hand, he raises some valid points and while he does next to nothing to back them up, he at least isn't telling people to put crystals in their mice or little bags of sand under their PC. I mean, HPET, interacing, DPC, bad drivers, bus traffic, etc. all are things that obviously affect the system to some degree, they are not pure snake oil in that regard.
He also is somewhat aware of his status and doesn't take himself too seriously.

Okay, I got the basics running, not as fast a system as flood has though(I think the limiting factor is the radeon 6870, but resolution doesn't seem to matter). All figures centered in about 1130microseconds of variance due to 1khz usb poll and 130 microsecond ADC read time.
CRT
vsync off ~2.5ms at 4.2kfps
vsync on ~58ms at 85hz
DFC(radeonpro) ~16.5ms at 120fps, ~23ms at 85fps, ~33ms at 60fps.

LCD(60hz TN, samsung p2370)
v-sync off ~16ms at 4.2kfps
vsync on. lol. 83ms at 60hz
DFC 60fps: ~33 or ~49ms 120fps: ~16 or ~32ms
DFC is acting weird with the LCD, it's like the display is adding it's own v-sync, but I can still see tearing on it. obviously these test cases are right on the edge of a deadline. The really strange part is the full 16ms delay on the 120fps test case, that should be an 8.3ms increment.

No pretty graphs for now, maybe after I modify the arduino to output csv.

MaximilianKohler wrote:It's been said before, but latency is not the only negative affect that various settings would cause. There's also variability from one computer to another. So 1 guy doing tests on 1 PC isn't comprehensive.

yup and this is why i try to be cautious when drawing conclusions...
hopefully more people replicate the tests

I'm fine with roach giving his opinions, and it's great that we have someone doing empirical testing. I don't like how vitriolic and borderline bullying the discussion got.

well he kind of brought it upon himself

Hey flood, does the timestamp from the teensy ISR get changed on every USB poll, or only after you've sent data? I had to compare the ISR timestamp to the input timestamp and add 1ms increments until I got the ISR after the input. (I checked polling stability first, and there was an occasional 8us jitter, but otherwise rock solid 1000 microseconds).

I think that might explain the tail on the low side of your data.

here's a graph:

Edit: graph updated with modified ADC clock in yellow and green.

Sparky wrote:Hey flood, does the timestamp from the teensy ISR get changed on every USB poll, or only after you've sent data? I had to compare the ISR timestamp to the input timestamp and add 1ms increments until I got the ISR after the input. (I checked polling stability first, and there was an occasional 8us jitter, but otherwise rock solid 1000 microseconds).

I think that might explain the tail on the low side of your data.

i do it like this. not sure if this is the best way but it seems to work so that the usb_mouse_move calls block until the ISR is called and finishes.

not exactly sure where the left/low tail is coming from but i don't think it's related to usb polling

Okay, that's a bit more straightforward than what I did, but I wanted to minimize modifications to the arduino code. I created a global var and made the ISR set it to micros(), then figured out the rest of the timing in my main code. I have to deal with a bit of poll jitter, but I don't have to block execution.

I modified the ADC clock with this method: http://www.microsmart.co.za/technical/2 ... duino-adc/

ADC samples now take ~24 microseconds instead of ~120. I probably lost some linearity, but I don't care about absolute voltages, I just care about which direction it's moving. The faster sample doesn't seem to need a lower threshold. so still using 3.

average latency (excluding USB poll) 1856 -> 1768 microseconds