The Deep End | Paul Venezia | November 2007

MORE ENTRIES

November 2007

November 25, 2007 | Comments: (0)

Having endured the Vongo ads during various football games the past few days, I figured I'd at least check it out. I wasn't sure what to expect, and boy was I surprised. If you don't already know, Vongo is a new digital movie distribution site that allows users to download as many movies as they want for $9.99 a month. Intriguing, for sure, but riddled with artificial restrictions, apparently.

For one thing, Vongo is deeply, deeply Microsoft-centric. So deeply, in fact, that you can't even view their website with a browser claiming to come from another OS. With a Linux or Mac browser, the only possible option is to enter your email address to be notified if/when your OS is supported.

This means that you can't do any research on Vongo from anything but a Windows box -- Switching FireFox to identify itself as IE on Windows XP completely broke the site rendering, and hitting the site from my Nokia N95 (as I would imagine lots of people will do when seeing the ads on football games in bars or at a friend's house) gave me the nice "Incompatible OS" page as well, preventing me from getting any more information about Vongo. Handy.

Also, if you enter in 'vongo.com' to go directly to the site, it redirects to 'www.vongo.com.', a typo that thankfully most browsers ignore, but does show a certain lack of attention to detail.

So I wandered around the site with my Windows XP VM, looking for some answers to what's really happening on the back end. It seems that the only compatible playback devices are Windows XP, 2000, and Vista, or an Xbox 360. I could find no mention of playback on portable devices, although the commercials made a point of referencing this ability (and a point of not mentioning/showing an iPod). I'd guess that the Zune is supported, but I've seen no specific information on that issue.

But the fact that they were expecting to support portable devices without specifically mentioning the Zune gave me a flicker of hope that these movies might not be horrendously crippled for playback on other devices, like my iPod, Nokia N95, and Mac. Those hopes were dashed when I read this on their site:

"In order to enjoy the full experience of Vongo and Media Center Edition feature integration with Windows Vista, we strongly recommend that you uninstall the Vongo application software prior to upgrading to Vista. (Please Note: When you uninstall Vongo you will lose movies and videos already downloaded to your library. Because Windows 2000 and XP are separate and distinct operating systems from Vista, there is simply no technical means of porting Vongo videos across operating systems. As a Vongo subscriber you can always replace the videos in your library at no charge.)"

Really? The movies you download on XP won't be playable on Vista due to technical reasons? Please. Pull the other one, it's got bells on. This little lie is probably in place just to convince potential users to upgrade to Vista first, with Vongo as the proverbial carrot.

So it seems to me that Vongo has been designed as a Vista delivery catalyst and little more...and why would I want to artificially restrict myself so heavily, to the point where upgrading to another Microsoft OS will cause me to lose the movies I've already downloaded?

Amazon recently started offering $8.99 non-DRM MP3 albums. I've bought several so far, since I can use them on any of my playback devices, from my Sonos system to my Linux workstations and laptops to my iPod. It's this reason that I don't use the iTunes store, or any other crippled delivery system. So sorry, Vongo, but I'm completely uninterested.

Posted by Paul Venezia on November 25, 2007 11:09 AM

November 12, 2007 | Comments: (0)

Stoked With Stoakley

I'll come right out and say this: I'm an AMD kinda guy. My main workstation runs Opteron 2220s, I prefer Opterons in my servers, and I've been looking forward to Barcelona for, well, far too long.

My attraction to the Opteron has been solely based on performance. In the past few years, the Opteron has consistently outperformed Intel's offerings, at least with my workloads. It seems that this may no longer be the case. My Stoakley reference system running two 45nm quad-core 3.0Ghz CPUs simply screams. I've had it running VMware ESX 3.0.2 for the past month, running a LAMP-based Web app load simulator I wrote in PHP. Even though on the face of it, Intel's design seems to be inferior and placing far too much emphasis on shared busses, the reality of the Stoakley platform is that it delivers.

Today's announcement from Intel regarding the new 45nm chips marks a reaffirmation of the next generation of processors. In reflecting on the fact that the new 45nm chips have transistor densities that place 30 million transistors on a space the size of a pinhead, I realize that the first Intel processors had around 2,300 transistors total. That was only thirty years ago, or so.

