Keep in mind that OBD2 data (vs CANbus-over-OBD2, usually used by high-end data loggers) tends to be rather laggy. You can see how the HUD tach lags behind the factory one in the lower gears on this drag run for an example of typical OBD2 data lag. The tach being kind of useless in lower gears is the only big issue I've run across caused by the lag though.
In reply to GameboyRMH :
I remember the RPM on the ScangaugeE being laggy enough to not be very useful, too. It's mostly useful for data that isn't changing rapidly.
Basically, OBD-II information is given as a response to a request, and it's low priority for the car. "What's the engine speed now? How about now? How about now?" It's still a fast response as far as people are concerned but the tach situation illustrates why.
Sniffing the CAN bus directly allows the gauges to read the information that is constantly being broadcast over the network. GM updates the engine rpm signal every 12.5ms, for example. That's so fast that if the engine is turning less than 4800 rpm, the rpm signal is updating faster than the engine is spinning. However, this requires a specific setup for the manufacturer and possibly even the car. If your gauge cluster requires you to load in a file identifying the make/model/year, it's probably reading the broadcast information off CAN and it'll be as fast as the factory gauges. If it's universal, it won't. The only thing it has in common with OBD-II is that the CAN bus almost always has a leg terminating in the connector - especially in newer cars where OBD-II communication is done over CAN.
Resurrecting this thread - I just ordered the Ultragauge, decided to take a risk on it being less reliable than the scangauge, since it was about half the price. Hope this doesn't bite me later, will see how it works out in the S10 this season. I was getting a little bit short on time, as I haven't gotten around to chasing down the wiring for the speedometer, and am a little tired of using the GPS unit stuck to the windshield method.