Don't Fedex your tapes, people! We're so fast it's SANdulous – WANrockIT Bridgeworks says it can make communicating with offsite tape libraries vastly faster than physically shipping tapes, and vastly cheaper if you are using a remote Fibre Channel SAN or site-to-site replication before transmitting data to the tape library. The basic pitch is: "Don't do this. Send your data direct to a SCSI tape …
When the round trip latency was increased to 360ms, simulating a longer WAN distance, the raw transmission time for 1GB was 42.6 mins while with WANrockIT it decreased to 12 seconds.
So they're using a bulk-transfer protocol with large window sizes, and possibly separate streams within the physical link? Is this really all that novel?
How does it compare with FTPing a tape image? Or even the classic "747 full of DVDs (or Bluerays)" ?
"How does it compare with FTPing a tape image? Or even the classic "747 full of DVDs (or Bluerays)"
The bandwidth of a 747 full of media is well in excess of 10TB/s [1] so the raw transmission time for 1GB is less than a millisecond. A motorcycle courier can manage 1GB/s (i.e. 10Gb/s) London to Edinburgh.
Ping time is several hours though!
I cannot remember a time in the past (nor envisage one in the future) when any networks had a higher bandwidth than the movement of contemporary physical media.
[1] A 747 can carry 100 tonnes of cargo (I think), a 2TB SSD weighs less than 100g including appropriate packaging, meaning that is 2 Exabytes per Jumbo, say 8 hours for a LON->NYC flight time and 2 more hours handling time, around 50TB/s unless my maths is letting me down.
In that case, rust is only about 8TB/Kg, compared to about 30TB/kg for SSDs.
100 tonnes of Samsung 850EVO 2TB SSDs at 66g is 3EB which I rounded [1] to 2EB; 100 tonnes of WD Red 6TBs at 753g is only 0.8 EB
[1] We probably need packing overhead but, in any case, when I'm guestimating I like to go for what I call 'currency logs' in other words, chose a 1, 2 or 5 then a number of 0s. I find this is a good compromise between the intuitiveness of 'order of magnitude' and the difficulty of, in situations like this, getting enough precision for even 1 significant figure (although I've never really been sure whether the choice for first digit should include '8').
"I cannot remember a time ... when any networks had a higher bandwidth than the movement of contemporary physical media."
One has to add in the time taken to transfer all of this data to the physical media concerned, which might not be insignificant - before there's anything to move / transport.
No it doesn't necessarily run with large window sizes it can still run with any window size and get the performance. Note we do not set the window size we let TCP/IP do that. This is a single stream to a single tape drive.
PS We can make FTP run faster but we can't do anything about making a 747 go any faster.
The article says "We're told 40ms of latency is approximately half way across the USA. Transmitting 1GB through an unaccelerated link with that latency took 5 mins 20 secs. WANrockIT accelerated it to 11.8 secs."
Since latency has no actual impact on one-way data transfer speed, any improvement is surely down to delaying acknowledgements, either by using large packets or large windows? Using large packets has a problem on noisy links, since even a small number of retries can kill performance. You're still subject to the laws of physics, and I suspect that a well-tuned TCP/IP stack with judicious packet and window sizes could match these figures, at least for a bulk transfer copy protocol.
The previous advertarticle about PORTrockIT has a graph that shows no real benefit from acceleration in the absence of packet loss, regardless of round trip time, but significant benefits in the presence of packet loss.
As far as I can gather (the company's website doesn't work with AdBbock Plus), WANrockIT is basically the same technology in a box, so it's surprising to see these claims relating to improved performance in the face of latency alone. If they can do it for one, why not for the other?
Sorry, so the PORTrockIT stuff is application-specific and the WANrockIT stuff is lower layer?
While I admit to being easily confused, the white papers refer only to PORTrockIT and the WANrockIT manuals all point to products that appear actually to be called SANslide, so the differentiation is not immediately obvious...
Bridgeworks says this "performance makes off-site tape replication into a realistic and attractive proposition for organisations of all sizes," and that would certainly seem to be true.
Where on earth is your usual cynicism, El Reg?
Replace "and that would certainly seem to be true" with "but I for one would like to see these results repeated by someone else before I was in any way convinced."
Sever a submarine cable between the two locations... Then ship the tapes home by conventional means... What do the tests show?
What fault tolerance is there to pick up and continue a backup after widespread disconnection... ? I honestly don't see any rigorous testing here....
Corporate outsourcing will mean no one notices until 'the IT infrastructure' falls over ... Confidence is not high!
Yes! That is why you can set primary and failover connections. As for a failure in the middle we will act exactly the same way as though you had lost a FC connection or an iSCSI connection within a DC. A tape drive failure will reported exactly as a local tape drive failure would be. We have accounts out there that have subjected our technology to severe fault injections and we have passed. Oh and by the way, typically you can read the tape at the same speeds you write to it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
