March 27, 2008 | Comments: (0)
The 45nm Xeon 5400 series in the lab
Yesterday, Intel announced the newest incarnation of their quad-core Xeon CPUs. The 5400 series is a low-voltage chip designed for tight spaces such as blades and 1U servers. On the very day of the announcement, I was finally firing up a test box running a pair of 5420s. These are 2.5Ghz quad-core CPUs with 12MB cache built on the 45nm die, and I'm running them in an Intel server chassis on the S5000PSL mainboard. These chips aren't designed to be speed demons -- rather, they're designed to be lighter on the power budget while still offering decent performance.
I haven't had a lot of time for testing and benchmarking yet, but I do have some results from basic tests. Some of these tests are threaded and make use of the eight total cores in the box, but others are single-threaded and highlight the performance expected from that type of application. Additionally, most of these tests also reflect disk I/O performance. Essentially, these are real-world tests, not just CPU tests.
All tests were run on my test system, which has 4GB in two 2GB FB-DIMMs, two quad-core Xeon 5420LV chips at 2.5Ghz per core, two Seagate SATA II drives in a hardware RAID1 array built with the Intel embedded RAID controller (which is an LSI chipset) on the S5000PSL mainboard. The OS was a fully-updated CentOS 5 build.
MySQL
I ran all tests in the sql-bench suite against the local host using sockets. All tests completed in 1435 seconds (23.9 minutes).
LAME
I used LAME to encode an 838MB WAV file to MP3 at a 256k bitrate, VBR 2. This is a single-threaded task, and completed in 404 seconds (6m 44s)
MD5 Sums
Another single-threaded task, but a common one. Calculating the MD5 sum of the same 838MB WAV file took 2.6 seconds.
Compression
I ran bzip2 on the same 838MB WAV file. The times were 182s (3m2s) to compress, and 77s (1m17s) to decompress.
Posted by Paul Venezia on March 27, 2008 10:49 AM
March 12, 2008 | Comments: (0)
It's been just over a month since I first unboxed my MacBook Air. I wrote a review for InfoWorld that garnered some attention, and a sidebar that far too many people seemed to think was the actual review -- a statement on their own preconceived notions and lack of reading comprehension more than anything else, perhaps.
In any event, I've subjected my MacBook Air to daily use, dropped it once, had it sat upon by a careless individual not once, but twice, and have travelled with it via plane, train, and automobile. I've used it for email, Web browsing, and Linux, Windows, and FreeBSD server administration. I've written thousands of lines of code and thousands of words on it. I've used it on a plane, on a desk, in a chair -- and I still dig my Air.
I've used it on WiFi hotspots, with 802.11b, g, and n networks. I've used it with my Nokia N95 acting as a Bluetooth modem. I've plugged into a wired Ethernet network using the USB adapter. I've done photo editing and some audio processing with the Air, watched movies and listened to music. I've used it with a USB serial adaptor to configure Cisco switches. I've done everything that I normally do on any computer, laptop or not, except use CDs or DVDs -- I haven't needed that function even once. I only used the Remote CD function to install XCode from the Leopard CD the first day. I used Apple's Migration Assistant to move over all my settings, email, and applications from my MacBook Pro (running Tiger at the time) and haven't had any issues with those apps either, except for having to reinstall Microsoft Office.
As with any piece of technology, your mileage may vary, but the miles I've put on my MacBook Air have been straight and true so far. I've only rebooted it once in that month, after installing some drivers, yet I use it every day. That's the key to usability for me. I loathe waiting for laptops or workstations to boot or dealing with OS issues. I have work to do. Open it up, log in, and launch another xterm, all within five seconds.
To be honest, I've grown somewhat disillusioned with the attention it receives in public settings. I can't take it to a coffee shop without at least two or three people interrupting me to talk about it. But if that's the biggest problem I have with the Air, I'm in good shape.
Posted by Paul Venezia on March 12, 2008 03:33 PM
February 13, 2008 | Comments: (0)
So apparently my MacBook Air review has hit both sides of the spectrum. There are those that think it's one of the most balanced reviews yet, and those that think I'm a fanboy.
Nick Farrell's own definition of fanboy (posted in a comment on this blog) is "someone who disengages brain whenever they look at a product. Apple is largely dependant on peddling products to such types who refuse to see that the outfit can do any wrong." If that were the case, why would I write the sidebar on the migration issues at all? Why would I include the negative comments on the Air in the review, and score it below "Excellent"? I suppose that's berating the obvious, however. The fanboy sentiment cuts both ways though -- there are people like Nick that view everything from a particular company in a negative light, regardless of facts or merit.
These accusations come with the territory -- if you give a product a positive review, you're a shill for that product. If you review it negatively, you're a shill for the competitor. If this were actually the case, I'd be a rich man indeed.
I do think that Mac OS X is superior to other operating systems for a variety of reasons, from usability to security, and so on, but my main workstation runs Fedora Core 8, and my servers run FreeBSD or Linux. Most of my laptops are Macs because they give me a very functional native UNIX-based environment in a portable package, never crash, instantly wake up from suspend, and perform very well under load. I view time taken dealing with OS issues, viruses, malware, drivers, and so forth as time wasted, and I have precious little time to waste these days. The day that changes is the day I move to something better -- but there isn't anything better right now. That's why I run Mac laptops along with a few Dells running Linux.
I've seen some forums discussing the review, complete with folks running the numbers on the 50GB file transfer, claiming that I was getting only a few MB a second during the transfer. I was getting 10-11.5MB/s during actual file transfer (as I mentioned in the review), with the remaining time taken up with the other requirements of migration such as configuring user accounts, replicating settings, and whatever else is necessary to completely (and successfully) migrate one system's state to another. Raw transfer time was probably closer to three hours, and I'd transferred nearly 60GB of data when it was all said and done. I also find it odd that of everything I wrote, this sidebar has become the hotpoint. It's specifically about the migration assistant, which is a tool that I've found to be incredibly handy and a significant timesaver, but one that not everyone uses. In fact, it's only tangentially related to the Air. I do really wish that Apple had coded it to let you pick specific folders to transfer as part of transferring a user, but the thirty seconds it took me to do that manually was hardly a cause for concern.
The whole point of the review, sidebar, and my additional comments was to point out what the MacBook Air is, not what others seem to think it should be. Much like a comparison between a Ford F-250 and a BMW Z4 is relatively worthless, reviewing the Air in comparison to even a MacBook Pro is worthless -- they're two completely different products for different needs and markets. That's the whole idea.
If you want to view the Air as just another laptop, that's fine -- you're just missing the point.
Posted by Paul Venezia on February 13, 2008 10:15 AM
February 12, 2008 | Comments: (0)
It seems that Nick Farrell over at The Inquirer isn't so thrilled by my MacBook Air review. Actually, he doesn't really mention the review, opting instead to summarize the sidebar with additional commentary. To clarify a few of his points:
o- Yep, it took five hours to do the whole migration. The first 30 minutes were problematic, but the rest of the time was the two systems transferring 50GB of files via 100Mbit Ethernet without supervision.
o- The Air didn't crash -- the Migration Assistant application crashed.
o- I bought the Air myself.
o- "Fanboy" seems to be a favorite expression of someone who doesn't like to see positive comments about something they don't like. I gave the Air a "Very Good" rating, and it earned it. If it had integrated 3G and a realistic 5 hours of battery life, it might have made it to "Excellent".
o- Isn't it odd that although I'm apparently a "hack" trying to put positive spin on Apple's products, I decided to write an entire sidebar about a negative experience?
I suggest that Nick read the whole review as well as my blog comments. I'd be delighted to see him run that though his fun-house mirror.
UPDATE: Interesting. All the comments on the Inquirer post just disappeared right after I submitted one.
UPDATE: They're back, sans my comment. Curious.
Yet another UPDATE: I might suggest that anyone interested in this topic read the actual review, and my companion blog post, not just the sidebar. I wouldn't want anyone to be embarrassingly misinformed -- it's bad for the knees.
Posted by Paul Venezia on February 12, 2008 11:22 AM
February 10, 2008 | Comments: (0)
The MacBook Air finds its Nietzsche
Quite often, less really is more. One staple of computing in general is the perceived need for options. Painting yourself into a corner a lack of options with hardware or software is never a good thing, but there's a difference between that and trying to paint the room with a half-ton paintbrush.
It's no secret that Steve Jobs -- and by extension, Apple -- is very interested in pushing the design envelope. Going back a long way, except perhaps the dark years in the nineties, Apple has had a history of making big changes and taking big chances with their hardware. The Mac was really the first home computer to have integrated SCSI and a mouse. Apple computers were among the first to be produced without internal floppy drives. The Apple Newton was one of the first usable PDAs and even today enjoys a startling number of users. NeXT Computer, founded by Steve Jobs in 1985, is looked on as being way too far ahead of its' time, producing a line of UNIX-based workstations running the NextSTEP OS, an OS that is the precursor to Apple's OS X. Apple's OS X itself is a complete and total departure from Mac OS -- a move that helped reinvent Apple. The iPod, of course, was instrumental in building a whole new industry. There are more examples, some flops, some not, but they have a common theme: out with the old, in with the new, whether you're ready for it or not.
Apple's design theory seems to be "Rounded rectangles, white or silver, as few seams and ports as possible, as few cables as possible". If Apple designed a Swiss Army knife, it would look like an egg. Their products certainly are attractive, with clean lines and an overall minimalist approach. To get those clean lines, however, all those bulky ports and slots have to go. Quite honestly, I think Steve Jobs harbors a deep, personal resentment towards D-Sub connectors. That's the concept behind the MacBook Air.
In an age when you can still get a laptop with a parallel port, Apple has created a laptop with no legacy ports, even deleting FireWire from the specs. There's also no built-in optical drive. Many reacted to this with disdain, decrying the lack of an internal optical drive, fixed RAM, and limited ports as being too limited and artificially handicapping the system. I've come to realize that I don't think that's the case at all. When I thought about it, I don't really need any of those things on a daily basis, and when I do, it's rare. Perhaps desktops need lots of ports, but not laptops -- not any more. In a time when I can buy a 16GB USB2 flash drive for under $80, why would I bother to carry DVDs and CDs? If I don't use those, why do I need the drive? If I need to transfer files between systems, I can use wired or wireless Ethernet, or that USB flash drive.
I get the vast majority of my computer-based entertainment via the Internet. Music and movies, and other forms of entertainment are easy to download from iTunes, Amazon, or anywhere. Though there are subscription services like NetFlix that are PC-only, that will likely change sooner rather than later. Occasionally, I'll buy a DVD, or a CD at a vintage store, and encoding those to MP3 and MP4 is trivial using a desktop system. I then get the benefit of being able to play them anywhere, instantly. I simply get more bang for my buck with digital files, and there's no reason I'll ever go back to physical media.
I also get the vast majority of my applications from the Internet. I can't ever recall loading a CD or DVD into a Mac to install software other than an OS installation. Even when devices come with driver disks on CD, I generally download them from the manufacturer's website since the version will be newer and hopefully better. The first disc I've put into my MacBook Pro in probably six months was the Apple disc that contained the MacBook Air's CD/DVD sharing installer. I won't miss it on the Air. With Bluetooth, I won't really need more than one USB port either. If I do, there are 3" x 1" four-port USB hubs on the market for less than $15.
So as I use the Air and think on this, I gaze around my lab, noting all the random cables, connectors, components, and options. There are several PC laptops around, rife with colored ports, switches, slots, and buttons. It's a stark contrast to the lithe little laptop in front of me. It's the antithesis, and I think that's a good thing. 
Posted by Paul Venezia on February 10, 2008 08:43 PM
November 12, 2007 | Comments: (0)
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
October 18, 2007 | Comments: (0)
So it occurs to me (and more than a few readers) that I neglected to give any details about the car in my last entry. Well, let's remedy that.
I bought a 2004 Audi A8L with 52,000 miles, which was relatively within my price range, and has the same layout and gear as the newer models. The downside is that the hardware revisions in this car are 3 years old, and apparently they made lots of changes in the interim. The other downside is the complete lack of warrantee, even though Audi recertified the car less than a year ago. Also, the nearest Audi dealer is around 50 miles away, and local shops won't touch this car for anything other than brakes or tires. In fact, the aforementioned problems with the garage door opener and light sensor were caused by a local tire shop letting the battery run down completely while putting on a new set of tires. After the jumpstart, those components stopped working.
So that's what led me to inspect the coding on the roof electronics module. This coding is standard base-8 additive, with specific values assigned to specific components. For instance, if the car has a solar sunroof, add 6, if it's a steel sunroof, add 2. If it has a garage door opener, add 256, and so on (the full list can be seen here). So I came up with a value for the roof electronics coding -- 4014. Inspection of this module with the VAG-COM software showed the coding was 4013, which is basically an impossible number. I changed that to 4014, and... nothing happened. I'm still feeling my way around the VAG-COM interface and capabilities, so I wasn't sure if an individual module reset was possible and I'd noted that even though I'd trickle charged the battery overnight, it was still showing only 50% capacity. Time for a reboot. I pulled the negative lead from the battery and replaced it a few minutes later. This powercycle fixed the battery level indication, and the roof electronics started working again.
When I was telling a non-geek friend about this, he was quiet for awhile, then asked how "a normal person" would have fixed this. The answer? I have no idea, but I'm willing to bet the dealer would have replaced the whole roof electronics module.
The other side of that coin was brought into sharp relief by Jon Udell, who emailed me this morning:
Here's hoping this query continues to produce zero results:http://www.google.com/search?q=%22bricked+my+audi%22
Then again, it would confer a certain sort of celebrity...
Posted by Paul Venezia on October 18, 2007 11:16 AM
October 17, 2007 | Comments: (0)
It's not exactly breaking news that computers are integral components in cars these days. They've been used since the 80's to handle various tasks such as fuel-oil ratios, performance tuning, transmission control, and so forth. What's far more interesting today is that they're in the cockpit, handling nearly every aspect of the car's direct control, navigation, and entertainment systems.
Much like embedded medical computing systems, the code running in newer cars goes through a more stringent QA regimen than, say, Microsoft Excel 2007, but they aren't perfect. The bothersome issue when problems occur is that many times, they "can't be fixed" by the dealer or private service centers.
It's one thing to bring a car to the dealer with a window that won't roll down due to a failed switch or motor. It's another thing entirely if the problem with the window is a bug in the car's computer. Given my recent experiences, it's all but impossible for even a certified dealer to handle problems of a firmware variety, rather than a physical issue. As car computing gets deeper, these problems will likely get worse, until some critical mass is reached and there are Linux geeks wearing coveralls and dragging laptops around in the garage.
To a geek like me, the design and control of these systems, especially in the high-end cars is quite interesting. Audi, for instance, has arguably the best in-car computing platform, called the MMI (MultiMedia Interface). It's present in the A6, A8, and Q7 series vehicles, and controls everything from the climate control to XM/Sirius, iPod, radio, video, navigation, and all associated preferences. The main control is a jogwheel with four softkeys, and a handful of function buttons. Like any embedded system, it has a bootloader, applications, several hardware components, and a facility to handle firmware updates. Curiously, this update path is based not on a proprietary connection from a dealer service computer, but can be done through the car's CD player. Essentially, it's possible to update the code on the car by loading an update CD-ROM into the CD player, and accessing a series of hidden menus to perform the update.
Unfortunately, it seems that many of these systems are relatively fragile. I've been told by dealers that not only are updates to the car's various control modules not covered by warrantees, it's not unlikely that some updates will irreparably harm some modules, requiring that they be replaced for hundreds or thousands of dollars. Essentially, you aren't covered for anything regarding the software in the car, and maybe not even some of the hardware if it fails during maintenance. This won't affect the car's nominal function, but the radio, navigation, climate control systems, and so forth may not function at all. This isn't unique to Audi either, as BMW has essentially the same policies. So in essence, although the mechanical/computer ratio on some of the newer cars is nearly 1:1, some of those computer parts aren't covered.
Another problem is with the techs themselves. I've heard time and again "Some of these cars are like your home computer. They break, and nobody knows how or why, or how to fix them." Rip and replace becomes the norm, rather than debugging.
So I'm on my own, armed with a VAG-COM USB CAN interface, a laptop, and my brain. So far, I've managed to dip into the car's computer to change a bevy of hidden settings, adjust the service interval timings, and reset the coding on the roof electronics module since it managed to forget that it had a light sensor and a garage door opener. The last part required rebooting the whole car by pulling the negative lead on the battery. Making changes to the car's computers in this way is highly dangerous in many cases. Setting the wrong value on a specific component can disable the component completely, or even cause the car to become inoperable. It's not quite the same as inadvertently dropping a washer into a cylinder, but the outcome can be similar.
On older cars, I've done radiator and manifold replacements, brakes, oil changes, and the like, but I'm on my quest to see what it's like as a modern-day shadetree mechanic. My tools aren't grease guns, ratchet sets and floorjacks, but rather firmware, CD-burners, and a laptop. My next tasks are to look into altering the transmission shifting timing and hopefully fix the route that's stuck in the navigation system. It's a whole new world.
Posted by Paul Venezia on October 17, 2007 03:01 PM
September 27, 2007 | Comments: (0)
VMware Workstation VMM issues resolved in 2.6.22?
For those unaware, VMware Workstation 6 has been exhibiting some significant stability issues under some 2.6.19 and 2.6.20 kernels. VMware Workstation would run and behave normally for some period of time, then crash with a VMM (VM Monitor) error, and take down the X11 subsystem, requiring a reboot of the whole system. I saw clear evidence of this under Fedora Core 6 x86_64 on these kernels, but not on the 2.6.18 kernel. There were several threads dedicated to this problem on VMTN, and a few possible fixes offered, but none worked. I resigned myself to running the VMware Server Console on my workstation, and housing my VMs on a different VMware Server system, which definitely has some benefits over running them locally, but I was bothered by this mysterious issue. My main workstation is a Sun Ultra 40 M2 with two dual-core Opteron 2220s and 8GB of RAM, so using that to drive VMware Workstation for my Windows needs is really the best option from a performance and functionality standpoint.
Since then, a FC6 kernel update to 2.6.22 was released, and rather than step back to 2.6.18 on that system, I tried going up to 2.6.22. That was about a week ago, and the VMware Workstation instance on my main workstation has been stable since. I haven't found any direct reason for the problem, or its resolution, but there you have it. Also, for those curious on getting the VMware Workstation components to compile and run on Fedora or other distributions, you'll likely need the VMware any-to-any patches found here.
Posted by Paul Venezia on September 27, 2007 10:42 AM
August 01, 2007 | Comments: (0)
So at the moment, I have my Nokia N95 playing some MP3s while connected to my MacBook Pro via USB syncing more MP3s and pics via Nokia Media Transfer, and I've taken a call, installed Google's Gmail app, browsed the Web a bit via Wifi, all at the same time. I haven't hit the dreaded OOM error yet, and everything's working flawlessly so far. Color me impressed.
Posted by Paul Venezia on August 1, 2007 10:11 PM
August 01, 2007 | Comments: (0)
So I've spent another day with the N95, and have a few tips to share.
First, I had to import some certificates into the phone to deal with some privately-signed secure services I run. I Googled for some info on this, and eventually found several quite convoluted ways to do this, including modifying MIME types on Web servers and browsing to a DER-encoded cert there, which seemed uniquely bizarre to me. I found a quick and easy way to do this, involving no Web servers or MIME types.
1) Convert the key to a DER format: openssl x509 -inform PEM -in ./cert.pem -outform DER -out cert.der, replacing cert.(der|pem) with your actual certificate.
2) Push the resulting .der file to the N95 with Bluetooth or USB and drop it somewhere on the phone's flash or memory card.
3) Select it in the file manager, and it should install nicely.
If you're on a Mac, use the OS X Bluetooth "Send File..." command to simply throw the file at the N95. It will then automatically prompt for installation.
Another task was to enable the N95 to be used as a modem on my MacBook Pro. This was actually so straightforward I had to double check to make sure I was actually using the phone and not my WiFi. Just follow the instructions on the Nokia E61 blog and you're all set. Note that my GSM provider doesn't make use of a username/password combo, and leaving those blank worked fine. Oh, and the modem script should be dropped into /Library/Modem Scripts, not /System/Library/Modem Scripts.
I also found a nice tuner/metronome app from VITO Technology that combines a standard metronome and a tuner using the phone's microphone. Handy for the gigs where I don't even bring an amp and forget my tuner. Guitar players hate it when you borrow theirs to tune an upright, drummers are always making too much noise to hear the harmonics, and keyboard players don't bother.
I still can't get the builtin email application to send email via SMTP AUTH, which is very annoying, but I'm warming up to Profimail, and will probably wind up buying it when the trial period expires.
Posted by Paul Venezia on August 1, 2007 08:32 PM
July 31, 2007 | Comments: (0)
Yep, I'm digging my new Nokia N95 so far.
To make a long story short, I'm one of the many people in the US who aren't covered by Cingular/AT&T Wireless. This means that although this area is saturated in GSM, AT&T Wireless doesn't have a presence here. My existing number can't be ported, and thus getting an iPhone isn't really an option since any local calls would actually be in-state long-distance to a new number on an iPhone. I thought about doing some Asterisk trickery to forward calls across my SIP trunks to alleviate this, but decided it wasn't worth it in the long run.
Then, I ran into the Nokia N95 while in Oregon in the hands of Inquirer writer Charlie Demerjian. I'm not sure if the N95 is even technically available in the US, and I haven't seen a single carrier that offers this phone as an option, but it's a standard quad-band phone that will work on most GSM networks, and it works great here on Unicel. I've only had it for a day now, but I've been spending some quality time with it. I'm happy overall, but there are some kinks, to be sure.
The N95 offers many of the same features of the iPhone, and lacks several features, such as a touch screen. It's far smaller than the iPhone, but thicker, and is a slider, not a fixed piece. Mine also came in the "plum" color, which is just odd. I'd have preferred silver or black, but I can deal with plum, I guess.
It's based on Symbian S60 v3 code, and is generally snappy in operation, with a plethora of available applications from Nokia and many third party vendors. The screen is nice and crisp, and the dual-action slider is rather cool -- slide it up to reveal the dialpad for normal phone operations, slide it the other way to reveal multimedia keys (play, pause, fwd, rev, etc) and switch the screen to landscape mode. It has 802.11b/g, Bluetooth, USB2, GPS, EDGE and 3G connectivity built in, a PDF reader, video player, Flash player (something the iPhone desperately needs), and a limited Office suite. It also has two cameras -- a 5 megapixel main camera and a 1.3 megapixel camera on the front for videoconferencing), as well as a micro-SD slot for storage upgrades (a major plus over the iPhone), and a replaceable battery (another major plus). A big downside is that it's very RAM-limited. Having more than a few apps open at once, or loading a sizable Web page in the browser will result in an "Out of memory" error that is highly annoying. I'm thinking that a firmware upgrade allowing the use of the micro-SD card as a swap source would be a very good idea. That said, as long as you're relatively good about closing apps when you're done with them, it's not a showstopper. From what I can tell, the N95 has 60MB of internal RAM, and judging from what I've seen, it really needs 128MB or so. That would go a long way towards increasing the daily functionality of the device.
The GPS functions are very nice -- the maps automatically download, there's a route planner that offers voice navigation and nicely appointed maps. It's not terribly fast, but it works well, and the few routes I've planned have been surprisingly accurate. The camera takes good quality pictures, but is slow. I've found that disabling the image preview helps here, since the phone isn't trying to write a large file and read it back to display it at the same time. I do like the ability for the N95 to figure out if it's home or not, binding to a local 802.11b/g access point for all data transmission rather than an EDGE or 3G service. Not only is the 802.11b/g connection faster, but it doesn't incur network charges. Further, there's a very accessible wireless scanner in the phone that will find and lock on to any WiFi that happens to be in the area. I've found that the N95 doesn't deal with roaming among APs terribly well, but well enough for such a tiny device, and the range is adequate.
On the input front, the N95 lacks a QWERTY keyboard, but the predictive typing is surprisingly accurate, though making corrections can be annoying. There is support for Bluetooth keyboards, but the idea here isn't to lug around multiple parts to your communications device, right? Of course, I'm mostly using the input for email, and I've been playing with a few email apps for the N95 -- the builtin app and Profimail. I had the builtin app reading from a SSL/TLS IMAP mailbox very quickly, but sending mail via authenticated SMTP proved to be a problem -- all the settings were correct, but the server never saw the auth string and bumped the mail every time. With Profimail I didn't have that problem, but the UI is vastly different than anything else on the phone. That's not to say it's worse, just... different. I'm still not sure which one I'll use more, but the fact that Profimail can actually send mail is obviously a major advantage.
I've installed PuTTY for Symbian on the N95, and it's actually surprisingly usable in emergency situations. The lack of a QWERTY keyboard is obviously a problem here, but if all you need to do is kill a process or check on something quickly, it'll do the trick. The TSMobiles RDP client I installed was also functional, but essentially unusable on the N95. It worked, but navigation was painful and the small display area was a joke.
As a phone (since that is the most important feature) the N95 works well. I've had no problems with coverage so far, even in places where I would expect signal drop, like the far corners of my basement. I really wish that the volume level could be increased beyond the current limits, since I've found that at top volume, it's just not loud enough for me, especially in public places. I'm assuming that the lawyers had a say in this, but I'd sign a document absolving Nokia of any liability to get a few more dB of earpiece output from this thing. The speakerphone is very responsive, on the other hand, and had no problems even from a respectable distance.
I was able to sync my Mac contacts with the N95 after downloading Nokia's iSync plugin for the N95, too. The voice dialing is pretty basic, especially when compared to my old Motorola RAZR, which had a surprisingly good voice dialing app. I've found that it works best if I run the names together, saying "Oliverrist" instead of "Oliver Rist", but it's sufficient. Of course, I could just rename his entry to "Hopeless Nerd" and maybe have better luck.
Bluetooth connectivity is nice and fast, and my various headsets and laptops had no problems with connections. Nokia even has a beta version of their Mac software, dubbed Nokia Media Transfer that has worked fine. The gist of that app is that a custom folder appears in iTunes and iPhoto, and whatever content is placed in those folders will be synced to the N95 when it is connected via USB or Bluetooth. It has worked fairly flawlessly for me so far.
The N95 also offers YouTube videos, among other providers via the RealPlayer (RealPlayer's still around?) app, though there's no searching to speak of. That part's still a novelty at best. The audio playback is nice, and the slider audio/video control buttons are a very nice touch.
One of the first things I did with my N95 was update the firmware from v10.x to v12.x. Unfortunately, the only way to update the firmware is with a Windows system and Nokia's firmware updater, but the procedure was relatively painless. I haven't noticed any major changes between the two versions, but my gut tells me that it runs slightly faster with the new revision. One downside to upgrading is that all customizations are lost -- though you can back up your settings to the micro-SD card and restore them after the upgrade.
Obviously, I'll be spending plenty of time with the N95 in the future, so I'll post updates as events warrant. The N95 is certainly no iPhone, but then again that's not necessarily a bad thing.
Posted by Paul Venezia on July 31, 2007 09:33 PM
July 25, 2007 | Comments: (0)
Intel had a fairly big announcement today, highlighting their work in the server MP space with a new multi-processor framework dubbed Caneland. This is a new one on Intel, and definitely new in the industry, marking the first time a four-socket quad-core offering has reached this level. The basis of the system is the Tigerton CPU, running four cores at up to 2.93Ghz per core. This is married to the Clarksboro chipset, and Intel is claiming a 2x speed improvement over existing Xeon-based chips. I had a chance to play with the Tigerton/Clarksboro framework in Intel's lab today, and it really is rather odd to see 16 cores on 4U, four-socket Windows box. I ran a few benchmarks, but I can't publish any of the data -- yet. Suffice it to say that the official launch of Caneland later this year will be quite interesting. Manufacturers have been getting shipments for over a month now, so Intel isn't worried about quantities.
I happened to be in Intel's Oregon location to attend a workshop centered around a some new products that will be announced in the coming months. It was a very enlightening few days, and left me truly wondering about AMD's delayed quad-core, Barcelona. It's clear to me that Intel's technology isn't quite as good as AMD's Opteron and Barcelona, but then again, they've had their version of a quad-core x86_64 CPU for quite some time, while AMD's still waiting on the official launch of their quad.
The differences in CPU design are significant. Where Intel basically bolts two dual-cores together to make a quad-core, AMD is placing all four cores on a single chip, in all its HyperTransport and NUMA glory. I've found the Operton to be the better choice for lots of workloads, especially RAM-intensive applications, and found Intel's new Xeons to be speedy, but challenged in key areas, such as bus performance and memory access. Those points are moot, however, if AMD delays Barcelona too much longer. I know I'm eager to set these new chips against each other, but it will be a bit of a wait on both fronts.
Whatever else is happening, it's certain that on every level, CPU development is full steam ahead... just in time for everyone to start spec'ing gear for their virtualization rollouts.
Posted by Paul Venezia on July 25, 2007 12:56 AM
June 08, 2007 | Comments: (0)
Making APC network cards play nice with Active Directory
Since I'm flush with APC gear at the moment, I've been working with the network management devices (obviously, since I wrote Cacti and Nagios plugins for most of them). One of the features of most of the hardware is the ability to use local or RADIUS authentication. Obviously, with a large number of devices, using centralized authentication is not just a good idea, it's the only way to fly. Unfortunately, none of the NMCs have straight-up LDAP auth, but they will do RADIUS. Thus, using Microsoft's IAS (Internet Authentication Service) -- their interpretation of a RADIUS server, it's possible to do auth to AD via RADIUS though it's not exactly straightfoward.
APC has a knowledgebase document that describes a RADIUS implementation using FreeRADIUS. I'm a big FreeRADIUS fan, having used it in countless UNIX and dialup scenarios. However, it won't authenticate to AD without some serious gyrations, and it's simpler to use IAS. In order to use IAS, however, custom attributes need to be defined, otherwise logins may work but the admin bit will not be set and administration of the devices will be impossible. Here's the remedy.
Install IAS on a Windows server and register it with AD. Then, define a client. The client should be configured with any friendly name, and the IP of the NMC card in the APC device. Set the vendor to RADIUS Standard, and define the shared secret you'll be using. Next, define a new Remote Access Policy. Add some conditions, such as Windows-Groups matches "DOMAIN\Domain Admins" AND Client-IP-Address matches "172.16.1.*", which would cause this policy to only grant access if the user account is in the Domain Admins group, and the client IP falls within the 172.16.1 network. It's a good idea to restrict access in this way, since IAS RADIUS policies stop on the first match -- if you have multiple policies, you want them to be specific to their task.
Once this is done, some custom attributes have to be defined to grant admin privs to the user logging into the APC gear. Click Edit Profile with in the policy properties page. Click the Advanced tab, and Add an attribute. Select Vendor-Specific, and then click Add. Click Enter Vendor Code, and enter 318 into the text field to the right. Then, click Yes, it conforms, and then click Configure Attribute. Set the Vendor Assigned Attribute Number to 1, Attribute Format to "Decimal", and the Value to 1. This specifies that the value of attribute number 1, with Vendor Code 318 should be a decimal (integer) and be set to 1. The other possible values are 2, which denotes a device login, or 3, which is a read-only login, and is the default if this attribute is not defined. Note that by defining another policy that might match on a different set of groups, and setting this value to "3" will result in those users getting read-only access to the same devices, which might be handy.
Click OK a few times to get back to the Profile settings dialog, and select Authentication. make sure CHAP and PAP are selected, then click Apply and OK. Make sure that "Grant remote access permission" is selected, and click OK again. At this point, the server should be configured properly for the one RADIUS client originally specified. I usually stop and restart the IAS server at this point, since I've seen it act oddly when this isn't done.
Now, log into the APC device and configure RADIUS authentication. This is usually found on the Administration tab, under Security/Remote Users. Note that this has been tested with APC app module v3.3.1, and aos 3.3.4. If you haven't updated to this revision of the firmware on your devices, it's well worth the time to do so before continuing. Prior revisions may not even support RADIUS auth, for instance.
Fill in the server IP address and shared secret, then test the authentication. Assuming it works, set the authentication selection to "RADIUS, then Local Authentication", log out and then log back in with an account that matches the Remote Access policy defined on the IAS server. You should be in like Flynn.
I've run into some issues with using Network PowerChute with RADIUS authentication -- namely, the Network PowerChute service will not properly authenticate to a UPS NMC card that's configured for RADIUS auth, even with valid RADIUS credentials. I'm working with APC on a solution to that issue now, but I've tested this configuration with APC managed rack PDUs and air units without issue.
Posted by Paul Venezia on June 8, 2007 12:33 PM
May 30, 2007 | Comments: (0)
3Ware's 9650SE and the Sun Ultra 40 M2
For the past few months, I've been running a Sun Ultra 40 M2 coupled with a 3Ware 9650SE SATA RAID controller. It would seem that this is a marriage made in heaven.
As I've remarked before, the Ultra 40 M2 is simply the most powerful workstation available from a mainstream vendor today. Armed with two AMD Opteron 2218 dual-core CPUs, up to 16GB RAM, eight hot-swap SAS or SATA drive bays, two PCI-X slots, built-in 7.1 sound, S/PDIF optical input and output, a dual-layer DVD burner, and (in my case) an nVidia Quadro 5500 graphics card, this system is the creme de la creme of the workstation world. The only downside is the relatively anemic nVidia SATA RAID controller built into the mainboard. The performance of this controller isn't terrible, but the Linux driver support simply isn't there. Enter the 3Ware 9650SE.
The 3Ware 9650SE-8LPML I have running in this system is a full-on 8-port SATA RAID controller with 256MB RAM and an optional battery-backup unit. There are two four-port SATA multilane connectors on the card, which can be used to marry the 9650SE to a multilane-capable disk array, or to individual SATA drives with multi-lane to discrete cabling. In the case of the Ultra 40 M2, however, multilane to SAS cabling is needed. Fortunately, the built-in nVidia controller uses multilane connectors to feed the disk backplanes within the Ultra 40 chassis, but the included cables aren't long enough to reach the 9650SE. Sun can supply cables of appropriate length to reach the card, however.
Once I had the right cables, it was simply a matter of cable routing to each backplane connector and then back into the 9650SE. The fan tray that sits to the left of the disk bays can get in the way here, but some creative cable management within the case made everything fit and look like it was meant to be there. I placed eight 250GB SATA drives in the disk cages, and powered the system on. The 9650SE posted, found all the drives, and all was well.
I configured the eight drives into a RAID50 set, giving me high throughput on 1.36TB of usable space while providing significant fault-tolerance. The configuration through the 3Ware BIOS tools is quick and easy. Unfortunately, installing and running Fedora Core 6 (or any reasonably recent distro) on the 3Ware 9650SE isn't as simple. The 9650SE and the more recent cards from 3Ware aren't supported in the included 3w-9xxx driver found in stock 2.6 kernels. Historically, 3Ware has been extremely good at providing support for Linux and FreeBSD, so I would think that this problem will be rectified shortly, but in the interim, there are a few steps involved in getting everything working right on Fedora and RedHat. The first is to download the right install disk from 3Ware. You can find the files for just about every major distro on their site. These are just zipfiles with driver sets. Format a floppy with mformat (mformat a:), and unzip the installdisk file to the floppy. Then, boot the system as you would for a normal installation. At the boot: line, enter linux dd and the installer will prompt for a boot disk. Select the floppy drive, and it should load the appropriate driver. Continue the installation normally. On the Ultra 40 M2, I had to use a USB floppy drive, which appears as /dev/sda.
Following the initial boot, the system needs to be updated. Be aware that updating the kernel may result in a non-bootable system since the new kernel will not have the right driver for the 3650SE. Fortunately, it's easy to remedy this problem. Run the yum update to pull in all the new packages, including a new kernel and kernel-devel package. Then, download the upstream driver for the 2.6.19+ kernels from 3Ware's download site. Extract the driver source into a new directory, such as /usr/local/src/3ware, (mkdir -p /usr/local/src/3w-9xxx; cd /usr/local/src/3w-9xxx; tar zxf /path/to/source.tgz; tar zxf ./3w-9xxx.tgz) move into the driver directory, and edit the Makefile to pull in the right kernel path. In my case, the SRC:= line at the top of the Makefile should be modified to SRC := /lib/modules/2.6.20-1.2948.fc6/source/. This will tell the compiler to build the driver with the source tree of the new kernel, not the running kernel. Then, simply run /lib/modules/2.6.20-1.2948.fc6/updates and you should be all set.
Once this was done, I rsync'd 190GB to the fresh install (yes, my home directory is 190GB), and saw write throughput to the RAID50 set at around 100MB/s. Reads were slightly higher than that at 110MB/s. I've been beating up the 9650SE and the Ultra 40 M2 with my normal brand of workstation torture -- cyclic MD5 sums on multi-gigabit files, kernel recompilations, DVD ripping, MP3 encoding, and two virtual systems running under VMware Workstation 6, all while playing movies from NFS shares and running Beryl with all the widgets enabled. Between the stellar performance of the 9650SE and the calm and steady power of the Ultra 40 M2, all of these tasks were handled with aplomb. Suffice it to say, you'd be hard-pressed to equal or surpass the performance of this box with any computing hardware available today.
As far as longevity and survivability goes, the 9650SE has been running for a few months without a problem, and my several-year-old 9500 8-port SATA RAID controller has been driving a four-disk RAID5 set without a hiccup. If history is any indicator, reliability isn't an issue with 3Ware cards. I'll be posting more on this power duo as time and events warrant, but for right now, I'm a very happy guy.
Posted by Paul Venezia on May 30, 2007 10:17 AM
May 02, 2007 | Comments: (0)
Check it out: Deep into APC hardware management
I just barely finished turning up two new datacenters in two different states within two weeks. Exhausting? Definitely. On the plus side, however, I wrote several new tools and plugins to manage all of the APC gear that went into both sites with Nagios and Cacti.
First, a little background. Both datacenters were built to be nearly identical to each other -- from rack layout to equipment, to color-coded patch cabling. The major difference is that one site is cooled with APC ACSC100 In-row air units, and the other cooled with ACRC100 In-row water-cooling units. Both sites are powered from APC Symmetra PX UPSes and PDUs, and use APC racks and 3-phase zero-U rackmount PDUs. In addition, several NetBotz WallBotz 500 units were implemented to provide external environmental monitoring and surveillance of the rooms. Basically, it's all APC gear. I'll be posting more on the build process over the next few weeks, but I wanted to get some of the code out there first.
I wrote two main plugins for Nagios and Cacti to assist in monitoring all this new stuff. The Nagios plugin checks the most pertinent data on the ACRC and ACSC units, as well as the main sensors on the NetBotz units, and the load on each phase on the PDUs. It's come in very handy since the sites were turned up, since I have a easily-digested central view of all PDUs, or all AC units on one page. Tweaking parameters on the AC units becomes very simple when you have all the data in one place, versus having to log into each unit to get status info, or even using APC's Infrastruxure Central Console.
I've released the Nagios plugin, check_apcext, and will be posting the Cacti templates soon. Here's the overview of the Nagios plugin, and a link to the NagiosExchange page. Enjoy.
Usage: ./check_apcext.pl -H <hostip> -C <community> -p <parameter> -w <warnval> -c <critval>Parameters:
APC NetBotz
nbmstemp NetBotz main sensor temp
nbmshum NetBotz main sensor humidity
nbmsairflow NetBotz main sensor airflowAPC Metered Rack PDU (3 phase)
rpduamps Amps on each phaseAPC ACSC In-Row
acscstatus System status (on/standby)
acscload Cooling load
acscoutput Cooling output
acscsupair Supply air
acscairflow Air flow
acscracktemp Rack inlet temp
acsccondin Condenser input temp
acsccondout Condenser outlet tempAPC ACRC In-Row
acrcstatus System status (on/standby)
acrcload Cooling load
acrcoutput Cooling output
acrcairflow Air flow
acrcracktemp Rack inlet temp
acrcsupair Supply air
acrcretair Return air
acrcfanspeed Fan speed
acrcfluidflow Fluid flow
acrcflenttemp Fluid entering temp
acrcflrettemp Fluid return tempThus, in checkcommands.cfg, place the following:
define command{
command_name check_apcext
command_line $USER1$/check_apcext.pl -H $HOSTADDRESS$ -C $ARG1$ -p $ARG2$ -w $ARG3$ -c $ARG4$
}and in services.cfg, you'll have something similar to the following:
define service{
use generic-service
hostgroup_name acsc
service_description ACSC Status
is_volatile 0
contact_groups admins
check_command check_apcext!public!acscstatus
}
define service{
use generic-service
hostgroup_name acsc
service_description ACSC Rack Temps
is_volatile 0
contact_groups admins
check_command check_apcext!public!acscracktemp!90!95
}... and so on, for all parameters you wish to inspect. There are two special cases:
1) ACSC and ACRC status has no warn/critical values -- it's OK if the unit is operating, and WARNING if it's on standby
2) Rack PDUs will flag as WARNING or CRITICAL if any of the three phases is beyond the threshold.TODO:
1) NetBotz external sensor monitoring
2) Other rack PDUs (although I don't have any to test)
3) Bugfixes?
Posted by Paul Venezia on May 2, 2007 11:29 AM
March 30, 2007 | Comments: (0)
When it rains, it pours. I've been absolutely slammed with work lately, between the Asterisk piece that printed a few weeks ago, going in-depth with Sun's x4500 Thumper storage server and ZFS, a large-scale NAS filer test that is just about to get sewn up, and coding the ASAP tool (nee FindMe) that I'll profile in this space very soon. All that on top of building two brand-new datacenters in two states simultaneously. Suffice it to say, there's little time for anything else at the moment.
During all of this, I took receipt of a Sun Ultra 40 M2 workstation loaded with 16GB of RAM, an nVidia Quadro 5500 graphics adapter, and dual dual-core Opteron 2218s. At around the same time, IBM sent me a zPro workstation with two dual-core 3.0Ghz Xeon 5160 CPUs, 8GB of RAM, and an nVidia Quadro 3500. They're both extremely high-powered workstations, but in two different classes.
The Sun Ultra 40 M2 is the next generation of the original Ultra 40, which I took a look at last year. The M2 is the refresh, and offers eight 3.5" hot-swap SAS or SATA drive bays, the new Quadro 5500 graphics adapter, and a few other tweaks. If you've never seen a Quadro 5500, it's a monster -- it's two slot-widths wide and uses all of a PCI-Express x16 slot. Of course, the Ultra 40 is nVidia SLI-ready.
Essentially, the Ultra 40 M2 is the most powerful x86_64 workstation you can buy today. The graphics performance is phenomenal, with quick testing of GLXGears showing around 15k frames per second at 1280x1024. The built-in 7.1 sound as well as S/PDIF input and output is great for DAW applications, and with a current max of 32GB RAM and 6TB storage with 750GB SATA drives, it can scale far beyond most servers, never mind workstations. The built-in RAID is of the nVidia flavor, which is relatively poorly supported on anything but Windows, but I tossed in a 3ware 9650SE PCI-E SATA RAID6 controller, which married quite nicely to the multilane drive backplane, and voila, 110MB/s writes to a RAID5 array of six 250GB SATA drives. I'll be posting something specifically about the 9650SE soon, as well. What a wonderful time to be alive.
Vista is well supported on the Ultra 40 M2, and an install of Vista Ultimate easily cleared every performance hurdle during install. All the semi-neato eye candy in Vista is at your fingertips. Red Hat Workstation 4 runs just fine, as does Fedora Core 5,6, and the nascent 7. Windows XP x64 is also supported.
The pricing starts at around $11,000 for the configuration I have here, but if it's the fists of God you're looking for, you'd better be willing to pay a holy price.
The IBM zPro isn't at the same level as the Ultra 40 M2, but then, it's not in the same price class as the Ultra 40 M2. It doesn't have the same aesthetic appeal of the Ultra 40, and it really looks like a small AS/400, but in a way, that's not a bad thing. It certainly looks powerful. And in reality, it is. The two dual-core Xeons aren't Opteron 2218s, but they're no slouch, and the same goes for the Quadro 3500. Internal storage is provided by up to four SATA or SAS drives with an optional RAID controller. The audio is pedestrian but functional, and the overall package is nicely appointed for the price, around $8k in my tested configuration. Like the Ultra 40, Vista Ultimate has no problem on this system, nor does FC5, 6, 7, and RHWS 4. With twin 21" LCD panels fired up and an installation of FC7, it's ready for anything.
Unless you're trying to find the last digit of pi, either of these workstations will knock your socks off and leave you wondering how you ever used a computer before. As I gaze at my dual 1Ghz PIII workstation from several years ago (which was the bee's knees then), the march of technology snaps into clear focus. The PIII is a doorstop now, not even really fit for server duty. These two workstations, however, have a long way to go before being relegated to inevitable obsolescence.
As I continue to work with these systems, I'll continue to post tidbits about them. If you're wondering, the forcedeth issue I noted awhile ago was from an install on the Ultra 40. Such is life.
Posted by Paul Venezia on March 30, 2007 02:21 PM
March 21, 2007 | Comments: (0)
IT Watchdogs and the Dell mystery solved
In response to my recent APC NetBotz review, Robert Rosen hipped me to IT Watchdogs, a company that makes similar environmental sensors. They lack the heavy-duty server-side components, but offer a wide array of sensors for reasonable prices. Looks cool.
My post the other day on Dell basically selling the 6950 for the cost of the RAM and CPUs garnered some attention. It seems that Dell's pricing is accurate for the moment -- 30-40% off the normal pricing in an effort to bring more eyeballs to their new server lines. At $29k, it might be worth buying the server just for the RAM and procs. I'm interested to get a look at a Dell-built Opteron server just as I'd be interested in checking out a sports car built by International Harvester -- just for the sheer novelty.
Posted by Paul Venezia on March 21, 2007 09:19 AM
March 19, 2007 | Comments: (0)
I've been perusing vendor websites comparing prices on their big iron Opteron boxes. I've found something that isn't quite right:
1) Sun x4600 M2, 64GB RAM, four Opteron 8218s, two SAS drives, RHEL3, rack kit: $47,999
2) HP DL585G2, 64GB RAM (extrapolated from their online pricing), four Opteron 8212s two SAS drives, RHEL3, rack kit: $70k or so
3) Dell PowerEdge 6950, 64GB RAM, four Opteron 8220SEs, two SAS drives, RHEL3, rack kit: $30k
Notice something odd? There isn't much in the way of detailed specs on Dell's site, but their pricing for 4GB DDR667 RAM is $20k for 64GB, or around $1.5k/DIMM. HP's pricing is $4k/DIMM. Sun is in the middle, and to be fair, the x4600 scales to twice the spec of either the Dell or HP system. Either Dell's throwing one heck of a loss-leader in a bizarre way, or someone messed up the site pricing.
Posted by Paul Venezia on March 19, 2007 11:41 AM
March 02, 2007 | Comments: (0)
Awhile back, Dell sent me an RD1000. It's an attractive little external removable drive, fed by USB2, with 40, 80 and 120GB cartridges. The cartridges are really just SATA hard drives, but they're cheap and easy to handle. I've put my RD1000 through an enormous number of read/write cycles without a hitch, and am currently running it on my FC6 workstation as a local backup drive. An rsync cronjob runs nightly to sync the most vital 110GB of my 180GB homedir to one of the 120GB cartridges. I've found that it's actually quite speedy relative to price, coming in at around 28MB/s writes, 38MB/s reads with an ext3 filesystem -- not too shabby. For remote site system backups in a small office, this thing is perfect. The cartridges are sturdy enough to be shipped repeatedly, easily handled by non-savvy folks, and cheap. I believe that the disks are just straight SATA drives, so in the event that the chassis has a problem, it may be possible to bring up a cartridge on a standard SATA controller -- I haven't tried this yet, though it's on The List.
I was actually thinking of the RD1000 following a phone call from Oliver Rist, who spent the first 5 minutes on the phone trying to unmount a failed IOMega external drive that had just gone south, taking 90GB of apparently important data with it. His preferred method for fixing the problem centered around rapid-fire expletives followed by hitting things with a shoe. Of course, this being Oliver, I can only imagine that at least 80GB of the departed data was home video of him practicing to be a cage fighter. The world mourns the loss.
Posted by Paul Venezia on March 2, 2007 05:53 PM
January 29, 2007 | Comments: (0)
Forcedeth issues in 2.6.19/FC6
If you happen to be running Fedora Core 6 on a AMD64 system with the nVidia MCP55 chipset, specifically the MCP55 Ethernet controllers, the update to kernel 2.6.19-1.2895 will probably break your Ethernet driver. In my minimal testing, the 0.57 forcedeth driver hangs after some number of bytes are passed through the interface, requiring an up/down to reset. This problem is not evidenced in 2.6.18-1.2798 with forcedeth 0.56, at least as far as I can tell.
The more you know.
Posted by Paul Venezia on January 29, 2007 04:11 PM
January 14, 2007 | Comments: (0)
 | The other day, I had to pick up a cheap PCI-X graphics card to add a third monitor to an Apple PowerMac G5. I also had to get a few other items, so I went to PC Connection's website and used their granular search feature to find all Mac-compatible PCI graphics cards. Admittedly, I wasn't paying terribly close attention to the specs of the card, but the ATI Radeon 7000-series card I purchased was in the Mac category, and was only around $45, so I picked it up. Of course, it's not Mac-compatible -- or at least ATI hasn't released drivers for it. It's detected in the system, but unusable. Time for an RMA. |
