• 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…

• NIC #1, QLogic QL41164HLRJ, 4x 10GbE BASE-T,
• NIC #2, Supermicro AOC-S40G-I2Q, 2x 40GbE QSFP+, Intel XL710
• NIC for Nodes: Qlogic QL41234HLCU, 4x 10/25GbE SFP28 w/ RDMA

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.

Adjusted Query: how much storage space would the user deploy to an existing multi-Petabyte array, with consideration to physical limitations in systems design which prioritize two common architectural decision targets: More or Faster?

(1) maximizing raw-block capacity
(2) maximizing I/O performance

TL;DR

Between 4-5PB is the simplest answer, but those are just numbers. Could be 10x either, but that’s not realistic - it’s conjecture. The full picture requires insight into physical limits of the transfer time, storage space, rack space, and rotational speeds involved; spacetime could be analyzed by the right minds if this were JPL ^_^ .. instead of limited to hardware I’ve acquired over a small handful of years.

Hypothetical or Reality

Let’s say that I contacted the datacenter and ordered additional power circuits to light-up additional drive shelves, which are already installed (minus the box of drive trays which are in a massive box on a parts shelf in my home office). Ok, reality checks out there.

The circuit drops would go to the central storage rack which is currently at 84% power limit. I know this because power is monitored and validated via a combination of Check_MK + Prometheus + SNMP exporters, which poll power stats remotely from the cabinet’s APC ATS, the rack’s per-port metered and switched outlet PDUs, and then if I really want to I can look at the DC’s circuit stats (via MRTG) which are tracked for the cabinet. Reality checks out there decently enough. Moving on…

The Hypothetical

First we’ll cover some raw numbers and theoretical maximums by looking at two high-level approaches required for “More or Faster”.

The astute reader may wonder why we’re not discussing >100TB QLC NVMe drives or ultra-dense E2 ruler-style 2U chassis, and the answer is that those calculations are generally similar in equation workflow (eg: how many things of X can we put into Y at A,B,C performance/size/latency), however those hardware types are not currently racked in my real-world systems at an interesting scale. However, migrating to denser NVMe arrangements will likely be part of an eventual down-scaling forklift operation whenever the SAS3 arrays are no longer useful for my personal labs or colo bills.

Production is another story, where large format SAS3 is still relevant and being deployed and improved over time; in the last several years we’re seen drive capacity double, along with some innovative designs. It’s not often considered exciting, but it lasts A LONG TIME, and the NSA loves archiving the internet on this medium over in their Utah storage complex (overheard, surely).

So, back to the math…

Decision: Optimize for Faster (prioritize IOPs + bw)

Aggregate per-rack w/ 10x shelves of raw 4K block = 3,824 TB == 3.72 PB

Decision: Optimize for RAW Storage Capacity

How about the same hardware focused on max-total raw space with less regard to per-drive IOPs (perhaps we offset the latency reduction per-drive via larger L1ARC and L2ARC buffers on the head-nodes, which becomes a loaded tangent)… then the rack could be upgraded to host 4.85PB @ $800/m MRC ($400/m cabinet + $400/m amperage)**.

We’ll also save the conversation about concessions made at time of contract signing where I might / maybe / surely have saved on recurring costs by locking-in a multi-year multi-rack contract. Sales team, thanks!

What is this MRC, MRR?

MRC in this situation is the ‘Monthly Recurring Cost’ for power + rack. This value does not include the cost of acquired hardware, which is variable on supply-chain sourcing and other factors. I’m also not going to describe potential MRC or MRR offsets which factor into profit margin potential and/or influence EBITDA.

Ok, what is MRR and EBID..? Fine, at least with MRR it’s ‘Monthly Recurring Revenue’, and one can read all about EBITDA elsewhere.

What about Flash-Cache or Optane or Non-Volatile blah blah blah

Sure, those are considerations, where applicable. Some footnote notes…

