GB300 system debugging.
One system. Several fault domains.
NetworkComputeComponentsSystem state
Follow the fault from rack to component, then turn the findings into a repeatable procedure.
Software / systems / curiosity San Jose, California
RYAN
CHOU.
I build software.
I get curious about
everything underneath.
Computer science at UC Santa Cruz.
Hands-on with code, infrastructure, and hardware.
01 / Experience Currently
Fremont, California · Aug 2026 — present
Closer to
the hardware.
Understanding a system means knowing what happens when it doesn’t work.
Quanta Manufacturing Fremont
Test Technician
Working in the testing department with switches, compute trays, and the connections that keep them running.
- Created an SOP for OSFP-board replacement.
- Work with RJ45 and DAC cables, BMC, switches, and compute trays.
- Apply systematic debugging to investigate hardware issues.
Inside the debugging process
Skip walkthrough ↓From rack to resolution.
Scroll through the debugging walkthrough.
GB300 / Engineering workflowIllustrative system · Sanitized data
Rack / System context
Bring-up starts here.
Is the environment ready for testing?
CONSOLE-01 / Serial console
console > connect switch > configure interface > status network > verify
IP 10.x.x.x
MAC XX:XX:XX:XX:XX:XX
MAC XX:XX:XX:XX:XX:XX
Shop floor configurationCONFIGURED
Change one variable.
Where does the failure follow?
CT ACable BPort A
PASSSame CT. Same port. Known-good cable.
CT? · less likelyCable A · suspectPort? · less likely
01 · Cable A TEST FAIL
02 · Cable B PASS
03 · Cable A TEST FAIL
Reintroduce Cable A to confirm the failure follows it. Hold the compute tray and port constant.
Inspect the connection.
Does the physical path match the test result?
LINK UPInspect → Reseat → Verify
Cable seatingConnector damagePowerPort state
Read the system state.
Does the observed state confirm the reported failure?
CT A / System verification
sensor_01 OK
sensor_02 OK
temperature 42 C
power OK
nic_state UP
device_state READY
firmware CHECKED
logs REVIEWED
sensor_03 WARN ↗Trace the abnormal observation back to the related hardware region before deciding what needs service.
Service. Then retest.
What needs physical investigation?
LocateInspectRemoveReplace / ReseatRetest
RETEST PASSComponent seated. System state verified.
OSFP board shown as a representative service component. A warning guides investigation; it does not establish the cause by itself.
Make the next diagnosis easier.
How does a repair become shared knowledge?
SOP / Generalized debugging flow
Failure detected↓Verify sensor / state↓Inspect / Reseat↓Retest
PASS ↓
Document / CloseFAIL ↓
Escalate
Document / CloseFAIL ↓
Escalate
Turning repeated failures into repeatable debugging procedures.
Read the debugging workflow
- Configure. Connect to the serial console, verify network state, and use sanitized device values to complete bring-up.
- Isolate. CT A + Cable A + Port A fails. Change only to known-good Cable B: pass. Reintroduce Cable A: fail. The original cable is implicated; CT and port are less likely.
- Inspect the physical path. Check connector damage, cable seating, power, and port state. Reseat the RJ45 connector and verify the link.
- Verify. Check sensors, temperatures, power, NIC, devices, firmware, and logs. Map an abnormal sensor observation back to the related hardware region.
- Repair. Locate and inspect the representative OSFP board, remove and replace or reseat it, then retest. A sensor warning alone is not a component diagnosis.
- Document. Convert the component view into a technical diagram and a generalized SOP. After retesting, document a pass or escalate a failure.
Two internships / Two perspectives
A little further
from home.
Different places. New ways to solve a problem.
Across the Pacific
Osaka JP↗Toronto CA
Internship locations · City-level positions
02 / Selected projectsGitHub ↗
Built. Broken.
Figured out.
A few ways I put what I learn into practice.
DNS→PROXY→SERVICES
CONTAINERSDATANETWORKS
A small corner of the internet, self-hosted.01 / InfrastructureOngoing
My own piece
of the internet.
Own and administer a VPS-based stack: containerized services, isolated networks, reverse proxies, databases, and email. Keeping it running is part of the project.
Write automation for backups, batch renaming, symlink-based organization, and recurring maintenance. Keep services clean and deployments recoverable.
02 / SoftwareContributor
Stats in Term.
A terminal statistics application built in C with a Scrum-based team. Contributed through feature branches, frequent commits, and dev-to-main merges.
Wrote Unity-based unit tests and used Makefile-driven CI/CD workflows to validate changes before merging.
03 / Foundation
Always
learning.
2024 — 2026
UC Santa Cruz
B.S. in Computer Science
Regents Scholarship
2022 — 2024
De Anza College
Computer Science for Transfer
3.69 GPA · Dean’s List · Full IGETC/UC Certification
01 Languages
Python / Java / C / C++ / JavaScript / TypeScript / Bash / SQL / R / HTML & CSS
02 Systems & infrastructure
Linux / Git / Docker / VPS administration / VPN networking / PostgreSQL / MariaDB / Redis / NGINX / Caddy / Cloudflare DNS / SPF, DKIM & DMARC
03 Foundations & tools
Data structures & algorithms / Computer systems / Functional programming / x86 assembly / Discrete mathematics / Figma / Canva / Google Workspace / Microsoft Office
04 Human languages
Conversational Mandarin Chinese
04 / Beyond the screenA few other things about me
Not always
at a keyboard.
The same curiosity.
A different change of scenery.
Off the clock, still curiousOpen it up.
Open it up.
Make it my own.
I like technology I can get my hands on: a modded ASUS ROG, an Xteink X4 Mini e-reader, and a digital camera whose screen I replaced.