 Okay, we're back, this is Dave Vellante of Wikibon.org. Ron Asher is here, he's the Director of Worldwide Development for XIV, based in Israel. Ron, first of all, welcome to the Cube, great to have you. Thank you, thank you. The design of XIV was always around taking low-cost discs, you know, SATA-based discs and making it, you know, perform like a Tier 1 storage device, but be very cost-effective. You had some innovative ways of spreading data around, but so now then Flash comes into the mix. So what's new with XIV? So I would say that, you know, when XIV started, there were only one terabyte drive available. And if you look at, if you compare it to the fast spinning drives, compared to the slow spinning drive that XIV pitched, there wasn't a huge difference in the capacity. If you look at it today, we are going to announce use of 4 terabyte drive, which is 4x of what we delivered to start with. And the improvement is huge. So we were able to take power consumption down, we were able to take, in the same footprint, fit 4x capacity, 4x usable capacity, and boost up performance. And it's the DNA of the architecture that we can spread everything across all the resources. Now it manifests itself to a slow spinning drive and boosting up performance with smart caching, but what we're doing with Flash is taking it to a larger extent. So like we do with spinning drives, we are using the MLC Flash Memory and we started conservatively using it for caching purposes and that manifests itself to a greater extent. So if you look at our XIV system without Flash, it can do 40K IOPS in random workload, which is like SPC1 like. But with the Flash, it can do 180K IOPS, which means that we are almost delivering 1K IOPS per slow spinning drive that physically can do about 200. That's the huge improvement. Now if you look at the architecture of XIV and Flash, you can have 15 Flash devices working for your workload at once. It's something that is very difficult to achieve with the traditional architectures. So the grid-scale architecture works here for Flash also. So now you're bringing in Flash into the equation. A lot of people are going to say, oh wait a minute, that's a bolt-on. That's that pejorative that they'll use against that. They'll say that the architecture wasn't designed for Flash. I'm presuming that you're going to argue that that's not the case. So please make that argument for us. So interestingly, using the Flash media is different than spinning media. So we have a lot of optimizations that has to do only with the spinning media. Like we're trying to sequentialize random workloads and do a lot of caching. But if you look at the fundamental architecture where the brooch load is broken into small pieces and spread out across all the resources that can be cached, that can be spinning media, that works also for Flash. So we were able with the Flash caching to leverage the Flash media to that extent. So you have megabyte pieces cached on the 15 SSDs that we are using. And you see how efficient that is in the Achilles seal of XIV in the random workload. And if we're taking it to a larger extent, if you look at Flash without breaking the volumes into smaller pieces, you can store them efficiently on Flash and you can better manage the high-grain or failure domain of Flash. So if we are losing a piece, we don't have to recover the entire media. We need just to recover this piece that failed. This is the advantage of the XIV architecture that has nothing to do with spinning drives.