• It’s prudent to deploy storage controllers with SLC NVMe or PMem/NVDIMM persistent cache (which are often a baseline performance requirement). These are sized anywhere from cumulative 1-12TB per-controller, depending on available PCIe lanes and/or NV-DIMM slots.
• It’s a good idea to make scoping decisions like that ahead of time, instead of later realizing that the controllers’ lanes are maxed out or all DIMM slots are used (or you bought 128GB NVDIMMs instead of 512GB, thinking “8x 128GB should be fine for PMem” or the other fun one about ignoring (or being unaware) about GHz speed reduction by running 4-DPC in a 2-DPC max-perf system.
• Those determinations may be either workload dependent, or in my personal life sometimes it qualifies as the “because I wanted to” type of maximalist methodology, or the “this is relevant for future proofing my own rationalization on fun hardware”, or could be considered a baseline in pre-sales because “they always want more performance eventually; just bake it in from the start”. It varies, but remember where you started and where any future requirements for performance headroom exists.

Where’s the Math?

Validation on spec baselines can be tedious, but anyway… the DE3-24C and DE3-24P have very shiny and well made Dual-Redundant IOMs with 4x SAS3 SFF-8643 connectors.

Specs for our SAS3 Fabric with DE3-24 Shelves

• One SAS-3 lane (PHY): 12 Gbit/s ⇒ 1.5 GB/s (raw line-rate, decimal GB)
• External SAS x4 port connector: 4 PHY × 12 Gbit/s ⇒ 48 Gbit/s ⇒ 6 GB/s
• Each DE3-24{C/P} has 2× IOM, with each IOM having 4× SFF-8643 ports

Drive Specs - Seagate EXOS & Oracle SSD

Scenario A – Maximum RAW Block Space

Before going into the theoretical weeds, let’s look at some per-shelf media limits.

1) Oracle DE3-24P shelf w/ 24TB Spinners**:** 24 × 285 MB/s = 6.84 GB/s (media-limited)

2) Oracle DE3-24C shelf w/ SSDs:

• Read: 24 × 2150 MB/s = 51.60 GB/s → capped by fabric at 36 GB/s (N=3)
• Write: 24 × 1980 MB/s = 47.52 GB/s → capped by fabric at 36 GB/s (N=3)

Scenario B: Maximum Performance

Hardware has limits, and we’re looking at 8× DE3-24P w/ 18TB Mach.2 HDD + 2× DE3-24C w/ 7.68TB SSD (N=3)

Aggregate sequential bandwidth (N=3)

• Mach.2 18TB HDD shelf: 24 × 554 MB/s = 13.296 GB/s (media-limited; below 36 GB/s fabric cap)
• SSD shelf: remains fabric-capped at 36 GB/s read and write (N=3)

Aggregate Random R/W 4K IOPS (N=3)

Fabric-derived 4K IOPS cap per shelf (upper bound):
36 GB/s @ 4KB = approx 8.79M IOPS

• SSD shelf
  • Read: 24 × 450k = 10.8M IOPs → capped to 8.79M IOPs
  • Write: 24 × 95k = 2.28M IOPs → media-limited (below fabric cap)
• Mach.2 HDD shelf (4K @ QD16)
  • Read: 24 × 304 = 7,296 IOPs
  • Write: 24 × 560 = 13,440 IOPs

Let’s See the Deltas!

What’s “a delta”? Sometimes it’s the headwaters of a bay, where the river distributes across a flood-plane into many separately-unified channels, eventually giving way to deeper waters and…. no no not that kind.

Delta as a value in storage is often used as a marker to show the differential of two functions which indicates directional change. At least, that’s what comes from my brain while I sit here having an ice cream sandwich, but it has some alternate terminology which applies irrespective of ice cream hour:

Delta uppercase Δ, lowercase δ
Uppercase: a change of any changeable quantity
Lowercase: the central difference for a function

~ The discriminant of a polynomial equation or symmetric difference of two sets
~ The determinant of the matrix of coefficients of a set of linear equations

Scenario B vs Scenario A (with N=3)

• Total sequential BW: 126.72 → 178.368 GB/s (increase +51.648 GB/s)
  • Primary determinant: per-shelf BW 6.84 → 13.296 GB/s (Mach.2 dual-actuator).
• SSD tier remains fabric-capped at 36 GB/s per SSD shelf under N=3; increasing N (or adding more independent uplinks with additional HBAs) is what changes that cap.

1. Faster array = less space @ higher IOPs and BW == 178 GB/s @ 3.8PB
2. Larger array = more space @ lower IOPs and BW == 126 GB/s @ 4.9PB

Equations w/ decimal units: 1 TB = 1000 GB

• jaja usually we work in 1024 (but I’m tired today, so not right now)

