# Chat-parity CROSSED CONTROL corpus: system block x assistant prose, 2x2.
#
# WHY THIS EXISTS. In tests/data/chat_parity_corpus.txt the two documents that carry an
# `S` system block are ALSO the two with no assistant turn, and the two with assistant
# turns carry no system block. "The defect needs a system block" and "the defect needs a
# document that is entirely prompt" are therefore the SAME statement about that corpus and
# no measurement on it can separate them.
#
# Here the two factors are crossed and the CONTENT IS HELD CONSTANT down the column: docs 0
# and 1 are the same long technical question with and without the system block, docs 2 and 3
# are the same two-turn dialogue with and without it. Any difference along a row is the
# system block; any difference down a column is the assistant prose.
#
# Texts are copied verbatim from chat_parity_corpus.txt so nothing new enters the corpus.

# doc 0 — system block, question only (the shape of the recorded defect documents)
S	You are a careful technical assistant. Answer directly and concisely.
U	I am debugging a performance problem in a C server and I want your help reasoning about it. The server accepts connections on a single listening socket, hands each connection to a worker thread from a fixed pool of sixteen threads, and each worker parses a request, looks up a key in a shared hash table protected by a reader-writer lock, serialises a response into a per-connection buffer, and writes it back. Under light load the median response time is about two hundred microseconds and the ninety-ninth percentile is about four hundred microseconds, which is fine. Under heavy load, at around forty thousand requests per second, the median stays near two hundred and fifty microseconds but the ninety-ninth percentile jumps to eleven milliseconds, and the machine is only about sixty percent busy across all cores, so it is not simply saturated. I have already checked that the network interface is not dropping packets and that the socket receive queues are not overflowing. The hash table is read-mostly: writes are under one percent of operations. Each response buffer is allocated from a global allocator on every request and freed at the end. The worker threads are not pinned to cores. Profiling with a sampling profiler shows about thirty percent of cycles inside the lock acquisition path, but the profile is flat and does not obviously point at one caller. Please walk me through the most likely causes of a tail latency of that shape, in order of how much I should suspect them, explain what evidence would confirm or rule out each one, and tell me which measurement I should take first and why. Be concrete about the mechanism in each case rather than giving general advice, and say explicitly which of these could produce a tail that is fifty times the median while leaving the median almost unchanged.

# doc 1 — NO system block, same question. The system-block control.
U	I am debugging a performance problem in a C server and I want your help reasoning about it. The server accepts connections on a single listening socket, hands each connection to a worker thread from a fixed pool of sixteen threads, and each worker parses a request, looks up a key in a shared hash table protected by a reader-writer lock, serialises a response into a per-connection buffer, and writes it back. Under light load the median response time is about two hundred microseconds and the ninety-ninth percentile is about four hundred microseconds, which is fine. Under heavy load, at around forty thousand requests per second, the median stays near two hundred and fifty microseconds but the ninety-ninth percentile jumps to eleven milliseconds, and the machine is only about sixty percent busy across all cores, so it is not simply saturated. I have already checked that the network interface is not dropping packets and that the socket receive queues are not overflowing. The hash table is read-mostly: writes are under one percent of operations. Each response buffer is allocated from a global allocator on every request and freed at the end. The worker threads are not pinned to cores. Profiling with a sampling profiler shows about thirty percent of cycles inside the lock acquisition path, but the profile is flat and does not obviously point at one caller. Please walk me through the most likely causes of a tail latency of that shape, in order of how much I should suspect them, explain what evidence would confirm or rule out each one, and tell me which measurement I should take first and why. Be concrete about the mechanism in each case rather than giving general advice, and say explicitly which of these could produce a tail that is fifty times the median while leaving the median almost unchanged.

# doc 2 — system block, same dialogue as doc 3. The assistant-prose control.
S	You are a careful technical assistant. Answer directly and concisely.
U	What does a CPU cache do, and why are there several levels of it?
A	A CPU cache is a small, fast memory that sits between the processor and main memory and keeps copies of recently used data and instructions. Main memory is roughly a hundred times slower than the core, so without a cache the processor would spend most of its time waiting. There are several levels because speed and capacity pull in opposite directions: the L1 cache is tiny, perhaps thirty-two kilobytes, and can answer in a few cycles; the L2 cache is larger and a little slower; the L3 cache is shared between cores and may be tens of megabytes, but it takes dozens of cycles to reach. Each level catches what the level above it missed, so the average access time stays close to the fastest level while the effective capacity stays close to the largest.
U	How does the cache decide what to keep?
A	Most caches use an approximation of least-recently-used replacement within a set. The address of a line selects a set, the line can go in any way of that set, and when the set is full the way that has gone longest without a reference is evicted. True least-recently-used tracking is expensive above four ways, so hardware usually keeps a cheaper approximation such as a tree of bits or a single reference bit per way. The important consequence for a programmer is that access pattern matters more than total working-set size: a loop that walks an array with a stride equal to the set spacing can thrash a cache that would happily hold ten times the data if it were touched in order.

# doc 3 — NO system block, dialogue only (the shape of the recorded clean documents)
U	What does a CPU cache do, and why are there several levels of it?
A	A CPU cache is a small, fast memory that sits between the processor and main memory and keeps copies of recently used data and instructions. Main memory is roughly a hundred times slower than the core, so without a cache the processor would spend most of its time waiting. There are several levels because speed and capacity pull in opposite directions: the L1 cache is tiny, perhaps thirty-two kilobytes, and can answer in a few cycles; the L2 cache is larger and a little slower; the L3 cache is shared between cores and may be tens of megabytes, but it takes dozens of cycles to reach. Each level catches what the level above it missed, so the average access time stays close to the fastest level while the effective capacity stays close to the largest.
U	How does the cache decide what to keep?
A	Most caches use an approximation of least-recently-used replacement within a set. The address of a line selects a set, the line can go in any way of that set, and when the set is full the way that has gone longest without a reference is evicted. True least-recently-used tracking is expensive above four ways, so hardware usually keeps a cheaper approximation such as a tree of bits or a single reference bit per way. The important consequence for a programmer is that access pattern matters more than total working-set size: a loop that walks an array with a stride equal to the set spacing can thrash a cache that would happily hold ten times the data if it were touched in order.
