Patent Application
20090327683
An embodiment of the present invention relates generally to booting of a computing device and, more specifically, to accelerating boot time of a diskless client computing device using non-volatile storage communicatively coupled to the network access device.
Various mechanisms exist for booting an operating system (OS) on a computing device. In devices having no disk, or hard drive storage, the OS files must be stored externally, and retrieved during launch of the OS. This type of diskless device may be called a “thin client.”
Current diskless client personal computer (PC) devices use network booting to enable diskless operation of the thin client. A minimal amount of data is stored locally on the thin client while the majority of the operating system (OS) boot files are stored remotely on a network accessible device (NAS). The thin client stores enough information in the network interface card (NIC) Option ROM (O-ROM) to start the network and begin fetching OS data, after which all local processing on the thin client is performed on remote data files; the thin client has no bulk storage. Due to the large sizes of modern OSes, for instance the Windows Vista® OS requires approximately 4 GB of data files to boot successfully, network boot performance is limited by network performance. On a 54 Mbit WLAN, network booting the Windows Vista® OS would require nearly 10 minutes of data transfer time (not counting the overhead of network processing). Users expect boot times on the order of seconds, not minutes. Therefore, a more efficient method for booting in a diskless environment is desired.
The features and advantages of the present invention will become apparent from the following detailed description of the present invention in which:
An embodiment of the present invention is a system and method relating to adding a substantial amount of non-volatile memory (NVM) accessible to a thin client's network interface card (NIC). In practice the NVM may be on the NIC or held elsewhere in the platform. The NVM is to be large enough to hold a bootable subset of the operating system (OS) on board the thin client, pinning the bootable subset within the NVM. In general, the NVM may be thought of as a cached, read-only copy of the boot files on a network accessible storage (NAS) device. Any excess NVM may be used as a read-only image of other OS files, application files, or libraries, accelerating performance and reducing network traffic. Embodiments of the invention enable the ability to boot the base OS and use a selection of applications when the network is inoperable, allowing the thin client to still be useful for some basic functionality. In addition to the NVM being accessible to the NIC, the NIC may utilize a basic hardware pattern matching device to interpret outbound boot file requests and translate these into hits or misses to the local NVM.
Reference in the specification to “one embodiment” or “an embodiment” of the present invention means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrase “in one embodiment” appearing in various places throughout the specification are not necessarily all referring to the same embodiment.
For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one of ordinary skill in the art that embodiments of the present invention may be practiced without the specific details presented herein. Furthermore, well-known features may be omitted or simplified in order not to obscure the present invention. Various examples may be given throughout this description. These are merely descriptions of specific embodiments of the invention. The scope of the invention is not limited to the examples given.
Processor 101 may be any type of processor capable of executing software, such as a microprocessor, digital signal processor, microcontroller, or the like. Though
Non-volatile memory (NVM) 107, such as Flash memory, may be coupled to the ICH 105 via a low pin count (LPC) bus. In an embodiment, a network interface card (NIC), or other network controller is coupled to the processor 101 via the ICH 105. Although an ICH 105 is shown as illustration, the NIC 109 may be coupled to the processor via an IOH, or a variety of other controller hub types.
In an embodiment, the NIC has access to non-volatile memory (NVM) 107. The NIC 109 has an internal pattern matching unit 111, to be discussed further below. The pattern matching unit 111 may be used to assist the NIC with retrieval and storage of boot files to/from the NVM 107. Boot files are to, at least initially, be retrieved from a network accessible storage (NAS) device 113. The NAS may be coupled to the platform 100 via a wired or wireless local area network (WLAN) 120.
In existing diskless, or thin client systems, a network boot requires boot files, such as the OS loader, to be retrieved from the NAS 113 each time the system is booted. Depending on the bandwidth of the WLAN 120, this boot may take a long time.
Intel® Corp. and Microsoft® Corp. have driven the Preboot eXecution Environment (PXE) as the standard protocol for network boot. PXE is essentially an extension to dynamic host configuration protocol (DHCP) that uses trivial file transfer protocol (TFTP) to transfer boot files to the client from the server. Most NICs support this in their Option ROMs. Files transferred from the NAS 113 to the client platform 100 during the PXE requests may be stored and pinned into the NIC's NVM 107 so that the requests may be serviced directly from storage on the client 100. In an embodiment of the invention, the NIC pattern match unit 111 interprets and redirects the PXE commands to serve the requested boot file back to the client processor. In this context, pinning means that the files stored in cache cannot be removed by accident based on caching protocols. Cached files may be selectively pinned, rather than merely stored, based on a set of prioritization rules executed in the NIC.
As the PXE requests arrive at the NIC, the pattern match unit strips the network protocol and extracts the requested file name, at a well defined location, as defined by the network file transfer protocol (NFS) of common Internet File system or (CIFS), as shown in block 203 or by the already mentioned TFTP protocol.
It is determined whether the requested file name, file offset and data size matches an entry in the NVM, in block 205. If there is no entry in the NVM matching the request, the original request is forwarded, unmodified, on the network to the NAS, in block 207, to retrieve the file from the NAS. Otherwise, if there is a matching file in the NVM, the requested file data is returned to the processor from the NVM, completing the request, in block 209. The information may even be stored in the NIC accessible NVM as full IP/TFTP packets, obviating the need for any NIC based processing before returning the packets to the booting processor. Processing may continue at block 203 to retrieve subsequent boot files.
Responses returned from the NAS may be recognized by the NIC as critical boot files and stored and pinned into the platform client NVM, at the discretion of the pattern match unit. Files may be pinned as full network packets, ready for immediate return through the NIC at the next request by the processor.
Several alternative embodiments may be implemented, based on the needs of the users. It will be noted that the above example flow does not maintain coherency between the NVM and the NAS. In an embodiment, an additional operation may be inserted after block 205 to help maintain coherency. In an embodiment, when the filename is found in the NVM, as determined in block 205, a file checksum on the NAS is examined and compared with the one in the client NVM, in block 202. If there is a difference in checksums, as determined in block 204, then the NVM is flushed of the out of date boot files, in block 206. The files would then be retrieved from the NAS in block 207, as before, as if they did not exist in the NVM.
Alternately, in another embodiment, a method of pushing updated OS files to the client NVM may be implemented, possibly using multicast to update many clients simultaneously. Similarly, a client application may run shortly after boot time checking the state of the files in the client NVM against those on the NAS and updating any that have changed and rebooting the system.
Alternatively, software running on the processor may compare the NIC accessible NVM stored boot files with those on the NAS after boot. If the NIC accessible NVM resident data is found to be out of date, the software can retrieve the newer files from the NAS and store them in the NIC accessible NVM, making them ready for the next boot of the system.
It should be understood that the NVM may be physically located on the NIC, or elsewhere on the platform, as long as the NVM is accessible to the NIC. In the case where the NVM is physically located on the NIC, system maintenance operations may be performed from a remote management PC without powering up the thin client. Much in the way that Wake-on-LAN operates, the system updates could be pushed into the NIC-resident NVM while the rest of the thin client PC sleeps or is powered off.
A NIC accessible NVM may similarly be used to store executable or library files in a read-only fashion. Here the operation would be very much like the already described accelerated network boot. The NIC pattern matcher unit would again look for accesses to NAS based files which it caches, and return those through the NIC to the CPU as already constructed network packets.
A NIC accessible NVM may also be used as a local network write cache for buffering outbound writes. Since these writes are committed to non-volatile memory they may be considered completed by the client, allowing a client worried about power fail consistency to continue computing, rather than waiting for the NAS to return an acknowledgement (ACK). When the NAS does return an ACK for the packet, the NVM stored copy would be deleted. At power-up the client will need to check the outgoing cache to ensure it is free of packets, or to complete the writes on the packets still stored there. This approach has the advantages of offering better performance for applications writing critical data to the NAS and allowing the client to power down even before its writes over the network have completed, to save power.
In an alternative embodiment, the pattern match unit may be configured to recognize specific requests, such as CIFS requests used as a part of computer startup after the diskless client boot loads and starts the kernel, rather than only boot specific network protocols. A CIFS header may be stored in the NIC for use in pattern matching request. Specific filenames may also be stored in the NIC to further customize which files are to be cached. This embodiment is similar to the other previously described, but differs in when the pattern match unit will actually intervene. In this case, if the protocol is identified as being a CIFS retrieval command in block 301, then it is determined whether the file to be retrieved in this command has been identified as one to be cached, in block 304. If it is, then execution flows as before to block 303 to determine whether a cached version of the file exists in NVM. It will be understood by one of skill in the art that the pattern match unit may be configured to recognize boot server names, boot file request protocols, or an other level of information that may be used to recognize that the NIC is to retrieve data from the NAS. Access lists and predetermined rules governing when files should be retrieved from the NAS by default, or whether an attempt should be made to retrieve the file from cache may be stored on the NIC accessible NVM.
In some cases, the protocol, such as PXE or TFTP, may indicate that the entire boot file should be cached or retrieved from cache, just by virtue of the TFTP request. In other cases, the request itself is parsed and a specific file name is matched in the pattern match unit based on a fetch request. The network protocols may be stripped from the file, or stored with the file in cache, based on the configuration of the pattern match unit. Headers may be reconstructed by the NIC so that when files are retrieved from the NVM, the appear to have come directly from the NAS, via the NIC.
In the case where the platform has not yet been booted, all boot files must be retrieved from the NAS. Support software in the BIOS or the Operating system, for instance, may be utilized to cache the first instance of the boot files into the NVM. In another embodiment, the first boot will operate as a legacy network boot so that caching will not slow the first boot. Support software may execute during runtime and based on the known location for future boots, will retrieve and cache the network filed, as necessary, so that they will be available in NVM during subsequent boots.
Embodiments of the invention may use a hybrid of the two alternatives illustrated in
Referring again to
In another embodiment, the NIC may recognize when a CIFS request is being made and automatically store the packets regardless of the filename of the requested packet. The NIC will store the request protocol so that when an identical request is made in a subsequent boot, the proper packet it retrieved from the NVM cache.
The techniques described herein are not limited to any particular hardware or software configuration; they may find applicability in any computing, consumer electronics, or processing environment. The techniques may be implemented in hardware, software, or a combination of the two.
For simulations, program code may represent hardware using a hardware description language or another functional description language which essentially provides a model of how designed hardware is expected to perform. Program code may be assembly or machine language, or data that may be compiled and/or interpreted. Furthermore, it is common in the art to speak of software, in one form or another as taking an action or causing a result. Such expressions are merely a shorthand way of stating execution of program code by a processing system which causes a processor to perform an action or produce a result.
Each program may be implemented in a high level procedural or object-oriented programming language to communicate with a processing system. However, programs may be implemented in assembly or machine language, if desired. In any case, the language may be compiled or interpreted.
Program instructions may be used to cause a general-purpose or special-purpose processing system that is programmed with the instructions to perform the operations described herein. Alternatively, the operations may be performed by specific hardware components that contain hardwired logic for performing the operations, or by any combination of programmed computer components and custom hardware components. The methods described herein may be provided as a computer program product that may include a machine accessible medium having stored thereon instructions that may be used to program a processing system or other electronic device to perform the methods.
Program code, or instructions, may be stored in, for example, volatile and/or non-volatile memory, such as storage devices and/or an associated machine readable or machine accessible medium including solid-state memory, hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, digital versatile discs (DVDs), etc., as well as more exotic mediums such as machine-accessible biological state preserving storage. A machine readable medium may include any mechanism for storing, transmitting, or receiving information in a form readable by a machine, and the medium may include a tangible medium through which electrical, optical, acoustical or other form of propagated signals or carrier wave encoding the program code may pass, such as antennas, optical fibers, communications interfaces, etc. Program code may be transmitted in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format.
Program code may be implemented in programs executing on programmable machines such as mobile or stationary computers, personal digital assistants, set top boxes, cellular telephones and pagers, consumer electronics devices (including DVD players, personal video recorders, personal video players, satellite receivers, stereo receivers, cable TV receivers), and other electronic devices, each including a processor, volatile and/or non-volatile memory readable by the processor, at least one input device and/or one or more output devices. Program code may be applied to the data entered using the input device to perform the described embodiments and to generate output information. The output information may be applied to one or more output devices. One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multiprocessor or multiple-core processor systems, minicomputers, mainframe computers, as well as pervasive or miniature computers or processors that may be embedded into virtually any device. Embodiments of the disclosed subject matter can also be practiced in distributed computing environments where tasks or portions thereof may be performed by remote processing devices that are linked through a communications network.
Although operations may be described as a sequential process, some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally and/or remotely for access by single or multi-processor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter. Program code may be used by or in conjunction with embedded controllers.
While this invention has been described with reference to illustrative embodiments, this description is not intended to be construed in a limiting sense. Various modifications of the illustrative embodiments, as well as other embodiments of the invention, which are apparent to persons skilled in the art to which the invention pertains are deemed to lie within the spirit and scope of the invention.
