To understand what remote storage is and how it works, imagine that you have a server with a terabyte of disk space. That sounds like a lot, but if you have a thousand users, then your server has a total capacity of less than one gigabyte per user. That’s still quite a bit of space, but depending on what type of files the users are creating, a gigabyte can be used up quickly. At any rate, let’s assume that you are burning through your disk space at an uncomfortable rate and setting disk quotas is not an option.

One thing that you can do to cope with the problem is to implement remote storage. The idea behind remote storage is that it allows you to use space on backup tapes as disk space. To put it bluntly, it allows you to lie to your server about how much free disk space it has.

Those of us who work solely with PCs have traditionally been conditioned to think of tape drives only as a backup mechanism. However, Windows Server’s remote storage feature allows you to use a tape in the same way that you would use a hard disk. Let’s say for example that your terabyte of disk space was just about filled to the limit. Obviously, Windows does not want you to run out of disk space. To prevent this from happening, Windows goes through your user’s files looking for files that have not been used in a long time. When such files are found, they are moved from the hard disk onto tape.

OK, let’s stop right there. Moving old files from disk to tape probably sounds more like archiving than increasing the machine’s overall storage capacity. There is a difference though. With traditional archiving, the tape is locked away in a vault, usually never to be seen again. With remote storage, the tape stays online. If a user looks at the contents of their home directory, they will continue to see all of their files, regardless of how long it has been since a file has been used. If a user decides to use a file that has been moved to tape, the system simply retrieves the file from tape and moves the file to the hard disk.

1 Introduction

This section is non-normative.

This specification introduces two related mechanisms, similar to HTTP session cookies, for storing structured data on the client side. [COOKIES]

The first is designed for scenarios where the user is carrying out a single transaction, but could be carrying out multiple transactions in different windows at the same time.

Cookies don’t really handle this case well. For example, a user could be buying plane tickets in two different windows, using the same site. If the site used cookies to keep track of which ticket the user was buying, then as the user clicked from page to page in both windows, the ticket currently being purchased would “leak” from one window to the other, potentially causing the user to buy two tickets for the same flight without really noticing.

To address this, this specification introduces the sessionStorage IDL attribute. Sites can add data to the session storage, and it will be accessible to any page from the same site opened in that window.

<label>
 <input type="checkbox" onchange="sessionStorage.insurance = checked">
 I want insurance on this trip.
</label>

if (sessionStorage.insurance) { ... }

<!– sessionStorage.flightDeparture = 'OSL'; sessionStorage.flightArrival = 'NYC'; for (var i in forms[0].elements) sessionStorage["data_" + i.name] = i.value; if (!sessionStorage[documents]) sessionStorage[documents] = {}; sessionStorage[documents][filename] = ; –>The second storage mechanism is designed for storage that spans multiple windows, and lasts beyond the current session. In particular, Web applications may wish to store megabytes of user data, such as entire user-authored documents or a user’s mailbox, on the client side for performance reasons.

Again, cookies do not handle this case well, because they are transmitted with every request.

The localStorage IDL attribute is used to access a page’s local storage area.

<p>
  You have viewed this page
  <span id="count">an untold number of</span>
  time(s).
</p>
<script>
  if (!localStorage.pageLoadCount)
    localStorage.pageLoadCount = 0;
  localStorage.pageLoadCount = parseInt(localStorage.pageLoadCount, 10) + 1;
  document.getElementById('count').textContent = localStorage.pageLoadCount;
</script>

Each site has its own separate storage area.

Storage areas (both session storage and local storage) store strings. To store structured data in a storage area, you must first convert it to a string.

2 Conformance requirements

All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]

Requirements phrased in the imperative as part of algorithms (such as “strip any leading space characters” or “return false and abort these steps”) are to be interpreted with the meaning of the key word (“must”, “should”, “may”, etc) used in introducing the algorithm.

Some conformance requirements are phrased as requirements on attributes, methods or objects. Such requirements are to be interpreted as requirements on user agents.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

The only conformance class defined by this specification is user agents.

User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

2.1 Dependencies

This specification relies on several other underlying specifications.

HTML5

Many fundamental concepts from HTML5 are used by this specification. [HTML5]

WebIDL

The IDL blocks in this specification use the semantics of the WebIDL specification. [WEBIDL]

3 Terminology

The construction “a Foo object”, where Foo is actually an interface, is sometimes used instead of the more accurate “an object implementing the interface Foo“.

