yeah lagless isn’t a good word to use. just call it the control stick I think. easy solution. no reason to introduce ambiguity or confusion into reading the results.
it would be pretty hard using your test to prove that anything is truly lagless. best case scenario all you could say is “the introduces the least lag of any control method available for that console.”
Where do you get 1ms from? bInterval for “Full” speed HID devices can’t be less than 1ms (and I don’t believe any “High” speed controllers even exist). @Lance3rd nailed it. This test method is incapable of detecting the actual lag of the “control” sticks.
-ud
I was not serious there when I said 1ms, I didn’t want to use 0ms as we all agree it is inaccurate.
And I don’t want to give any more support to Teyah’s claims about this whole lag testing nonsense.
At minimum, it’s a legitimate concern. I would much rather see it addressed sensibly and accurately. In that sense, the biggest missing piece is checking how much the lag affects gameplay. (I really don’t think that 3ms is likely to have a significant impact.)
I think we all get that the +0.00ms is the reference stick. Faster than reference would be a negative number, or the reference and other values would have to shift. I agree it’s misleading to call it “lagless” even though the quotes and context should be a dead giveaway.
Also isn’t it just “how much does your arcade stick lag (compared to the VX-SA)”? Both Undamned and Teyah’s tests mean something. Teyah’s just have a lot more variables that can introduce doubt and confusion. Undamned’s test with the Oscope are the only ones that the stick manufacturers can do anything about.
Not quite. UD-CPS2 shows raw PCB performance because it ignores requested polling rates. If a stick lags more heavily on console than on UD-CPS2 you should probably lower the requested polling rate of the stick.
we’re still missing similar tests done by other people on the same boards to see if results come out the same
even though undamned used an oscilloscope, its still difficult to tell if the lag time difference between boards for x360 is consistent (360 PS360+ vs the other 2 tests which were both PS3). At least it more or less confirms Madcatz PS3 Fight Stick Pro isn’t really the best option - Teyah used a formula based on how many wins/ties/losses to determine approx how much lag it has which can skew results heavily down vs the actual oscilloscope result of almost 1f. Also kinda brings in the discussion of whether or not ps3 just polls at a higher rate than 360, and therefore the inherent input delay people noticed between 360 and ps3 is really ps3 just straight up adding x frames of lag
Stick lag testing is absolutely a worthy task, and again I’m grateful since this is the first and only resource out there that even touches on the idea of it. However, I do agree with some criticisms.
Labelling a stick “lagless” seems like bad practice. For one, it doesn’t take into account the polling rates of each system. You could give a range of lag depending on the polling rates for each console, which would represent real world lag. For example, if the 360 polled at 125hz, the lag for a certain stick would vary by 7-8ms, so for instance the HRAP VX-SA would be +~1.00ms to +8.00ms. And for another, how much lag is +0ms? The “0” might mean 20 on the 360, and 1 on the PS3. It certainly means that you can’t use these results to answer the question asked in the very title of this thread, though the question has more issues that that. The problem, like Undamned says, is that the goal you’re setting out to achieve doesn’t correlate with your results. According to the current results table, the real question should be “how much total lag is there in a certain game on a certain console using different arcade sticks, relative to the fastest arcade stick on each console, ignoring polling rate?”, which is quite different from “how much does your arcade stick lag?”. And it shouldn’t be implied that the numbers are directly indicative of design faults in the sticks, since there are more variables than stick design in your methodology.
I understand that what you’re trying to do is test real world lag, in which case it seems like all you need to do is reword your premise. However, the current results table seems a bit lacking. The slowest stick in the 360 table could be anywhere from 12.5ms to 19.5ms (let’s say), in addition to whatever the control value is. Right now, the results don’t tell you if that stick lags by one frame, two frames, or even ten frames. Factoring in console lag and game lag is perfectly fine, since that’s your intention. But I think it would be an improvement if you removed the polling rate and “lagless” control variables, perhaps by subjecting your control sticks to a similar methodology as the one Undamned used.
Not sure if this is the best place to discuss this as it doesn’t really have to do with Teyah’s test methodology, but I’ll shoot:
I’m curious if there was much thought put into the polling rates defined in the USB descriptors for these controllers. Seeing that, based on my 1ms poll testing, there can be a huge swing in response time from one sample to another (upwards of 50%), I wonder if any controller manufacturers realize this and, in an effort to make the input updates more consistent, tailor the poll rate toward worst response times? For example, if a controller has best response time of 5ms and worst of 15ms, if you specify a polling rate of 5ms the player may experience some inputs coming out nearly immediately and other inputs 10ms later than that (potentially an entire frame later, depending on when the sample occurred), which could be frustrating to the player when they sometimes get their desired timing and sometimes not. Now, if the polling rate were leaning toward worst case, say 10ms instead of 5ms, there would be less detectable discrepancy in response time. Inputs would never be faster than 10ms, but they would be more consistent.
-ud
I expect that the most time intensive thing that happens on the stick is the USB protocol or the encryption BS. The USB clock runs at 6 Mhz, so even on a SNES style bus, reading the buttons should take microseconds.
I am really appreciative of this thread. If it wasn’t for the thread I would just think that something with the PS360+ was off and maybe mine specifically was broken. I’d go through the motions of trying to figure it out and replacing it with a different one only to have the same issue. This thread has caused me to order a Paewang, which I’ve confirmed with eTokki no longer has the issues that caused it to get stuck between systems and have inputs occasionally go out (very rare issue but it happened). The Paewang seems like the simplest way to get all 3 major systems working. Its probably a quarter as hard to set up as a padhack + cerebus or cthulu and there’s documented data that it works great. That and I doubt most cases have the room for a padhack, cerebus, imp, and crossbone / xbox 1 padhack. With the Paewang you could throw in an xbox 1 solution and be okay. Granted, if they release another PS360+ that fixes the xbox 360 issues and offers (non laggy) xbox 1 and ps4 support then I can just as easily switch out to a new PS360+. However, I’m sure as heck not going to wait for something that hasn’t even been announced yet.
Just something to consider for those who are worrying.
I know that when I move on the ps360+ it feels like walking in mud compared to moving on my madcatz pad. I set them both up in training mode and its night and day.
EDIT: That’s on xbox. On PS3 its amazing. I’ve heard the same thing about it on PC but I can’t get my PC to register it as anything other than unknown device so I can’t tell for myself.
The funny thing would be if he’s playing SF4 training on PS3. Inherent 1 frame extra lag over Xbox would be equal (possibly even slower) to Xbox + PS360+ in Xbox mode. Oh but it’s so much faster right?