# this desktop: hardware and data flow

initial inventory: september 8, 2026, 05:25:46–05:26:08 UTC, before the gpu move.
gpu link and topology checked again at 07:51:12 UTC after the user moved the card
to the upper long slot. this document and the website catalog reflect that
change. live reads have their own timestamps.

## a concrete transfer

consider an **illustrative** 1 GB buffer already in system ram, copied to the
rtx 2070 and then reused by a gpu kernel. the observed path is:

ram → cpu memory controller/io fabric → cpu pcie root → gpu pcie endpoint
→ device memory. a later kernel load can use gpu l1 or l2, or fetch from vram;
it does not have to cross pcie again. cpu caches are involved when cpu code
prepares or reads data, but a gpu dma copy is not a required serial trip through
cpu l3, l2 and l1. arrows describe data relationships, not one compulsory pipeline.

| individual transfer | assumed ceiling | ideal time for 1 GB |
| --- | ---: | ---: |
| system ram pins, both channels active | 51.2 GB/s | 19.53 ms |
| observed gpu pcie 3.0 ×16, one direction | 15.754 GB/s | 63.48 ms |
| gpu local gddr6 memory pins, rated | 448 GB/s | 2.23 ms |

these are calculated lower bounds for separate transfers, **not measurements**.
packet overhead, contention, launch cost, caches and clocks change the result.
do not add the rates or treat the fastest one as the end-to-end rate. a workload
that repeatedly streams new data over pcie can be link-bound while gpu busy %
stays low; data reuse on the gpu can change that balance. the old ×4 link's
calculated ceiling was 3.938 GB/s and its ideal 1 GB transfer time was 253.91 ms.
the move gives four times the pcie coding ceiling; it does not establish a
fourfold application speedup or measured transfer rate.

## evidence and units

- **observed configuration:** what windows or nvidia reported at a stated time.
  link generation, capacity and cache topology are not throughput measurements.
- **documented:** a vendor rating or architectural capability. drive sequential
  ratings are results under vendor conditions, not hard guaranteed maxima.
- **calculated:** arithmetic from a stated configuration or an explicit scenario.
  a 3.8 GHz cache scenario is not an instantaneous clock reading.
- **measured traffic:** a named counter divided by its sample interval. its
  scope is retained: os disk io, network interface traffic or gpu host-link traffic.
- **not measured / no read:** no supported sample exists. JSON uses null; CSV
  leaves the value empty with a status. zero means a real counter reported zero.

GB/s = 1,000,000,000 bytes/s; MB/s = 1,000,000 bytes/s.
GiB = 1,073,741,824 bytes; MiB = 1,048,576 bytes; KiB = 1,024 bytes.
Gbit/s describes bits/s. GT/s describes transfers/s before encoding.
memory capacity, busy time, latency, instructions/s, FLOPS and bytes/s are
different quantities. **memory-active % × rated bandwidth is not a measurement.**

## inventory and topology

| part | observed or documented detail | evidence |
| --- | --- | --- |
| motherboard | asus prime x570-p | windows baseboard + asus manual |
| cpu | amd ryzen 5 3600x; 6 cores / 12 threads | windows processor/topology |
| cpu l1 data | 6 × 32 KiB, private per core | windows cache API; amd slides |
| cpu l1 instruction | 6 × 32 KiB, private per core | windows cache API; amd slides |
| cpu l2 | 6 × 512 KiB, private per core | windows cache API; amd slides |
| cpu l3 | 2 × 16 MiB; each group shared by 3 active cores | windows cache-sharing masks |
| ram | 2 × 16 GiB, reported 3200 MT/s, slots a2/b2 | windows smbios module records |
| gpu | nvidia geforce rtx 2070, 8192 MiB gddr6 | nvidia-smi; nvidia spec |
| gpu l2 | 4 MiB device cache | nvidia turing whitepaper appendix b |
| gpu l1/shared | 96 KiB per sm, configurable 64/32 split | nvidia turing tuning guide |
| gpu registers | 64K 32-bit registers = 256 KiB per sm | nvidia turing tuning guide |
| gpu execution | 36 sm, 2304 cuda cores | nvidia turing whitepaper/spec |
| nvme | crucial ct1000p1ssd8, 1,000,204,886,016 bytes | windows storage + pcie tree |
| sata | wd blue 3d wds100t2b0a-00sm50, same byte capacity | windows storage |
| network | realtek pcie gbe, 1 Gbit/s, full duplex | windows adapter record; checked again at 08:14 UTC |