The term DOM is used to refer to the API set made available to scripts in Web applications, and does not necessarily imply the existence of an actual Document object or of any other Node objects as defined in the DOM Core specifications. [DOMCORE]

A DOM attribute is said to be getting when its value is being retrieved (e.g. by author script), and is said to be setting when a new value is assigned to it.

The term “JavaScript” is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known. [ECMA262]

4 The API

4.1 The Storage interface

interface Storage {
  readonly attribute unsigned long length;
  getter any key(in unsigned long index);
  getter any getItem(in DOMString key);
  setter creator void setItem(in DOMString key, in any data);
  deleter void removeItem(in DOMString key);
  void clear();
};

Each Storage object provides access to a list of key/value pairs, which are sometimes called items. Keys are strings. Any string (including the empty string) is a valid key. Values can be any data type supported by the structured clone algorithm.

Each Storage object is associated with a list of key/value pairs when it is created, as defined in the sections on the sessionStorage and localStorage attributes. Multiple separate objects implementing the Storage interface can all be associated with the same list of key/value pairs simultaneously.

The object’s indices of the supported indexed properties are the numbers in the range zero to one less than the number of key/value pairs currently present in the list associated with the object. If the list is empty, then there are no supported indexed properties.

The length attribute must return the number of key/value pairs currently present in the list associated with the object.

The key(n) method must return the name of the nth key in the list. The order of keys is user-agent defined, but must be consistent within an object so long as the number of keys doesn’t change. (Thus, adding or removing a key may change the order of the keys, but merely changing the value of an existing key must not.) <!–The order of keys may differ between instances of the Storage interface accessing the same list. [removed for now for clarity, but if people ask, put it back. this is part of the spec.]–>If n is greater than or equal to the number of key/value pairs in the object, then this method must return null.

The names of the supported named properties on a Storage object are the keys of each key/value pair currently present in the list associated with the object.

The getItem(key) method must return a structured clone of the current value associated with the given key. If the given key does not exist in the list associated with the object then this method must return null.

The setItem(key, value) method must first create a structured clone of the given value. If this raises an exception, then the exception must be thrown and the list associated with the object is left unchanged. If constructing the stuctured clone would involve constructing a new ImageData object, then throw a NOT_SUPPORTED_ERR exception instead.

Otherwise, the user agent must then check if a key/value pair with the given key already exists in the list associated with the object.

If it does not, then a new key/value pair must be added to the list, with the given key and with its value set to the newly obtained clone of value.

If the given key does exist in the list, then it must have its value updated to the newly obtained clone of value.

If it couldn’t set the new value, the method must raise an QUOTA_EXCEEDED_ERR exception. (Setting could fail if, e.g., the user has disabled storage for the site, or if the quota has been exceeded.)

The removeItem(key) method must cause the key/value pair with the given key to be removed from the list associated with the object, if it exists. If no item with that key exists, the method must do nothing.

The setItem() and removeItem() methods must be atomic with respect to failure. In the case of failure, the method does nothing. That is, changes to the data storage area must either be successful, or the data storage area must not be changed at all.

The clear() method must atomically cause the list associated with the object to be emptied of all key/value pairs, if there are any. If there are none, then the method must do nothing.

When the setItem(), removeItem(), and clear() methods are invoked, events are fired on other HTMLDocument objects that can access the newly stored or removed data, as defined in the sections on the sessionStorage and localStorage attributes.

This specification does not require that the above methods wait until the data has been physically written to disk. Only consistency in what different scripts accessing the same underlying list of key/value pairs see is required.

4.2 The sessionStorage attribute

[Supplemental, NoInterfaceObject]
interface WindowSessionStorage {
  readonly attribute Storage sessionStorage;
};
Window implements WindowSessionStorage;

The sessionStorage attribute represents the set of storage areas specific to the current top-level browsing context.

Each top-level browsing context has a unique set of session storage areas, one for each origin.

User agents should not expire data from a browsing context’s session storage areas, but may do so when the user requests that such data be deleted, or when the UA detects that it has limited storage space, or for security reasons. User agents should always avoid deleting data while a script that could access that data is running. When a top-level browsing context is destroyed (and therefore permanently inaccessible to the user) the data stored in its session storage areas can be discarded with it, as the API described in this specification provides no way for that data to ever be subsequently retrieved.

The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.

When a new HTMLDocument is created, the user agent must check to see if the document’s top-level browsing context has allocated a session storage area for that document’s origin. If it has not, a new storage area for that document’s origin must be created.

