Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Our $100M Series B

oxide.computer

Post reply on HN
Print view View original

451–460 of 522 posts

Re: Our $100M Series B

#451

Post by cpach »

AngryData wrote: post #431
cpach wrote: post #106

Earlier quoted context omitted.

I’m not sure I follow. In what market(s)?

Agriculture has a lot, utility services including fiber internet, electrical, and natural gas, many credit unions, there are a few retail stores like REI, mutual insurances, a number of pharmacies and homecare and other health services are co-op, many other worker co-ops, and there are a decent number of housing co-ops. Other than maybe a few rural fiber co-ops most are not super fast growing businesses, and they lac…

Cool!

Re: Our $100M Series B

#452

Post by mustyoshi »

doctorpangloss wrote: post #447
sudomateo wrote: post #443

Earlier quoted context omitted.

Similar to what others noted earlier I'm having trouble understanding exactly what you're trying to communicate here. I'll respond based to points I am clear on. Selling a customer a contract for on-premises computing and giving them a fake metal box and SaaS is borderline unethical depending on the terms of said contract. I understand the sentiment of that point though. There are many reasons a customer chooses to o…

there's seriously nothing complicated about this. Define ownership. Who cares about owning a bunch of computers? If you can get the compute, and you pay up front for it once, and then you can sell "it" later, and it's cheaper than renting, what does it matter if the compute comes in the form of a physical box or if it is in the cloud? So these are all things that matter about ownership! To me, occupying a physical sp…

I'm not part of Oxide, but I think you're assuming everyone is okay with not controlling the hardware they run on.

There is plenty of addressable market where a public cloud or even a colocation of hardware doesn't make sense for whatever bespoke reason.

I don't think their target customer is startups, and that's okay. You likely aren't their target customer. But they've identified a customer profile, and want to provide a hardware + software experience that hasn't been available to that customer before.

Re: Our $100M Series B

#454

Post by syntheticgate »

hinkley wrote: post #420
syntheticgate wrote: post #395

Earlier quoted context omitted.

At a certain point in EE power design you don't really want to go from 54V -> point of load for every rail (1.8V, 1.1V, 0.9V, SVI3 rails etc), so sticking with an intermediate voltage makes sense often even when viewing this from an efficiency perspective. Voltages such as 54V require different creepage and clearance requirements, so saddling every point of load regulator (of which we have many many!) with those requ…

The thermal dissipation is a function of the current squared. The heat in the conductor is a function of the size of the conductor and the surface area for heat dissipation. So these high current common rail systems you can sometimes see in youtube videos for power distribution, have great honking bars of copper in them. And in most of the videos I've seen, the video is about someone screwing one of these up, damagin…

In Oxide's design, we do have a 54V DC busbar so that's what the rectifiers put out, and runs vertically up and down the back of the rack. The power connection into each of the cubbies for the sleds, and the power into the sidecar switches connect to this bus bar at 54V. Each of these assemblies has an intermediate bus converter IBC that does the 54->12V conversion on board and 12 and other lower rails are used for the various supplies required.

We do run the 54V to our fans (in both sleds and switches) without additional DC-DC conversion as those can be fairly power hungry and we can buy reliable fans that are rated for this voltage.

Our sleds actually don't connect directly to the bus bar to help mitigate some of the "oops" factor as they're going to be potentially mated and unmated buy customers as they reconfigure, upgrade or support things. The sled cubbies are wired to the bus-bar and support hot insertion of the sleds. And yes, while possible, an in-field replacement of the bus bar wouldn't be fun, but in our design it's a big copper bar hidden away so the risk of damage or dropping stuff into is minimal.

So our 12V IBC design gets us into more normal range for commodity point-of-load supplies, and balances the losses due to higher current at 12V vs the complexity of dealing with 54V all over the boards. For the AMD parts, we also have to have supplies that deal with SVI2 or SVI3 where the part itself can adjust its voltage at run-time for efficiency. These are pretty complicated devices (like the RAA228218) that we're happy to not have to design ourselves and they have expected operating envelopes for their supply-side rails that don't work at 54V.