But enough reminiscing. Penryn is here, and it's going to make a splash if the performance of my reference system is any indication. The 6MB cache per die is definitely helping the numbers here, along with the 1.6Ghz FSB. If you want an exhaustive account of the ins-and-outs of the Stoakley platform and the new 45nm chips, check out Scott Wasson's Tech Report entry from September. I was at Intel in Oregon, standing a few feet from him when he took that beautiful photo of that wafer with a video camera of all things. I think I was laughing at the sight of three geeks desperately trying to photograph a largely reflective surface with digital cameras, and even took a photo of them trying to take photos.

On the outside of the box, I'm more concerned with what Stoakley can do for me. My Web app test hasn't changed much since I used it to test blade servers and VMware VI3 late last year. It's a relatively simple PHP script and a 500,000-record MySQL database. When a Web load generator is pointed at the script, it either serves up a static page, or makes a database call to generate a dynamic page. Tuning the parameters of the script can lean more towards Web server or SQL server performance, but normal operation has the predominate load shifting between the two as the test runs.

So I built a VMware ESX 3.0.2 server on the Stoakley box. The box itself had 16GB RAM, two 136GB U320 SCSI drives, and two Intel gigabit NICs. The onboard NICs weren't supported by VMware until just a week ago or so, and the SuperMicro case was low-profile, so I was limited to the dual-port LP Intel NIC I had. I dedicated one NIC to VM storage, and the other as the front end for all servers. I then built out six CentOS 5-based VMs: A two-CPU MySQL server, four single-CPU Apache servers, and a single-CPU load-balancer. Using LVS for load balancing, I nailed the box with HTTP requests for the Web test app installed on all four Apache servers. The load on all boxes grew substantially, delivering up to 4,000 requests per second, a number that's very dependent on the parameters of the test script, but certainly showed that the box was running on all eight cores, and running them hard. Over 200 million requests and nearly 15 hours later, the box showed no signs of distress, and each VM was still running like mad.

I kept the tests running over the next week, simulating a scenario that should never happen in real life, but occasionally does. After finally stopping the attack, I let the system quiesce, and then proceeded to load it up with more VMs for other tests I needed to do in the lab. I've wanted to run other benchmarks on the server, like compression and encoding tests, but that means that I have to power it down. I won't be able to realistically do that for another few days -- at this point, it's already indispensable.

So for now, I'm lacking raw numbers on standard tests, but I can tell you that my love affair with AMD is on shaky ground. I don't yet have a Barcelona system to run against Stoakley, and I really need to run those tests before I make any hasty moves. From what I've seen of Stoakley and Penryn this past month, my AMD honeymoon may be over.

Posted by Paul Venezia on November 12, 2007 07:12 PM

November 07, 2007 | Comments: (0)

Grinding my gears

I've had an annoying day. It's one thing when the technology refuses to cooperate, it's another when it seems that human incompetence plays the key role. My woes today revolved around the fact that Ubuntu Server 7.10 seems to be terribly broken on the initial install. I was actually installing Ubuntu Server on a new SPARC system, and was amazed that after the first reboot, the initial account created during the installation did not have sudo permissions, and the root account is locked out. Essentially, the installation was useless without rebooting via rescue mode and manually modifying /etc/sudoers. Of course, the rescue boot hung, and at that point, I just turned the server off and grabbed some dinner. This isn't the first time I've crossed swords with Ubuntu and came away feeling that it just isn't worth the effort.

Otherwise, I've been getting riled up with net neutrality issues, such as Verizon's recent experiments on breaking DNS. Earthlink is also playing this game, apparently. I fail to understand the logic behind these attempts to hijack their own users and subvert a core Internet service. It's small potatoes compared to the other shenanigans that major ISPs play, perhaps, but didn't everyone learn a lesson from Verisign's attempted coup a few years ago?

And coming in third, perfectly framing my disaffection with human incompetence is NaviSite. 165,000 to 200,000 sites offline for days following a failed datacenter migration? How is it possible that a large, publicly-traded company can fail so miserably at a fairly straightforward task? I cannot fathom undertaking such an effort without proper planning and the necessary expertise, but then, I'm kinda fond of not causing epic disasters. Not only have they taken all these customers off the Internet for days and days, but they're apparently also berating them on the phone and no longer participating in conference bridges they themselves set up. It's gone from a tragedy to a farce and back again. Cynthia Brumfield is one of those customers, and after five days is heading to Andover MA to get her data back. She's also bringing a video camera to document her experience.

