Networking on Eva Winterschon https://winterschon.gitlab.io/tags/networking/ Recent content in Networking on Eva Winterschon Hugo -- gohugo.io en Some copyright notice - [my license](https://example.com/license) Thu, 18 Jun 2026 23:39:50 +0000https://winterschon.gitlab.io/logo.svg Inference Sector KPI SLO https://winterschon.gitlab.io/en/posts/inference-sector-kpi-slo/ Thu, 18 Jun 2026 23:39:50 +0000 https://winterschon.gitlab.io/en/posts/inference-sector-kpi-slo/ Why should anyone care about KPIs and SLOs?

Generally, unless one gets paid to deal with OBS/Tel and SLA conformance.. ehh. Except that the modern world operates within the bounds of a diverse and often not-fascinating array of performance indicators and services’ operating metrics.

So.. Here are two for today.

  • KPI == Key Performance Indicator
  • SLO == Service Level Objective

Minor Backstory - Today

While aggregating directory content from several workstations into a unified NFS remote mount,(can’t simply have one workstation, right? right), another encounter with SLO defs appears upon the terminal.

This time it’s for LLM Inference customers and their typical requirements. Perhaps our standards repository would be helpful as an adjunct resource:

Inference Service KPIs by Sector

An extension of distributed cloud services architecture with heavy focus on baremetal with VMs and Containers throughout. Many ways to solve the problems, scale the infra, etc.

SLO Additions to the Classifier Repo

  • This file is a compact companion to the observability + telemetry glossary.
  • Each threshold is a starting point and should be tightened to real-world workload SLOs after baselining standard operations.
Sector High-signal KPIs Default alert style
LLM Inference (GP-GPU Service Infra) TTFT, ITL/TPOT, E2E, QTS SLO-derived or baseline-relative; baseline-relative
LLM Inference (API Service Infra) P95 LAT, ERR, 429R, UST SLO-derived
LLM Inference (Network Hardware + Protocol Infra) OWD, PDV, LOSS, ECN baseline-relative; budget-relative
LLM Inference (Prompt Caching, Compute + Re-Compute) PCHR, CTR, TTFTR, RCR absolute for cache-eligible traffic
LLM Inference (Prompt Caching, Storage Infra) CHR, CLAT, COCC, EVR absolute; absolute for cache-eligible traffic
LLM Inference (Prompt Caching API + Load-Balancers) RCHR, LQ, URT, RTR absolute
LLM Training (bulk initial datasets) ITPS, DHR, UDR, CONT absolute; capacity-envelope
LLM Training (pre-training MoE) MFU, STEP, A2AS, EIR absolute starting point; baseline-relative
LLM Training (post-training MoE) TPS, MFU, RACC, RMAR absolute starting point; baseline-relative
HPC - High Frequency Trading - VM Clusters RDY, CSTP, NUMA MISS, T2D absolute starting point
HPC - High Frequency Trading - Baremetal W2W, JITR, CPM, MPKI baseline-relative; budget-relative
HPC - High Frequency Trading - CDN CHR, OOR, TTFB, OTTFB absolute
HPC - High Frequency Trading - Low-Latency Exec OWD, JIT, FLAT, OLAT baseline-relative; budget-relative
HPC - Dark Fiber Regional Network + Infra AVAIL, OWD, Pre-FEC BER, OSNRM SLO-derived; budget-relative
HPC - Quantitative Research + Machine Learning BTT, FLAT, TSS, FFL absolute starting point; baseline-relative
HPC - Big-Data & Multivariate Pattern Analysis JDUR, SKR, SPILL, CLAG SLA-derived; absolute
SLA + SLO Monitoring, Telemetry, Alerting Infra SLI-AV, SLI-LAT, EBR, UP SLO-derived