t_1TB(s)      = 1000 / BW_GBps
t_full(s)     = (Capacity_TB * 1000) / BW_GBps
t_full(hours) = t_full(s) / 3600
BW_density    = BW_GBps / Capacity_TB   (GB/s per TB)
              = 1000 * BW_density       (MB/s per TB)

So… what’s the answer? More, Faster?

Is bigger is better? Sometimes. Sometimes you need it faster. Sometimes you want both.

People in the industry are playing hard and fast, and whether those qualities may be considered a good thing is up for endless debate, but not right now. Right now I’m going to show some End of Year snapshots which are relevant to the blog’s purpose: wtf am I doing here anyway?

2025 was mostly extremely challenging, and mostly in helpful ways, but also featured a repetition of lessons which it seems I need to reflect on for additional forward momentum.

Let’s take a look at some of my core qualities as told by the oft-loved and oft-maligned OpenAi’s Chat-GPT 💟.

Your Year, Painted in Pixels

Very close, nice work GPT. While I do not have a 400GbE switch on my desk, I do have a few 100GbE 32-port switches in the racks, and occasionally 200GbE NICs and optics will float around the test bench.

The Architect Archetype ~ 3.9% of ChatGPT Users

It’s true! Over the 25 years of this career I’ve held architecture specific roles across the domains of Hardware Systems, Infrastructure Automation, Databases, and HPC Storage realms. It’s what I’ve always wanted to do, going all the way back to 1985 when introduced to the 4.77MHz IBM PC, Model 5150.

Personality: Specialist, Planner, Conceptual

That’s fairly accurate, more so if we add “spatial reasoning” to a list of cognitive methods.

“Thinks in structures and systems. Uses ChatGPT to design elegant frameworks and long-term strategies within a domain.”

A Datacenter in the Living Room?

Close in accuracy, however the “living room datacenter” is more commonly located in a home-office room (when living in an apartment), or in a dedicated area of the garage with HVAC filtration + dedicated 208/220/240V power, and the requisite automated cooling systems (usually Tripp-Lite units with duct-blowers). For systems at home the machines are often bought as separate server components along with a 4-5U chassis + rails + multiple sub-50 decibel large-format 120-180mm fans. Systems with high RPM 40-80mm axial screamers belong in a proper colocation facility.

How about that Homelab - is it in a constant state of flux?

Yes, mostly. It’s often helpful for proof of concept tests, hypothesis validation, and running benchmarks without having to drive to the DC or go back and forth with Remote Hands requests. Plus, lots of fun going on with hardware at home, but sometimes results in broken nails 😔.

Messy cables? Sometimes. Labels? Sometimes.

The homelab is often rebuilt: storage devices, fiber, dac, cables, and test clusters revised.

Homelab, sure… but how about those colocation photos instead?

As we’ve seen, some of the server hardware lives at home in my 25U shorty-racks, some is across the bay at a datacenter where big-loud machines require CRAC style cooling, and some of it is spread across the globe at other colocation facilities where The Providers have megawatt and gigawatt infra capacity. My personal infrastructure is a hybrid design, utilizing everything from embedded systems to multi-GPU hosts to public-cloud virtual machines… so, let’s see a bit more…

• Recent datacenter photos: https://prose.winterschon.com/a-recent-datacenter-colo-visit/

Your Chat Style

The analysis says… well, it’s fairly accurate for a description of being in-person as well as at the keyboard during remote meetings or daily chats.

Technical or otherwise, usually this is consistent. I’m often chatty, verbose, attentive, talkative, opinionated, even positively bubbly at times. Unless you catch me on a day where those qualities are supplanted by the clouds of quietly recalcitrant moods - the type which are grounded on a dualistic view of existence best described as Stoicistic-Nihilism, having been sourced from far too many post-traumatic stress events endured.

Your Chat Style: Direct, technically precise, often layered with humor and a critical edge, mixing structured reasoning with conversational spontaneity and sharp observational wit.

Your 2025 Chat Stats

Hold on now. I’ve used em dashes since 6th grade English class—so if seeing those in my writings is giving an impression that I use LLMs for all of my authoring is quite incorrect. For all of those people who don’t like them I have a solution: go to the settings section and set your rules and move on with your life. 😏

