Google: We look forward to running non-Intel processors in our cloud Google has gently increased pressure on Intel – its main source for data-center processors – by saying it is "looking forward" to using chips from IBM and other semiconductor rivals. The web advertising giant said it hopes to use a mix of "architectures within our cloud" in the future. Back in April, Google revealed it had …
AMD uses the same architecture as Intel and is so-so financial shape. Google is looking at other architectures to keep Intel's pricing honest especially if AMD goes belly up. The technical issues will largely be transparent to the user so if this works well the user will not care and Google (and others) have other supplier options.
Amd hasn't refreshed their server chips in years. I still have a bunch of opteron 6xxx i like the chips and hope their new shit is good, gave up hope for them since they abandoned their high end chips and I assume lost a lot of the engineering talent behind them. HP has gone 2 generations of servers with no AMD.
My latest servers are 18 to 22 core intel though. If AMD comes out with lotsa cores for vmware even if the per core performance is lower I'll buy some for vmware servers for sure. As is core for core the intel chips are 2x faster than my AMD. I don't think I'd accept a 50% performance hit for new AMD chips unless there is perhaps double the number of cores.
More curious to me is it sounds like they have no ARM either. Which given google's scale surprises me that they wouldn't have some in there. Guess ARM on servers sucks more than I thought.
Which given google's scale surprises me that they wouldn't have some in there
Shouldn't do. Google are a 99% Intel shop. The purpose of this little flurry of news is to try and gain some leeway in (I suspect) another round of framework purchasing negotiations. Until ARM, IBM, AMD have some credible market share in server chips, and the prospect of Google defecting is real, this won't have too much effect on Intel - it's just a long term threat.
And if server makers don't start actually buying those alternatives in volume, then the makers won't develop their technology (like AMD haven't), and the Intel monopoly will continue.
I see VGA D-sub on the diagram. Something which has been abandoned by all PC makers in newer models.
1. WTF is the function of a VGA in a cloud server in the first place
2. If it is a video, why a spec that is known to be obsolete instead of HDMI or Displayport (they take slightly less space too).
Because it's a pain in most cases? VGA over IP has been good for a decade. Serial works alright but still often painful to use. I remember the last time i had serious serial console use a decade ago, in servers with 3ware raid cards. Everything worked fine outside of the 3ware raid bios.
HP servers automatically detect serial and switch to CLI (or they did last time I ran serial on them years ago). But setting options via CLI took much longer than using the ANSI GUI. Last I tried again yeara ago installing esxi interactively via serial not possible either.
So nice option to have but will take HP iLO advanced over serial in a heatbeat. I've even just for shits and giggles installed esxi 5
5.5 via ISO from my phone at a bar using xenapp, iLO advanced and remote desktop.
1) Because it's the means by which you install the OS, or at least configure it for network boot in order to make it install an OS as needed. And diagnose problems or view error messages that prevent network connectivity. And do firmware configuration.
2) Because it's cheap, and because VGA KVMs are really, really cheap, including the sixteen-port-per-unit, stackable sort of KVM you want in a datacenter.
1. That's most certainly not how you install OS if you have more that handful of servers. It also not how you diagnose issues on servers.
2. No one putting KVM in datacenters anymore for at least 10 years, everything you might ever need can be made available remotely to any part of the world.
No one putting KVM in datacenters anymore for at least 10 years, everything you might ever need can be made available remotely to any part of the world.
And how many server rooms have you graced with your presence in that time? Yet again somebody assumes that all servers can be configured and monitored from the network even when said network is stuffed up...
"And how many server rooms have you graced with your presence in that time? "
More than 50K of servers installed in around 10 data centers and yes, all of them were configured and are managed remotely, simply because all of them a lights out datacenters where techs come only to replace hardware.
So, no, I do not assume, unlike you, I know for the fact.
VGA's death will come. But not just yet. At the moment there's still the question of why *wouldn't* you put VGA in a chassis? Space isn't too much of an issue and you get a ubiquitous output that may only be used a couple of times on one out ten machines built, but that sysadmin using it will be very glad it was there that day.
Let me see, Google are converging on 48V servers running their own designs and slightly exotic chips from anyone but Intel. I'm having a flashback to the days of Ma Bell: Nortel DMS-10, Lucent 5ESS and pretty much anything that runs in the traditional phone network. Ironic really, because telcos today are moving full-tilt the other way, running everything in x86 VMs.
With one notable exception: transcoding on x86 is a dog. It's a general purpose CPU so will never be a efficient as the DSPs. Will be very interesting to see how Goog solves that. Oh and the ridiculous patent rules around codecs :)
I've been seeing PCIe cards built specifically for speeding up virtualized telco servers. The cards are equipped with an FPGA or ASIC that is loaded with hundreds of DSPs and some session management logic. There isn't any reason why they couldn't work on other architectures, so long as they speak PCIe (And drivers are available for the platform).
Names please? Sounds interesting.
Someone else on this thread commented about YouTube, but that's not what Bob Ajob had in mind I think. Non-real-time transcoding is "straightforward". AWS has transcoding as a service for example for cases like this. But try wideband voice to G.711 in real time, without dropping a single packet, and life gets much more interesting.
48V is very standardised from probably before WWI and often Exchanges, Industrial controllers, comms gear on masts, etc. Standard PSUs. Probably used in other things too as it's a sort of maximum voltage allowed to be regarded as "low voltage". 12V is too much current. Mostly 12V is domestic and cars and 24V only trucks and some larger SUV type things or mobile/vehicle Military.
48V is also the "normal" voltage for PoE (PoE provides 15.4W, PoE+ provides 30W). I doubt if these bits of kit will run over PoE in a fully loaded configuration, as in with the PCIe buses fully populated, but it may possible that the basic configurations could particularly as Google and others tend to spec low power kit both for energy cost and heat dissipation reasons. Also, running a consistent power supply voltage makes the deployment of power rather simpler and less prone to potentially expensive mistakes.
Google might be tempted to stick with POWER. It's open so they can if they wish tailor it anyway they want. They can know for certain what they're actually doing (Intel's blob is questionable at best from a security point of view). And, if they wanted, they could probably make them themselves, cut out Intel and their dividend-demanding shareholders altogether.
Not to mention that Intel is no longer the leader in the fabrication process. Well, not for much longer anyway, with both TMSC and GF pursuing 7nm quite aggressively.
At this moment Intel's biggest advantage is established (actually, it well past the point it should have been called "legacy") instruction set and binary compatibility going back decades. But that means little for a company with enough software developers to invent their own (and successful for that) language.
Apparently not, if another poster is right and google is 99% intel. Intel also has scale so lower cost right there. I'm sure google and others use all sorts of "custom" intel chips (there was a story a while back on el reg how oracle gets them too).
Wish AMD hadn't blown both feet off when they had some pretty good chips back ending with the 6000 series which hasn't changed much in 6 years now.
This post has been deleted by its author
48V is an old telco standard. It was chosen as 48-ish-more-or-less volts because that's what you get if you connect four 12V lead-acid batteries in series, and back in the dark ages telephone exchanges used that as their UPS. 48V is what gives you a dial tone, and it's at the sweet spot in another way too: High enough to send power very long distances (ie, your phone) but low enough that it's not going to kill anyone*. It also, by fortunate coincidence, is just the right voltage for DC distribution in a data center. All that needed changing was to set a formal standard for acceptable deviation from 48V nominal.
48V is also the supply for PoE, and for phantom microphone power. For much the same reason: It's low enough to be safe and practical without requiring too much insulation, but high enough that current and drop are manageable.
Take a look on eBay: There are tons of 48V supplies.
*It hurts, though.
"...48V is what gives you a dial tone."
Minor expansion to your excellent post.
48V is what gives you a dial tone (which is generated back at the Central Office, using equipment powered by that 48v).
The phone line DC voltage at the subscriber end is nominally 48v when the phone is on-hook (hung up, open circuit). But it drops to about 6v when the phone is off-hook (in use).
Cheers.
PS. Being shocked by the 90v 20Hz Ringing voltage is hilarious because it feels exactly like the old fashioned ringer bells sound.
"PS. Being shocked by the 90v 20Hz Ringing voltage is hilarious because it feels exactly like the old fashioned ringer bells sound."
Yes, although I seem to remember the hilarity mostly comes from connecting some other poor sod's pliers to it when they're not looking, or tipping the wink to a switchboard operator when your mate is at just the right part of changing out a faulty cord..
The booster voltage on x-bar switches (200v for select and 150v for hold, IIRC) was also something worth keeping away from as well.
Genetic Diversity
Of course an alternative would for Google to BUY AMD. It is almost petty cash for them. At one time Motorola made chips, but that was spun off as Freescale swallowed up by Renasas. One of these days the musical chairs will stop, but given the environment I never know.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