Global Policy Adjustments

  • baseline_window:
    • 7d median or p50/p95 baseline unless otherwise stated
  • slo_policy:
    • page: error budget burn rate > 14.4 over 1h and 5m, or > 6 over 6h and 30m
    • ticket: error budget burn rate > 1 over 3d and 6h
  • capacity_policy:
    • warn: sustained > 80% of validated steady-state capacity
    • critical: sustained > 90% of validated steady-state capacity or latency inflects above SLO
  • regression_policy:
    • warn: > 1.10x to 1.25x baseline depending on sector sensitivity
    • critical: > 1.20x to 1.50x baseline depending on sector sensitivity

Reference Considerations

  • Thresholds are starting operational thresholds, not universal laws.
  • Where a standards or vendor reference provides an acceptable range, that range is used.
  • Where no universal value exists, thresholds are either SLO-derived or baseline-relative (typically against a 7d median or a validated capacity envelope).
  • For latency-sensitive sectors, alert on percentile regressions and budget exhaustion, not averages.
]]> Performance Engineering - Evaluative Metrics https://winterschon.gitlab.io/en/posts/performance-engineering-evaluative-metrics/ Sat, 13 Jun 2026 15:43:01 +0000 https://winterschon.gitlab.io/en/posts/performance-engineering-evaluative-metrics/ LLM Inference
Sector Common metrics Less-known / specialist metrics
GP-GPU Service Infrastructure TTFT, ITL/TPOT, E2E request latency, TPS, RPS/QPS, Queue-Fill, KV/C metrics request_queue_time, request_prefill_time, request_decode_time, inflight time, SM occupancy, HBM/DRAM memory throughput
API Service Infrastructure p50/p95/p99 latency, streaming TTFB/TTFT, RPS/QPS, error rate, 429 rate, active downstream connections, backend latency x-envoy-upstream-service-time, upstream_rq_time, TR/Tw/Tc/Tr/TA timer split in HAProxy, retry rate, queue-slot saturation, circuit-breaker usage
Network Hardware + Protocol Infra RTT (round-trip time), one-way latency, jitter/PDV (packet delay variation), PPS/BPS, packet loss, retransmits ECN mark rate, PFC (priority flow control) pause events, microburst depth, CQE (completion queue entry) compression state, SymbolErrors, LinkRecoveries, PTP offset/path delay
Prompt Caching, Compute + Re-Compute cache hit rate, cached_tokens, prompt_tokens, generation_tokens, TTFT reduction, cache read/write counts partial-hit ratio, cache-miss ratio, prefix-cache block hit rate, predicted KV hit rate, per-request routing overhead
Prompt Caching, Storage Infra cache hit ratio, eviction rate, cache latency, TTL, GPU/CPU cache usage CPU-vs-GPU cache-hit split, priority-based eviction effect, TTL refresh behavior, KV-block fragmentation / block reuse
Prompt Caching, API + Load-Balancers per-route/model hit rate, active and pending requests, backend latency, request rate, retries, error rate cache-aware routing predicted KV hit rate, routing overhead, queue time before backend selection, circuit-breaker saturation, connection-slot pressure

Acronyms

  • TTFT == Time to First Token
  • ITL == Inter-Token Latency
  • TPOT == Time per Output Token
  • E2E == end-to-end
  • TKS == tokens/sec
  • RPS == requests/sec
  • QPS == queries/sec
  • KV/C == Key-Value Cache

LLM Dataset Training

Operations Common metrics Less-known / specialist metrics
Pre-loading datasets ingest throughput (docs/s, rows/s, bytes/s, tokens/s), tokenization throughput, DataLoader throughput, dedup ratio fuzzy-duplicate rate, semantic-duplicate rate, contamination rate/AUC, consumer lag, shuffle spill bytes
Pre-training + MoE tokens/s, step time, MFU (model FLOPs utilization), training loss/perplexity, all-to-all/dispatch time, GPU memory auxiliary load-balancing loss, router z-loss, expert capacity factor, token-drop rate, per-layer expert imbalance
Post-training + MoE step time, samples/s or tokens/s, train/val loss, reward/preference accuracy, KL divergence, MFU chosen vs rejected reward margin, chosen/rejected rewards, router aux/z loss during alignment, expert saturation under small-batch tuning