The sessionStorage attribute must return the Storage object associated with that session storage area. Each Document object must have a separate object for its Window‘s sessionStorage attribute.

When a new top-level browsing context is created by cloning an existing browsing context, the new browsing context must start with the same session storage areas as the original, but the two sets must from that point on be considered separate, not affecting each other in any way.

When a new top-level browsing context is created by a script in an existing browsing context, or by the user following a link in an existing browsing context, or in some other way related to a specific HTMLDocument, then the session storage area of the origin of that HTMLDocument must be copied into the new browsing context when it is created. From that point on, however, the two session storage areas must be considered separate, not affecting each other in any way.

When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a session storage area, if the methods did something, then in every HTMLDocument object whose Window object’s sessionStorage attribute’s Storage object is associated with the same storage area, other than x, a storage event must be fired, as described below.

4.3 The localStorage attribute

[Supplemental, NoInterfaceObject]
interface WindowLocalStorage {
  readonly attribute Storage localStorage;
};
Window implements WindowLocalStorage;

The localStorage object provides a Storage object for an origin.

User agents must have a set of local storage areas, one for each origin.

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running.

When the localStorage attribute is accessed, the user agent must check to see if it has allocated a local storage area for the origin of the Document of the Window object on which the method was invoked. If it has not, a new storage area for that origin must be created.

The user agent must then return the Storage object associated with that origin’s local storage area. Each Document object must have a separate object for its Window‘s localStorage attribute.

When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every HTMLDocument object whose Window object’s localStorage attribute’s Storage object is associated with the same storage area, other than x, a storage event must be fired, as described below.

Whenever the properties of a localStorage attribute’s Storage object are to be examined, returned, set, or deleted, whether as part of a direct property access, when checking for the presence of a property, during property enumeration, when determining the number of properties present, or as part of the execution of any of the methods or attributes defined on the Storage interface. the user agent must first obtain the storage mutex.

4.4 The storage event

The storage event is fired when a storage area changes, as described in the previous two sections (for session storage, for local storage).

When this happens, the user agent must queue a task to fire an event with the name storage, with no namespace, which does not bubble and is not cancelable, and which uses the StorageEvent interface, at each Window object whose Document object has a Storage object that is affected.

This includes Document objects that are not fully active, but events fired on those are ignored by the event loop until the Document becomes fully active again.

The task source for this task is the DOM manipulation task source.

If the event is being fired due to an invocation of the setItem() or removeItem() methods, the event must have its key attribute set to the name of the key in question, its oldValue attribute set to a structured clone of the old value of the key in question, or null if the key is newly added, and its newValue attribute set to a structured clone of the new value of the key in question, or null if the key was removed.

Otherwise, if the event is being fired due to an invocation of the clear() method, the event must have its key, oldValue, and newValue attributes set to null.

In addition, the event must have its url attribute set to the address of the document whose Storage object was affected; its source attribute set to the that document’s browsing context’s WindowProxy object, if the two documents are in the same unit of related browsing contexts, or null otherwise; and its storageArea attribute set to the Storage object from the Window object of the target Document that represents the same kind of Storage area as was affected (i.e. session or local).

4.4.1 Event definition

interface StorageEvent : Event {
  readonly attribute DOMString key;
  readonly attribute any oldValue;
  readonly attribute any newValue;
  readonly attribute DOMString url;
  readonly attribute WindowProxy source;
  readonly attribute Storage storageArea;
  void initStorageEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in DOMString keyArg, in any oldValueArg, in any newValueArg, in DOMString urlArg, in WindowProxy sourceArg, in Storage storageAreaArg);
  void initStorageEventNS(in DOMString namespaceURI, in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in DOMString keyArg, in any oldValueArg, in any newValueArg, in DOMString urlArg, in WindowProxy sourceArg, in Storage storageAreaArg);
};

The initStorageEvent() and initStorageEventNS() methods must initialize the event in a manner analogous to the similarly-named methods in the DOM Events interfaces. [DOMEVENTS]

The key attribute represents the key being changed.

The oldValue attribute represents the old value of the key being changed.

The newValue attribute represents the new value of the key being changed.

The url attribute represents the address of the document whose key changed.

The source attribute represents the WindowProxy object of the browsing context of the document whose key changed.

The storageArea attribute represents the Storage object that was affected.

4.5 Threads

Because of the use of the storage mutex, multiple browsing contexts will be able to access the local storage areas simultaneously in such a manner that scripts cannot detect any concurrent script execution.