So what exactly is ATI trying to tell us with this image? Ostensibly, this card will work in a 386 running OS X with Windows XP floating around somewhere. Click the image for the closeup.
Posted by Paul Venezia on January 14, 2007 09:45 AM
January 11, 2007 | Comments: (0)
The floppy is dead. Long live the floppy!
Today I ran across a dual-CPU HP DL145 G2 that was exhibiting some strange behavior. Although 12GB of RAM was installed in the box (three ranks of 2GB DIMMS per CPU), it was only booting with 6GB visible. Some poking around on HP's support site turned up a technical note that the BIOS on the server (ROM version 2.14) was probably causing the problem. The note's recommendation is to update the BIOS, and provides a handy link to the new firmware download page. This page contains a downloadable Windows executable that will create a floppy disk that updates the BIOS when booted.
Except there's no floppy drive in the server. In fact, it's not possible to buy an internal floppy for the DL145 G2. HP offers a USB floppy drive as an accessory, but that's it. At the risk of berating the obvious, why are the updates distributed this way? What could possibly cause HP to distribute most firmware and BIOS updates as Windows-only executables that can only create floppy disks in the A: drive, especially for servers without even the option of an internal floppy drive?
Another option for booting this server is via virtual floppy. In later revisions of the ILO management code on the DL145 G2, there's an option to enter a TFTP server address and filename that will be presented as a virtual floppy drive on boot. As luck would have it, this server has the older ILO firmware that doesn't support this quite roundabout method of booting from a floppy. The solution? Upgrade the ILO firmware to the later version that does support virtual floppies. Of course, that update is only available as a self-contained floppy-imaging Windows executable. It appears that you simply can't get there from here. My, how aggravating.
Even if booting this server from a virtual floppy was possible, you'd still need to find a Windows XP system to download the update and create a floppy disk, then image that floppy back to a file that could be TFTP'd to the server at boot. Oh, and the Windows-only floppy creating executable in question refuses to run on Windows Server 2003 SP1.
We've been hearing all about the death of the floppy. Many servers and workstations aren't shipping with floppy drives at all, and they aren't an optional part. I've been in many situations where looking for a single usable floppy disk has taken far longer than the update. I recall spending over an hour trying to locate a functional 3.5" 1.44MB floppy at 1am to update the BIOS on another system. What fun that was.
Server vendors are pointing at USB flash drives as the replacement for floppies, which I think is a great idea. But you can't go halfway here -- it's either all or nothing. For compatibility purposes, these updates should be distributed with code that can create a bootable floppy and a bootable USB flash drive. Further, the ability to download the image without the Windows wrapper would make all kinds of sense. There are lots of admins that can use dd; it's not rocket science.
These ideas seem straightforward to me, but are apparently completely novel to HP. Providing required updates in a format that's basically unusable for your own hardware is just breathtakingly ridiculous.
Posted by Paul Venezia on January 11, 2007 02:13 PM
December 27, 2006 | Comments: (0)
Your PSTN and you: Linksys SPA-3102 and Asterisk
So another piece of my Asterisk/TrixBox puzzle was completed today -- or rather, almost completed. I received the Linksys SPA-3102 FXO/FXS SIP ATA, which will be the bridge between Asterisk and one of the incoming POTS lines to the lab. I probably should have ordered the SPA-3000, since I really don't need the routing/NAT capabilities present in the SPA-3102, but then again, it's a lab. I have it working inbound and outbound with Asterisk, and it's also driving a few analog phones that are referenced as a single addressable Asterisk extension. It was a bit of a struggle, but not much. Some notes on this follow:
auth=md5
context=from-pstn
dtmfmode=rfc2833
fromuser=spa3102
host=172.16.32.123
insecure=very
port=5061
secret=spa3102
type=peer
username=spa3102
The Asterisk server is set under Proxy, and the username/password is referenced in the SPA-3102 PSTN Line Subscriber Info section. You will show a failed registration on the PSTN line, but as long as you've flagged
Make Call without Reg and Ans Call without Reg as Yes, it will work. I'd rather have this setup than cluttered extensions on Asterisk that aren't used.
(S0<:4155551212) as Dial Plan 2 under PSTN Line with a corresponding flag to use DP2 under PSTN-to-VoIP Setup will generate a 4155551212 DID to Asterisk for an incoming call. Obviously, you can put whatever you want in that field.
(*x|*xx|xxx|[3469]11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx.)This speeds up recognition of internal extension and feature code dialing, as well as just about everything else. With this dialplan, calls from the FXS port are routed to Asterisk, which has outbound routing configured to prefer the SIP trunks over the PSTN lines for long-distance, and the PSTN lines for all local calling, including emergency dialing.
Aside from a few little pieces, the SPA-3102 is a great unit for the $90 price. The firmware is very complete in terms of tweaking just about every setting, and each port (FXO, FXS, SIP) can be treated as a unique entity, which makes it perfect for this purpose. I did upgrade to the latest firmware (5.1.5GWa as of this writing) without issue, though it requires a Windows system for the upgrade. The Web interface is a little wonky at times, but is otherwise fast and responsive. I especially like the fail-open configuration -- if power is out, the FXS port is bridged to the FXO port so normal calling is still possible.
I'm expecting another one of these for another PSTN line, and possibly a Digium Iaxy to play with. Suffice it to say, I'm getting into Asterisk in a big way.
Posted by Paul Venezia on December 27, 2006 05:07 PM
December 19, 2006 | Comments: (0)
Year end lab notes part 3: Thrilla in Manilla
And at last we reach the last installment of the year-end lab notes for 2006. The previous posts dealt with infrastructure, servers, and network gear. I'm going to add a few notes to those categories, and finish up with workstations, testing tools, apps, PBXes and ISPs.
Workstations
My main workstation is the homegrown Ultra 40 I built in May, running Fedora Core 5 x86_64. After six months of constant (ab)use, it's humming right along. At some point I'll update it to FC6, but not until it's absolutely required. I've found FC5 x86_64 to be stable and reliable, with only a few dependency glitches when installing packages with yum. I'm also using several quasi-compatible repos, so most of those are probably on me anyway.
The raw performance of this workstation is not to be dismissed. I'm routinely pushing the upper limits of the 8GB of RAM present in the system, as well as the disks. It's not just a pretty face, it's a solid workhorse.
As far as laptops go, with one exception, they're all G4 PowerBooks or MacBook Pros. I just received a new 17" MacBook Pro, and my initial impressions are positive. The screen is surprisingly light, and the hinges don't seem to be as tough as on my 15" PowerBook, which has caused a few issues, but performance-wise, it's a keeper. As Tom Yager told me awhile ago, once you get a 17" laptop, you can't go back. I think he's right.
The one exception is a Dell Latitude D800 running FC6. This laptop has definitely not had an easy life. It has traveled probably 50k miles in the air -- via FedEx -- as well as many thousands more a carry-on, been left running for weeks at a time in labs all over the country, and at one point in its life it was drafted into service as the core of an entire L3 city network when the production core switch developed a hardware problem. The embedded gigabit Broadcom NIC actually did surprisingly well at handling the load, as did the FC3 build that it was running at the time.
ISPs
My lab is a bit limited in terms of locations and available services. Actually, very limited. Cable is my only non-TDM option, so RoadRunner it is. In the three-plus years the business-class service has been in, it's been exceedingly reliable and fast. The prices are right, the bandwidth is guaranteed, and the reality is that I've found that nothing else is required. It would be nice to see FIOS or even DSL availability to provide a backup circuit, but given RoadRunner's track record, I'm not worried.
Testing Gear
Whenever I need to pull in some heavy network testing gear, I make a call to Spirent and get a SmartBits chassis with whatever modules I need. The SmartBits are powerful, reliable, and infinitely configurable, almost to a fault. For lower-end testing, I simply write small tools in perl, or use nuttcp, netperf, IOMeter, or any of a dozen other open-source network testing tools. On the storage side, IOMeter, bonnie/bonnie++ and good ol' dd are all that's really required. Also, I'm currently evaluating a Shunra VE network testing appliance, which I'm very interested in using for some upcoming tests.
Apps
I don't really have a stable of go-to applications, I tend to use whatever is available on whatever system I happen to be using. I do plenty of writing in OpenOffice.org and Microsoft Word, but also in vim. I do all of my coding in vim. I use Apple Mail, Evolution and Thunderbird just about equally, as well as SquirrelMail for a Web email client. Firefox and/or Camino are the browsers of choice, and iChat and Gaim handle IM nicely. I do have to give props to ecto, which is one app that I definitely rely on, since I do all my blogging from a MacBook or PowerBook, and ecto makes it obscenely simple.
PBX
If you've been reading my Asterisk posts recently, you know that the voice side of the lab is in flux right now. I'll keep up my notes on that as it progresses.
If anyone has specific questions on hardware or lab infrastructure, feel free to drop me a note and I'll address it. Also, in the very likely event that I've forgotten something, we might just have a part four.
Posted by Paul Venezia on December 19, 2006 06:01 PM
December 15, 2006 | Comments: (0)
More on Asterisk and the Cisco 7970
After some tweaking, I believe I have everything working the way I want it with my new TrixBox/Asterisk system. To recap, the actual Asterisk server is a Trixbox 1.2.3 build running on a VMware virtual server, linking to a SIP trunk from BroadVoice. Internal phones have now been expanded to include a few Cisco 7960 sets as well as the 7970.
Following my earlier posting about getting the 7970 to function with Asterisk, TrixBox founder Andrew Gillis sent me a note about the Endpoint Manager feature in TrixBox, which will create Cisco phone configuration files on the fly. In TrixBox 1.2.3, there's support for the XML configuration file format that drives the 7970's SIP firmware, as well as older phones such as the 7940 and 7960. I'd seen this in my initial perusal of TrixBox, but didn't immediately see that the configuration files were available anywhere, so I built my own. Of course, TrixBox assumes that it will be the TFTP server for the phones, so it dumps the configuration files into /tftpboot on the TrixBox server itself. Well, if I'd looked there to begin with, I wouldn't know half of what I now know about the configuration of these phones... and the phone setup would have been much quicker.
The configuration files generated by TrixBox for the 7970 will work (and seem to have cleared up the continuous ring problem, though I'm not sure exactly why yet), but still need manual intervention to configure some extended functions of the phone, such as multiple line and speed dial settings. Also, the Services and Phonebook menus on the 7970 wouldn't work -- they wouldn't even make a HTTP request to the server. It appears that with the <webAccess> parameter set to '1', the phone's internal Web server and client are disabled. Setting this to '0' seems to have enabled both functions, and the phonebook and services menus are now populated on the phone. In addition, there's a debug statement present in /var/www/html/cisco/services/PhoneDirectory.php that will cause XML parsing errors. Comment out the echo $Query statement near the bottom of that script to fix that problem. I also noted that Cisco has released a new rev of the SIP firmware for the 7970, version 8.2(0) Unfortunately, it seems flawed right out of the box, as the load file that comes with the firmware references the wrong filenames. Specifically, it begins the firmware upgrade process, and looks for a file named Jar70sip.8-2-0-55.sbn, but that file doesn't exist in the firmware zip file. Presumably, it's looking for the file jar70sip.8-2-0-55.sbn, which is present. I began to rename the file to permit the firmware upgrade to continue, but then thought better of it. If Cisco can't seem to get the names of their own files straight in a production firmware release, what other bugs might be in this new version? I punted and am still running 8.0(3).
As far as the 7960s go, they're a whole different beast than the 7970. The configuration file syntax is arguably easier, and they don't have the 7970's habit of going into a reboot death spiral when there are XML parsing problems on the configuration file. They also work flawlessly with Asterisk.
So at the moment I have five extensions on my Asterisk box with a single SIP gateway. I'm going to be dropping in a Linksys SPA-3102 to act as both an FXS and FXO analog adapter for a regular POTS line, and run through the dialplans on both that and the Asterisk box to bring at least one POTS line into the mix, along with an analog phone. If that goes well, the other lines will get the same treatment. The SPA-3101 seems to have the right featureset, including internal dialplans to shift calls from the analog phones to Asterisk first, then the connected POTS line should the Asterisk server be unavailable. Also, in the event of power loss to the SPA-3101, it will fail open, providing the analog phone with a passthrough to the POTS service. Hopefully, it will arrive early next week.
In a perfect world, I'll have everything running through Asterisk with several POTS lines and at least one SIP trunk, a smart dialplan to prefer certain trunks over others depending on the number dialed, and failover to POTS. It'll be a little bit of a project, but every step of the way, I'm more impressed with Asterisk and TrixBox.
Posted by Paul Venezia on December 15, 2006 02:42 PM
December 11, 2006 | Comments: (0)
Year end lab notes part 2: Rumble in the Jungle
Continuing the year-end series I started a few days ago, I'm going to detail some of the networking and infrastructure components of my lab, with special emphasis on what I rely on day after day.
Networking
I've been reviewing Dell's PowerConnect switching line since its inception a few years ago, and have yet to be disappointed with one of their switches. They're not top-end Cisco gear, but they also don't carry top-end prices, and that means quite a lot in both lab and SMB infrastructures. Make no mistake, there's some big Cisco iron in the lab as well, including a 6509, and a 4506, switch. Those switches are used in production as well as forming the baseline for all switch testing. However, as part of my testing of the newest PowerConnect, the 6248 (look for the review in an upcoming InfoWorld issue), I pulled the 6509 out of the core, replacing it with the 6248. The lab network is fully L3 switched, so this put the full weight of the lab through the new Dell L3 switch, and I have yet to pull it out. I might even leave it in place for awhile. Since I did this a month or so ago, the new core has switched petabytes of data without missing a beat. The long-term testing I've been doing with older PowerConnect switches has also gone well -- I haven't had a single hardware problem with any of those switches to date, from the 6024 to the 3424P that runs PoE to all the phones.
The configuration file syntax has changed significantly with the 6248 vs its' predecessor, the 6024. Gone are the scattered commands and repetitive port configurations, and in their place is more in line with true Cisco IOS configs, with each port granted a separate place in the config for individual parameters. It's much, much better.
The Cisco gear hasn't had an easy life, like most of the lab gear, but lives up to Cisco's reputation for reliable, dependable, high-performance switching products. As a general rule of thumb, you can't go wrong buying Cisco switches -- even though you might spend a bit too much. Both the Cisco and Dell switches coexist peacefully, with PAgP aggregate links and 802.1q trunking. No muss, no fuss, it just works.
Wireless
There isn't a significant WiFi implementation in the lab, just a few Apple Airport Extremes and actually a few Linksys 802.11G units. They work well and are largely set-and-forget.
Firewall
The entire lab is firewalled by IPCop 1.4.10 running on an elderly Dell Optiplex GX110. It's a very small footprint workstation-class system with a PIII 667Mhz CPU, 128MB of RAM, a few 10/100 NICs and a CF-to-IDE adapter with a 512MB CompactFlash card. No moving parts other than the CPU and case fans, and voila, a stable, reliable, configurable, open-source firewall. IPCop really is extremely easy and featureful. Currently, my IPCop box is doing some rudimentary QoS for SIP calls, providing an OpenVPN endpoint for when I'm on the road, and running several nailed-up IPSec VPN connections to a variety of other gear, including PIX firewalls and SonicWall firewalls. This system has been in place for five years now without missing a beat. I even had time to put together a gkrellm package for IPCop to let me watch network I/O and stats on the firewall in real-time from my workstation.
Racks, PDUs and UPSes
American Power Conversion (APC), all the way. The abuse that the racks in the lab receive is generally far beyond what any normal production infrastructure would endure, with servers being racked, unracked, and re-racked on a constant basis. The APC enclosures that I have in the lab withstand all of that without even a scratch (really). There's plenty of sidewall cable-routing space, and the 0U networked PDUs make remote powercycling simple.
The UPSes are all APC as well. I don't have a hard-wired UPS, so the lab is served by several SmartUPS 2200XLs and a few smaller units. I do have several dead UPSes still hanging around, including a few older APC models whose batteries gave up the ghost, but the Tripp-Lite unit is a doorstop now, even though the batteries aren't dead, as are the lower-end Belkin units. In addition, when the generator kicks in, it tends to produce occasional harmonics in the lab power service, which none of the other units dealt with very well. The APC units would trigger alarms during these instances, but with the easily-adjustable sensitivity control at the rear of the units, it became a non-issue. Also, the SNMP support is great, providing my Cacti-tweaking habit with plenty of fodder.
As far as the generator goes, it's a Guardian LP unit, straight from Home Depot, with a 200 amp automatic transfer switch. It's saved my bacon several times, though it hasn't been called into service in 10 months or so. Winter's definitely coming, however, and so I have every belief that it'll see some action soon. In the interim, it runs weekly 10-minute exercise cycles that have been keeping it in shape.
KVM
I just installed a Raritan Dominion KX432 to take over for a few smaller Raritan units, including a 10-year-old Master Console IIx. The Dominion series' density is high, the physical units are small, and they have all the features I need in an IP KVM, all contained in a single unit that doesn't require an additional physical server like the Avocent units. Their Java-based console app seals this deal, since I work on Linux and Mac OS X workstations. I've found that the console app can be somewhat flaky over higher-latency connections, but still usable, although working with the networking prefs can improve performance. As a front-of-rack KVM, the Dominion is as solid as any that Raritian has produced... and my recently-retired Master Console IIx can attest to that reputation.
The next part of this series will be workstation hardware and OSes, monitors, phones, and the rest of the little bits. Stay tuned.
Posted by Paul Venezia on December 11, 2006 06:27 PM
December 08, 2006 | Comments: (0)
Asterisk, VMware, a Cisco 7970 and a few hours
Since I seem to be feeling rather talkative today, I figured I'd post a bit on the latest little bit of geekery I committed this week. All noted configuration file examples can be downloaded from here.
I've had a Cisco 7970 running SCCP firmware in the lab for a little, but suddenly it lacked a Cisco CallManager box to talk to when I shipped out some test gear. The 7970 is simply a gorgeous phone (although the SIP code could use some help) and I have a deep-seated requirement to use a cool piece of hardware whenever possible, I decided to hook that phone up to my Broadvoice SIP account instead of my Zyxel 2000W V2 WiFi SIP phone. Theoretically, it should have been simple -- Broadvoice offers a TFTP server for Cisco 7940 and 7960 phones, so it should just be a matter of telling the phone where to find a config file and voila.
Not so.
The 7970 changed all the rules of Cisco IP phone configurations. The new config format is XML, versus the prior variable=value style configuration. This presented a problem. I could take some time and whack away using guessed values for the phone's configuration until I was able to peer with my Broadvoice account, or I could set up an Asterisk system in the lab to switch that phone and the Zyxel, and peer with Broadvoice for outbound calling.
It certainly wasn't as simple as it should be, but it's all working -- well, most of it. At the moment, if a call comes into the SIP line, both phones (extensions) ring as they should given the call group configuration. The Cisco phone, however, never stops ringing. If left unanswered, it will bleat until someone gets annoyed enough to "answer" the non-existent call. I haven't fleshed that bug out yet, but then, I've spent a total of two hours on this since Tuesday, so I'll consider myself ahead of the game.
There's lots of bits and pieces of 7970 information floating about on the Internet. Kerry Garrison's excellent Cisco 7970 tutorial was brief, but formed the kernel of the working configuration I