Techhawking

The two big names in the messaging industry came out with two major upgrades today. Yahoo announced “Yahoo Messenger 8.0” for Windows platform and MSN released their Windows Live Messenger. While both MSN and Yahoo are offering some form of VoIP support, the big thing for Yahoo was the opening up of the APIs for its messenger and the discussion happening is around its Yahoo! Messenger On-the-Road offering which seems to be some kind of a paid service which will grant you access to more than 30000 wifi spots around the world. On MSN side the big thing is the announcement that Philips is now making Voip handsets with embedded Windows Live Messenger in it. This trend of moving VoIP software to handheld devices is not new, but with Microsoft jumping into the market, it not very surprising why Skype is giving away free minutes.

Which brings this discussion to the third player in this market, Google. While MSN and yahoo are desperately trying attach the kitchen sink to their IM client, Google seems to be less interested in developing standalone “Google Talk” clients and is more interested in gathering generating grass root support with least bottlenecks for the end user. For coming late to the party, thats not too much to ask for.

However what we all miss to see in this picture is that in the IM world, MSN and Yahoo are not very far from what centralized networks like AOL and Compuserv looked like before they hooked up to the internet. Isn’t it a shame that you as a user of MSN also have to create a Yahoo, GoogleTalk, ICQ and AOL account just to talk to all of your friends ? And while you can sign up with just one ISP to visit all the websites on the internet is it really necessary to sign up with 10 different service providers just to exchange instant messages with your friends ? After all how different is instant messages from regular email messages ?

When Google decided to use an open protocol called Jabber which has close to 100 different client implementations, they did two things which was not very apparent outright. First they bought themselves a huge developer base which have been screaming about Jabber as an alternative to proprietary protocols. Second they have now forced MSN and Yahoo to acknowledge that inter-IM communication is eventually possible.
Infact, Jabber protocol, unlike other instant messaging protocols was designed ground up like SMTP protocol to be decentralized, flexible and diverse. Its so much alike like SMTP, that from a birds eye view Jabber could look like SMTP in the way it works.

GoogleTalk in short is what Internet was to AOL the reason why Google doesn’t care about GoogleTalk client is because Jabber like SMTP can be routed, archived and searched for targeted advertisements.

//p.s. In the current design GoogleTalk is not routable(s2s)… but that hopefully would be fixed soon.

Sun Microsystems was one of the first big companies to come up with 64Bit AMD V20Z servers which quickly replaced our ancient Sparc servers. Compared to the old E220s and E420s, AMD servers were about 3 to 5 times faster depending on what we wanted it to do.

The first round of V20z’s we deployed saved us a lot of rack space, but the heating and power requirements were little higher than expected. Though the v20z’s did reduce the footprint on the racks, the heat generated forced us to leave room on the top of the servers where the ventilation holes were placed. For all practical reasons, we couldn’t use it as one U system.

We ordered a second round of V20Z’s a few months back and though we were prepared for the extra rack space, we stumbled upon a whole new problem this time. We noticed that some of these servers were randomly rebooting, especially at times of high activity. We were using a mirror image of the Suse distribution which we installed on the first set of servers which rules out any change in the software/os side. Whats funny is that some of these servers were so predictable faulty that a simple “tar -xvzf filename.tgz” would kill it. Putting the boot drive from the faulty server in a perfectly working server confirmed that it wasn’t the OS or Harddisk which was faulty, but the server hardware itself.

These problems have been going on for over atleast a couple of months and we have opened up a case with sun for few weeks now. Among the things we have done to fix this includes updating different firmwares in various V20z components, play around with the memory modules add more space for ventilation and we even checked the voltage regulator to see if its defective. These servers are brand new and of the 30 or so which we bought we can consistently reproduce this problem on 6 of them. Infact we had the sun engineer (2 of them) come on site and see it for themselves and yet its hard for them to agree that they need to replace the server.

So the question is, how long does it take for someone to admit a mistake and give us a replacement ? Does Sun realize that while they request us to upgrade firmwares on our servers and do other time delaying steps, 20% of these servers can’t be used at all ? Do they understand that if we just wanted to keep them unused, we would probably not have bought it in the first place ?

Our company has tried to escalate this problem with Sun so many times, and the guy on the other end just refuses to sign off on the replacements.

Which leads me to the next question, how many other servers are there which have this problem ? If you have this problem, could you please reply to this blog, or let me know by email ? If 20% of the servers sold to us were badly defective, there has to be others out there who are having the same problem.

We have spent between 300 to 600 man hours trying to debug this problem and setting up  workarounds instead of resolve this issue. Posting of this blog online is not just an act of desperation on my part, but is also a message for Sun Microsystems to let them know that they are not the only server vendor out there.