Re: Our $100M Series B

#455

Post by steveklabnik »

purpleidea wrote: post #430

Building sovereign systems management with low overhead is an incredibly important goal. For this I salute them for pursuing that path. However their mistake is that it's a hardware problem. It's actually almost entirely a software problem, modulo convincing some hardware vendors to make their ILOM/IPMI implementations not be buggy or suck. Disclosure, I work in the software automation space.

We are doing both hardware and software. We don’t use vendor IPMI stuff, and have instead implemented our own stack for it. You’re absolutely right!

Re: Our $100M Series B

#456

Post by cpach »

unicornhose wrote: post #388
neom wrote: post #83

I'm a Bryan Cantrill fan so I'm glad this is working out, I was extremely skeptical of them at the beginning(on HN too), I think because I've built DCs for many years and was stuck in a mindset that served my use case, I've come around to Oxide. My main concerns originally were 2 fold: "this seems bougie", is there actually a market for this, and, is there a good interoperability story with mix and match. From what I…

I must admit that I am much more unsophisticated than this, and yet I "invested" in Oxide (by running my own projects off Oxide servers), and it is gratifying to see them continue to grow. My (naive) assessment: (a) agreed with Cantrill's opinions on software, (b) liked his willingness to put himself out there, and (c) felt the eng blogs showed a high level of (socio-)technical ability. I think for the internet to br…

Did you order a unit from them or how did you manage to get access to the Oxide hardware?

Re: Our $100M Series B

#457

Post by ShroudedNight »

doctorpangloss wrote: post #447
sudomateo wrote: post #443

Earlier quoted context omitted.

Similar to what others noted earlier I'm having trouble understanding exactly what you're trying to communicate here. I'll respond based to points I am clear on. Selling a customer a contract for on-premises computing and giving them a fake metal box and SaaS is borderline unethical depending on the terms of said contract. I understand the sentiment of that point though. There are many reasons a customer chooses to o…

there's seriously nothing complicated about this. Define ownership. Who cares about owning a bunch of computers? If you can get the compute, and you pay up front for it once, and then you can sell "it" later, and it's cheaper than renting, what does it matter if the compute comes in the form of a physical box or if it is in the cloud? So these are all things that matter about ownership! To me, occupying a physical sp…

It's not clear to me that the counter-party risk is _remotely_ similar between the two offerings. Someone reselling indefinite access to AWS could relatively easily set things up to go "poof" after a few years, whereas if it's your box, that's not possible. Now, critical components of the box could croak, and someone could still be screwed, but even there, you likely have more options for support than just paying Amazon's ransom.

Re: Our $100M Series B

#458

Post by steveklabnik »

doctorpangloss wrote: post #434
steveklabnik wrote: post #422

Earlier quoted context omitted.

> what stops a bank from selling "virtual racks" that work financially the same as owning an Oxide rack, but it's just AWS? I'm struggling to understand what you're suggesting here, to be honest. First of all, banks don't sell cloud compute, so no bank is going to do that. Secondly, what does "work financially the same" mean? These are fundamentally different products, AWS is a service, Oxide is purchasing hardware t…

> I'm struggling to understand what you're suggesting here, to be honest. First of all, banks don't sell cloud compute, so no bank is going to do that. Secondly, what does "work financially the same" mean? These are fundamentally different products, AWS is a service, Oxide is purchasing hardware that you then own. You're telling me it's important to people to "own" instead of "rent." Well I can manufacture an "Own" o…

> You're telling me it's important to people to "own" instead of "rent." Well I can manufacture an "Own" out of a "Rent": I write up a contract for my customer that says "$1,000,000 for 100 EPYC servers", I ship an empty steel box, the end user gets an AWS account which they cannot add anything to, and it has 100 EPYC server metal instances in it. I pay the bills in that account. Okay? Now I have created "owning" out of renting.

