How this data is collected

Where values come from

Data is collected from five kinds of source, in this order of authority:

1. Vendor specification sheets. Intel ARK, AMD.com and NVIDIA product specifications. These are authoritative for the parts their own vendor makes, and they take priority over every other source for those parts.
2. Benchmark databases. PassMark supplies G3D and G2D scores together with the sample counts behind them.
3. Structured extraction from public reference pages, read semantically rather than by scraping table positions.
4. Wikipedia list and series articles, read through the MediaWiki API. Their tables are parsed cell by cell and every value is cross-checked before it is used (see below). The article and revision behind a value are recorded.
5. Architecture inference, used only for instruction-set and capability facts that follow necessarily from a known microarchitecture. These carry lower confidence and are never allowed to overwrite a vendor value.

How conflicts are resolved

When two sources disagree about the same field, the value with the higher confidence wins, and vendor sources outrank secondary ones. The losing value is not deleted: both remain in the fact store with their provenance, so a disagreement can be audited rather than silently resolved.

Cross-source adjudication

When a stored value disagrees with newer evidence, it is changed only under one of these rules, and every change is logged:

• Vendor of record. For a part the vendor makes, the vendor's own specification page decides.
• Two independent sources agree. With no vendor figure, a value replaces the stored one only when two independent sources agree with each other and contradict the stored value. Sources that share an origin count once: a PassMark list entry and the same model's PassMark page are one source, and the Wikipedia list articles for one vendor are one source.
• Single-rule nulling of physically invalid values. A value that cannot be true, such as a launch date before 1990 or after today, a codename that is really bus or memory text, or a price below the floor for the product class, is cleared. It is not replaced with a guess.

Every change keeps the old value, the new value, the rule applied and the evidence behind it, and any change can be reverted. The complete log is public on the Corrections page. A value filled where none was recorded is listed there too, but it is counted as a fill and not as a correction.

Reading Wikipedia tables

Wikipedia tables have merged cells, multi-row headers and values packed into one cell, so reading them by column position mis-assigns values. Feex parses each table into a full grid (resolving row and column spans), maps each column to a field by its header path, and then applies a per-column trust gate: a column is used only if, on parts where the vendor's own value is already verified, that column agrees with the vendor. A column that fails the gate is not used at all. Wikipedia text is licensed CC BY-SA 4.0; see Sources for attribution.

Calculated values

A few figures are calculated rather than read from a source, and are always labelled as calculated with their formula: pixel and texture fill rates, FP32 throughput (where the architecture allows the calculation), memory bandwidth (transfer rate x bus width), cache totals (cores x per-core size) and threads per core. A calculated value is never stored in place of a sourced one.

Architecture from the chip codename

GPU architecture is set from the chip codename using the vendor's die-naming convention (for example, an NVIDIA G86 die belongs to Tesla), and only where the Wikipedia hatnote for the same part names the same architecture. A codename that does not map leaves the architecture unrecorded.

API versions and explicit "not supported"

For graphics API version fields (DirectX, OpenGL, Vulkan, OpenCL, CUDA compute capability) the vendor's value wins over every secondary source. A feature is published as "not supported" only when a source says so explicitly; if no source says anything the page shows "not listed". Silence is never converted into "no".

Validation before publication

Every numeric value must pass a physical-plausibility check before it is written. Examples of rules currently enforced:

• A boost clock below its own base clock is rejected.
• Thread count below core count is rejected.
• Memory bus width must be a real width (32 to 8192 bits, from a known set).
• Shading units outside 4 to 40,000, TDP outside 1 to 1,500 W, die size outside 8 to 2,000 mm² are rejected.
• Parts that architecturally cannot have a feature are asserted negative rather than left blank: EPYC and Threadripper processors never report integrated graphics, and Intel F and KF parts have the iGPU fused off.

A value that fails these checks is discarded, not corrected by guesswork. On a public reference, a blank field is better than a confident error.

What we do not do

