Main > Main Forum

TurboTwist Hi-Low Spinner Backspin problem. XP 64 Poll rate, Works Now!

Pages: << < (17/18) > >>

2600:


--- Quote from: RandyT on March 03, 2009, 02:14:22 pm ---
This would make sense, to a point.  However, seeing that the system is obviously capable of the higher speeds, it is, IMHO, a bonehead decision to not offer users the option of setting that speed to whatever they wish through a simple registry entry modification.  Still no need to constantly monitor or shift gears, so if that was their primary concern, this approach would have been infinitely better.

RandyT

--- End quote ---

I'm not sure that first statement is totally accurate.  Can it be capable, yes.  Always, no.  The low speed spec was specifically designed to help allow super cheap products without a critical need in speed.  For example, the cable does not have to be as robust as the default cable you provide.  When you start attaching or daisy chaining a lot of devices shielding starts playing a much bigger role.  Also, when the spec was written motherboards had one or two host controllers unlike today where one EHCI controller which has multiple USB 1.1 controllers built in.  When you start loading the bus down, you don't want the priority going to a mouse or keyboard.

The fact is if a device needs a faster poll rate the designer is suppose to choose full speed over low speed.  With full speed the designer has the option of polling as fast as 1ms, but can be polled slower if the designer chooses.  For HID devices, the device does not need to respond immediately to a poll if the designer chose a faster speed then needed.


Granted, I do like the ability to modify things through the registry, but you have to use what's given to you.


RandyT:


--- Quote from: 2600 on March 03, 2009, 03:19:00 pm ---I'm not sure that first statement is totally accurate.  Can it be capable, yes.  Always, no.  The low speed spec was specifically designed to help allow super cheap products without a critical need in speed.  For example, the cable does not have to be as robust as the default cable you provide.  When you start attaching or daisy chaining a lot of devices shielding starts playing a much bigger role.  Also, when the spec was written motherboards had one or two host controllers unlike today where one EHCI controller which has multiple USB 1.1 controllers built in.  When you start loading the bus down, you don't want the priority going to a mouse or keyboard.

--- End quote ---

This is kind of getting into another discussion, but I've yet to see a situation where the system was not capable of higher poll rates than the newer MS operating systems default to.  If you have, I'd appreciate an example to investigate.  We are also talking primarily about the capabilities of the host, not the device.  It is true that there are "super-cheap" mouse devices out there that are incapable of operating properly when the poll rates are hiked.  The processor used in the GGG optical devices, however, is not one of these devices.  It is, in fact, using the same 12 million cycle per second core as our other encoder products, which is more than capable of sustaining higher poll rates.  The difficulty doesn't come from the host, as the bus is the bus.  If it can go "Full-Speed", then it can operate properly at higher poll rates at "Low-Speed".  Also, we aren't talking about bulk transfers, rather very small amounts of data at a higher frequency.  "Full-Speed" devices are usually things like card readers and mass storage devices (at least under 1.1) where large amounts of data need to be transmitted as fast as possible.

Again, the intent of the "Low-Speed" specification was to benefit the device, not the host.  The host is simply more flexible as a result. 

RandyT

2600:

Yeah, sorry for the sidetrack on thread discussion.

One thing, I wasn't trying to imply that the GGG is a super cheap device in fact I was saying the opposite.  What I was more trying to imply is that you can't hold all low speed devices to your GGG standard.  If you increase the low speed poll rate in the OS for one device, you are increasing it for all devices.

I'm not quite sure I understand the rest of your argument.  If you want low speed devices with full speed device characteristics, why not make it a full speed device.  Why would the creators of the spec who are probably much more knowledgeable about it then us, although I do loathe USB, create 2 different speeds if they weren't trying to imply a difference?

I don't have a specific example about poll rates, but I imagine if you start increasing the bus length and increasing the number of devices as well as traffic on the bus you will start seeing that situation.  It may not be blatantly apparent, but if you put an analyzer on the bus you may start seeing errors or devices that would not enumerate correctly.

RandyT:


--- Quote from: 2600 on March 03, 2009, 05:00:32 pm ---Yeah, sorry for the sidetrack on thread discussion.

One thing, I wasn't trying to imply that the GGG is a super cheap device in fact I was saying the opposite.  What I was more trying to imply is that you can't hold all low speed devices to your GGG standard.  If you increase the low speed poll rate in the OS for one device, you are increasing it for all devices.

--- End quote ---

Apparently, this is not the case for one of the better solutions out there.  You can actually assign the device you want to increase the poll rate with so it only affects that particular device...at least if what I have been hearing is true.


--- Quote ---I'm not quite sure I understand the rest of your argument.  If you want low speed devices with full speed device characteristics, why not make it a full speed device.  Why would the creators of the spec who are probably much more knowledgeable about it then us, although I do loathe USB, create 2 different speeds if they weren't trying to imply a difference?

--- End quote ---

Well, it isn't really a "Full-Speed" characteristic.  The spec allows for whatever poll rate one wants to request, but only requires the host to honor 10ms.  One should view that as a minimum for compliance, which MS did seeing as they upped it to 8ms, but not as a definition for what constitutes the capability of a "Low-Speed" device.   As for the difference, it's as was stated before.  It's merely an accommodation of less capable devices, that for the most part is a subset of the full capabilities of the host.  So one cannot technically state that MS is not complying with the spec, because they are.  But one can state that they are of the opinion that not allowing the user (or the devices) the ability to do better is a "bonehead decision", as doing so does not in any way violate the specifications for a USB "Low-Speed" device.

And finally, in the practical world of USB, it seems that the host implementation reigns supreme, not the specification.  I have a great little, inexpensive 16-input USB device here capable of kicking out standard keyboard data very quickly, and it works fantastically for gaming under 98SE, XP and Vista.  But under Win2K, it can't seem to get out of it's own way.  It works fine under Win2K for an application like a kiosk or museum display (or a keyboard), but just doesn't have the throughput under Win2K for what folks here would use it for.  So my point is, referring to the spec doesn't always give you a solid indicator of what to expect from the performance of any particular device when coupled with any particular host.  What has been exhibited, over and over again, is that the hosts in the context of this discussion, set to higher polling of "Low-Speed" mouse devices, work just fine.

On the subject of host performance, one has to keep in mind that the host does not need to poll at 500hz reliably for this application.  It is overkill, as half that would likely be sufficient.  So the host can vary it's poll rate wildly without the user ever seeing an issue, so long as it is able to sustain a rate higher than that which would cause an overflow condition.  In other words, we don't care if there isn't a "dead nuts 500hz reliability"  because it just doesn't matter here.

RandyT

TPB:



--- Quote from: Todd H on March 03, 2009, 03:00:54 pm ---
Good to know about Arkanoid. It's one of my favorites.


--- End quote ---


Rest easy.

The TT2 was MADE for Arkanoid (and its sequel DOH).

It remains the only hi-res spinner with steering wheel options, and a high-low version.

Of course, there is now another hi-res compact spinner in the market, which is giving the TT2 some stiff competition.  It was developed with the assistance of a design sharing and collaboration agreement, the fruits of which shall soon see another product come to market, a revolutionary new joystick called the G360 GroovyStik.    ;)



Pages: << < (17/18) > >>

Go to full version