Thus, the length attribute of a Storage object, and the value of the various properties of that object, cannot change while a script is executing, other than in a way that is predictable by the script itself.

5 Disk space

User agents should limit the total amount of space allowed for storage areas.

User agents should guard against sites storing data under the origins other affiliated sites, e.g. storing up to the limit in a1.example.com, a2.example.com, a3.example.com, etc, circumventing the main example.com storage limit.

User agents may prompt the user when quotas are reached, allowing the user to grant a site more space. This enables sites to store many user-created documents on the user’s computer, for instance.

User agents should allow users to see how much space each domain is using.

<!–If the storage area space limit is reached during a setItem() call, the method will raise an exception.

–>A mostly arbitrary limit of five megabytes per origin is recommended. Implementation feedback is welcome and will be used to update this suggestion in the future.

6 Privacy

6.1 User tracking

A third-party advertiser (or any entity capable of getting content distributed to multiple sites) could use a unique identifier stored in its local storage area to track a user across multiple sessions, building a profile of the user’s interests to allow for highly targeted advertising. In conjunction with a site that is aware of the user’s real identity (for example an e-commerce site that requires authenticated credentials), this could allow oppressive groups to target individuals with greater accuracy than in a world with purely anonymous Web usage.

There are a number of techniques that can be used to mitigate the risk of user tracking:

Blocking third-party storage

User agents may restrict access to the localStorage objects to scripts originating at the domain of the top-level document of the browsing context, for instance denying access to the API for pages from other domains running in iframes.

Expiring stored data

User agents may automatically delete stored data after a period of time.

For example, a user agent could treat third-party local storage areas as session-only storage, deleting the data once the user had closed all the browsing contexts that could access it.

This can restrict the ability of a site to track a user, as the site would then only be able to track the user across multiple sessions when he authenticates with the site itself (e.g. by making a purchase or logging in to a service).

However, this also puts the user’s data at risk.

Treating persistent storage as cookies

User agents should present the persistent storage feature to the user in a way that associates them strongly with HTTP session cookies. [COOKIES]

This might encourage users to view such storage with healthy suspicion.

Site-specific white-listing of access to local storage areas

User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorize access to local storage areas.

Origin-tracking of stored data

User agents may record the origins of sites that contained content from third-party origins that caused data to be stored.

If this information is then used to present the view of data currently in persistent storage, it would allow the user to make informed decisions about which parts of the persistent storage to prune. Combined with a blacklist (“delete this data and prevent this domain from ever storing data again”), the user can restrict the use of persistent storage to sites that he trusts.

Shared blacklists

User agents may allow users to share their persistent storage domain blacklists.

This would allow communities to act together to protect their privacy.

While these suggestions prevent trivial use of this API for user tracking, they do not block it altogether. Within a single domain, a site can continue to track the user during a session, and can then pass all this information to the third party along with any identifying information (names, credit card numbers, addresses) obtained by the site. If a third party cooperates with multiple sites to obtain such information, a profile can still be created.

However, user tracking is to some extent possible even with no cooperation from the user agent whatsoever, for instance by using session identifiers in URLs, a technique already commonly used for innocuous purposes but easily repurposed for user tracking (even retroactively). This information can then be shared with other sites, using using visitors’ IP addresses and other user-specific data (e.g. user-agent headers and configuration settings) to combine separate sessions into coherent user profiles.

6.2 Cookie resurrection

If the user interface for persistent storage presents data in the persistent storage features described in this specification separately from data in HTTP session cookies, then users are likely to delete data in one and not the other. This would allow sites to use the two features as redundant backup for each other, defeating a user’s attempts to protect his privacy.

6.3 Sensitivity of data

User agents should treat persistently stored data as potentially sensitive; it’s quite possible for e-mails, calendar appointments, health records, or other confidential documents to be stored in this mechanism.

To this end, user agents should ensure that when deleting data, it is promptly deleted from the underlying storage.

7 Security

7.1 DNS spoofing attacks

Because of the potential for DNS spoofing attacks, one cannot guarantee that a host claiming to be in a certain domain really is from that domain. To mitigate this, pages can use SSL. Pages using SSL can be sure that only pages using SSL that have certificates identifying them as being from the same domain can access their storage areas.

7.2 Cross-directory attacks

Different authors sharing one host name, for example users hosting content on geocities.com, all share one persistent storage object. There is no feature to restrict the access by pathname. Authors on shared hosts are therefore recommended to avoid using these features, as it would be trivial for other authors to read the data and overwrite it.