No, you haven’t. You didn’t deliver what was paid for. This wouldn’t be accepted.

> Do you see?

I’m sorry, but I do not. You’re not describing a business. You’re throwing some numbers out to describe a fraudulent enterprise.

> what is really the material difference between cloud and on-premises compute, when the interfaces between the two look so similar?

The material differences are around capex vs open spending, that you can locate your own hardware where you want to (which matters for things like “must be in a colo in southern Manhattan” (or any of the other reasons why physical location matters for latency reasons) or “must not leave the soil of $COUNTRY”), and the entirety of “TCO of owning is cheaper than renting for many workloads.” That’s just some of the larger obvious ones.

Re: Our $100M Series B

#459

Post by kev009 »

doctorpangloss wrote: post #447
sudomateo wrote: post #443

Earlier quoted context omitted.

Similar to what others noted earlier I'm having trouble understanding exactly what you're trying to communicate here. I'll respond based to points I am clear on. Selling a customer a contract for on-premises computing and giving them a fake metal box and SaaS is borderline unethical depending on the terms of said contract. I understand the sentiment of that point though. There are many reasons a customer chooses to o…

there's seriously nothing complicated about this. Define ownership. Who cares about owning a bunch of computers? If you can get the compute, and you pay up front for it once, and then you can sell "it" later, and it's cheaper than renting, what does it matter if the compute comes in the form of a physical box or if it is in the cloud? So these are all things that matter about ownership! To me, occupying a physical sp…

You are casually transitioning between something that is pretty well understood through the history of online commercial computing (i.e. 1970s): 1) owned hardware versus leased/timeshared/rented hardware or services and 2) concepts of financial instruments that many readers here are probably not intimately familiar with.

If I needed a generator to run a remote mining operation, and you just told me to just buy energy futures instead, we'd be having a silly discussion. Whether it makes sense for me to rent or buy the generator has more to do with governments, [,tax ]laws, and risks that ultimately manifest as cashflow decisions. You have some valid thread you are pulling on for what are the economics of general purpose compute and to whom, but your argument needs a lot more care to carefully define and make your case and why it is okay to dismiss the outlier cases for instance.

Re: Our $100M Series B

#460

Post by syntheticgate »

jeffbee wrote: post #412
syntheticgate wrote: post #395

Earlier quoted context omitted.

At a certain point in EE power design you don't really want to go from 54V -> point of load for every rail (1.8V, 1.1V, 0.9V, SVI3 rails etc), so sticking with an intermediate voltage makes sense often even when viewing this from an efficiency perspective. Voltages such as 54V require different creepage and clearance requirements, so saddling every point of load regulator (of which we have many many!) with those requ…

It's certainly the current mainstream style to have an intermediate voltage rail of 12V or more. But this OCP talk from a few years ago was interesting, showing a prototype direct 48V-1V conversion with high efficiency. https://www.youtube.com/watch?v=JQHiKIfrwI0

Yes it certainly can be done, but there's a cost and design complexity with doing that too. I did a quick count of gimlet (our server sled's) power rails and got to over 26 different power domains, and I probably missed a few in my quick scan! It's unclear to me if the efficiency gains from re-doing these with something more exotic to go from 54V would make enough of a difference to justify doing so, and we'd still end up with some stuff like the SVI2/3 controllers needing an intermediate rail (or have to go design those ourselves too) and some analog rails needing LDOs for noise rejection reasons etc. As mentioned before, creepage and clearance at higher voltages cascades into layout complexity and pain if you have to run it everywhere on the board: but for the same reasons we're talking about this, we can't very well do a 54V:1V conversion in the back of the sled and run it all the way to the front- losses, noise etc.

As with all things engineering is a series of tradeoffs and right now, an IBC from 54V to 12V has been a reasonable design point for us.

Post reply on HN