LTO vs DLT
Emerging as the new market leader, LTO, or Linear Tape Open has spent better part of this year stealing market share from DLT. Attempts by Quantum to maintain their leadership in the midrange backup arena have proved almost fruitless with their SDLT offerings.
Why has IBM's LTO received such a warm welcome? A potent formula combining high capacity, high throughput storage with some of IBM's key tape innovations from the last decade is the catalyst. Sporting 100gb native capacity cartridges and 3rd generation heads and servo tracks expanded from technologies developed as part of IBM's Magstar product line, it's no surprise that IBM's LTO dealt such a vicious blow to Quantum.
Combating IBM has proven to be a true test of Quantum's market strength and maneuverability; so far to no avail. Early in Q3 Quantum announced the SDLT roadmap, which seems to confirm that even they have accepted they cannot stand up to LTO with their current technology. This roadmap sets high expectations, and Quantum will be hard pressed to reach their goals. The SDLT roadmap shows plans for unprecedented strides in unproven technologies to reach their lofty goals. What does this mean? Such an aggressive stance has only been taken as an attempt to keep market share based on the promise of future enhancements. LTO is ready now, and promises to built on existing technologies providing a stronger base for future deliverables to be built upon.
| IBM | SDLT | |
|---|---|---|
| Performance | ||
| Performance | ||
| Load Time( to BoT) | 15s | 15-40s |
| File Access Time (from BoT) | 65s | 70s - 142s |
| Unload time (from BoT) | 10s | 12s |
| Unload time (from BoT) | 10s | 12s |
| Reliability | ||
| MTBF at 100% Duty Cycle (Hours) | 250,000 | 250,000 |
| Uncorrectable error rate | 1 in 10 to the 14 | 1 in 10 to the 17 |
| Undetected Error Rate | 1 in 10 to the 27 | |
| Head Life | 60,000 Hours | 30,000 Hours |
| Fibre Channel Native | Yes | N/A |
| Format and Features | ||
| Drive Memory Buffer | 32MB | 32MB |
| Media | Ultrium Cartidge 1/2" MP with factory written magnetic servo tracks, with memory trip | SDLTtape 1/2" AMP with factory written optical servo tracks |
| Native Media Capacities | 100 GB | 110 GB |
| Variable Tape speed | No | No |
| Data Compression Algorithm | LTO ALDC | DLZ |
| Dual Compression Nodes | Yes | No |
| Media Compatibility | ||
| Backwards Write Compatibility | No | No |
| RoadMap | 4 Generations of tape up to 800 GB and 60MB /sec | 3 Generations of 500 GB and 80 MB/Sec |
| RoadMap | 4 Generations of tape up to 800 GB and 60MB /sec | 3 Generations of 500 GB and 80 MB/Sec |
What do I do with my DLT's??? We'll buy them!
To Learn More About LTO - Go To LTO Product Page.
Packed Numbers
Numbers are a very important element of many computer records. They could be phone numbers, stock parts, prices, quantities just as a few examples. Numbers have to be represented in a way that a computer can handle and display them, and sometimes the simplest way is as a text string. Thus a phone number could be 1234449999.
Everybody will be aware of the Y2K problem that was generated by storing just 99 rather than 1999. This was done to save space in computer storage, and hence over the years there have been several methods implemented to help store data in fewer bytes. One of the most common ways which started on mainframes, and in Cobol is several variations of 'Packed Decimal', or COMP-3. Most computer storage is based on an 8 bit byte, that has the range of values from 0 to 255. If a single digit is stored in a byte then only 10 of the possible 256 combinations is used. It is therefore more efficient to store 2 numbers on a single byte, and so make use of 100 combinations (00-99).
The hex representation of the above phone number could therefore be
12 34 44 99 99
and so will store the 10 digits in 5 bytes.
Often though, a number needs to be signed, ie negative or positive and the standard for this is then to add a code at the of the string to represent positive or negative. Being in Hex, the values A - F are available, and C is positive (credit) and D is negative (debit) and F for unsigned. The number above would be
01 23 44 49 99 9F
It should be noted that this COMP-3 representation the length of numbers is always odd, but this can be taken care of in the application. The application processing the record will also add any implied decimal places.
These packed records are very common in mainframe records, but modern PC programs, such as Access can not handle them. It is therefore necessary to have a tool to convert these strings normally to straight text strings - in ASCII or EBCDIC. The eMag tool to do this is the Record Reformatter (RR32), in which record layouts can be defined and numbers converted as required. RR32 can also handle all other types of numbers, and dates.
For more details on packed numbers, please visit the RR32 product page. RR32 is an option in MediaMerge/PC, or can be run as a stand alone program.
This article may be re-published as long as the following resource box is included at the end of the article and as long as you link to the email address and the URL mentioned in the resource box:
Article by eMag Solutions. For more articles on eDiscovery and Data Restoration, subscribe to our e-mail Newsletter by sending a blank email to newsletter@emaglink.com or by going to www.emaglink.com.