HPC + HFT Analytics Infrastructure

Sector Common metrics Less-known / specialist metrics
Virtual Machine Clusters p50/p99 service latency, jitter, CPU ready time, throughput, packet loss CPU co-stop, NUMA locality (numa_hit/numa_miss/local_node/other_node), vCPU scheduling contention, latency-sensitivity effectiveness
Baremetal Systems wire-to-wire latency, p99/p999 jitter, PPS/Mpps, cycles, instructions, LLC-load-misses, branch-misses, RX/TX drops NUMA locality, interrupt coalescence, CQE compression state, packet pacing, driver extended stats / ring stress
Content Delivery Networking cache hit ratio, TTFB, origin offload, request rate, error rate, egress bandwidth shield-layer hit ratio, origin_ttfb, child/parent cache status, regional cache-performance variance
Low-Latency Trade-Execution Networks one-way latency, RTT, jitter, packet loss, order latency, feed latency microburst depth, queue/buffer pressure, ECN mark rate, PFC pause events, path asymmetry, PTP offset
Dark Fiber Regional Network Infra one-way latency, RTT, availability, BER, pre-FEC BER, post-FEC BER OSNR/ESNR, Q-factor, CD (chromatic dispersion), PMD (polarization mode dispersion), FEC degrade indicators
Quantitative Research + Machine Learning backtest wall-clock runtime, feed latency, order latency, feature-serving latency, feature-ingestion throughput training-serving skew, feature inflight vs write-to-store success metrics, feature health/correctness monitoring
Data Analytics + Multivariate Analysis job duration, stage/task duration, throughput, end-to-end delay, records-consumed-rate, consumer lag, shuffle read/write spill bytes, skew via task-duration discrepancy or shuffle-read imbalance, straggler share, input-pipeline prefetch effectiveness

SLA + SLO Reliability, Telemetry, Alerting

  • Pre-Defined latency/error/throughput SLIs and error budgets require burn-rate alerting
  • Prometheus and Alertmanager define scrape and notification timing controls
  • OpenTelemetry defines histograms and exemplars
  • Apdex is a standard user-satisfaction score
  • Elastic APM measures application performance traces
Sector Common metrics Less-known / specialist metrics
SLA + SLO Monitoring, Telemetry, Alerting Infra availability SLI, latency SLI, error rate, throughput, Apdex, error-budget burn rate multi-window multi-burn-rate alerts, scrape_duration / scrape_timeout ratio, group_wait / group_interval / repeat_interval, histogram bucket design, exemplars

Shared Analytics of Interest

Metric Signal Typical domains
Queue time Separates saturation from raw compute/network slowness LLM serving, API gateways, load balancers, HFT
Prefill vs decode split Distinguishes prompt-processing bottlenecks from token-generation bottlenecks LLM GPU serving
Prefix/KV cache hit rate Direct proxy for avoidable recompute and TTFT improvement LLM serving, agentic systems
Auxiliary MoE loss and router z-loss Early warning for expert imbalance and routing instability MoE training
CPU ready / co-stop / NUMA miss Often the real cause of inconsistent latency in virtualized clusters VM-based HFT / HPC
Microburst depth and ECN/PFC behavior Reveals congestion that average bandwidth hides Low-latency Ethernet / RoCE fabrics
OSNR / CD / PMD / pre-FEC BER Core optical-health indicators long before full link failure Dark fiber / coherent optics
Spill bytes and consumer lag Early warning for data-path backpressure and skew Big-data pipelines
Burn rate and exemplars Better operational signal than raw alert count or average latency SLO / observability stacks
]]> Superfun Supermicro SMBUS Seriousness https://winterschon.gitlab.io/en/posts/superfun-supermicro-smbus-seriousness/ Mon, 02 Mar 2026 20:52:00 +0000 https://winterschon.gitlab.io/en/posts/superfun-supermicro-smbus-seriousness/ Repurposing now somewhat older system, a Supermicro X11SSM-F motherboard in a 2U chassis with Xeon E3-1285 v6 and 64GB ECC.

  • Old role: VM box for local infrastructure analytics
  • New role: BSD router w/ CNAs for RoCE-v2 RDMA fabric.

