At 60 updates per second you don't notice that the game stands still between two steps. With a logic rate of 5 you see it right away. That's what the demo is for.
A click switches the rate to 5, 10, 20 and 60 steps per second. The orange square is drawn at the position of the latest logic step and jumps. The teal one is interpolated between the last two steps and glides.
What's left in the bucket
You know the accumulator from Update loop: after the logic steps there is usually some time left over, less than a whole step. That remainder tells you how far the picture already is between two steps. Divide it by the step time and you get alpha between 0 and 1:
const float alpha = accumulator / step; const float drawX = prevX + (curX - prevX) * alpha;
So what gets drawn is not the newest state but a point between the second to last and the last one. That costs something: the picture always trails the game by up to one logic step. At 60 steps that's 16 milliseconds, at 5 steps it's 200, and you notice that in the demo.
Catching stalls
Key S adds half a second to the frame time, as if the game had hung for a moment. Without a clamp the accumulator would catch up 30 steps at 60 steps per second, with complex logic that takes long itself and the next frame has even more to catch up. The demo clamps the frame time to 0.25 seconds, so at most 15 steps per frame at 60 steps per second. Some game time is lost for that, the game runs slower for a moment. The line steps this frame at the bottom shows how many steps were just caught up.
How the loop looks as a whole is in Update loop, why using the frame time as the step size isn't enough is in Delta time.
The code is in the repo under fixed-timestep. The project Game Dev Snippets collects all demos of the series.