Out of curiosity, what transport are you using? Long polling or long-lived iframes? I find that the former doesn't give me low enough latency for my purposes and the latter tends to get quirky for me when I have a high spiked data throughput.
long polling XHR. Latency is extremely good if the server software is up to the task. As soon as the server sends an HTTP header and data response, it's there on the XHR response. (Also iframes mean memory leak, and possibly 'loading' spinner. Neither of which you get with XHR).
You can also do some neat optimizations like decide that a latency of 100ms is ok enough, and so delay sending any data for up to 100ms to see if you can piggy back on the next recv request and reduce the HTTP request count by 1. Also in order to batch up sends.
For example:
Without optimization--
0ms Long polling Recv
800ms Send some data
900ms Long polling Recv (After some data was received)
With optimization--
0ms Long polling Recv
(Send queued for up to 100ms)
900ms Data sent, in Long polling Recv request.
"There's nothing hacky/quirky about comet... long polling XHR."
Now, unless I'm misinformed, long polling XHR does not work in Internet Explorer, although you do list it as a supported platform:
http://wiki.mibbit.com/index.php/Platforms
IE will wait patiently for data to be received, just like other browsers. It'll do keep-alive also with XHR, so you get that benefit as well. You can also remove some HTTP headers in js to get some bandwidth optimization :)
One possibility you may be thinking of is XHR reuse, which is a pain in IE, as far as I remember there's a couple of bugs if you try to reuse the same XHR object. There's hoops to jump through depending on the state or something, and it's just more reliable to not reuse the object on IE.
At the moment, I create a new XHR object for each request, to be sure there aren't issues with IE (I believe XHR reuse isn't an issue on other browsers).