Installed for the purpose: QLogic QL41234HLCU, and…

Great, nice upgrades. The router will have its 4x 10GbE QL41164 ports connected in 802.3ad to the switch-fabric, with two VM host nodes direct-connected using SFP28 ports on the QL41234 NIC. These systems run lightweight validation suites for Project Coherent Flash (the full cluster lives in the colo) and therefore require RDMA and RoCE networking.

In other connectivity areas, the XL710 based NIC is for non-RDMA traffic to the nodes via direct non-switched connection. It does not participate in the memory fabric. In this mode, each QSFP+ 40GbE port has a quad-lane breakout cable going to 4x 10GbE SFP+ connectors, and each of those (8 total) offers 2x 10GbE to each of the four nodes in an adjacent cluster.

Just remember, on this board there’s a jumper to inspect and possibly flip, for reasons better described via the following nerdery.

the X11SSM-F bridges the slot SMBus (SMCLK/SMDAT on PCIe pins B5/B6) to the board SMBus via jumpers JI2C1/2. Some PCIe cards expose an I²C device on those lines at the same addresses used by DIMM SPD EEPROMs (0x50–0x57). That creates address conflicts, which can block SPD reads, hide a DIMM, scramble IPMI sensors, or hang POST. Disabling JI2C1/2 isolates the slot SMBus and removes the conflict.

]]> A Recent Datacenter Colo Visit https://winterschon.gitlab.io/en/posts/a-recent-datacenter-colo-visit/ Sat, 06 Dec 2025 06:06:59 +0000 https://winterschon.gitlab.io/en/posts/a-recent-datacenter-colo-visit/ A short post with annotated photos should be sufficient for this post. Perhaps more detail later, but the short version is that just about everything in racks 1,2,3 – aka Cab.68, 69, 70 – is going to be mostly upgraded. My hardware has been here for several years and it needs a refresh.

So, where to begin… let’s see… we start with the POWER9 at home on my desk, and me looking a wreck in the morning…

Where is this wonderful place that brings me so much joy? Hurricane Electric of course.

For Silicon Valley datacenter nerds, Hurricane Electric’s Fremont and San Jose facilities are the spiritual home of budget-friendly colo: cabinet and partial-cabinet plans with same-day turn-up, straightforward BGP, and native v6 on a backbone that’s been aggressively peering since the early 2000s, making it a historically significant and still notably affordable place to park gear in the Bay Area.

And as such… it’s where most of my gear resides. What was once a HomeLab at home has become a situation of _“let’s move everything into the colo and tell PG$E to suck it on their $300-600/month apartment electric bills (which is physically impossible, they’re a proven CA Governor sponsored monopoly).

Tools and So Forth

How about a photo of my lovely Wera designed Datacenter tool bag? Yes! It’s rugged and strong and doesn’t distort with heavy items. Love it. At the top of the photo is whichever purse happened to be brought along that day; Kors or Burbs or Coach or whichever fit size requirements at the time.

Not shown: a squared-rasp-file occasionally required for “standardizing” the rail mounting holes in those old-ass blue racks. My right hand still has scars from years ago - before owning that rasp to fix the burrs.

Always Getting Injured, but that’s OK.

Now, about those old scars - there are surely new ones periodically. While getting ready for the colo, just standing at the sink with some sheers, cutting… cutting… and ohffs that’s my finger. Yep, it’s definitely deep! Apply pressure! Wrap it tight! Not too tight though… and what was at my disposal? Paper medical tape and clear plastic industrial packing tape.

FINE. It’s FINE. The bleeding mostly stopped, and off we go to the datacenter!

done cut my self real bad

Networking, Servers, Drives, DPUs, and all the other fun!

Ok, enough rambling. Here’s a photo gallery with annotated pics. Each rack has some major revisions to undergo, which requires planning and documentation updates and all the usual production readiness routines.

More Hardware - More ARM64!

Now you may wonder, where is all of my ARM64 equipment and the other clusters? Those are still in the 2x 25U racks at home – they’ll be migrated to the colo as well, once I convert them to use industrial Compact-PCI chassis blade mounts with integrated/redundant power and backplane. I bring you… the ADLINK cPCIS-2632R 3U Compact PCI chassis.

Industrial ADLINK cPCIS-2632R CompactPCI

SATA3… Really?

And we wrap up the day’s fun with… decisions on what to do with these SATA3 SSDs recovered from some old R420 systems… perhaps the LC922 boxes can use those + some 240GB Intel or Samsung boot drives. These days I never bother with SATA, only SAS or NVMe. HoHumBoringSataSoSlow.

A Tale of Two Labs - One is Real, The Other…

I love having my own hardware for my own labs. I love not having to rely on a corporation over-promising on lab resources for the architecture design process – real physical hardware which is absolutely required for “Proof of Concept Engineering”.

As a wise-one once related, not everything can be a Power Point Presentation. Engineers need physical hardware for validation workflows, otherwise it’s all just vaporware.

🙉 🙈 🙊

]]> DPU Cabling and Rack Elevations https://winterschon.gitlab.io/en/posts/dpu-cabling-and-rack-elevations/ Sat, 11 Oct 2025 18:32:15 +0000 https://winterschon.gitlab.io/en/posts/dpu-cabling-and-rack-elevations/ Generally when deploying DAC for inter-rack network connections, particularly the quad-breakout heavy gauge Mellanox type, I’ll go with the RU waterfall–fanout method. If I’m using regular fiber-optics and MMF/SMF then the calculations sometimes change, depending on whether those are multi-lane MPO to single-port fanouts or port-to-port direct connections. Anyway, those acronyms aside, let’s move on.

In preparation for a hardware refresh and much needed colocation visit, I’ve ordered additional Mellanox DPUs. Those require a few additional cables to augment the existing hardware stockpile. I already have some 100G to 4x 25G breakouts, but not enough, and not in the correct lengths. Yay for ebay, all acquired for under $100 as “new old stock”.

What do those DPUs look like?

Well, for starters they don’t look exactly like these old ConnectX-3 QDR Infiniband NICs but the DAC are similar. Mellanox changed their heatsink aesthetic along the way, and the heatsinks are far larger on the newer chipsets, with no less cooling required (~200+ LFM).

Mellanox ConnectX-3 Infiniband NICs and QDR DAC from ~2015, photo circa 2022

Once the DPUs arrive - which is supposed to be today - I’ll take some photos and clean all of the PCBs and traces and slot connectors. In the interim, here’s the eBay photo for reference.

The big question… spend precious time with the R630 cluster in cab68, remove their ConnectX-4 Dual-Port 100G NICs, or install the BF2 DPUs to the cluster of IBM LC922 POWER9 systems in cab70… hmmmm.. 🤔 This decision will not be completed today. So, let’s think about cable maps and rack units.

Here’s a lazy ASCII diagram

Showing three lengths of DAC being used for rack-height designated connections, each cable SKU being 0.5M longer/shorter to account for the destination system’s location. DAC is heavy, so any time we can make the cable runs shorter we’ll (perhaps marginally) reduce latency while reducing load on the rack-cabling organizers, and generally resulting in a cleaner layout. The following diagram is not to scale for either cab68 or cab70, it simply shows how the waterfall method uses length-based drops.

+----------------------------------------------------------+
| RU42 | [Leaf Switch, QSFP28/56]                          |
|      |  [P01..P16]                                       |
|      |     |                                             |
|      |     +-DAC-1 1.5m ——————————> [RU38] Server-A      |
|      |     +-DAC-2 2.0m ————————————> [RU32] Server-B    |
|      |     +-DAC-3 2.0m ————————————> [RU26] Server-C    |
|      |     +-DAC-4 2.5m ———————————————> [RU20] Server-D |
+----------------------------------------------------------+

