Archive for February, 2012

Polling rates in music games

February 24, 2012

A common misconception about music game polling rates:

I still don’t understand why people think that overclocking USB ports help with IIDX. The game only polls for input every 60th of a second, and the USB polls for input every 250th of a second. There’s no reason to overclock your port; the USB port polls more than 4 times before the game updates itself.

I thought to myself… this can’t possibly be the case. I then tried to create some scenarios in my head which worked, but I knew that there was a timing where increasing the USB polling rate would help even though the game polls the USB buffer slowly. Many cycles need to pass before this happens, but it does (and it sure does happen often.)

Here was my response.

Even if IIDX polls the USB buffer at 60Hz (every 16.6ms) and USB polls your inputs at 125Hz (every 8ms), there can be a timing when the game polls the buffer after you hit the key, but before the key input has been placed into the buffer.

Classic example of a situation where increased polling rate would make no difference:
8ms: USB polls your input. sees nothing.
16ms: USB polls your input. sees nothing.
16.2ms: you hit a key
16.7ms: IIDX polls USB buffer. sees nothing.
24ms: USB polls your input. retrieves the input you hit at 16.2ms
33.3ms: IIDX polls USB buffer, retrieves the input you hit at 16.2ms, that the USB buffer retrieved at 24ms.
(Now whether or not this affects your game is a different story, and depends on the game.)

My guess is that increasing the USB polling rate from 125/250Hz to 1000Hz will make it so that your input will actually be stored in the PC’s buffer sooner after you hit it. It would make the accuracy fine enough to not worry about whether or not the PC has retrieved your input (so you only have to worry if the game polled the buffer or not)

1000Hz USB making no difference:
15ms: USB polls your input. sees nothing.
16ms: USB polls your input. sees nothing.
16.2ms: you hit a key
16.7ms: IIDX polls USB buffer. sees nothing.
17ms: USB polls your input. gets the key.
33.3ms: IIDX polls USB buffer, retrieves the input you hit at 16.2ms, that the USB buffer retrieved at 17ms.

1000Hz USB making a difference: (need several cycles before hitting this situation)
281ms: USB polls your input. sees nothing.
281.3ms: you hit a key
282ms: USB polls your input. retrieves the key.
283.3ms: IIDX polls USB buffer, retrieves the input you hit at 281.3ms, that the USB buffer retrieved at 283.3ms.

now take the previous situation but with 125Hz USB polling:
280ms: USB polls your input. sees nothing.
281.3ms: you hit a key
283.3ms: IIDX polls USB buffer. sees nothing.
288ms: USB polls your input. retrieves the key.
300ms: IIDX polls USB buffer, retrieves the input you hit at 281.3ms, that the USB buffer retrieved at 288ms.

so you hit the key at 281.3ms but IIDX doesn’t even see it until 300ms. if the polling rate was higher, it would’ve seen the input on its previous 60Hz poll, at 283.3ms.

when you have tons of these inputs over a long period of time, this situation can happen very often, which means polling rate can really make a difference. of course, again, whether it affects the game is a different story (timing windows of the game etc.)

disclaimer: i’m a programmer, and i’m less knowledgeable about music games than computers. I’ve only increased USB polling rate for my mouse for competitive CS and SC. there are a billion other factors to consider, including the kernel’s I/O scheduler, which can shift the delay.

Advertisements

Group Messaging: Huh?

February 24, 2012

Shit, I took 2-3 months to write this blog post. Since then I’ve done a handful of techy things worth blogging about.

Recently, I’ve seen surrounded by a swarm of messaging confusion, especially with the release of iOS 5. I’ve been so accustomed to traditional SMS, which costs nothing to network carriers, and has limitations expected of a 20-year-old technology. Sprint doesn’t offer tiered texting, and is free/required with a data plan (thus no need for text-over-data workarounds)

iOS5 introduced a new concept called iMessage. Apple knows whether or not the user on the other end is using an iOS device. If he/she is using an iOS device, the input field will show “iMessage” in a light shade. If not, it will show “Text Message” (or possibly other things I have not seen, as I cannot test this myself)

If the message is sent over iMessage, it is sent over data through Apple servers, bypassing the carrier. Most people pay for enough data to field this; these messages don’t take up much bandwidth anyways. However, it is arguable that one with an unlimited SMS/MMS plan may prefer to send messages through that channel instead of iMessage over a limited data plan. Generally this is not the case, because iMessage should not use enough data for you to even care.

I hate SMS. It’s limited to 160 characters, doesn’t support Unicode, takes up to 30 seconds for end-to-end transmission when working properly, and the carriers charge you for it when it costs them nothing (it’s carried inside a field of the packet that’s sent from your phone every so often anyhow.)

I also hate MMS. It requires you to be on 3G so if your smartphone is connected to WiFi, it usually falls back to 3G to receive the MMS, but I have seen cases where it doesn’t. And if you are in an area with good WiFi and no 3G, you’re SOL. I also use Google Voice full-time, which does not work with MMS (and does not return an error message if someone tries to send my GV number a MMS…)

I am a fan of third-party messaging apps like WhatsApp and KakaoTalk, for various reasons. These apps popularized the concept of device push messaging over data, long before Apple integrated it into their iOS. And that’s why iMessage is so popular.. it’s integrated into the OS. It’d be interesting if Google implemented something similar in Android, after all of the copying/stealing Apple has done.

iOS5 also introduced a concept called “Group Message”. This confused the shit out of me at first because of iMessage. At first I thought Group Message was just an iPhone/iMessage circlejerk. But I noticed that when this circlejerk included an Android phone (or, to be specific, a non-iOS5 phone) that some strange behavior happened.

The non-iOS5 phone received the messages as MMS. This made less sense to me. If an iPhone user sends a message to three other people – 2 iOS and 1 non-iOS, I thought 2 of those messages would be delivered over iMessage and the third over SMS. But that was not the case.. The last one was over MMS.

This is because MMS “extends” SMS capability by a bit. It is a completely different type of message, but it supports long messages, (obviously) media, and the recipient list is sent in the message. This is how phones recognize that a group conversation is happening: threading multiple MMS messages with the same group of recipients.

Now we have another problem. A phone can read that a MMS was sent to multiple recipients, but

  1. it usually doesn’t do anything to show the user that it happened.
  2. when a reply is composed, it may address it only to the original sender, via SMS, which breaks the chain.

The recipient data is in the MMS message, but dumbphones and many smartphones seem to ignore it. The native Messaging app for Android (as of 2.3, Gingerbread) ignores it. Handcent for Android recognizes it, but sends replies as SMS unless you attach a dummy image which would make it MMS/work “properly”.

My coworker looked into this issue for a while as he uses an Android phone and communicates with some iPhone users. For Verizon, there is an app called “Verizon Messages” which behaves properly with “Group MMS” threads when it sees them. I have yet to find solutions on other platforms, but I haven’t really searched.