Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output process timing
Reexamination Certificate
2001-07-27
2004-07-20
Gaffin, Jeffrey (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output process timing
C710S029000, C710S060000
Reexamination Certificate
active
06766388
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to data transfer in a hard disk drive system, and more specifically to the dynamic adjustment of buffer utilization ratios within the hard disk drive and monitoring thereof.
BACKGROUND OF THE RELATED ART
Conventional hard disk drives generally include two individual data transfer engines configured to cooperatively move data into and out of a hard disk drive storage medium, as shown in FIG.
1
. The first of the two engines, typically referred to as the drive side engine
101
, is generally responsible for transferring data between a memory buffer
102
, which may be a bank of dynamic random access memory (DRAM), and the magnetic media
100
of the hard disk drive. The second of the two engines, typically referred to as the host side engine
103
, is responsible for transferring data between the memory buffer
102
and a host interface
104
. The host interface
104
may be, for example, an advanced technology attachment interface (ATA), a small computer systems interface (SCSI and/or scuzzy), fiber channel arbitrated loop (FC-AL), and/or another known interface configurations. The first and second engines generally operate independently of each other, but often operate to transfer data into and out of the memory buffer
102
simultaneously. Additionally, the first and second engines often operate at different data transfer speeds, as host-type interfaces often operate in the 1 to 2 gigabit per second (Gbps) range, while the interface between a hard disk drive and a memory are traditionally much slower, generally in the range of 20 to 60 megabytes per second (Mb/s).
In an operation to read data from the hard disk drive, for example, when a device requests information residing on the hard disk drive, the drive side engine
101
generally operates to transfer the requested data from the storage medium
100
of the hard disk drive to the memory buffer
102
. After a predetermined period of time has passed, the host engine
103
will generally begin moving data transferred to the memory buffer
102
by the drive side engine
101
to the host interface
104
for distribution to the device requesting the data from the hard disk drive. It is important that the host side wait before initiating data transfer, as the host side is generally capable of transferring data at a substantially faster rate. Therefore, the host is capable of rapidly catching up to the drive side, which results in loop performance delays due to re-arbitration, as the host side engine must then be temporarily disabled in order to allow the drive side transfer more data for the host side to process/transfer. After the drive side initiates data transfer, it will eventually complete the transfer of the requested information from the medium of the hard disk drive to the memory buffer. At some time after drive side engine initiates data transfer, host side engine starts transfer and eventually completes transfer of the requested data from the memory buffer to the host interface. Once the host side engine completes the transfer of data from the memory buffer to the host interface, the data transfer process for that particular read operation is generally complete. However, in a typical hard disk drive configuration, there are generally multiple individual chunks of data transferred in order to complete a single transfer command, and therefore, the host side may regularly catch up to the drive side at the end of each data segment transfer. These end of segment-type catch-up conditions may generally be referred to as desired catch-up conditions, and are expected to continue until the segments are collectively transferred, thus completing the individual transfer command.
A similar operation is conducted for writing data to the hard disk drive, however, the data flow and respective engine handling is essentially reversed. Therefore, when a device is to write data to the hard disk drive, the host side engine generally begins to transfer the portion of data to the memory buffer from the host interface, for example, a segment of data. The memory buffer will begin to fill up with the data to be written, and therefore, at some predetermined time thereafter, which is generally as quickly as possible, the drive side engine begins to transfer data into the drive storage medium for storage thereon. Both engines may simultaneously transfer data to and from the memory buffer until the data is completely transferred to the hard disk drive. This simultaneous transfer operation generally occurs in segments or blocks, in similar fashion to the above noted read operation. However, drive side catch-up conditions are generally much less frequent than host side catch-up conditions, as the performance penalty associated with a drive side catch-up is substantially greater than a host side, and is therefore to be avoided. In this configuration the host side engine generally completes data transfer operations prior to the data side engine.
However, since the drive and host side engines generally operate at different data transfer rates, one engine may “catch-up” to the other engine during a data transfer operation, irrespective of the direction of the data transfer. In this situation, the transfer operations of engine that has caught up must be halted, and the engine must wait until the other engine has transferred additional data, i.e., caught up, before the halted engine can reinitiate and continue its own data transfer operations. If the host side engine catches up to the drive side engine, then the catch-up condition is generally referred to as a host catch-up. Alternatively, if the drive side engine catches up to the host side engine, then the catch up condition is generally referred to as a drive catch-up. Both of these conditions are detrimental to the efficiency and performance of the hard disk drive and the surrounding components/devices, as each time a catch-up event occurs, an efficiency/performance penalty is incurred, as the respective engine is halted while the software intervenes to calculate when the engine may be subsequently restarted.
On hard disk drives in particular, drive catch-up conditions have a substantial performance penalty, as it requires one complete revolution of the hard disk storage medium before access to the storage medium may be reinitiated at the same location at which the previous data read/write was stopped. For example, on a 10,000 revolution per minute disk drive, the timing penalty for waiting for the drive medium to complete a single revolution to return to the point on the drive at which the drive medium was halted would be at least 6 milliseconds. Although host catch-up penalties are typically smaller than drive catch-up penalties and depend primarily upon the specific type of interface used, host catch-up penalties nevertheless also contribute to decreased system performance. In a fiber channel arbitrated loop configuration (FC-AL), for example, the halt/wait time penalty generally amounts to the time required to re-arbitrate for the loop. However, on large loops or public loops, the wait time penalty can be significantly increased and become a substantial factor in decreased system performance. Both types of catch-up conditions generally require software intervention to halt and/or reinitiate the respective transfer engine. As a result thereof, both catch-up conditions require allocation of valuable processor cycles, which reduces the number of processor cycles available for other devices and tasks, such as, for example, command reordering.
In view of the performance degradation resulting from catch-up conditions, it is desirable to have a logical structure and/or controlling-type software for hard disk drives that is configured to avoid catch-up conditions and to optimize the host side engine usage so as to reduce the number of times it must be re-started. Some conventional scuzzy-type (SCSI) devices attempt to accomplish this task via allowing users selective control over when the host side engine initiates data transfer. This selective control i
Chen Alan
Nock James R.
LandOfFree
Method for determining a host data transfer goal in a hard... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for determining a host data transfer goal in a hard..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for determining a host data transfer goal in a hard... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3247428