• Total Chats: 720
• Messages sent: 4,861 (not tokens, messages)
• Chattiest day: September 5th (why? we’ll need to see…)
• Images generated: 3 (Sora kinda sucks)
• Em-Dashes “Exchanged”: 1,882
• Top Messages Sent: 1% (percentile)

Regardless of those stats, even with my use of ChatGPT’s advancements with their “Pro Account”, most of my Ai/ML occurs on self-made infrastructure. I don’t rely on closed source, I don’t like closed source, and I don’t like non-democratized intelligence services that are just in it for profit. My career was built on Open Source and this current infra uses tooling like Ollama, Open-WebUI, vLLM, llama.cpp, CUDA, PyTorch, ROCm, and many other examples of collaborative ingenuity - free to use, free to improve, so please contribute if you can.

Three Big Themes of 2025

1. Building Ultra-Low-Latency Systems (true)
2. Experimenting, Measuring, Refining (true)
3. Engineering Meets Everyday Life (true)

Thoughts on 2026, Ai Industry Trends != Rules

Working in the Ai/HPC/ML industry, an observable fact is that the majority of consumer-facing Ai companies are still trying to figure out this new landscape, how it works, why anyone should care, and how to monetize whatever it is that they’re focused on.

Most will repeat the errors of the past, most will fail, most will malign the tech while misunderstanding nearly everything about the topic; and that’s fine. That’s the routine in Silicon Valley, but it doesn’t have to be.

1. We cannot solve today’s problems with yesterday’s methods, and that is a simple fact. We need the core technologies involved with Ai in order to resolve the massive amount of tech debt from earlier generations, but we need to stop expecting the same success from the same methods from the past; this is not the same world as 10, 20, or even 5 years ago.
2. The current anti-Ai mentality in mass-media is occurring despite companies like IBM, Cray, Fujitsu, BullSequana, and a handful of others with Top-500 dominant postures being focused on Ai-enabled Supercomputing, HPC, and acceleration hardware domains for well over two decades. These clusters have been active at research facilities with names like CERN, Technion, and of course the DoD and Military labs. These clusters keep us safe, they advance human understanding, assist with solving otherwise unsolvable problems, and are used to maintain the systems and functions our current world relies on for security and the advancement of human potential.
3. Ai is not just chatbots, it’s not limited to multi-modal agentic buzz-words, but that’s a tangent for another day. Datacenters are not ruining the world like mass-destruction of rainforests just so people can eat more cows. Conversely, we have an entire section of the Supercomputing industry focused on green energy and resource efficiency. Medical advancements, brain research, climate science and modeling, cancer research, etc… all of this is and has been advanced by Ai - but it’s not from the consumer side and it’s not how the media presents the information. Gosh, I wonder what incentive the media has to engage in such maligning tactics?

How Do We Move Forward?

In spite of or despite anti-Ai sentiments, while the public-facing corporate marketing landscape fights for “Consumer Economy Dominance”, engineers and architects like myself are busy in the background innovating with (sometimes our own) Ai/ML systems and (sometimes our own RSU/ISO/BST* funded) heavy-compute big-data storage infrastructures.

People like myself do this because we love it (mostly, nothing is perfect), and because we want to improve the lives of those around us, not to simply make money and acquire material goods. These skills require compromise, dedication, attention to detail, and a deeply held desire to improve the human condition through personal investment of time, mentoring younger engineers, and the occasional runway.

TOGETHER WITH THE AIs WE WILL BUILD A BETTER ULTRON

Kidding, mostly. Ultron had some good philosophical points, but we’re not in Strawberry Fields or the BS about paperclips from unimaginative and uninformed bloggers; this is real life and The Terminator is not around the corner. Pass the espresso and let’s check the local-node TTFT and CHRs to see how SkyNet is doing. ❤️

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.

🙉 🙈 🙊

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.

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.

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.

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).

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.

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.

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

Rj12 APC View

USOC (RJ‑12) Pinout

RJ‑45 (T568B) Pinout

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

Inspecting Flow Control Modes

• 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. 😄

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).

• 1x Nvidia Jetson Xavier NX 16GB
• 3x Nvidia Jetson Orin NX 16GB
• 3x GoWin R86S, N6005 16GB
• 2x Pi-KVM v4-mini for remote/headless access
• 2x NanoPi nodes, a RISC-V LeechiPi, and LattePanda Mu
• Associated networking for 10/5/2.5/1G ports

Setup in a Pelican Air case, ready for the flight!