If it happens, that should be interesting. What might be more interesting is NaviSite's declining stock price, and what I can only assume are some cold feet on the part of Sapotek, who just last week announced a partnership with NaviSite to deliver SaaS via Sun's Startup Essentials program. If I were Sapotek -- or even Sun -- I wouldn't want to be anywhere near this trainwreck. They want to deliver SaaS to thousands of customers, anchored by a company that can't even get a mature business like Web hosting right?

Brave.

PS: Check out NaviSite's page discussing the outage. Doesn't it look like the guy in the image at the top is leaning over to throttle the other guy in the foreground? Maybe it's one of their customers.

Posted by Paul Venezia on November 7, 2007 07:22 PM

November 07, 2007 | Comments: (0)

Catharsis via hypervisor

So for all the virtual infrastructures that I've built in the lab and in the field, for every time I've PXE booted a new VMware ESX server into a production environment, I hadn't virtualized my own core systems... until yesterday.

It was a spur of the moment kinda thing, and I went with it. I started the day with five physical core servers of varying age, and ended the day with two, having collapsed the others onto a single Dell PowerEdge running VMware ESX 3.0.2. These were a few Windows boxes, three Linux boxes, and a FreeBSD system, all running on relatively ancient hardware.

It might be odd to think that just feet away from an Intel reference system running the new Stoakley platform and several 8- and 16-core servers from HP and Sun, a 6-year-old HP Kayak XU800 sat, a Fedora Core 3 system with a Pentium III-866 and two 40GB PATA drives in software RAID1, running Cyrus IMAPD for my 5GB mailbox, as well as primary DNS, DHCP, and NTP tasks for the entire lab on all VLANs. Around the corner from that were several other servers running various backup tasks, public Web apps, and so forth. I decided that everything had to go, and by 5pm, I'd rebuilt all the systems on the VMware box, including a somewhat annoying Berkeley DB 4.2->4.3 migration for Cyrus, since the new server was built on CentOS 5. Essentially, this was a 5-hour server consolidation project from conception to reality, and I don't seem to be the worse for it. In fact, I've lightened the power and heat loads in the lab, and am making far better use of the Dell PowerEdge 2800 that's holding down these new systems.

The PE2800 isn't the highest-spec box, especially for VM tasks. It has two HyperThreaded single-core 3.6 Ghz Xeons with 4GB RAM and a bunch of disk in a RAID 5, but it's now running 6 VMs like a champ, including my Asterisk PBX build. I plan on moving over a few more boxes today, but the bulk of the work is done.

One of the only issues that I have with the new environment is that all the VMware management tools are Windows-based. I really wish that VMware had continued their practice of producing Windows and Linux management tools, since my only Windows XP system is a VM running on my workstation and I now have a slightly disconcerting dependency there. Add to that the fact that the VirtualCenter server is running on a VM of its' own on another physical system under VMware Server, and I probably should build a standalone Windows server to handle those tasks. It would be ideal if VMware could bring simple VM management for ESX hosts into the VMware Server Console. I don't need all the bells and whistles there, but I do need to be able to powerup/powerdown servers and access their console. Since there's been consternation regarding the management split between VMware Server and ESX, this might actually happen, but I'm not holding my breath.

On the other side of the coin, migrating a VMware Server 1.0.3 VM to ESX 3.0.2 was very simple -- move the files into place on the ESX host, run vmkfstools on the vmdk, and import the VM via VirtualCenter. I found that it's best to delete the NIC from the VM and re-add it since there's some issue with variable syntax in the .vmx file between VMware Server and ESX, but all told, it was quick and easy, just the way it should be.

Posted by Paul Venezia on November 7, 2007 10:42 AM

November 02, 2007 | Comments: (0)

Some more on fileages.pl

I made a few changes to the code, enough to warrant a sub-version bump. These were a few cosmetic changes and I added a -i option that will force fileages.pl to ignore .snapshot directories. In the future, I might expand that syntax to handle a definable ignore string, but in the short term I needed to run it on a filer that had snapshot support, and I didn't want to count the snapshots, so there you go.

It's also been tested on Mac OS X, and Martin Heller wrote in to tell me that it works just fine under Windows if you have a Win32 perl install. I ran it on a few 10-million-file directory hierarchies without issue, though it did take quite some time to run, as you might expect.

You can grab fileages.pl here.

Posted by Paul Venezia on November 2, 2007 03:41 PM

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert