If you want your game to have consistent behavior across platforms, you really should have a fixed frame rate for your game logic and physics code. That way, your time step will be constant, which means that any (inevitable) roundoff and other errors caused by the finite time step will be the same for all players.
The one major exception to this is games that don't (always) run in real time. For such games, you want to keep the time step constant in game time, but you can allow game time to run as fast compared to real time as the player wants and the platform can handle.
It's OK — and, in fact, often very useful — to allow your graphics front-end code to have a variable frame rate, but even then, there's obviously no point in letting the graphics frame rate exceed the physics frame rate. (Actually, that's not completely true; if your drawing code can interpolate / extrapolate movement between physics updates, it may be useful to run it more often. However, doing that well involves some relatively advanced issues.)
There's also no point in letting your graphics frame rate exceed the screen refresh rate (which is typically around 60 to 75 Hz), even if your physics frame rate is higher than that e.g. due to accelerated game time. Any effort spent on drawing more than one frame per screen refresh is completely wasted, since the player is only going to see one of those frames anyway.