Settings entries in the settings file of the server of Crossfire; usually located in the {prefix} /etc/crossfire directory.
The settings are read and compared by the function static void load_settings(void) in the source code file server/server/init.c .
A not matching settings entry should at the end throw an error message LOG(llevError,“Unknown value in settings file: %s\n”, buf); without early exiting and death of the server at it's start.

This setting variable needs to be a positive integer or a Zero (0) .
A negative value would
LOG(llevError, “load_settings: fastclock must be at least 0” “, %d is invalid\n”, lev);
and fall back to the default set in server/include/global.h
as uint8 fastclock; /* if true, clock goes warp 9 */ ..

The only function that uses it, is static void block_until_new_connection(void)
in server/socket/loop.c, and just tests it if it is greater than 0 .
Setting the fastclock to something like 2 or 10 does not make the server “faster” .

Older servers until including v1.11.0 used this variable once more in server/server/weather.c
and also tests if it is set greater than zero;
found in void tick_the_clock(void) to call the write_skymap function.

My impression was that the Computer's CPU used one whole Core 100% when setting fastclock to 1 .
So it seems not advisable to set it to anything else than 0 .

But therefore the skymap is not painted in the var/crossfire/weather.ppm 300×300 pixels picture; it's field in the middle of the bottom row of the picture of 9 climate maps stays black.
The weather.ppm can be easily converted by ppmtoxpm weather.ppm >weather.xpm to be viewed.

Unknown is the behaviour of the server, when the fastclock is set to something like X, *, NULL, TRUE, FALSE .