all cpu cache lines are 64 bytes. l1/l2 are 8-way; l3 is 16-way.
the two threads of a core share its caches. the l3 groups are separate;
32 MiB must not be drawn as one uniformly shared cache.

the current os ancestry puts the gpu directly below an amd cpu root bridge,
with no x570 bridge in its path. the gpu path is `PCIROOT(0)#PCI(0301)#PCI(0000)`;
the acpi slot path identifies `X161`. sata and ethernet remain below the shared
amd chipset branch. the nvme controller sits below a separate cpu root bridge.
the asus manual places the first long slot on cpu ×16 lanes, the second long
slot on chipset ×4 lanes, m.2_1 on cpu lanes and m.2_2 on chipset lanes.
the user confirmed the earlier lower-slot placement and moved the gpu to the
upper long slot; the new ×16 link and direct cpu ancestry agree with that move.
the nvme's m.2_1 physical position remains **inferred**, not inspected.

nvidia now reports **pcie gen 3 ×16**, with device maximum gen 3 ×16. windows
pnp reports gen 1 ×16 for the gpu. both reports are retained: power state and
cached properties can differ. ×16 agrees. the earlier reports were gen 3 ×4
from nvidia and gen 1 ×4 from windows; those belong to the before-move capture.
neither maximum capability nor a long physical slot alone establishes an
installed ×16 link. the current chipset-uplink generation was not established;
the gpu no longer shares that uplink.

ram modules report 64 data bits each. matching a2/b2 population supports
dual-channel operation, but active memory-controller mode, fclk/uclk, timings
and sustained clocks were not directly read. wmi cpu “current clock” can be a
firmware/base value. its approximately 4 GiB gpu memory field is unsuitable
for this card; use nvidia's 8192 MiB report.

## rate register

| path | reference rate | exact meaning | actual traffic |
| --- | ---: | --- | --- |
| cpu l1 data → registers | 64 B/cycle; 243.2 GB/s at assumed 3.8 GHz | architectural load capacity **per core** | not measured |
| cpu registers → l1 data | 32 B/cycle; 121.6 GB/s at assumed 3.8 GHz | architectural store capacity **per core** | not measured |
| cpu l2 ↔ l1 data | 32 B/cycle; 121.6 GB/s at assumed 3.8 GHz | per-core cache path | not measured |
| cpu l2 → l1 instruction | 32 B/cycle; 121.6 GB/s at assumed 3.8 GHz | per-core refill path | not measured |
| cpu instruction fetch → execution | no fixed rate assigned | fetch/decode/issue are distinct | not measured |
| cpu registers ↔ execution | no fixed rate assigned | instruction and operand dependent | not measured |
| cpu l3 ↔ l2 | no verified rate assigned | sharing, misses and coherence matter | not measured |
| core complexes ↔ io fabric | no verified rate assigned | fclk, direction and topology matter | not measured |
| ram ↔ memory controller | 51.2 GB/s conditional | 3200e6 × 8 B × 2 channels; read/write share bus | not measured |
| cpu root ↔ chipset | 7.877 GB/s each way, conditional | assumes pcie 4.0 ×4; installed uplink not verified | not measured |
| gpu ↔ cpu root | 15.754 GB/s each way at recheck | observed pcie 3.0 ×16; direct cpu lanes, before packet overhead | coarse nvidia host-link MB/s |
| gpu dma ↔ device memory/cache | no independent rate assigned | host traffic is not internal memory traffic | not measured |
| gpu vram ↔ memory controller | 448 GB/s rated | 14e9 bits/s × 256 pins / 8; shared read/write pins | not measured |
| gpu l2 ↔ sm l1 | no verified rate assigned | cache hit and refill traffic differ | not measured |
| gpu shared/l1 ↔ registers | no combined rate assigned | shared-memory banks and caches are different paths | not measured |
| gpu registers ↔ execution | no fixed rate assigned | operand width, issue and banks matter | not measured |
| nvme link | 3.938 GB/s each way | observed gen 3 ×4, before packets | link traffic not measured |
| crucial p1 host io | 2,000 / 1,700 MB/s read/write, vendor typical | 1 TB drive sequential rating | windows disk bytes/s |
| sata interface | 600 MB/s after encoding | 6e9 × 8/10 / 8; negotiated mode not read | link traffic not measured |
| wd blue host io | up to 560 / 530 MB/s read/write | 1 TB drive sequential rating | windows disk bytes/s |
| ethernet nic pcie | 250 MB/s each way | observed gen 1 ×1; 2.5e9 × 8/10 / 8 | nic pcie traffic not measured |
| ethernet wire | 125 MB/s raw equivalent each way | reported 1 Gbit/s / 8; full duplex observed at 08:14 UTC | windows interface bytes/s |
| usb gen 2 port | 1.25 GB/s raw equivalent | 10 Gbit/s / 8 before encoding/protocol overhead | not measured |

