Baidu deploys ARM Servers

GigaOm's Stacey Higginbotham covers the deployment of ARM servers at Baidu.

Chinese search engine giant Baidu is using ARM-based servers from Marvell making it the first company to depend on servers using the cell-phone chip in a production environment. Baidu is using the new ARM servers in its cloud storage application named Baidu Pan.

The area the servers used are for cloud storage.

Marvell’s release says the chip firm customized the ARM servers specifically for Baidu’s cloud storage requirements, taking the concept of server customizationcommon in webscale deployments to the chip level. Marvell says the platform is designed to increase the amount of storage for conventional 2U chassis up to 96 TB, and to lower the total cost of ownership by 25 percent, compared with previous x86-based server solutions. The end result should cut Baidu’s power in its data center by half according to the release.

I know my Drobo FS is powered by an ARM.

We'll see who next launches ARM servers.  I have a feeling this could be a regular occurrence.

Here is a picture from the Register.

Avi Liebermensch, manager of server products at the maker of ARM processors and other kinds of chips, tells El Reg that the Baidu server is based on the company's Armada XP MV78460. This is the same quad-core processor that Dell chose for its "Copper" ARM sled servers announced last May and purchased by unspecified customers of its Data Center Solutions bespoke server business unit. TheBaserock slab ARM server from Codethink also uses this Marvell processor as its main engine.

Baidu has deployed an ARM server for cheap and dense storage with local processing

Liebermensch was not at liberty to give a lot of details on the Baidu machines, and China is celebrating its New Year right now so people in Beijing are not around to answer calls. But Marvell did sneak us a picture and gave us some insight into the machine that Baidu has worked with Marvell and an unspecified ODM to create.

Finally an over current scenario identified as potential causes for 787 battery problem

The burned out batteries on the 787 have grounded the 787 fleet.

I've been waiting to write a blog entry on the 787 battery issue, and was amazed the amount of coverage discussing over voltage.

Japan transport-ministry investigator Hideyo Kosugi said the state of the battery indicated “voltage exceeding the design limit was applied” to it.

Eventually it was discovered over voltage was not an issue.

30 years ago I spent a lot of time working as a reliability engineer, tearing apart the insides of semiconductors to figure out why they failed.  Semiconductors failed for basically reasons of manufacturing defect (lifted bond), over voltage, or over current.  It was pretty cool milling the plastic down to create a trough down to the semiconductor, then using sulfuric acid to remove the remaining plastic to expose the semiconductor die and its wire bonds.  For over voltage you would look for where there was a break in a connection that was very small and hard to see.  But, when it was an over current problem, many times the plastic was cooked from the heat and the sulfuric acid would not remove the plastic.  These hard crusted plastic burned areas looked like the above picture.

Finally there is coverage for improperly wired batteries causing over current in the battery.

According to the AP, on the ANA flight, the Japanese Transport Ministry noted:

Flickering of the plane's tail and wing lights after it landed and the fact the main battery was switched off led the investigators to conclude there was an abnormal current traveling from the APU due to miswiring.

I am sure many of you have seen over current failures and you recognized as well that the 787 batteries were subjected to over current.

A finalist in the ARM Server competition, Samsung, huh?

I was with the family in Whole Food last night having everyone pick up their Valentine's day dessert.  Anything you want.  As I headed to the dessert area, I ran into an ARM expert I met 5 years ago who lives in the Seattle area.

One of the fun conversations we had 5 years ago 3 blocks from the Whole Food we were now standing in was how big the potential market is for ARM servers.  We need 64 bit and we need more SW.  Well 5 years later, 64 bit is around the corner and SW support is coming too.  But, something else showed up over the last 5 years.  Samsung.  25 years ago when I worked on display technologies for Apple, our monitors were made by Sony, Hitachi, Mitsubishi, and Samsung.  I remember the Japanese guys saying how aggressive the Koreans were and how hard they work, just like Japan used to in the 70s.  Working with Samsung was great back then.  I tend to buy Samsung devices - TVs, Blu Ray, and Android Phones.  I would buy a Samsung refrigerator if they had a look that my wife liked.  And, wow what has Samsung achieved over the last 25 years.

My ARM friend and I usually run into each other at Intel Developer Forum which is funny given we live so close to each other, and him being an ARM guy we chat at IDF.  Seeing my ARM friend/expert in Whole Food was convenient as I have been meaning to chat with him and Sept 2013 IDF was too far out in time.  We reminisced about our discussions on ARM servers and we were right.  He was right saying it would be big inside ARM and the support has come.  The new thing we talked about is how big Samsung is going to be the ARM Server market.  

When I was down at the Open Compute Summit I was able to catch up with a bunch of industry people and they confirmed Samsung has been hiring server guys, and the Samsung IO chips are being worked on.  Take a look at the Samsung Galaxy phones, throw out the display, put some kick ass IO on it and you have an ARM server that will be tough to beat.

There will be a dozen companies with ARM servers over the next 2 years, and over time, within 5 years there will be 3-5 players dominating the market.  Samsung will be one of the players.  Intel will have some market.  Who will be the others?  Hard to guess 5 years out.

One vote from Wired, Tesla Data logs wins over NYTimes Reporter's notebook

NYtimes reporter John Broder wrote his rebuttal to Tesla's shared data logs.  John put his experience down as why we should believe him.

Since 2009, I have been the Washington bureau reporter responsible for coverage of energy, environment and climate change. I have written numerous articles about the auto industry and several vehicle reviews for the Automobiles pages. (In my 16 years at The Times I have served as White House correspondent, Washington editor, Los Angeles bureau chief and a political correspondent.)

