THE LAB / WORKING SETUP
A small lab, by design.
A place to turn systems questions into something I can run, observe, and change.
The setup is simple: a Mac for editing, an Ubuntu laptop for execution, and an SSH connection between them. The Linux machine is also the home of this notebook.
The machine
| Part | Working setup |
|---|---|
| Operating system | Ubuntu 24.04 LTS |
| GPU | NVIDIA GTX 1050 Ti, 4 GB VRAM |
| Memory | 16 GB RAM |
| Access | SSH and Tailscale |
| Development | C++ / CUDA experiments on Linux |
The hardware gives me a concrete place to explore memory limits, resource sharing, and the difference between an idea and its execution.
Three lines of work
01 / CUDA notebook
Status: practice and experiment planning.
Kernel exercises, memory access patterns, and careful comparisons between implementations. The first task is to make the measurement setup clear enough that a result can be interpreted later.
Read: Write the question before the benchmark.
02 / Reliability sandbox
Status: installed; basic data-path checks passed.
A small Python API talks to PostgreSQL and uses Redis as a short-lived cache. The lab runs with Docker Compose. The first checks cover readiness, a database write/read, and a cache miss followed by a cache hit.
The next questions are about dependency failures, connection limits, and latency under load.
Read: A cache hit is only part of the story.
03 / Inference workbench
Status: questions being scoped.
I want to connect GPU constraints to the experience of a serving system: how memory, requests, and background work affect the shape of latency. Results belong here once the workload and measurements are ready.
A useful rule
Keep everyday work and measurement sessions distinct. When it is time to benchmark, reduce competing work and record what is running.
Aynı makine, farklı çalışma modları. Ölçüm yaparken ortamı da not al.
The notebook will grow alongside the experiments. Follow along through RSS.