Framerate means more than just how smooth your picture is - it can also have an effect on the precision of your controls, and in some circumstances, on the physics of the game. Here's how I understand things to work.
One of the central features of the Quake engine is that it works with
a client-server architecture. At one end sits the client. The client
receives input (in the form of commands, including commands to do with
movement; and also some extra stuff such as the player's orientation)
from the player, and sends it on to the server. The server interprets
this information (and possibly other information coming from other
clients), and works out what happens to the player according to the
rules of physics built into the engine and the progs.dat.
It then tells the client the results. This transaction happens even on
a single machine when playing single-player Quake; in this case, a
single machine acts as both client and server.
The other thing that the client does is render the display according
to where the server says things are, and according to the
map *.bsp that it has. (Lag in the display is the delay
caused by waiting for the server to come back with this information.
Client-side prediction in net play is just the client guessing from
its own incomplete information about the game what the server is
likely to calculate ahead of time, so that it doesn't have to wait for
the server response before it displays. Of course, when it gets it
wrong, the correct information can be a bit surprising, so things can
appear to happen without warning.)
Drawing the Quake graphics takes the biggest part of time needed for the game cycle. You'll find that it also takes a variable amount of time depending on what is being displayed. This means that the client framerate depends on how fast the screen is displaying. Now, the client's framerate is also the rate at which it can send commands to the server. So for the best precision in control, you want as fast a client framerate as possible.
Zigzagging, for example, is mostly dependent on accurate controls, so the client framerate is the one to watch out for when zigzagging.
If the server and client are on the same machine, then the server
framerate and the client framerate are one and the same. If one runs a
-listen server, then the server framerate will be related
to the framerate of the client on the same machine. But a
-dedicated server runs at a rate independent of all its
clients. And since it is the server that calculates the physics that
control the game, when a variation in this framerate causes a
difference in behaviour, then it is the server framerate we ought to
be watching. Wall-hugging is dependent on the minutiae of these
physics, and so it is the server framerate that needs to be considered
when talking about wall-hugging.
There are two ways to present a framerate. The way that is most
coherent with the English language, and that is commonly used to
describe how fast a game or piece of hardware runs is to measure it as
a number of frames per second, or fps. On recent versions of
QuakeWorld, you can get your client to display the framerate in this
way continuously above your status bar by setting show_fps
1.
However, for the most part id tended to use a different terminology:
they measured how long each frame lasts. In this article, I'll refer
to this as the frametime rather than the framerate. However,
the Quake console variables host_framerate and
sys_ticrate both measure things from this point of view;
probably they should really be called host_frametime and
sys_tictime. Of course, the framerate and the frametime
are just reciprocals of each other; framerate = 1 / frametime.
host_framerate
Normally (i.e. by default), host_framerate is set to a
special value of 0. This value means that the engine should match the
rate at which time in the Quake universe proceeds with the rate at
which the player sees it proceed in real life. Thus if some frame
takes 0.04 seconds of processing time to compute, Quake will tick its
internal clock along by that amount, so that "Quake time" has also
progressed by 0.04 seconds.
However, if you set host_framerate to be something other
than zero, then "Quake time" instead advances by this amount for every
frame displayed by the machine. As a result, if you set it to a value
that is greater than your real life average frame time, Quake time
will appear to progress faster than normal. If you set it to a value
that is less, Quake will have run slower than normal. (This is how
unscrupulous people do slow-motion cheats in single-player Quake. More
usefully, it also lets you play demos in slow-motion or fast-forward
them.)
You can use host_framerate as a client when talking to a
server to ensure that control commands are stamped as having been sent
some exact period of time apart (rather than the real time, which can
vary as your client struggles to display different numbers of brushes
and so forth.) This accuracy allows such things as reliable 180 degree
spins, and consistent zigzagging. However, if your client is talking
to a server and you let your "Quake time" get too much out of step
with the server (which will probably be running at the default rate)
then strange things will appear to happen from your point of view, and
eventually you'll lose the connection. So, you have to reset
host_framerate to 0 every so often to allow your engine
to realise what the time should really be.
(Thanks to Matthias Buecher for his nice explanation of "Quake time"
and his investigations into using host_framerate on a
remote client.)
Recall that the server framerate is important to us because it determines how often the physics calculations are performed: this is not noticeable for most of the behaviour in the Quake universe, but it it very relevant to wall-hugging.
In normal Quake, the server framerate is controlled by a console
variable called sys_ticrate. This measures the amount of
time each frame should last, and its default value is 0.05 (that is,
twenty frames per second.) Most server administrators don't bother to
change this variable; if they do, they tend to decrease the framerate
to 10fps by increasing the variable to 0.1. This gives the server more
time to process each frame. If for some reason the server machine
can't process everything in time to keep up with the framerate
specified by sys_ticrate, then the server will just run
as fast as it can manage; but if it has plenty of time (as is normally
the case, especially with a -dedicated server) then it
won't increase the framerate any further, but keep to the
sys_ticrate value.
Therefore NQ servers tend to have reliable framerates, and you may be able to guess what they are, but they are likely to be relatively low.
In QuakeWorld, the server runs as fast as it can, just like a client normally does. The less work it has to do, the faster it will go and the greater the framerate will be. Thus QW servers tend to have slightly less reliable framerates - but still, their workload is fairly consistent and so they don't vary that much, and they also tend to run a bit faster. What the exact rate may be will be harder for a remote client to guess, though.
I don't believe there is any way for a remote client to query the server and discover what the server framerate is. (The Quake-C variable "frametime" is supposed to keep track of the value of the the server frametime, but one can't run a client-side mod to look at this when playing on a remote server...) If anyone does know of a way to read or to take a good guess at the server fps from within the Quake client, I'd be pleased to hear from them.
My thanks are due to Zoid for answering a few technical queries
relating to this footnote. Any errors remaining in my understanding
and in the above explanation are my own fault,
though!