Wired covers this rebuttal.

Times Reporter Disputes Tesla’s Claims, ‘Cannot Account’ for Data Conflict

• BY DAMON LAVRINC
• 02.14.13
• 8:24 PM

• …

• New York Times reporter John Broder responded in detail Thursday to Tesla president Elon Musk’s data-driven takedown of Broder’s review of the Model S sedan. And it’s becoming clear that in the credibility battle between a veteran reporter’s notebook and Tesla’s hard data, data has the edge.

I really like the cruise control explanation by the NYTimes reporter.

Musk disputes that Broder turned down the heat, but as Broder points out accurately, Tesla’s logs show that he did just that. But the logs also show that Broder never cruised as slow as 54 miles per hour, nor did he later slog along at 45 miles an hour in a desperate effort to reach a charging station. Broder’s response Thursday relies on his memory, and some shoulder-shrugging.

I do recall setting the cruise control to about 54 m.p.h., as I wrote. The log shows the car traveling about 60 m.p.h. for a nearly 100-mile stretch on the New Jersey Turnpike. I cannot account for the discrepancy, nor for a later stretch in Connecticut where I recall driving about 45 m.p.h., but it may be the result of the car being delivered with 19-inch wheels and all-season tires, not the specified 21-inch wheels and summer tires. That just might have impacted the recorded speed, range, rate of battery depletion or any number of other parameters.

Wired jumps on the cruised control issue.

That strains credulity a bit. Modern cruise control systems generally maintain vehicle speed even on downhill slopes. They aren’t prone to a 15 mile per hour speed boost.

And the Tesla tire issue?  Uh, check out the tires size. With the change of 45 to 35 aspect ratio.  The 19" wheel has 751 revs/mi.  the 21" wheel has 749 revs/mi.  No difference.  But, that makes no sense how can a 19" wheel and 21" wheel have the same speed?  Because aspect ratio of the tire.  The 19"/21" is the rim size, not the diameter of the tire. 

19" aluminum alloy wheels with all-season tires (Goodyear Eagle RS-A2 245/45R19). Note: optional 21" wheels come with Continental Extreme Contact DW 245/35R21 high-performance tires

 

Wired closes with the point of the debate.

But what this grudge match is no longer about the Model S’s suitability for road trips. It’s about old school reporting, based on note-taking and memory, peppered with color and craft, versus the precision of numbers and data. And the Times is now obliged to address it on those terms. Because in the end, Broder either set his cruise control for 54 miles and hour, or he didn’t.

 

It will be interesting how reporting gets changed when data loggers are more accurate than a reporter.  This can make for dull uninteresting news.  But, data is going to most of the time be closer to the truth than a reporter who thinks cruise control varies by 15 MPH and 19" vs 21" wheels would explains errors in speed indicated.

BTW, I believe in data logging in the car.  I have data logger connected up to the OBD port on mine.  I use it for tracking mileage for business.  But, once my kids start driving I'll be able to see their speed, brake deceleration, acceleration, throttle position, RPM, distance driven.

Tesla Data Logging vs. NYTimes Journalist, who will win?

I got a chance to ride in a Tesla a couple of years ago with a salesman at an OSIsoft event.  OSIsoft is about data monitoring to show real time performance, so it felt natural to discuss the data logging feature of the Tesla.  It's a great feature to get data on how the car is performing and how it is being driven.  And, this feature is creating an interesting PR battle between Tesla CEO Elon Musk and NYTimes reporter John Broder.

The Public Editor's Journal just posted its investigation.

Conflicting Assertions Over an Electric Car Test Drive

By MARGARET SULLIVAN

2:53 p.m. | Updated Let me get this out of the way up front: This blog post will not be the definitive word on the contentious subject of a Times article in Sunday’s Automobiles section. It’s just an early effort to put some claims and counterclaims out there, while I continue to look into it.

I will keep reporting on this, and, for now, am simply telling readers what I know so far.

Elon Musk put his post out yesterday and they have learned from the creative reporting from Top Gear to always turn on data logging when loaning their cars out to the media.

After a negative experience several years ago with Top Gear, a popular automotive show, where they pretended that our car ran out of energy and had to be pushed back to the garage, we always carefully data log media drives. While the vast majority of journalists are honest, some believe the facts shouldn’t get in the way of a salacious story. In the case ofTop Gear, they had literally written the script before they even received the car (we happened to find a copy of the script on a table while the car was being “tested”). Our car never even had a chance.

The logs show again that our Model S never had a chance with John Broder. In the case with Top Gear, their legal defense was that they never actually said it broke down, they just implied that it could and then filmed themselves pushing what viewers did not realize was a perfectly functional car. In Mr. Broder’s case, he simply did not accurately capture what happened and worked very hard to force our car to stop running.

The NYTimes is preparing a response.

I will be interviewing Mr. Broder later on Thursday. When I reached him earlier, he said that he and his editors were working on a point-by-point response to Mr. Musk’s blog that would appear on The Times’s Wheels blog.An earlier post on that blog made an initial response on the matter, but that predated Mr. Musk’s release of the logs. I’ll link to the new post when it’s available.

Mr. Musk has not returned my call, made at about noon on Thursday. I eventually intend to ask him to fully release and “open source” the driving logs, along with whatever other data might be necessary for better understanding and interpretation.

But, what data does the NYTimes have?  I am looking forward to see what the NYTimes come up with.  Does the NYTimes have a secret data logging feature on their journalists?  :-)