{"id":3249,"date":"2018-01-10T13:43:15","date_gmt":"2018-01-10T18:43:15","guid":{"rendered":"https:\/\/antipaucity.com\/?p=3249"},"modified":"2018-01-10T13:43:15","modified_gmt":"2018-01-10T18:43:15","slug":"but-i-got-them-on-sale","status":"publish","type":"post","link":"https:\/\/merikebi.warrenmyers.com\/?p=3249","title":{"rendered":"but, i got them on sale!"},"content":{"rendered":"

Back in August 2008, I had a one-week “quick start” professional services engagement in Nutley New Jersey<\/a>. It was a supposed to be a super simple week: install HP Server Automation<\/a> at BT Global<\/a>.<\/p>\n

Another ProServe engineer was onsite to setup HP Network Automation.<\/p>\n

Life was gonna be easy-peasy – the only<\/em> deliverable was to setup and verify a vanilla HPSA installation.<\/p>\n

Except, like every Professional Services engagement in history, all was not as it seemed.<\/p>\n

First monkey wrench: our primary technical contact \/ champion was an old-hat {{Sun Solaris}} fan (to the near-exclusion of any other OS for any purpose – he even wanted to run {{SunOS}} on his laptop).<\/p>\n

Second monkey wrench: expanding on the first, out technical contact was super excited about the servers he’d gotten just the weekend before from Sun because they were “on sale”.<\/p>\n

It’s time for a short background digression. Because technical intricacies matter<\/a>.<\/p>\n

HP Server Automation was written on Red Hat Linux. It worked great on RHEL. But, due to some [large] customer requests, it also supported running on Sun Solaris.<\/p>\n

In 2007, Sun introduced a novel architecture dubbed, “Niagara”, or UltraSPARC T1, which they offered in their T1000<\/a> and T2000 series servers. Niagara did several clever<\/a> things – it offered multiple threads running per core, with<\/a> as many as 32 simultaneous<\/a> processes running.<\/p>\n

According to AnandTech, the UltraSPARC T1 was a “72 W, 1.2 GHz chip almost 3 times (in SpecWeb2005) as fast as four Xeon cores at 2.8 GHz”.<\/p>\n

But there is always a tradeoff. The tradeoff Sun chose for the first CPU in the product line was to share a single FPU (floating point unit) between the integer cores and pipelines. For workloads that mostly involve static \/ simple data (ie, not much in the way of calculation), they were blazingly fast.<\/p>\n

But sharing an FPU brings problems when you need to actually do floating-point math – as cryptographic algorithms and protocols all end up relying upon for gathering entropy for their random value generation processes. Why does this matter? Well, in the case of HPSA, not only is all interprocess, intraserver, and interserver communication secured with HTTPS<\/a> certificates, but because large swaths are written in Java, each JVM needs to emulate its own FPU – so not only<\/em> is the single FPU shared between all of the integer cores of the T1 CPU, it is further time-sliced and shared amongst every JRE instance.<\/p>\n

At the time, the “standard” reboot time for a server running in an SA Core was generally benchmarked at ~15-20 minutes. That time encompassed all of the following:<\/p>\n