The server keeps time.
Every question opens and closes on the server's clock, and every answer is timed when the server receives it. Devices correct for their own clock to show the timer and start media together. The figures below were measured, and come with their conditions.
Who decides when a question opens and closes?
The server. It sets the start, after a reading time (3 s by default, 0 to 10 s) or after the media when the author chose Start the timer when the media ends, and the deadline, start plus the time limit. It keeps both in Redis and sends them to every device.
An answer is timed on arrival. One sent too early, after the deadline (with a 300 ms grace) or twice is refused. Points follow that time: full at once, half at the limit, plus a streak bonus. A pause, a lost host or a resume keeps the time left.
There is no latency compensation: a player on a slow connection has their answer timed when it arrives.
Does everyone see and hear the same instant?
That is the aim, whatever each device's latency. QuizDock does not trust the clock of a phone, nor assume every device plays sound as fast as the next. Three mechanisms line the room up:
- The server's clock, on every device. Each device measures how far its clock is from the server's: a burst of eight pings when it connects, again after 2 and 8 seconds, then every 30 seconds. Countdowns are computed from the server's deadline on that corrected clock, so a phone set wrong still shows the right time.
- A common start for media, minus each device's own delay. The server sets the start of a question's video or sound 1.6 s ahead. Each device starts it at that instant of the server's clock, earlier by its own audio output delay (what the browser reports between the mixer and the speaker), so that every device is heard at the same moment.
- Drift corrected while it plays. Every 500 ms, each device compares where it is with where it should be: a gap under 30 ms is left alone, up to 600 ms it plays 5 % faster or slower until it catches up, beyond that it jumps.
Media are fetched one question ahead, and the room waits for the devices that play them, 10 s at most by default; the host can Start anyway at any moment of the wait. What this costs is borne by the devices: the server only answers the pings.
Its limits: how closely devices actually play together has not been measured; it is built and tested on Chromium-based browsers; remote participants are experimental. And it is about what people see and hear: scores are not adjusted for network latency (see above).
What happens when someone disconnects?
- A player comes back to the current step and their own result. Their browser keeps a reconnection token for 4 hours, renewed at each question; it is refused once the game has ended.
- During a question, a player who drops is marked disconnected. An answer already sent counts; no answer scores 0. If everyone still connected has answered, the answer is revealed early.
- The host has 5 s to come back unnoticed. Then the room is told and the timer pauses. Within 2 minutes the host resumes with the time left; after that the game ends and is archived as Interrupted.
- The server re-arms the timers from Redis when it starts again, and Compose keeps Redis's data on disk. This is implemented, not tested end to end. The standalone image's Redis keeps nothing on disk.
Can several rooms and quizzes run at once?
Yes. Each room has its own six-digit PIN and its own events: a room's messages go to its devices only. A quiz can run in several rooms at the same time. Within one room, the host can play several quizzes under the same PIN with Next quiz: participants stay, each quiz scores from zero, and Room standings add them up.
Can participants play from elsewhere?
Yes, experimentally. When a quiz has sound or video, joining asks Where are you playing from?: In the room or Remote. A remote participant gets the question and its media on their own device. Who hears the sound is set per quiz, per question or per session: Projection only, Projection and remote participants (the default), or Every device.
What was measured?
The load test, run on 2026-09-27, under these conditions:
- A Firecracker micro-VM on a shared host: Intel Xeon at 2.1 GHz, 4 vCPU, 16 GB.
- The backend built from source, on Node 22, pinned to one core; PostgreSQL 16 and Redis 7 on the same machine, not pinned.
- Simulated players on the other cores, over WebSocket on the loopback: no network latency.
- Single-choice questions with four options, no media; every player answers at a random moment within 3 s.
- One run per step.
Ack is the time from a player sending an answer to the server acknowledging it, in milliseconds. Start spread is how far apart the devices of a room received the same question.
Waits on purpose are not latency
So that everyone starts together, QuizDock waits on purpose: a reading time before answers open (3 s by default), a media start 1.6 s ahead, and, when a question has media, the time every device takes to load them (10 s at most, by default). These waits are the same for every player and are not in the figures below: they measure how fast the server does its own work, with no media.
Rooms of 30, all started together
| Rooms | Players | Ack p95 | Ack p99 | Start spread p95 | Answers lost |
|---|---|---|---|---|---|
| 10 | 300 | 7 ms | 11 ms | 1 ms | 0 |
| 20 | 600 | 6 ms | 10 ms | 1 ms | 0 |
| 30 | 900 | 7 ms | 12 ms | 2 ms | 0 |
| 40 | 1200 | 8 ms | 12 ms | 2 ms | 0 |
| 50 | 1500 | 9 ms | 14 ms | 2 ms | 0 |
| 60 | 1800 | 25 ms | 105 ms | 2 ms | 0 |
One room
| Players | Ack p95 | Ack p99 | Start spread p95 | Answers lost |
|---|---|---|---|---|
| 300 | 7 ms | 11 ms | 12 ms | 0 |
| 500 | 12 ms | 16 ms | 18 ms | 0 |
| 700 | 18 ms | 25 ms | 39 ms | 0 |
| 1000 | 29 ms | 38 ms | 81 ms | 0 |
| 1500 | 61 ms | 431 ms | 60 ms | 0 |
A second run of the same series gave 41 ms at p95 and 52 ms at p99 for 1500 players: at that size the slowest 1 % varies between runs. Several small rooms cost less than one large room of the same total: 1500 players as 50 rooms, 9 ms at p95; as one room, 41 to 61 ms.
What was not measured
- Questions with sound or video, and how closely devices play media together.
- Real phones on a real Wi-Fi network.
- PostgreSQL archiving a very large session.
- Rooms starting at different moments; more than 60 rooms; more than 1500 players in one room.
- The Docker image itself, and a VM of the sizes below.
What size of machine?
| Load | vCPU | RAM |
|---|---|---|
| Up to 700 players in one room, or 20 rooms of 30 | 2 | 2 GB |
| Up to 1500 in one room, or 60 rooms of 30 | 2 | 4 GB |
| Beyond | Not measured | |
These sizes are deduced from the measurements, not measured on VMs of that size: one core for the backend, one for PostgreSQL, Redis and the system. The live engine runs on one Node.js thread, so a faster core helps and more vCPU do not. One instance is one process: there is no horizontal scaling. The backend held about 250 MB at rest and 0.9 to 1 GB at 1500 to 1800 players.
Raw results: one room · rooms of 30 · the load-test script, to measure again on your own hardware.
Questions
How many players can QuizDock support?
QuizDock sets no limit per room. Measured: up to 1500 players in one room, and 60 rooms of 30 (1800 players) at once, with no answer lost. Beyond that, nothing was measured. Conditions: 2026-09-27, backend on one 2.1 GHz core, players simulated on the same machine over the loopback, no media, one run per step. The figures.
How is latency measured?
As the time from a simulated player sending its answer to the server's acknowledgement, reported at the 95th and 99th percentiles. The players ran on the same machine over the loopback, so the figures leave out the latency of a real network.
What happens if a player disconnects?
They come back to where the game is, with their score. The browser keeps a reconnection token for 4 hours, renewed at each question. An answer already sent stays; a question missed scores 0.
Can multiple quizzes run simultaneously?
Yes. One instance runs many rooms at once, each with its own PIN, and the same quiz can run in several rooms. A room can also play several quizzes one after the other under one PIN, with standings across them.
Can remote participants join?
Yes, as an experimental feature. A participant who says they play remotely gets the question and its media on their own device.
How are audio and video synchronized?
So that everyone hears the same instant. The server sets a common start 1.6 s ahead on its own clock; each device starts at that instant of the server's clock, earlier by its own audio output delay, and corrects any drift every 500 ms (5 % faster or slower, or a jump beyond 600 ms). The work is done by the devices. How closely they actually play together has not been measured, and only Chromium-based browsers are tested.
Is the scoring fair for players on a slow connection?
Every answer is timed when the server receives it, the same rule for everyone. QuizDock does not compensate for network latency: on a slow connection, an answer arrives, and is timed, later.