Labeling scheme:
  Leaf ports: P01–P16 (logical)
  Designators: 4x 25G lanes per 100G QSFP28 port (physical)
  Servers: A,B,C,D with SFP28 1–4 (A-1, A-2, A-3, A-4)
  Cables: DAC-1..4 with length tag (DAC-3 2.0m)

Where are these new DAC?

On their way… hopefully sooner than the stated arrival.

[update] Guess What Showed Up?

One of the correct SKU with correct firmware and PCB revision (MBF2H332A-AECOT Rev-C1 2022-02-15), and three of the same SKU without the correct firmware or PCB revision. So, three of them will not work for this project, and in an ideal world the vendor will reship the correct ones quickly.

]]> Serial RS232 + Crossover Keystones https://winterschon.gitlab.io/en/posts/serial-rs232-crossover-keystones/ Sat, 20 Sep 2025 22:07:07 +0000 https://winterschon.gitlab.io/en/posts/serial-rs232-crossover-keystones/ HomeLab, Networking, Cables… let’s look at the requirements for building custom keystone jacks and RS232 serial cables. A minor discussion of the core components is necessary before looking at the technical aspects.

This post was written over a series of months, initially as lab notes, with some bits and bytes added each time the tools come out or the patch panels are rewired. While perhaps not a common task, hopefully the knowledge finds someone else looking for these solutions.

Switch-Port System Roles

This post discusses several types of connections and signals conversion in a field where the list of potential operating modes is prone to complexity. Brands involve APC, Avocent, Blackbox, Cisco, Cyclades, Moxa, Netshelter, OpenGear, Vertiv, and more - but here in my HomeLab and in the enterprises in which I’ve worked, there’s a common requirement for critical equipment to talk to a System Infrastructure Manager system or OOB device.

System Infrastructure Manager

Featured in the post’s header image, I’m using Blackbox for OOB services, but these specs are matched by various brands in similar price points.

Device: BlackBox model LES1248a out‑of‑band (OOB) connection manager
Specs: 48‑port, 1U, dual-PSU, dual-LAN, cellular 3G and POTS optional

Provided Features

  1. Remote access services using web-based serial console interface for infrastructure devices (switches, routers, PDUs, UPS, etc).
  2. Centralizes remote‑management via multi-protocol connections and bridging between serial devices and user-facing network services.
  3. Access‑control lists (ACLs) and role‑based access control (RBAC)
  4. Monitoring, logging, and alerting

Reference: Generic Pin Mapping for 8P8C RJ45

This represents the usual 8P8C RJ45 connector layout, with pin usage according to different serial standards. While we are focused on RS232, it can be helpful for visualization purposes to see how other standards are implemented.

Pinout EIA‑232 EIA‑422 EIA‑485 Full Duplex EIA‑485 Half Duplex
1 (in) DCD
2 (out) RTS TxD+ TxD DATA+
3 (in) DSR
4 (out) TxD TxD‑ TxD‑ DATA‑
5 (in) RxD RxD+ RxD+
6 GND GND GND GND
7 (in) CTS RxD‑ RxD‑
8 (out) DTR

Working with Keystone Connectors

Those 48 ports aren’t going to fill themselves up without some occasional head scratching along the lines of..

Q: “How can I connect this RJ12 RS232 based APC PDU to a RJ45 RS232 infrastructure manager?”

A: You’re going to have to convert the pin-out for an RJ12 cable to the expected pin-map of an RJ45 RS232 rollover cable.

Great. I have those requirements!

Let’s see the various pin and cable maps involved with some common use cases. We’ll get to the RJ12 content, but let’s see standard mappings first.

1) Standard Ethernet, 8P8C Straight-Straight

These are simple and have no pin conversion to map. This is a basic reference only, there’s nothing to do.

J1 (Keystone Front) J2 (Keystone Back)
J1‑1 → J2‑1
J1‑2 → J2‑2
J1‑3 → J2‑3
J1‑4 → J2‑4
J1‑5 → J2‑5
J1‑6 → J2‑6
J1‑7 → J2‑7
J1‑8 → J2-8