• We do not interpolate, estimate or round up missing specifications.
• We do not generate specification values with language models. Prose on entity pages is generated deterministically from stored values, so it cannot state anything the database does not hold.
• We do not collect from sources that gate access. See Sources for the specifics.

Machine-readable access

Every entity is published on four synchronised surfaces: HTML, Schema.org JSON-LD, FHX XML (/gpu/{slug}.xml, /cpu/{slug}.xml) and a JSON API. FHX carries the unit, source, confidence and observation date for each individual value, and publishes unknown values explicitly with a reason rather than omitting them. The schema is at http://foxhole.feex.it/schema/hardware/1.0/fhx.xsd. An automated test asserts that all four surfaces report identical values.

Fleet compute (FCU)

CPU pages include a "Real-world compute in the Feex fleet" section, and the fleet compute leaderboard ranks CPU models by it. It describes how hard processors are actually driven on Feex machines. It is observed load, not a benchmark.

Definition

• 1 FCU is one billion retired instructions; FCU/s equals GIPS.
• Tier 3 formula (every Windows client): FCU/s = whole-machine CPU utilization x logical threads x base clock in GHz x reference IPC 1.0. Capacity is the same product at 100 percent utilization.
• Logical threads come from the machine's reported count when it is consistent with the catalog (equal, or an even count below it such as a virtual machine); otherwise the catalog count is used. The clock is the catalog base frequency. Boost clocks and real per-core IPC are not modeled, so values are estimates.

Resolution and statistics

• Minute resolution: one value per machine-minute. Minutes when the machine was fully idle count as zero, so percentiles include idle time. P50, P95 and P99 come from log-bucket histograms (about 4 percent resolution, never above the exact recorded peak); peak and mean are exact.
• Hour resolution: the hourly average (mean of reported minutes) and the hourly peak (the busiest minute of the hour). Only hours with at least 30 reported minutes are used.
• Minute and hour values are never combined in one percentile, and every figure names its resolution, window and sample size.

Cleaning rules

• A process can be reported twice in one minute (a foreground/background split or a start-time jitter). Per machine, minute and process id the larger value is kept, then processes are summed.
• A machine-minute whose total exceeds 102 percent is rejected and counted, never clamped to 100. Totals between 100 and 102 percent are rounding noise and are capped at 100.
• An hour whose busiest minute exceeds 102 percent is excluded from peak statistics; its average is kept only if it is 100 percent or less. Rejection counts are published next to the figures.
• Machines are matched to a CPU only by exact model identity. Machines without a CPU name, or whose CPU is not in the database, are not counted anywhere.

Privacy floors

• Only aggregates are published: machine counts and sample sizes, never machine identifiers, names or per-machine rows.
• A CPU's figures appear only with at least 60 valid machine-minutes or 6 valid machine-hours; below that the page states how much data exists.
• A program is named only if it ran on at least 3 Feex machines with that processor and on at least 5 distinct Feex machines overall, and its name is a product name rather than a path, version string or identifier. At most 10 are shown; the share of everything withheld is stated.
• The hour-of-day profile is shown only when at least 3 machines with that processor contribute. Program lists and daily curves describe what people do, not what the processor can do, so with one or two machines they would expose an individual's habits. Throughput figures (peak, percentiles, capacity) are not behavioral and are not held back by this floor.

What is not measured

• Instructions are not counted by hardware counters on these clients; FCU is derived from utilization.
• Only the 40 busiest processes each minute are reported, so very small background load can be missed.
• Machines that were switched off, or where Feex was not running, contribute no minutes: figures describe time the machine was on and reporting.
• GPU, memory and disk load are not part of FCU.

Corrections

If a value here is wrong, it is a defect and we want to know. Report it with the entity URL and the correct value plus its source, and we will verify and update. Corrections to vendor-sourced fields are checked against the vendor sheet before any change is made. Corrections already made are listed, with old value, new value, rule and evidence, on the Corrections page.