Might be the server you're playing on that caps it at a certain value as r1q2 does not cap your fps AFAIK (well except for a minimum of 5). If you're using cl_async 1 you can control maxfps by setting r_maxfps to whatever value you'd like, while cl_maxfps controls the NETWORK packet rate (recommended settings: cl_maxfps 30;r_maxfps 1000).
From the readme (
http://www.r1ch.net/forum/index.php?topic=105.0):
One of the largest changes in the client is the separation of the network and rendering rate. Unlike other clients, R1Q2 accomplishes this by sampling input for several frames and generating one network packet. This avoids the problem of "warping" exhibited in other clients that rely on Q2's packet loss recovery features to lower the network rate, however it also creates some more.
cl_maxfps will control the NETWORK packet rate - ie how many packets/sec you send to the server. r_maxfps controls how many FRAMES are rendered per second at a maximum. You should never need to adjust r_maxfps, but try cl_maxfps 30 or other similar values in order to save bandwidth and server CPU time if possible.
Using a lower cl_maxfps will cause a few issues, notably: physics exploits such as crate jumping will not work, jump height when launching off ramps will be lower and prediction misses when climbing stairs can occur. For the vast majority of mods you shouldn't really experience a problem unless you're one of these people who run cl_maxfps 200 or something idiotic. For mods where jumping is crucial, eg the Q2 Jump mod, the cl_async cvar can be set to 0 to restore original Q2 "one packet per frame" behaviour.
Even when running a lower cl_maxfps, important events such as weapon firing or sending a command will still cause a packet to be sent immediately if cl_instantpacket 1 is set (default). This will cause you to go slightly above the cl_maxfps packet rate at times but gives you the timing benefit as if you were running cl_async 0.
Author