2) Cisco Rollover, 8P8C Switch-Crossover

Standard rollover cable pin-map. In this case it’s what we want to use when connecting a Cisco style switch to our Blackbox (both with RJ45 RS232 ports).

Pin Signal Direction
1 DCD in
2 RTS out
3 DSR in
4 TxD out
5 RxD in
6 GND (none)
7 CTS in
8 DTR out

Keystone Pins, 8P8C Switch-Crossover

My patch panels use keystone jacks to simplify things, and they ship with straight-through RJ45-RJ45 connectors which do not change the wiring. That’s fine in some cases, but let’s see what we need to do to build a custom crossover keystone jack.

J1 (BlackBox side) J2 (Cisco side)
J1‑2 (RTS) → J2‑8 (CTS)
J1‑3 (DSR) → J2‑2 (DTR) (optional)
J1‑4 (TxD) → J2‑6 (RxD)
J1‑5 (RxD) → J2‑3 (TxD)
J1‑6 (GND) → J2‑4 (GND)
J1‑7 (CTS) → J2‑1 (RTS)
J1‑8 (DTR) → J2‑7 (DSR)
J1‑1 (DCD) → — (no connection to J2)

3) APC PDU Conversion, 6P6C RJ12 → 8P8C RJ45

  • APC PDU side: 6P6C RJ12 connector with grey ethernet cable
  • Blackbox side: 8P8C RJ45 connector with grey ethernet cable

RJ12 6P6C Connector for APC (940-0144A)

While APC has more than one RJ12 connector on their products, this one is the most common from my SKU usage in the enterprise.

Pin Signal Direction / Notes
1 — No connection (NC)
2 GND Ground
3 TX Serial transmit to peer
4 RX Serial receive from peer
5 GND Ground
6 — No connection (NC)

Keystone Pins, 6P6C RJ12 for APC PDU

This is where things get fun? We have an 8-pin cable on both sides of the jack, but only 4 pins are needed on the APC RJ12 side. Look closely and plan ahead when you’re chopping wires and punching connectors.

Rj45 Blackbox View

J1 (BlackBox side) J2 (APC side)
J1‑1 (DCD) — (no connection to J2)
J1‑2 — (no connection to J2)
J1‑3 — (no connection to J2)
J1‑4 (TxD – out) J2‑4 (RxD – input to APC)
J1‑5 (RxD – in) J2‑3 (TxD – output of APC)
J1‑6 (GND) J2‑2 (GND) and J2‑5 (GND)
J1‑7 — (no connection to J2)
J1‑8 — (no connection to J2)

Rj12 APC View

APC RJ12 (6P6C) Console RJ45 (8P8C)
pin 1 – –
pin 2 GND pin 4 GND
pin 3 TX → pin 6 RXD (into console)
pin 4 RX ← pin 3 TXD (out of console)
pin 5 GND pin 5 GND (optional second ground)
pin 6 – –

USOC (RJ‑12) Pinout

Pin (L→R) Colour (typical US C) Pair
1 White P3
2 Black P2
3 Red P1
4 Green P1
5 Yellow P2
6 Blue P3

RJ‑45 (T568B) Pinout

Pin (L→R) Colour (T568B)
1 White‑Orange
2 Orange
3 White‑Green
4 Blue
5 White‑Blue
6 Green
7 White‑Brown
8 Brown

Both USOC/T568B tables assume the connector tab is facing down and the pins are read left‑to‑right.

Regarding Flow Control - DSR/DTR Assertion

Fun times with RS232 sometimes involve flow-control, though often this is set to “None”, there are more options than None where None is concerned. Let’s see why Blackbox offers the following options, given the following debugging scenario:

Defining a Common Flow Control Issue

Problem: Blackbox shows incomplete port status*, with no terminal output when connecting via Cisco rollover cable.

[*] (“RTS | DTR” instead of “RTS | DSR | DTR | DCD”)

