Slashdot Mirror
HyperSCSI Examined
An anonymous reader writes "Eugenie Larson of byteandswitch.com has published a brief article that reviews the HyperSCSI protocol, which like iSCSI allows for an IP based san. The twist of HyperSCSI is that it's opensource, and runs over raw ethernet, avoiding the overhead of TCP/IP. The article has some comments from early adopters of HyperSCSI, as well as some comments from top vendors in the iSCSI industry."
The summary says "IP based" then "without the overhead of TCP/IP" and then "raw ethernet".
Which one?
Can't be both IP based and raw ethernet at the same time.
You don't expect us to RTFA do you?
I like the idea. Ethernet hardware is dirt cheap and fast. What it needs is a cheap IDE bridge board. That would let you put some IDE drives in an external enclosure and plug them into the local LAN.
Mea navis aericumbens anguillis abundat
why is there an article on this, i mean linux wont support it for another 2 years lol obviously, it's so when linux does support it, legions of slashbots can complain about the duplicate stories!
Do you even lift?
These aren't the 'roids you're looking for.
If you look go to the MCSA site and look at the HyperSCSI FAQ, it does implement reliability and flow control, just not in the same manner as TCP.
The only technical negative side I can (at this time) is that because the implementation isn't over IP, you can't traverse a router. This usually isn't a problem but could cause some inflexibility in larger deployments.
More to the point, we have usb 2, serial ata, and firewire. Really all you should need is usb 1.1 and firewire in ever-increasing speeds, besides your display output. There's literally no need for anything else. Firewire can be operated in a synchronous fashion, after all. It supports lots of devices per adapter (63 or 127 depending on implementation) and comes in powered and unpowered as well as peer to peer or host-based forms, but nearly all devices will fall back to the lowest, slowest mode - which is capable of 400Mbps per second, or 50 Megabytes, clearly enough for all but the fastest hard drives, and nearly any other use to which you might put it. 800Mbps firewire is available today, and 1.6Gbps is uh, just over the horizon or something. They claim they'll do 3.2Gbps over fiber in the near future as well, but I'll just stick to developments just over the horizon, not way over it, here.
Frankly what I want to see more than anything is native 1394 storage devices. 1394 is somewhat to scsi (it would kind of have to be, wouldn't it?) and is at least well documented. I want hard drives that have only power and 6 pin 1394 connections on them, pass through style. You could treat them basically like an external scsi chain not requiring termination, but inside your PC. Firewire to IDE bridges are not the answer, they just make things more complicated and firewire is supposed to make things less complicated, though I suppose they are a sort of interim solution.
For the average user, if you could get native (and thus inexpensive) firewire solutions for everything, it would fulfill your needs much better and would make computer use much simpler. The only thing you need besides firewire and USB for every common peripheral is video output and possibly high speed networking, perhaps provided from a MII or similar connection, just as AUI was the standard at one time. Just, without the annoying box and cables. And let us not forget, a memory slot. I assume most people would also like to have wireless ethernet with an external antenna jack. For the rest of us, we would continue to run our however-shaped boxes with internal expansion, PCI-Express or what have you, and our cabling would be much simplified. Once again, 800Mbps is 100MBps, yes? Assuming you can only really sustain 50 or 60% of that with multiple devices competing for the bus, that's still fast enough for basically any two hard drives anyone is likely to have at home. So 800Mbps firewire is perfectly adequate to the task of connecting hard drives today. It's not that SATA isn't, it's that having less types of interface simplify a computer. If you're only going to have two interfaces, you will get more mileage out of USB2 and IEEE1394 than you will USB2 and SATA, even one of the bastardized forms of it like External SATA, if people will just make IEEE1394 devices.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The article does and abysmal job of covering this, but the homepage for HyperSCSI has a nice PDF presentation that covers just this topic. In short, it goes something like this: The SCSI protocols already provide error checking The HyperSCSI layer adds flow control and retransmits Ethernet provides certain other checks So, in total, you have the same reliabilty of iSCSI and FibreChannel with less overhead (i.e. significant overlapping of the protocols in terms of error detection/correction).
Oh, was that my outside voice?
USB maximum cable length: 5m
Serial ATA maximum cable length: 1m
Fiber Channel maximum cable length: 10,000 m
The lessons of NFS are being ignored, and I'd expect HyperSCSI to die when it hits the same limitations.
NFS started out UDP-based, and moved toward TCP with NFSv3. Why? Because having all that error correction done at the network layer made for a better product; TCP does all the work to insure packets aren't lost or out-of-order. UDP doesn't, and the NFS application layer had to handle it, making it slower, more painful, and a duplication of effort better spent elsewhere.
The industry guys are almost right on this one. It isn't a beer can with a motor; it's a beer can with an M-80. Fun to watch when it works right, damn painful if you screw it up.
Fiber Channel maximum cable length: 10,000 m
Add the appropriate routers and switches and you can easily go 90 km on dark fiber. Add some appropriate routers onto a fast network (T3, ATM, what have you) and you can go 500 km. With fast FC connected storage at each end. Of course, this sort of solution is used by data centers, not home users. But Fiber is the obvious solution to data storage problems. And there is enough mass in the server storage market now that prices are starting to come down. Of course, if you need fast, redundant, capable storage you won't blink at the cost.
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.
Never underestimate the bandwidth of a pair of sneakers carrying a hotswappable hard drive jogging down the hallway.
KFG
Because the IP checksum and TCP checksum occasionally disagree about the packets' validity in real-world routers and operating systems - they are both needed to provide redundancy and robustness. Stevens' TCP/IP Illustrated cites [Mogul 1992] providing counts of checksum errors on a busy NFS server:
Layer Total packets # chksum errs
Ethernet 170,000,000 446
IP 170,000,000 14
UDP 140,000,000 5
TCP 30,000,000 350
Basically, when absolute accuracy is required the more error checking the better.