the cpu load/store port capacities can total 96 B/cycle for a suitable instruction
stream. this is not a sustained benchmark, not a cache-miss rate, and not a
ram rate. do not multiply by 12 smt threads or add bandwidth across successive
cache levels. no simultaneous full-rate l2 fill/eviction claim is made.

pcie formula: transfers/s × encoding efficiency × lanes / 8.
gen 1 uses 2.5 GT/s and 8/10; gen 3 uses 8 GT/s and 128/130; gen 4 uses
16 GT/s and 128/130. the quoted pcie numbers are **per direction** before packet
overhead. even full-duplex links are subject to endpoint and shared-route limits.
the chipset uplink is a shared resource, not a dedicated copy for each device.

usb combines cpu and chipset ports, gen 2, gen 1 and usb 2.0. the diagram's
usb node is a representative group, not a port-by-port wiring claim. display,
audio, storage nand channels and internal gpu render/video engines are not
separately inventoried or instrumented in this memory/io view.

## read / write / total bars

on device links, read means device → host; write means host → device.
total traffic is read + write. if either read is missing, total is missing too.
zero is a real zero; stale reads stay marked stale.

| link | read / write reference | total reference |
| --- | --- | --- |
| gpu pcie | current reported gen/width, each way | sum of both ways |
| nvme pcie | observed gen 3 ×4: 3.938 GB/s each way | 7.877 GB/s |
| sata | 600 MB/s interface cap, shared | 600 MB/s |
| ethernet | current wire rate / 8, each way | twice that rate when full duplex |
| ram / vram | shared memory bus | same shared rate |

full duplex: total % = 100 × (read + write) / (read cap + write cap).
shared bus: total % = 100 × (read + write) / shared cap.
so one saturated direction gives 50% total on a symmetric full-duplex link,
or 100% on a shared link. unknown duplex gives no total %.

these bars use link references. disk counters are host io, not wire-byte
counts. the drive ratings stay 2,000/1,700 MB/s for the p1 and 560/530 MB/s
for the wd blue; adding each pair does not give a mixed-io drive maximum.
nvme link data is a dated observation; sata's negotiated rate is not read.
pcie references exclude packet overhead.

at `2026-09-08T08:14:04.7709920Z`, windows `Get-NetAdapter` reported the
realtek pcie gbe link up at 1 Gbit/s with `FullDuplex = true`: 125 MB/s each
way, 250 MB/s total. this is a link observation, not an internet speed test.