Even if a path-restriction feature was made available, the usual DOM scripting security model would make it trivial to bypass this protection and access the data from any path.

7.3 Implementation risks

The two primary risks when implementing these persistent storage features are letting hostile sites read information from other domains, and letting hostile sites write information that is then read from other domains.

Letting third-party sites read data that is not supposed to be read from their domain causes information leakage, For example, a user’s shopping wishlist on one domain could be used by another domain for targeted advertising; or a user’s work-in-progress confidential documents stored by a word-processing site could be examined by the site of a competing company.

Letting third-party sites write data to the persistent storage of other domains can result in information spoofing, which is equally dangerous. For example, a hostile site could add items to a user’s wishlist; or a hostile site could set a user’s session identifier to a known ID that the hostile site can then use to track the user’s actions on the victim site.

Thus, strictly following the origin model described in this specification is important for user security. References

Tools like GoogleDocs and Zoho can be used to store standard Office-type documents. There is a need to store audio, video, and non-office types of files (like PDF files). There are services that specialize in audio, others that specialize in video. There are also many services for storing any type of artifacts in online file storage services.

Examples:

ScanAll.zip Simple example to show all buttons on First expansion module DB15 connectors, Module1 (on 40 pin ribbon connector wires 9-24) and Module2 (40 pin ribbon wires 25-40). EPICenter tools\epic info\ buttons to see buttons. A checkmark indicates the switch is “on” (closed).

BaseTick.zip This example shows how to use a base tick loop to control lamp flashing, execute timed jobs, rotary speed detection and other rotary examples.

DisplayExample.zip defining and using displays.

GearExample.zip shows how to generate an event into FS2002. A switch is used for gear up/down

Stepper_example.zip shows how to make a unipolar stepper motor move using 4 bits of an output module.

EPICINFOexample.zip example of getting data from FS using Peter Dowson’s EPICINFO. This example gets the manifold pressure and sends it to a gauge and to a display.

SimpleRotary.zip example showing how to generate events with a single rotary. For more complex rotary usage see BaseTick example above.

SetNav1.zip example showing two methods of setting values in Flight sim using EPICINFO. See Readme.txt in project directory

Memory Types

In order to enable computers to work faster, there are several types of memory available today. Within a single computer there is no longer just one type of memory. Because the types of memory relate to speed, it is important to understand the differences when comparing the components of a computer.

SIMM (Single In-line Memory Modules)
SIMMs are used to store a single row of DRAM, EDO or BEDO chips where the module is soldered onto a PCB. One SIMM can contain several chips. When you add more memory to a computer, most likely you are adding a SIMM.

The first SIMMs transferred 8 bits of data at a time and contained 30 pins. When CPU’s began to read 32-bit chunks, a wider SIMM was developed and contained 72 pins.

72 pin SIMMS are 3/4″ longer than 30 pin SIMMs and have a notch in the lower middle of the PCB. 72 pin SIMMs install at a slight angle.

A slender circuit board dedicated to storing memory chips. Each chip is capable of holding 8 to 9 chips per board, the ninth chip usually an error checking chip (parity / non parity). The typical bus from the chip to the motherboard is 32-bits wide. When upgrading a Pentium motherboard you will be required to upgrade 2 of the same type of chips at the same time to accommodate the Pentium processor.

Determining SIMM memory specifications:

SPEED: You can determine the size amount of the chip by looking at the part number of each chip on the SIMM board. For 2-, 8- and 9- chip SIMMs, all the chips should have the same part numbers. Look at the number that ends with a dash and a digit such as “-7″. This is the rate speed or nanoseconds of the chip. With “-7″ this would indicate that the memory is 70ns.

SIZE: Look at the four digits to the left of this number; these often carry information about the number of bits in the chip. A 4256 indicates 256K bits arranged in sets of four, for a total of 1Mb. “1000″ indicates 1MB of bits arranged in one set.
With some types of memory, the last one or two digits may be changed to indicate different kinds of memory; there are 1MB chips that end with 4256, 4257, and 4258. In this case, round the last digits to an even 256 or thousand. Three-chip SIMMs will typically have two larger chips that are four times the capacity of the third chip (because 4 plus 4 plus 1 makes 9, which is the number of bits needed per byte including parity).

PARITY / NON PARITY: To determine if the SIMM is Parity / Non Parity, look for x36 / x9 which indicate that the chip is parity (Error checking). x36 is used with 72-pin SIMMs and x9 is for 30-pin SIMMs. If x32 / x8 this would be an indication that the chip in Non Parity (Non Error checking) x32 is used with 72-pin SIMMs and x8 is used with 30-pin SIMMs.

