Nearly all video games (including Minecraft) are driven by one big program loop. Just as every gear in a clock is synchronized with the pendulum, every task involved in advancing a game simulation is synchronized with the game loop. Appropriately, one cycle of the game loop is called a tick.
Minecraft's game loop normally runs at a fixed rate of 20 cycles per second, so one tick happens every 1/20th of a second. An in-game day lasts exactly 24000 ticks, or 20 minutes.
However, if the computer is unable to keep up with this speed, there will be fewer game ticks per unit time. As the vast majority of actions are timed based on tick count rather than on wall clock time, this means that many things will take longer on a slower computer.
On each tick, various aspects of the game advance a little bit: moving objects change position, mobs check their surroundings and update their behavior, health and hunger are affected by the player's circumstances, and much more.
One thing that does not happen as part of a tick is drawing graphics. Rendering happens after updating. This is why there can be a variance in fps (if vsync is not enabled) but the tps (ticks per second) will stay constant. This prevents video performance from affecting game mechanics, and vice-versa.
Note that a multiplayer server may be "slow" at initial startup; this is partially due to the java virtual machine taking longer by default to optimize java code at runtime.
As of Minecraft 1.2, chunks are comprised of sixteen so-called sections, each one a 16×16×16 block cube. On every game tick, 3 block positions are chosen at random from each section in an area 15 chunks on a side and centered on the player. Any blocks at those positions are given a "random block tick". Most blocks ignore this tick, but some use it to do something spontaneous: plants grow or die, fire burns out, ice melts, leaves decay, farmland becomes hydrated, and so on. These ticks are called random ticks. You can change how often random ticks occur using
/gamerule randomTickSpeed [Random ticks per section].
Other blocks can request a tick sometime in the future - these are called "scheduled ticks". This is used for things that have to happen in a predictable pattern - for instance, redstone repeaters will schedule a tick to change state and water will schedule a tick when it needs to move.
The two kinds of ticks are kept separate from each other - a scheduled tick will execute different code than a random tick.
Because random block ticks are granted randomly, there is no way to predict when a block will get its next tick. The median time between ticks is 47 seconds. That is, there is a 50% chance that the interval will be equal or shorter than 47 seconds, and a 50% chance it will be equal or longer than 47. However, sometimes it is much longer or shorter: for example, there is a 1% chance that the interval will be over five minutes. On average, blocks are updated every 68.27 seconds. For the math behind these numbers, see the Wikipedia entry for the Poisson distribution.
- To clarify: Which sections are chosen does not depend on render distance, or anything else that loads chunks outside of the 15x15 chunk range. It is not based on block distance -- it is not plus or minus 127 blocks from you. Tested on a server with display range of 10 chunks, with cracked sand spreading; spread limit was a chunk boundary plus two blocks (cracked sand has a spread range of 2 blocks)
A redstone tick describes two game ticks. This creates a 0.1 (2/20) second delay in the signal of a redstone circuit. That is, the signal's time to travel from a location A to location B is increased by 0.1 (1/10) seconds. A tick only pertains to the increase in signal time, thus, a signal's travel time can never be decreased in reference to ticks.