I just ran through another update exercise. IB cards, OFED stack. GlusterFS atop this. Cards are well known vendors cards. They work pretty well. But … only with very specific kernels. Other kernels need not apply. Our 2.6.32.22 kernel is pretty darned fast (so our customers tell us). Now lets build the OFED 1.5.2 … and see what happens … To make a long story short, we wound up abandoning that approach.

Been a very busy beaver, even with a broken finger. We now have 3 new resellers. We’ll have this info up on a page soon at the day job. One very well known group in edu/research, another helped us get our first NOAA sale, and another is headed up by a former colleague from SGI/Cray days. Very exciting times!

Customers machine went down. They have a spare (buy them in pairs). Needed us to look at it. Set their unit up to boot from a virtual CD over the IPMI port. ?Pointed that virtual CD at a bootserver we had built in a VM. Poked some holes in the firewall. And voila. The machine about 1400 miles away is up and booted, using the bootserver, and we are looking into the failure (looks to be temperature related … go figure) Yeah, it was a little slow, but thats fine for the moment.

One little single chassis JR4 apparently is a bit faster, at being a NAS, than a 6 shelf product from [some other scale out NAS vendor, a rather well known one]. This vendor is currently the rage in NGS circles. We know we are fast. We knew the other folks weren’t so fast. I am … I guess … not surprised … to hear this. There are benchmarks. And then there is the real world.

Latest Scalable Informatics high performance JR4 test runs … untuned. I should say, imagine a rack full of 10 of these, with a functional IB QDR fabric behind them. Makes for a nice 23 GB/s (best case) per rack cluster file system platform. [root@localhost ~]# dd if=/dev/zero of=/data/big.file ... 2450+0 records in 2450+0 records out 82208358400 bytes (82 GB) copied, 36.4844 seconds, 2.3 GB/s [root@localhost ~]# dd of=/dev/null if=/data/big.file ... 2450+0 records in 2450+0 records out 82208358400 bytes (82 GB) copied, 37.

While I am pleased to see them in the news, and they are showing how their technology works well on a multi core system … I guess I am troubled by something. Maybe it was the run on the SGI Altix unit. You don’t expect many of those to be around. Maybe it was the 30x performance gap over the CUDASW++. Which suggests that 30 nodes with 2 Teslas each could match the results obtained, at a fraction of the cost, power, floor space, cooling budget.

Again,M&A; on a roll. Larger vendors going for the “integrated” stack. I won’t comment on whether or not a single vendor is a good idea for anything … there are several recent examples of single vendor with a change of business direction resulting in a rather large and extended “oh-feces” situations for their now former HPC client??le. There are economies of scale, there are synergies. One company cannot hope to do everything well for all customers.

Doing more siCluster quotes per day than I thought I would be at this stage. Each unit in the JackRabbit JR4 based siCluster sustains well over 2GB/s to and from disk for TB sized files. Some of the benchmarks we’ve seen suggest strongly that ‘competitive’ solutions require many more of their systems to achieve bandwidth and application performance parity, which turns the already unfavorable price performance comparison into a rout. We are hearing from customers deploying JackRabbit units in ways we didn’t originally intend, now indicating that they scale quite a bit better than their modern (insert enterprise NAS vendors here) NAS system.

Hearing more M&A; rumors, can’t say who. This is the time to buy, get the deal done now before the prices rise.

I have a cast on from my hand surgery last week. I have a new metal plate attached to my bone. Learning to be a southpaw isnt easy. I get the cast off this morning. Should be fun. Then the PT starts. This is one of the very few forms of socially and legally acceptable torture on the planet.