Signal Debugging Workflow
Configuration Action Purpose
1. Validate “Hardware Flow Control” Enable sampling Detect carrier signals
2. Pinout Verification Check mappings Ensure proper signal visibility
3. Signal Testing Use multimeter Confirm remote device asserts DSR/DCD
4. Manual Carrier Assert Add loop adapter Force carrier presence
Inspecting Flow Control Modes
Configuration Result
None - Default Take no action
None - Flow control signals unpowered FC signal pins explicitly disabled
Hardware (implied: signals are powered)
Software (implied: signals are powered)
Software - Flow control signals unpowered FC signal pins explicitly disabled
  • Q: What, surely the two None types are equivalent?
  • A: They are not equivalent.

The port is usable in either “None-Type” modality only if TxD/RxD signals are present. The console server will report “No signal data available” when the connected Blackbox port is operating in the following states:

  1. not powering when it needs power
  2. actively sampling modem-control lines
  3. when the remote device side never asserts them

Confusions with State-Mode Usability

Using “None - Flow control signals unpowered” disables the port’s modem-line sensing, which prevents the appliance from reporting DSR/DCD/CTS.

  • Whether or not you can connect over the line depends whether the device has active TxD/RxD connection signals, irrespective of whether Blackbox knows about DSR/DCD/CTS state.
  • Alternatively, the remote device may never assert DSR/DCD, as many network-console ports don’t provide carrier signals, so the server has nothing to report.

Ok… What else?

Despite many efforts and assumptions, it’s a fact that RS232 is not going anywhere any time soon and it remains not simply useful but necessary.

The global view of serial connection usage includes datacenters, industrial automation systems, expansive cellular / broadband / telco networking hardware, mainframe connected terminals, all the way to a near-endless number of embedded systems. Good times, plenty of TxD/RxD signals to go around. 😄

]]> Sunday Homelab TPM OMGOSH https://winterschon.gitlab.io/en/posts/sunday-homelab-tpm-omgosh/ Sun, 31 Aug 2025 15:08:18 +0000 https://winterschon.gitlab.io/en/posts/sunday-homelab-tpm-omgosh/ It’s 0721 on a Sunday morning. I’m laying on the couch, pondering the facts of existence, still dealing with C19 Nimbus side effects, and going through a mental checklist for #HomeLab tasks which need attention.

During standard weekends, when not afflicted with the covids, all of the following tasks could be completed in a relaxing and reasonable pace. Perhaps two or three.. time will tell. 😌

  1. Remove all ephemeral hardware from 25U rack #2
  2. Swap out 4U APC 3kVA UPS for 2U APC 1.5kVA, in 25U rack #2
  3. Move ARM64 cluster from 12U rack to 25U rack #2
  4. Swap 1x APC PDU (metered only) for APC PDU (switched), in 25U rack #1
  5. Validate LACP map on EX3300-48T, rack #2
  6. Validate 40mm fan situation on EX3300-48T, rack #2
  7. Recable 3x 24 port patch panels, rack #2
  8. Deploy 1x 24 port patch panels, rack #1
  9. Replace all fans in 2U net-infra SmartOS node
  10. Finish firmware updates on all APC devices
  11. Upgrade firmware on all managed switches
  12. Validate 5GbE SFP+/BASET optic for FTTH on X710 NIC
  13. Install 3x SM863 SSD boot drives for Talos II Power9
  14. Install 3x 883DCT SSD storage drives for Talos II Power9
  15. Swap 2x10G Intel X550 for 4x25G QL41234 in Talos II
  16. Swap 2x 120mm & add 1x 92mm fans in Talos II
  17. Ident 1000W PSU for EPYC box, needs PMbus
  18. ooooh there’s so much more…

rack consolidation strongly needed

Ehrlich gesagt, just look at this mess, and it’s on carpet? Even with solid 14 gauge copper grounding straps on every UPS, PDU, ATS, along with GFCI + AFCI isolation breakers, I cannot in good conscience recommend such blasphemy of electrical code compliance concerns.

So, add this to the list: find some manner of solid platform with a grounding-strap for the two 25U racks (12U needs to be elsewhere, byeeeee).

]]>