Another method: count the chips. If you see three or nine discrete chips, the SIMM probably includes a parity. If there are two or eight chips, the SIMM probably does not include parity bit. In this case, divide the number of bits by 8 to determine bytes.

SIMM Memory and Pentium computers: When updating the computer’s memory with a Pentium processor, ensure that you purchase two SIMMs rather than one. Such as if planning to upgrade to 32 MB of RAM that you use two 16 MB SIMMs rather than one. This must be done to allow the memory to work properly with the Pentium processor.
DIMM (Dual In-line Memory Modules)
DIMMs allow the ability to have two rows of DRAM, EDO or BEDO chips. They are able to contain twice as much memory on the same size circuit board. DIMMs contain 168 pins and transfer data in 64 bit chunks.

SODIMM (Small Outline DIMM)
SO DIMMs are commonly used in notebooks and are smaller than normal DIMMs. There are two types of SO DIMMs. Either 72 pins and a transfer rate of 32 bits or 144 pins with a transfer rate of 64 bits.

RDRAM – RIMM
Rambus, Inc, in conjunction with Intel has created new technology, Direct RDRAM, to increase the access speed for memory. RIMMs appeared on motherboards sometime during 1999. The in-line memory modules are called RIMMs. They have 184 pins and provide 1.6 GB per second of peak bandwidth in 16 bit chunks. As chip speed gets faster, so does the access to memory and the amount of heat produced. An aluminum sheath, called a heat spreader, covers the module to protect the chips from overheating.

SO RIMM
Similar in appearance to a SODIMM and uses Rambus technology.

Technology

DRAM (Dynamic Random Access Memory)
One of the most common types of computer memory (RAM). It can only hold data for a short period of time and must be refreshed periodically. DRAMs are measured by storage capability and access time.

Storage is rated in megabytes (8 MB, 16 MB, etc).

Access time is rated in nanoseconds (60ns, 70ns, 80ns, etc) and represents the amount of time to save or return information. With a 60ns DRAM, it would require 60 billionths of a second to save or return information. The lower the nanospeed, the faster the memory operates.

DRAM chips require two CPU wait states for each execution.

Can only execute either a read or write operation at one time.

FPM (Fast Page Mode)
At one time, this was the most common and was often just referred to as DRAM. It offered faster access to data located within the same row.

EDO (Extended Data Out)
Newer than DRAM (1995) and requires only one CPU wait state. You can gain a 10 to 15% improvement in performance with EDO memory.

BEDO (Burst Extended Data Out)
A step up from the EDO chips. It requires zero wait states and provides at least another 13 percent increase in performance.

SDRAM (Static RAM)
Introduced in late 1996, retains memory and does not require refreshing. It synchronizes itself with the timing of the CPU. It also takes advantage of interleaving and burst mode functions. SDRAM is faster and more expensive than DRAM. It comes in speeds of 66, 100, 133, 200, and 266MHz.

DDR SDRAM (Double Data Rate Synchronous DRAM)
Allows transactions on both the rising and falling edges of the clock cycle. It has a bus clock speed of 100MHz and will yield an effective data transfer rate of 200MHz.

Direct Rambus
Extraordinarily fast. By using doubled clocked provides a transfer rate up to 1.6GBs yielding a 800MHz speed over a narrow 16 bit bus.

Cache RAM
This is where SRAM is used for storing information required by the CPU. It is in kilobyte sizes of 128KB, 256KB, etc.

Other Memory Types
VRAM (Video RAM)
VRAM is a video version of FPM and is most often used in video accelerator cards. Because it has two ports, It provides the extra benefit over DRAM of being able to execute simultaneous read/write operations at the same time. One channel is used to refresh the screen and the other manages image changes. VRAM tends to be more expensive.

Flash Memory
This is a solid-state, nonvolatile, rewritable memory that functions like RAM and a hard disk combined. If power is lost, all data remains in memory. Because of its high speed, durability, and low voltage requirements, it is ideal for digital cameras, cell phones, printers, handheld computers, pagers and audio recorders.

Shadow RAM
When your computer starts up (boots), minimal instructions for performing the startup procedures and video controls are stored in ROM (Read Only Memory) in what is commonly called BIOS. ROM executes slowly. Shadow RAM allows for the capability of moving selected parts of the BIOS code from ROM to the faster RAM memory.

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!