[pcie has separate concurrent directions](https://www.intel.com/content/www/us/en/io/pci-express/pci-express-architecture-general.html).
[sata shares one payload direction at a time](https://www.seagate.com/files/www-content/product-content/ssd-fam/nvme-ssd/nytro-3000-sas-ssd/_masters/sas-vs-sata-enterprise-vs-consumer-tp677-1-1503.pdf).

## recording and visualization

the website catalog is `public/hw/flows.json`. each node records capacity and
scope. each link contains directed readings, a reference limit, its kind,
source, notes and an optional binding to an existing telemetry field. absent
counters remain null. exact device models must match uniquely; array position
must not select a disk.

the existing collector supplies one-second-window disk/network/cpu counters and
nvidia's coarse host-link reads, about every ten seconds. all apps contribute.
disk and network intervals belong to each device. nvidia's interval is not the
windows interval and remains unspecified. the ui preserves those boundaries.

use **start recording** on the local hardware page, select a path, then stop and
download the CSV. recording is user-started and held in that tab's memory; it
does not install a service or create server history. the 300-snapshot cap stops
the recording. refreshing or closing the tab loses its unsaved record.
the trend uses only recorded values; no interpolation supplies missing counters.
a plot connecting sampled rates is not continuous traffic capture.

only fresh, unique snapshot timestamps enter a recording. stale or unavailable
feeds are shown explicitly. a matching desktop inventory does not prove its
slots, channel mode or clocks stayed unchanged; the catalog remains dated.
for a new hardware configuration, collect and review a new inventory and update
the catalog before treating its references as applicable.

## completing the missing measurements

the local stats view adds gpu temp, power, graphics/memory clocks and vram
active time from the existing feed. active time is not byte bandwidth.

the local preview can also show a dated, finite Nsight Systems vram capture.
read and write are percentages of cycles in which the memory interface was
active in that direction. total adds the paired read/write percentages on
this shared bus. the displayed means use the same valid paired samples;
missing rows are not filled or treated as zero. no rate in GB/s is derived.
see [NVIDIA's metric definitions](https://docs.nvidia.com/nsight-systems/UserGuide/index.html#gpu-metrics).

this is a separate capture panel, not a live counter or a traffic CSV input.
the public feed schema remains unchanged. raw profiler files stay local.
cpu cache/ram byte rates and internal gpu cache byte rates remain unmeasured.

| remaining surface | required evidence |
| --- | --- |
| cpu cache traffic | supported zen 2 performance events with event unit, cache level, hit/miss scope, core mask and actual interval |
| ram/fabric traffic | supported memory-controller/fabric counters, controller/channel mapping and bytes-per-event |
| gpu l2/l1/shared/vram | workload-scoped nvidia profiling counters supported by this card/driver, with event scope and clock/window |
| sustained bandwidth/latency | a separately labeled benchmark with working set, access pattern, threads, affinity, direction, clock/power state and elapsed time |
| remaining slot/port routing | physical inspection plus board manual; gpu move and current ×16 link are verified, nvme position remains inferred |
| long-term rate history | a separately agreed storage duration/location and collection policy; current page recording is temporary |

a cache benchmark measures its workload's effective bytes/s; it is not a
whole-machine live counter. a DRAM benchmark must exceed cache capacity and
state read, write or copy byte accounting. physical-disk io is not nand writes,
and network-interface bytes are not internet goodput. no profiler, driver,
stress workload or new background recorder was installed for this documentation.

## sources and local evidence

- [amd ryzen 5 3600x specifications](https://www.amd.com/en/support/downloads/drivers.html/processors/ryzen/ryzen-3000-series/amd-ryzen-5-3600x.html)
- [amd zen 2, hot chips 31](https://old.hotchips.org/hc31/HC31_1.1_AMD_ZEN2.pdf), slides 10, 12 and 15.
- [asus prime x570-p manual](https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM4/PRIME_X570-P/E17441_PRIME_X570-P_UM_v3_WEB.pdf), specification summary and board layout.
- [nvidia rtx 2070 specifications](https://www.nvidia.com/content/nvidiaGDC/gb/en_GB/geforce/graphics-cards/rtx-2070.html), full memory specifications.
- [nvidia turing tuning guide](https://docs.nvidia.com/cuda/turing-tuning-guide/index.html), occupancy and memory throughput.
- [nvidia turing architecture whitepaper](https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/technologies/turing-architecture/NVIDIA-Turing-Architecture-Whitepaper.pdf), appendix b.
- [pci-sig encoding explanation](https://pcisig.com/how-does-pcie-30-8gts-double-pcie-20-5gts-bit-rate).
- [crucial p1 specification table](https://www.crucial.in/content/crucial/en-in/home/products/ssd/p1-ssd.html), 1 TB row and test conditions.
- [wd blue 3d nand sata datasheet](https://documents.sandisk.com/content/dam/asset-library/en_us/assets/public/western-digital/product/internal-drives/wd-blue-ssd/data-sheet-wd-blue-3d-nand-sata-ssd-2879-800092.pdf), 1 TB column.
- [nvidia-smi reference](https://docs.nvidia.com/deploy/nvidia-smi/index.html), dmon and pcie throughput.

current local evidence is in the global project's `hardware/observed-hardware.json`;
`hardware/observed-hardware-before-gpu-move.json` preserves the earlier inventory.
the seven-snapshot `hardware/traffic-session-2026-09-08.csv` also predates the move
and retains its original ×4 references; it is not a record of the current link.
`hardware/collect-hardware.ps1` refreshes the finite inventory without benchmarking.
the website collector and relay retain their existing schema. raw local inventory
is not a public route. the public reference excludes serials, addresses, user
files, credentials and private-memory content.