Efficient data relocation in an asymmetric multilevel caching structure for efficient data storage and retrieval

Abstract

[0009] Provided herein are systems and methods for efficient data relocation within a multilevel memory cache. In particular, the method may include (i) storing particular data structures, or tiles, in a first memory cache containing open order data representing open orders for either buying or selling financial instruments at successive price levels that fall within a defined price range between a most aggressive price and a least aggressive price, (ii) storing multiple tiles in a second memory cache containing open order data representing open orders for either buying or selling financial instruments at prices that are outside the defined price range, and relocating the tiles between the first and second memory caches in response to changes in the open order data for either buying or selling financial instruments at the most aggressive price.

Description

[Technical Field]

[0001] Related Applications This application claims the benefit of U.S. Provisional Application Nos. 63 / 430,777 and 63 / 430,778, filed December 7, 2022, the disclosures of which are incorporated herein by reference in their entireties.

[0002] The systems and methods described herein relate to caches for data storage and retrieval, and more particularly to asymmetric multi-level caching structures for use in electronic trading systems, electronic data feed systems, or other automated systems involving priority-based data storage and retrieval.

[0003] The systems and methods described herein also relate to efficient data relocation and key selection in a multi-level hash-indexed cache. [Background technology]

[0004] In an electronic trading system, an order book receives orders from market participants to buy and sell stocks or other financial instruments and attempts to process them by matching them with counterorders (e.g., buy to sell, sell to buy). Unmatched orders are stored in an open order data store until they are matched or otherwise canceled. Electronic trading systems may also include an electronic data feed service that provides subscribers with trading data related to open orders and matches. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] U.S. Patent Application Publication No. 2017 / 039651 Summary of the Invention [Problem to be solved by the invention]

[0006] There is a need for improved systems and methods for efficient data storage and retrieval from data feed services or order books for electronic trading.

[0007] The foregoing will be apparent from the following more detailed description of exemplary embodiments of the invention, as illustrated in the accompanying drawings. Like reference figures refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present disclosure. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic diagram illustrating an automated trading system according to an embodiment. [Figure 2] 2 is a schematic diagram illustrating detailed components of the matching engine book of FIG. 1 according to an embodiment. [Figure 3] FIG. 2 is a schematic diagram illustrating a tile data structure according to one embodiment. [Figure 4] 1 is a schematic diagram illustrating an embodiment of an asymmetric multi-level cache provisioned for storing and retrieving tiles according to a price priority scheme. [Figure 5] FIG. 2 is a schematic diagram illustrating an exemplary provisioning of a first memory cache in a multi-level memory cache for a single stock. [Figure 6] 1 is a flow diagram illustrating a method for fetching tiles from an external multi-level cache, according to an embodiment. [Figure 7] 10A and 10B are schematic diagrams illustrating an example of using a target price tick as an index to determine a tile location within an active order area of ​​a first memory cache. [Figure 8] 10 is a flow diagram illustrating a method for generating hash keys that index into inactive price regions of a second memory cache in the form of a sparse hash array, according to an embodiment. [Figure 9]1 is a flow diagram illustrating a method for processing tiles of different types, according to an embodiment. [Figure 10] 10A to 10D are schematic diagrams showing examples of obtaining different types of tiles using the method of FIG. [Figure 11] 1 is a flow diagram illustrating a method for gradually adjusting a sequence of price consecutive tiles in an active order area of ​​a first memory cache to include more aggressive price tiles, according to an embodiment. [Figure 12] 10A and 10B are schematic diagrams illustrating an example of gradually adjusting a sequence of price consecutive tiles within an active buy order area of ​​a first memory cache to include more aggressive price tiles with higher bid prices. [Figure 13] 1 is a flow diagram illustrating a method for gradually adjusting a sequence of price consecutive tiles in an active order area of ​​a first memory cache to include less aggressive price tiles, according to an embodiment. [Figure 14] 10A and 10B are schematic diagrams illustrating an example of gradually adjusting a sequence of price consecutive tiles within an active buy order area of ​​a first memory cache to include less aggressive price tiles with lower bid prices. [Figure 15A] 15 is a flow diagram illustrating a method 1500 for converting target prices into ticks having successive intensifier sequences regardless of changes in the minimum price change between successive prices, according to an embodiment. [Figure 15B] 15 is a flow diagram illustrating a method 1500 for converting target prices into ticks having successive intensifier sequences regardless of changes in the minimum price change between successive prices, according to an embodiment. [Figure 16] 16 is a flow diagram illustrating a method 1600 for proactively prefetching tiles, according to an embodiment. [Figure 17] FIG. 2 is a schematic diagram illustrating a processing unit for optimizing the use of cache space in a multi-level memory cache, according to an embodiment. [Figure 18]FIG. 1 is a schematic diagram illustrating an embodiment of an automated trading system that includes a ticker plant that maintains separate order books in the form of an asymmetric multi-level memory cache. [Figure 19] FIG. 1 is a schematic diagram illustrating another embodiment of an automated trading system including a ticker plant that maintains separate order books in an asymmetric multi-level memory cache. DETAILED DESCRIPTION OF THE INVENTION

[0009] Electronic trading systems, and in particular order matching engines that execute orders to buy and sell stocks and other financial instruments, are highly latency-sensitive environments. Disclosed herein is an electronic trading system that can be implemented using field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other fixed logic to increase order execution speed. FPGAs, ASICs, and other fixed logic generally perform operations faster than central processing unit (CPU)-based platforms. However, electronic trading systems must handle large data sets, sometimes referred to as "order books," for example. Order book data sets often include, among other things, varying numbers of buy and sell orders for each price point of each financial instrument. Therefore, order book data sets generally cannot fit into the internal memory caches of FPGAs, ASICs, and other fixed logic.

[0010] An external memory cache, such as dynamic random access memory (DRAM), may be used to better accommodate large data sets for order books. However, memory access in FPGA designs can be expensive in terms of latency, especially if the large data set imposes the use of external DRAM. DRAM is relatively slow for initial accesses and only becomes efficient for sequential accesses. In FPGAs, read / write memory access operations to an internal memory cache, such as block random access memory (BRAM), are generally faster than read / write memory access operations to external DRAM.

[0011] To address the aforementioned challenges, embodiments of the electronic trading system disclosed herein are configured to minimize the number of external memory accesses, thereby minimizing memory access latency. For example, order data for all open orders of a particular symbol, side, and price ("SSP") may be organized into defined data structures (referred to herein as "tiles") that can be fetched from an external memory cache. Once loaded into an internal memory cache of an FPGA or other fixed logic, the tiles may be accessed frequently with minimal latency to obtain order data for multiple open orders with the same symbol, side, and price. Thus, rather than accessing the external memory cache multiple times to obtain data separately for each individual order, a single access to the external memory cache can be used to obtain a tile containing order data for all open orders with the same symbol, side, and price.

[0012] Additionally, to minimize the number of external memory accesses, the external memory can be provisioned as an asymmetric multilevel memory cache adapted to handle the large data sets of the matching engine book and ticker plant services. In the following embodiments, the multilevel memory cache is shown as including two external memory units in the form of DRAM for storing tiles according to a price priority scheme. However, those skilled in the art will recognize that embodiments of the multilevel memory cache can be provisioned with a single external DRAM or three or more DRAMs. The term "asymmetric" refers to several characteristics of the external multilevel memory cache, including how tiles can be organized and accessed differently based on price.

[0013] In some embodiments, the first external memory cache allocates space for a given symbol and side and stores a limited number of tiles at consecutive price levels within the actively traded price range. Because separate cache space is allocated for each symbol and each side, tile locations can be easily indexed according to price within the actively traded price range using a symbol registry, preferably in the form of a circular buffer array, that defines the boundaries of a contiguous memory segment.

[0014] Because it is impractical to allocate space for every possible price point for a given symbol and side, the multi-level memory cache may also include a second memory cache. The second memory cache may be used to store tiles that are outside of the actively traded price range for a given symbol and side. The second memory cache does not allocate separate cache space for each symbol and side. Rather, the second memory cache may be at least partially provisioned to include a sparse hash array that facilitates shared tile storage.

[0015] A hash key algorithm is presented herein to minimize the risk of hash key collisions for the same tile location in the sparse hash array of the second memory cache. When a hash key collision occurs between two or more tiles, a special type of tile, referred to herein as a "redirection tile," can be stored at the tile location of the hash key collision. The redirection tile contains address information to identify the tile involved in the hash key collision, and the tile is relocated to a free heap buffer or other unstructured memory area of ​​the second memory cache.

[0016] Redirection tiles may also be used in other special situations. Tiles are generally defined to have a fixed size and can therefore represent orders to buy or sell a given financial instrument up to the maximum order capacity. However, as previously mentioned, order book data sets often include, among other things, a varying number of buy and sell orders for each price point of each financial instrument. If the number of orders for a given symbol, side, and price exceeds the maximum order capacity, a larger-sized tile, referred to herein as an "extended tile," may be created for the open order data and stored in the free heap buffer or other unstructured memory area of ​​the second memory cache. To identify the extended tile in the free heap buffer, a redirection tile including the memory address of the extended tile may be stored in a tile location in the first memory cache or the second memory cache for the specific symbol, side, and price of the extended tile.

[0017] As discussed above, the first external memory cache allocates space for storing a limited number of tiles at consecutive price levels within the actively traded price range for a given symbol and side, while tiles outside the actively traded price range can be stored in a shared sparse hash array in the second memory cache. However, during the trading day, price behavior may change, such that the actively traded price range for open orders may trend toward more aggressive or less aggressive prices depending on the side. Higher prices are generally more aggressive prices for buy-side orders, while lower prices are generally more aggressive prices for sell-side orders. Embodiments include the ability to gradually reallocate tiles from the first memory cache to the second memory cache, and vice versa, in response to changes in price behavior.

[0018] An advantage of using the external multi-level memory cache embodiments described herein is that in most cases, a tile can be obtained from either the first or second memory cache with a single external memory access. In special cases, a tile can be obtained with up to two external memory accesses (i.e., a first external memory access to fetch the redirection tile from either the first or second memory cache, and a second external memory access to fetch the immediate tile from a free heap buffer or other unstructured memory location referenced by the redirection tile).

[0019] Various embodiments of a method for rearranging tiles in a multilevel memory cache are provided herein. In some embodiments, the method may include (i) storing a number of tiles in a first memory cache including open order data representing open orders for one of buying or selling financial instruments at successive price levels that fall within a defined price range between a most aggressive price and a least aggressive price, (ii) storing a number of tiles in a second memory cache including open order data representing open orders for one of buying or selling financial instruments at a price that is outside the defined price range, and rearranging tiles between the first memory cache and the second memory cache in response to changes in the open order data for one of buying or selling financial instruments at the most aggressive price.

[0020] In some embodiments, when price action in an active order area for a particular financial instrument is trending more aggressively, the method may include (i) creating a new tile including open order data representing at least one open order for buying or selling the financial instrument at a new most aggressive price, (ii) determining whether a tile associated with a least aggressive price within a defined price range includes any open order data, (iii) in response to determining that the tile associated with the least aggressive price includes open order data, copying the tile associated with the least aggressive price from a first location in the first memory cache to a second location in the second memory cache, and (iv) overwriting the first location in the first memory cache with the new tile associated with the new most aggressive price. Conversely, in response to determining that the tile associated with the least aggressive price does not include open order data, the method may include overwriting the tile associated with the least aggressive price in the first location in the first memory cache with the new tile associated with the new most aggressive price.

[0021] In some embodiments, when price action in an active order region for a particular financial instrument is trending more aggressively, the method may include (i) determining whether the open order tiles stored in the second memory cache include a tile including open order data for one of buying or selling the financial instrument at a less aggressive price adjacent to the least aggressive price in the defined price range, and (ii) overwriting a tile associated with the most aggressive price in a first location in the first memory cache with a tile associated with the less aggressive price in a second location in the second memory cache. Conversely, in response to determining that the second plurality of tiles stored in the second memory cache does not include any tile associated with a less aggressive price, the method may further include (i) creating a new tile associated with a new least aggressive price for the defined price range, and (ii) overwriting a tile associated with the most aggressive price in a first location in the first memory cache with a new tile associated with the new least aggressive price.

[0022] Further embodiments may include an electronic data access system for rearranging tiles in a multilevel memory cache, including a cache manager that performs the methods of the embodiments summarized above. The cache manager may be implemented using fixed logic, including but not limited to, a field programmable gate array (FPGA) and an application specific integrated circuit (ASIC).

[0023] Certain exemplary embodiments will now be described to provide a general understanding of the principles of structure, function, and use of the systems, methods, and devices disclosed herein. One or more examples of these embodiments are illustrated in the accompanying drawings. Those skilled in the art will understand that the systems, methods, and devices specifically described herein and shown in the accompanying drawings are non-limiting exemplary embodiments, and that the scope of the present disclosure is defined only by the claims. Features illustrated or described in connection with one exemplary embodiment may be combined with features of other embodiments. Such modifications and variations are intended to be included within the scope of the present disclosure. In this disclosure, like-named components of embodiments generally have similar characteristics and / or purposes, unless otherwise stated.

[0024] 1 is a schematic diagram illustrating an automated trading system 100 according to an embodiment. As shown, the system may include a gateway 110, a sequencer 130, a ticker plant 140, a matching engine book (MEB) 150, an asymmetric external multilevel cache 160, and an open order database 170. While a single instance of each component is shown, multiple instances of the aforementioned components may be provided for load balancing purposes, among other reasons.

[0025] The electronic trading system 100 may process orders from and provide related information to one or more participant computing devices 120. The participant devices 120 that interact with the electronic trading system 100 through the gateway 110 include, but are not limited to, personal computers, tablets, smartphones, servers, or other data processing devices configured to display and receive trade order information. The participant devices 120 may be operated by humans via a graphical user interface (GUI), or they may be operated via high-speed automated trading methods running on some physical or virtual data processing platform.

[0026] The gateway 110 establishes a connection through which the participant devices 120 can exchange messages (i.e., send and receive messages) with the electronic trading system 100. In some embodiments, the gateway 110 may convert messages according to a financial transaction protocol received from the participant devices 120 into a normalized message format used to exchange messages between components within the electronic trading system 100. Similarly, in the other direction, the gateway 110 may convert outgoing messages generated in a normalized message format by the electronic trading system 100 into messages in the format of one or more financial transaction protocols used by the participant devices to communicate with the gateway 110.

[0027] Sequencer 130 ensures that the proper sequence of any order-dependent actions is maintained. To ensure that actions on incoming messages are not performed improperly, incoming messages received at gateway 110, for example, a new open order message from one of participant devices 120, may pass through sequencer 130 where they are marked with a sequence identifier.

[0028] The sequence identifier may be a unique, monotonically increasing value that is used in the course of subsequent processing throughout electronic trading system 100 to determine the relative order between messages and to uniquely identify messages throughout electronic trading system 100. However, it should be understood that, while unique, the identifier is not limited to being a monotonically increasing or decreasing value. Once sequenced, the marked incoming messages, that is, messages marked with a sequence, are typically then forwarded by sequencer 130 to other downstream components (e.g., matching engine book 150) to perform potentially order-dependent processing on the messages.

[0029] Ticker plant 140, sometimes called a market data feed, is a streaming data service that delivers individual or broadcast messages to participant devices 120 or other data feed subscribers that convey the price of each traded commodity and related information such as trading volume and other statistics.

[0030] The matching engine book 150 forms the core processing unit of the electronic trading system where buyers and sellers interact. The matching engine book 150 receives messages representing different trade requests from participant devices. Trade requests may include requests to initiate orders to buy or sell financial instruments, requests to cancel orders, requests to replace orders, or requests to modify orders. The matching engine book 150 attempts to execute each trade request.

[0031] For some trade requests, matching engine book 150 may access external memory to fetch data representing one or more open orders corresponding to a particular symbol, side, and price (“SSP”). Specifically, the symbol represents a financial instrument, the side represents the type of order (i.e., either buy or sell), and the price represents the amount in currency to be bought or sold. The external memory may include an open order database 170 and an asymmetric multi-level cache. Matching engine book 150 may include a cache manager 152 and a symbol registry 154 to store, retrieve, and manage tiles in external multi-level cache 160.

[0032] Open orders database 170 is an external memory that stores data structures or containers referred to herein as "cells." Each cell contains open order data representing a single open order to buy or sell a financial instrument. In some embodiments, a cell may include the following fields:

[0033] [Table 1]

[0034] Open order database 170 may be implemented as an array in DRAM. Cells may be indexed within the array of open order database 170 according to the sequence in which their respective open order messages are received. For example, in a preferred embodiment, cells may be indexed within the array in the order of global sequence numbers assigned by sequencer 130.

[0035] Multilevel memory cache 160 is an external memory that stores data structures or containers referred to herein as "tiles." While each cell contains open order data representing a single open order for a given symbol, side, and price, a tile contains open order data representing all open orders for a given symbol, side, and price. In some embodiments, a tile may provide an index location (e.g., a global sequence number) and priority for each order cell in open order database 170. Higher priority orders may be matched before lower priority orders. In some embodiments, the open order data contained within a tile may include a list of cell access nodes, each of which includes address information for identifying a corresponding cell in open order database 170. A tile may also include one or more lists of cell access nodes that prioritize orders for order execution purposes. An exemplary format of a tile according to a preferred embodiment is described below in connection with FIG. 3.

[0036] Gateway 110, sequencer 130, ticker plant 140, and matching engine book 150 may be implemented at least in part by hardwired logic, including, but not limited to, field programmable gate arrays (FPGAs) and application specific integrated circuits (ASICs). External multilevel memory cache 160 and external open order database 170 may be implemented with DRAM, including, but not limited to, synchronous DRAM (SDRAM). Those skilled in the art will recognize that other forms of external memory can be used to implement external multilevel memory cache 160 and external open order database 170.

[0037] 2 is a schematic diagram illustrating detailed components of matching engine book 150 of FIG. 1, according to an embodiment. As shown, matching engine book 150 server may include interconnection interface 180, book processing logic 190, open order database 170, cache manager 152, and symbol registry 154.

[0038] Interconnection interface 180 receives incoming messages in the form of cells from sequencer 130 and other components of electronic trading system 100 ("incoming cells") and transmits the incoming cells to book processing logic 190 for further processing. Interconnection interface 180 may also receive outgoing messages in the form of cells ("outgoing cells") from book processing logic 190, such as order acknowledgments, rejected orders, and processed orders. Interconnection interface 180 may then transmit the outgoing cells from book processing logic 190 to other components of electronic trading system 100.

[0039] Book processing logic 190 may perform various operations, including, but not limited to, matching orders, canceling orders, modifying orders, exchanging orders, and pausing unmatched orders. To perform such operations, book processing logic 190 may interface with open order database 170 to read, write, and delete open order data for individual cells representing remaining open orders. In some embodiments, book processing logic 190 interfaces with open order database 170 through controller 172, which is coupled to external memory cache 174 ("L3 RAM"). External memory cache L3 may be implemented using DRAM.

[0040] To coordinate access to individual order cells present in open orders database 170, book processing logic 190 interfaces with external multilevel memory cache 160 through cache manager 152. In particular, cache manager 152 may provide an interface through which book processing logic 190 may read or write open order data for individual orders from tiles without any knowledge of the tile structure and external multilevel memory cache 160.

[0041] In one example, cache manager 152 may provide an interface through which book processing logic 190 can input a side, symbol, and price (SSP) to request open order data for an order that can be used to match a counterorder upon execution. In response to receiving a data request for an open order, cache manager 152 may fetch a tile from external multilevel memory cache 160 and load the tile into internal memory cache 156 (the “block RAM L0 cache”). After verifying that the loaded tile matches the requested side, symbol, and price, cache manager 152 may return open order data for one of the open orders that has next priority for execution to book processing logic 190 via an outgoing interface. Cache manager 152 may access a symbol registry 154 maintained in internal memory cache 156 as a fast lookup to identify a tile in external multilevel memory cache 160 as a function of symbol, side, and price (“SSP”).

[0042] In the illustrated embodiment, external multi-level memory cache 160 includes a first memory cache 160a ("L1 RAM") and a second memory cache 160b ("L2 RAM") for tile storage. Each cache may be implemented using external memory in the form of DRAM. External memory caches 160a and 160b are larger in size than internal memory cache 156 of cache manager 152. However, external memory access operations are slower compared to internal memory access operations. Therefore, the number of external memory access operations is minimized in several ways.

[0043] According to one embodiment, the number of external memory accesses may be minimized by organizing open order data for all open orders of a particular symbol, side, and price ("SSP") into a single tile that can be fetched from an external memory cache in a maximum of two external memory accesses. The tile preferably contains all open order data needed by book processing logic 190 to perform order matching processing, including data for all orders of a given side, symbol, and price, as well as metadata statistics, order indexing, and prioritization information for those orders. Once loaded into the internal memory cache of the FPGA or other fixed logic, the tile may be accessed frequently with minimal delay to obtain order data for multiple open orders with the same symbol, side, and price. Having all such relevant data for the orders in the tile already loaded into internal memory cache 156 enables extremely fast processing of order matching by book processing logic 190.

[0044] 3 is a schematic diagram illustrating the data structure of a tile 300, according to one embodiment. A tile may include a header portion 310 and a body portion 320. The header portion 310 may include various fields that identify the type of tile and the symbol, side, and price ("SSP") tuple. In the illustrated embodiment, the header portion includes the following fields:

[0045] [Table 2]

[0046] The body portion 320 of the tile depends on the type of tile identified in the header portion 310. In the illustrated embodiment, the tile is identified as an "immediate tile" (i.e., Type=MODE_IMMED). Thus, the body portion 320 contains open order data representing all open orders for a given symbol, side, and price.

[0047] In the illustrated embodiment, the open order data includes multiple data structures, sometimes referred to herein as "cell access nodes." A cell access node 325 represents the priority of an order relative to single-order cells 330 in the open order database 170 and other open orders represented by other cell access nodes 325 in the tile 300. As shown in the table above, the tile capacity may be an integer representing the size of the tile, and therefore the maximum number of open orders that can be represented in it if the tile were an immediate tile. For example, the tile capacity may be represented by a 2-bit enumeration (ENUM) that can represent the size of a given tile in kilobytes (e.g., SINGLE, DOUBLE, QUAD, or JUMBO).

[0048] As shown, the body portion 320 of the immediate tile may include a free list of cell access nodes 327 that are available for assignment to open order cells. The cell access nodes 325 assigned to open order cells 330 of the open order database 170 may include address information for identifying the cells of the open order database 170. For example, a global sequence identifier (i.e., GSEQ) assigned by the sequencer 130 of FIG. 1 may be used as an index to identify the cells of the open order database 170.

[0049] The immediate tile body portion 320 may also include one or more priority lists 329a, 329b, 329c (e.g., P0List, P1List, and P2List). A cell access node 325 representing a corresponding ordered cell may be added to one of the priority lists. Cell access nodes in higher priority lists preferably have their respective orders executed before the open orders of cell access nodes in lower priority lists. Within each priority list, cell access nodes at or near the top of the list have their respective orders executed before cell access nodes at or near the bottom of the list. In the illustrated embodiment, the priority lists are implemented as linked lists. Thus, a cell access node may include a pointer to internally link the cell access node to one of the priority lists. For example, as shown, a cell access node may include one pointer (e.g., a next pointer) to the next cell access node in the list and another pointer to the previous cell access node in the list. Thus, as shown, the instant tile may include a cell access node that contains all the information necessary to index and prioritize all open orders for a particular symbol, side, and price in the open order database 170.

[0050] However, special tiles, sometimes referred to herein as "redirection tiles," may be used in the multilevel memory cache 160 as placeholders containing address information for identifying immediate tiles elsewhere in the external multilevel memory cache 160. As discussed in more detail below in connection with FIG. 9, redirection tiles may be identified by different type field values ​​(e.g., type=MODE_COLLISION or type=MODE_EXTEND). The structure of a redirection tile differs from the structure of an immediate tile. Specifically, a redirection tile may not contain any open order data. Rather, a redirection tile may contain a specific memory address or other address information for identifying at least one immediate tile in the multilevel memory cache 160 for the same symbol, side, and price. Such address information may be provided in either the header portion of the redirection tile or the body portion of the redirection tile.

[0051] To further minimize the number of external memory accesses, the external memory can be provisioned as an asymmetric multi-level memory cache adapted to handle large data sets for the matching engine book and ticker plant services. In particular, the multi-level memory cache can include two or more external memory caches to store tiles according to a price priority scheme.

[0052] 4 is a schematic diagram illustrating an embodiment of an asymmetric multilevel cache 160 provisioned for storing and retrieving tiles according to a price-first scheme. As shown, the multilevel memory cache 160 includes a first memory cache 410 and a second memory cache 450.

[0053] The first memory cache 410 allocates contiguous memory segments 412a, 412b (collectively contiguous memory segments 412) for each given symbol and side to store a limited number of fixed-size tiles at consecutive price levels within an actively traded price range. Each of the contiguous memory segments 412, sometimes referred to herein as an "active order area," may be implemented as a memory array of contiguous price tiles, preferably a circular buffer array. Because each active order area may be a defined memory array of fixed-size tiles, the cache manager 152 can index by price to a particular tile that comprises the active order area.

[0054] As shown, the first memory cache 410 includes a pair of active order areas for each given symbol, where one of the active order areas includes a buy tile 412a and the other includes an sell tile 412b. Although the buy and sell active order areas for a given symbol (e.g., 412a, 412b) are shown adjacent to each other, the active order areas can be organized in any order, provided that the active order areas do not overlap.

[0055] The actively traded price range of the active order area 412 is generally a price range that is close to the best bid price of the buy side active order area or clustered around the best ask price of the sell side active order area. In some embodiments, the actively traded price range can be defined such that the midpoint between the minimum and maximum price levels is the best bid price of the buy side active order area 412a or the best ask price of the sell side active order area 412b.

[0056] The size of each tile within an active order area for a particular symbol is preferably fixed, and the order capacity of each tile is constant within the same active order area. While the tile size is fixed within an active order area, the tile size may vary for each active order area based in part on historical order volume. In some embodiments, the number of tiles allocated to the active order area for a given stock and / or the maximum open orders per price point for that stock may be based on the stock's historical price movement, intraday movement, and order volume.

[0057] Allocating tiles for every possible price point for a given symbol and side would be an inefficient use of space in the first memory cache. Therefore, multilevel memory cache 160 also includes second memory cache 450. Second memory cache 450 allocates space 452, sometimes referred to herein as the “inactive order region,” which stores tiles that are outside of the active order region 412 of first memory cache 410.

[0058] The inactive order area 452 of the second memory cache 450 does not allocate separate cache space for each symbol and side. Rather, the inactive order area is provisioned for shared tile storage. In the illustrated embodiment, the inactive order area 452 is implemented as a sparse hash array.

[0059] To identify a tile in the sparse hash array 452, the cache manager 152 may generate a hash key based on at least the symbol and price of the target tile. A method for generating a hash key to identify a tile in the sparse hash array 452 of the second memory cache 450 is disclosed herein in connection with FIG.

[0060] Second memory cache 450 may further include unstructured memory areas, such as free heap buffer 454, disclosed in connection with FIGS. 9-10D, for handling special situations.

[0061] 5 is a schematic diagram illustrating an exemplary provisioning of a first memory cache within a multilevel memory cache for a single stock (e.g., MSFT). As shown, active buy-side order area 512a for MSFT stock has a defined price span of three dollars ($3.00) with a minimum price fluctuation of one penny ($0.01). Thus, active buy-order area 512a, which may be implemented in the form of a circular buffer array, stores 300 tiles containing open order data (e.g., sell access nodes) representing buy-side orders for MSFT stock at consecutive prices ranging from $315.41 to $312.41.

[0062] Although the best bid price tile 514 is shown as the highest price tile ($315.41), the active buy order area 512a may include one or more tiles for price levels higher than the current best bid price. In some embodiments, the active buy order area 512a may span between the lowest and highest price tiles, such that the best bid price tile is identified at or near the midpoint of the area. In some other embodiments, the active buy order area 512a may span between the lowest and highest bid price tiles, such that the bid price in the highest bid price tile may be 15% to 25% higher than the highest bid price. Thus, the tile with the highest bid price may be allowed to change without having to constantly adjust the active price range of the active buy order area.

[0063] Similarly, active sell orders area 512b for MSFT stock has a defined price span of three dollars ($3.00) with a minimum price fluctuation of one penny ($0.01). Thus, active sell orders area 512b, which may be implemented in the form of a circular buffer array, stores 300 tiles containing open order data (e.g., sell access nodes) representing sell orders for MSFT stock at consecutive prices ranging from $315.51 to $318.51.

[0064] Although the best ask price tile 516 is shown as the lowest price tile ($315.51), the active sell order area 512b may include one or more tiles for price levels lower than the current best ask price. In some embodiments, the active sell order area may span between the lowest and highest ask price tiles, such that the best ask price tile is identified at or near the midpoint of the area. In some other embodiments, the active sell order area 512b may span between the lowest and highest ask price tiles, such that the ask price in the lowest ask price tile may be 15% to 25% lower than the highest ask price. Thus, the tile with the highest ask price may be allowed to change without having to constantly adjust the active price range of the active sell order area.

[0065] The size of each tile within an active order area is preferably fixed for a given stock and side. However, as noted above, the size of the tile may vary between active order areas of different stock-side tuples. For example, in FIG. 5, the size of each tile within each active order area 512a and 512b accommodates up to a maximum order capacity of 1024 cell access nodes (i.e., a quad-sized tile). The tile sizes of other active order areas may accommodate a greater or lesser maximum number of cell access nodes. For example, a single-sized tile may have a first size in the amount of four kilobytes (4 KB) to provide a maximum order capacity of 256 cell access nodes, a double-sized tile may have a second size in the amount of eight kilobytes (8 KB) to provide a maximum order capacity of 512 cell access nodes, and a quad-sized tile may have a third size in the amount of sixteen kilobytes (16 KB) to provide a maximum order capacity of 1024 cell access nodes.

[0066] 5 also shows buy order tiles 518a and sell order tiles 518b having outlier prices that are outside the price ranges of active buy order area 512a and active sell order area 512b, respectively, for MSFT stock. As discussed in more detail in connection with FIGS. 6 and 8-10D, the tiles with outlier prices may be stored in second memory cache 450 of external multilevel memory cache 160.

[0067] 6 is a flow diagram illustrating a method 600 for fetching tiles from an external multilevel cache 610, according to an embodiment. In some embodiments, the method 600 may be implemented by the cache manager 152 described above in connection with FIGS. 1 and 2.

[0068] At block 610, the cash manager 152 receives a request for open order data representing orders to buy and sell stocks or other financial instruments. The request may be entered by the book processing logic 190 of the matching engine book 150, an embodiment of which is described in connection with Figures 1 and 2. The request may also be entered by a ticker plant or other market data feed server component, an embodiment of which is described in connection with Figures 18 and 19.

[0069] In a preferred embodiment, an open order data request may include a symbol identifying a stock or other financial instrument, a side indicating whether the order is a buy or sell order, and a price ("SSP"). In a preferred embodiment, prices may initially be represented by integers with an implicit decimalization, referred to herein as ticks. For example, $1.00 may initially be represented as 10,000 ticks with an implicit decimalization equal to 4.

[0070] In block 620, the cash manager 152 converts the price into a target price tick within a sequence of consecutive ticks. In U.S. and other financial markets, prices may be defined to have different minimum price movements above and below one or more price precision levels. For example, a price may have a first minimum price movement (MPV) of one cent ($0.01) above a price precision level of one dollar ($1.00) and a second minimum price movement of one-hundredth of a cent ($0.0001) below one dollar. Such differences in MPV may result in discontinuous tick sequences. For example, the tick sequence corresponding to prices $0.9999, $1.00, and $1.01 may be 9999, 10000, and 10100, resulting in a 10-tick gap between $1.00 and $1.01.

[0071] Since tiles are preferably indexed in external multilevel memory cache 160 according to price, prices are preferably normalized to fall within a contiguous tick sequence regardless of the difference in minimum price movement. Details regarding an embodiment for converting target prices to normalized target price ticks within a contiguous tick sequence are described below in conjunction with Figures 14A-14B.

[0072] In condition block 630, the cash manager 152 determines whether the target price falls within the active price range defined for the active order region for the given symbol and side. The active price range may include a continuum of prices between the most aggressive and least aggressive prices, depending on the side. For buy-side orders, the most aggressive price is the highest bid price, and the least aggressive price is the lowest bid price in the range. Conversely, for sell-side orders, the most aggressive price is the lowest ask price in the range, and the least aggressive price is the highest ask price in the range.

[0073] If condition block 630 determines that the target price falls within the active price range, the process proceeds to block 640. At block 640, the cache manager 152 uses the target price tick as an index to fetch a tile from the active price area for the given symbol and side from the first memory cache 410. Details of an example for determining a tile location within the active price area of ​​the first memory cache using the target price tick as an index are described below in conjunction with Figures 7A and 7B.

[0074] If condition block 630 determines that the target price is outside the active price range, the process proceeds to blocks 650 and 660. At block 650, cache manager 152 generates a hash key based on the target price tick and symbol. At block 660, cache manager 152 fetches tiles from the inactive price region of the second memory cache using the hash key as an index. Details of an embodiment for generating a hash key that indexes the inactive price region of the second memory cache in the form of a sparse hash array are described below in conjunction with FIG. 8.

[0075] As previously discussed, the cache manager 152 can use the target price tick as an index to fetch a tile from the active price area for a given symbol and side of the first memory cache 410. Figures 7A and 7B are schematic diagrams illustrating an example of using the target price tick as an index to determine a tile location within the active order area of ​​the first memory cache.

[0076] Specifically, Figure 7A shows an active buy order area for a financial instrument 710, while Figure 7B shows an active sell order area for a financial instrument 720. Each active order area may be implemented as a circular buffer array of tiles.

[0077] Cache manager 152 may maintain the bounds and state of the circular buffer array for a given symbol and side in symbol registry 154, which is maintained in internal memory cache 156, as described above in connection with Figures 1 and 2. In particular, symbol registry 154 may include the following parameters to define the current bounds and state of the active order area in the form of a circular buffer array for a given symbol and side:

[0078] base address of the active orders area,

[0079] The total number of tiles allocated to the active order area,

[0080] A fixed tile size within the active ordering region (e.g., single-sized tiles (4KB), double-sized tiles (8KB), or quad-sized tiles (16K)),

[0081] The current best price (i.e., the best bid price for an active buy order area, or the best ask price for an active sell order area)

[0082] the current best price index (i.e., the current index of the array element containing the current best price tile), and

[0083] The current wrap index (i.e., the current index of the array element containing the tile with the worst bid or ask price in the active order space).

[0084] Given the above information from the symbol registry 154 for a given symbol and side, and that the tiles are indexed consecutively by price, the cache manager 152 may determine that the active buy order area 710 of FIG. 7A begins at the buy side base address 712 and contains a total of 1024 indexable tiles.

[0085] Referring to FIG. 7A , and assuming the symbol registry can provide, among other information, (i) a wrap index (e.g., index number 1023) that identifies the location of tile 714 having the worst or least aggressive bid price (e.g., 9077 ticks ($0.9077)), (ii) a current best price index (e.g., index number 300) that identifies the location of tile 716 having the current best bid price (e.g., 9800 ticks ($0.9800)), and (iii) a total number of indexable tiles (e.g., 1024 tiles total), the cache manager 152 can determine whether the target buy side tile falls within a contiguous price range of the active buy order area 710. In this example, the contiguous price range of the active buy orders area 710 extends from the highest (or most aggressive) bid price of 10,100 ticks ($2.00) at index 0 of the array to the worst (or least aggressive) bid price of 9,077 ticks ($0.9077) at index 1,023. Furthermore, if the tiles of the active buy orders area 710 are indexed consecutively by price, the cache manager 152 can determine, for a given symbol, the index location of any buy-side tile within the active buy orders area by best price index, lowest price index, and price relative to the total number of tiles as identified in the symbol registry.

[0086] Referring to FIG. 7B , and assuming the symbol registry can provide, among other information, (i) a wrap index (e.g., index number 1023) that identifies the location of tile 724 having the worst or least aggressive ask price (e.g., 10023 ticks ($1.23)), (ii) a best price index (e.g., index number 200) that identifies the location of tile 726 having the current best bid price (e.g., 9200 ticks ($0.9200)), and (iii) a total number of indexable tiles (e.g., 1024 tiles total), the cache manager 152 can determine whether the target sell-side tile falls within a contiguous price range of the active sell order area 720. In this example, the contiguous price range of the active sell orders area 720 extends from the lowest (or most aggressive) ask price of 9000 ticks ($0.9000) at index 0 of the array to the worst (or least aggressive) ask price of 10023 ticks ($1.23) at index 1023. Furthermore, if the tiles of the active sell orders area 722 are indexed consecutively by price, the cache manager 152 can determine, for a given symbol, the index location of any sell-side tile within the active sell orders area 722 by best price index, lowest price index, and price relative to the total number of tiles as identified in the symbol registry.

[0087] Additionally, as the price of a given symbol behaves and shifts over the course of a trading day, cache manager 152 may adjust the price range of each active order region by updating one or more of the aforementioned parameters defined in symbol registry 154. To account for such adjustments, cache manager 152 may add or remove tiles in response to the adjusted price range of the active order region. Methods 1100 and 1300 for gradually adjusting the sequence of price consecutive tiles within the active order region of the first memory cache are presented below in connection with Figures 11-14B.

[0088] As discussed above, when the target price is determined to be outside the active price range of the first memory cache, the cache manager 152 may generate a hash key as an index to identify a tile location in the sparse hash array of the inactive price order area 452. A hash key collision may occur when the generated hash key corresponds to a tile location currently occupied by another tile. In particular, a hash key collision may be more likely to occur if the hash key is calculated based solely on price.

[0089] Therefore, to minimize hash key collisions and thus improve access times for fetching tiles from the sparse hash array, the cache manager 152 may generate hash keys based on a target price and a unique offset that represents a stock or other financial instrument. Because inactive price levels, sometimes referred to as outlier prices, are typically centered around fractional currency values ​​(e.g., dollars rounded to the nearest 1, 5, and 10), the likelihood of hash key collisions may be reduced by adding a unique offset to the target price, as discussed below with respect to FIG.

[0090] 8 is a flow diagram illustrating a method 800 for generating hash keys to index inactive price regions 452 of second memory cache 450 in the form of a sparse hash array, according to an embodiment. In some embodiments, method 800 may be implemented by cache manager 152 described above in connection with FIGS. 1 and 2.

[0091] At block 810, the cache manager 152 receives the target price in the form of target price ticks. In some embodiments, the target price ticks may be generated by the cache manager 152 in response to receiving a request for open order data associated with a given symbol, side, and price, as described above in connection with method blocks 610 and 620 of FIG. 6.

[0092] In block 820, the cache manager 152 offsets the target price ticks by adding a numeric symbol identifier that uniquely identifies a given stock or other financial instrument, resulting in an intermediate symbol-specific value. As previously discussed, the cache manager 152 maintains a symbol registry 154 as a memory lookup for information specific to stocks or other financial instruments. To access information for a particular stock or other financial instrument, the symbol registry 154 assigns each instrument a unique symbol index (e.g., integers 0, 1, 2, ... N). Thus, in some embodiments, the cache manager 152 can offset the target price ticks using the symbol index of a given stock or financial instrument.

[0093] At block 830, the cache manager 152 may generate a hash key by applying a modulo operation to the intermediate symbol unique value with respect to the total number of tile positions in the sparse hash array of the inactive order area 452. Because inactive price levels, outlier prices, are generally centered around fractional currency values ​​(e.g., dollars rounded to the nearest 1, 5, and 10), the likelihood of hash key collisions may be reduced by offsetting the target price ticks by a symbol index or other symbol identifier. For example, given two tiles at the same price (e.g., 10,000 ticks, or $1.00) for different symbols (e.g., with assumed symbol indices equal to 1 and 2), the intermediate symbol unique value would be 10001 for the first tile and 10002 for the second tile. By performing a modulo operation on each value with respect to the total number of tiles assigned to the sparse hash array, for example, for one million (1M) tiles, the hash key is 10001 and the hash key for a second tile is 10002, thereby avoiding hash key collisions for tiles with the same price for different symbols.

[0094] At block 840, the cache manager 152 uses the hash key as an index to identify the memory address of a tile in the inactive order area 452 of the second memory cache 450 in the form of a sparse hash array. As previously discussed, the sparse hash array in the inactive order area 452 preferably provides shared tile storage for tiles having prices outside of the actively traded price range. Given that the sparse hash array may be defined to store tiles having a fixed size, the cache manager 152 may determine the index of the tile location for a given symbol, side, and price by adding the base memory address of the sparse hash array to the product of the hash key and the fixed tile size.

[0095] 3, an immediate tile contains open order data (e.g., a cell access node) that contains all the information necessary to index and prioritize all open orders for a particular symbol, side, and price in open order database 170. However, special tiles, sometimes referred to herein as “redirection tiles,” may be used in multilevel memory cache 160 as placeholders that contain address information for locating immediate tiles elsewhere in external multilevel memory cache 160.

[0096] 9, cache manager 152 can generally fetch an immediate tile from the multilevel memory cache with one external memory access, although in other situations cache manager 152 may require up to two external memory accesses to fetch the immediate tile. For example, as discussed in more detail below in connection with FIG. 9, cache manager 152 may first fetch a redirection tile from either the active order area of ​​the first memory cache or the inactive order area of ​​the second memory cache, and then fetch the immediate tile at an address in a free heap buffer or other unstructured memory area of ​​the second memory cache. Once the immediate tile is loaded and validated, cache manager 152 can access the immediate tile in its internal memory cache with minimal delay to obtain open order data for multiple open orders with the same symbol, side, and price.

[0097] 9 is a flow diagram illustrating a method 900 for processing tiles of different types, according to an embodiment. The method 900 may be implemented by the cache manager 152 described above in connection with FIGS.

[0098] At block 910, the cache manager 152 may load the tile into an internal memory cache 156, such as a block random access memory (BRAM). As previously discussed in connection with FIG. 3, there are different types of tiles. An immediate tile contains open order data (e.g., cell access nodes) representing multiple buy or sell orders for a financial instrument. A redirection tile contains at least one address for accessing the immediate tile's memory location elsewhere in the multilevel memory cache 160, such as a free heap buffer or other unstructured memory area.

[0099] At conditional block 920, the cache manager 152 determines whether the loaded tile is an immediate tile. If it is determined that the loaded tile is an immediate tile, the process proceeds to block 960. At block 960, the cache manager 152 validates the contents of the immediate tile. In some embodiments, the cache manager 152 verifies that the symbol, side, and price of the tile match the symbol, side, and price of the requested open order data. For example, as previously discussed in connection with FIG. 3, the header portion 310 of the tile may include fields that identify the symbol, side, and price of the tile.

[0100] Conversely, if the loaded tile is not an immediate tile, the cache manager 152 proceeds to blocks 930-960. In condition block 930, the cache manager 152 determines whether the loaded tile is a redirection tile. As described above, a redirection tile includes an address of an immediate tile in a memory location of the free heap buffer 454 or other unstructured memory area of ​​the second memory cache 450. In some circumstances, a redirection tile (e.g., Type==MODE_EXTEND) can provide memory address locations for an extended immediate tile with a larger tile size that accommodates open order data (e.g., cell access nodes) that exceeds the maximum order capacity of a tile in a given active order area 412 or inactive order area 452. In other circumstances, a redirection tile (e.g., Type==MODE_COLLISION) can provide respective memory address locations for two or more immediate tiles in the free heap buffer 454 that collide at the same hash key location in the inactive order area 452 sparse hash array.

[0101] At block 940, the cache manager 152 obtains from the redirection tile the memory address location of the immediate tile in the free heap buffer 454 of the second memory cache 450. In some embodiments, the cache manager 152 reads the redirection tile from the internal memory cache 156 and obtains the memory address location contained in the redirection tile for a given symbol, side, and price (“SSP”) of the target immediate tile. In some embodiments, the cache manager 152 reads the specific memory address or other address information for identifying the target immediate tile from the body portion of the redirection tile. In some other embodiments, the cache manager 152 may read the specific memory address or other address information from the header portion of the redirection tile. An advantage of reading the address information from the header portion of the redirection tile is that the cache manager does not need to load the entire redirection tile (e.g., the header and body portions) into the internal memory cache 156 before beginning to fetch the immediate tile referenced by the address information in the header portion.

[0102] In block 950, the cache manager 152 fetches the immediate tile from the free heap buffer 454 at the memory address location provided by the redirection tile and loads the immediate tile into the cache manager's internal memory cache 156.

[0103] At block 960, the cache manager 152 validates the contents of the instant tile, eg, price, symbol, as described above.

[0104] 10A-10D are schematic diagrams illustrating examples of retrieving different types of tiles according to the method of FIG. 9. As previously discussed, different tile types may be stored in the multilevel memory cache 160 described herein. In particular, an immediate tile contains open order data (e.g., cell access nodes) representing multiple buy-side or sell-side orders for a financial instrument, while a redirection tile contains at least one address for accessing the immediate tile's memory location elsewhere in the multilevel memory cache 160, such as in a free heap buffer or other unstructured memory area.

[0105] 10A illustrates a second memory cache 450 provisioned with a sparse hash array representing an inactive order space 452 and a free heap buffer 454 or other type of unstructured memory. While the sparse hash array 452 and the free heap buffer 454 are shown as being contained in a single cache 450, those skilled in the art will recognize that the sparse hash array and the free heap buffer can be implemented in separate caches. The sparse hash array 452 represents an inactive order space that can include immediate tiles and redirection tiles, each associated with a symbol, side, and price ("SSP") that is outside of the respective active order space of the first memory cache 410. The free heap buffer 454 is an area of ​​unstructured memory that can store immediate tiles at memory address locations referenced by the respective redirection tiles. Although not shown in FIG. 10A, the active order area of ​​the first memory cache can also store both immediate tiles and redirection tiles that reference other immediate tiles in the free heap buffer 454.

[0106] 10B illustrates an example of retrieving immediate tiles 1010a, 1010b, and 1010c (collectively, immediate tiles 1010) in one external memory access from the sparse hash array 452 of the second memory cache 450, according to an embodiment. As previously discussed in connection with FIG. 3, the immediate tile contains open order data, e.g., in the form of cell access nodes, representing all orders to buy or sell a given stock or other financial instrument at a given price. Thus, the cache manager 152 can read the immediate tile 1010 directly from the sparse hash array 452 into its internal memory cache (e.g., 156 in FIG. 2) in a single memory access for immediate validation (e.g., block 960 in FIG. 9) and subsequent use.

[0107] 10C illustrates an example of retrieving an expanded immediate tile 1022 with two external memory accesses from the free heap buffer 454 of the second memory cache 450, according to an embodiment. In a preferred embodiment, the tile is defined to have a predetermined size and can therefore represent orders to buy or sell a given financial instrument up to the maximum order capacity. If the number of orders for a given symbol, side, and price exceeds the maximum order capacity, the cache manager 152 can create an expanded immediate tile 1022 for the given symbol, side, and price for storage in the free heap buffer 452 of the second memory cache 450. The expanded immediate tile 1022 can have the same data structure as the tile shown in FIG. 3, except that the body portion 320 can have a larger size to accommodate all of the open order data (e.g., cell access nodes) for the given symbol, side, and price.

[0108] To identify the extended immediate tile 1022 in the free heap buffer 454, the cache manager 152 may store the redirection tile 1024, sometimes referred to herein as an extended redirection tile (e.g., Type=MODE_EXTENDED), in a tile location in the first memory cache or the second memory cache for the particular symbol, side, and price of the extended tile. As shown schematically in FIG. 10C, the extended redirection tile 1024 may include a memory address along with the extended tile size that points to the extended immediate tile 1022 in the free heap buffer 454.

[0109] 9, the cache manager 152 can access the extended immediate tile 1022 with at most two external memory accesses. In particular, the cache manager 152 may first fetch the extended redirection tile 1024 from the sparse hash array of inactive order space 452, and then fetch the extended immediate tile 1022 at the memory address of the free heap buffer 454 specified by the extended redirection tile 1024. Once the extended immediate tile 1022 is loaded and validated, the cache manager 152 can access the immediate tile 1022 in its internal memory cache (e.g., 156 in FIG. 2) with minimal delay to obtain open order data (e.g., one or more cell access nodes) for multiple open orders having the same symbol, side, and price.

[0110] FIG. 10D illustrates an example of retrieving colliding immediate tiles 1032a and 1032b with two external memory accesses from the free heap buffer 454 of the second memory cache 450, according to an embodiment. As discussed above in connection with FIG. 8, the cache manager 152 can generate a hash key as an index to identify a tile within the sparse hash array 452 for a given symbol, side, and price. A hash key algorithm is presented herein to minimize the risk of hash key collisions for the same tile location within the sparse hash array of the second memory cache. However, there may be instances in which hash key collisions occur between two or more tiles 1032a and 1032b. Such instances are more likely to occur when the target prices of the tiles are not centered around a rounded price (e.g., $1.00, $15.00, $300.00, etc.).

[0111] If the hash key index generated for a particular symbol, side, and price collides with the hash key index for a tile location currently occupied by another tile for a different symbol, side, and price, the cache manager 152 rearranges the immediate tiles 1032a and 1032b with the same hash key index to separate memory locations in the free heap buffer 454 of the second memory cache 450.

[0112] To identify the immediate tiles 1032a and 1032b that have been relocated to the free heap buffer 454, the cache manager 152 may store redirection tiles 1034, sometimes referred to herein as collision redirection tiles (e.g., Type=MODE_COLLISION), in a sparse hash array 452 of tile locations indexed by the common hash key of the relocated tiles. As shown schematically in FIG. 10D, the collision redirection tiles 1034 may include memory addresses that point to each of the immediate tiles 1032a and 1032b involved in the hash key collision in the free heap buffer 454.

[0113] 9, cache manager 152 can access immediate tiles involved in a hash key collision with at most two external memory accesses. Specifically, cache manager 152 may first fetch collision redirection tile 1034 from sparse hash array 452, and then fetch one of the immediate tiles involved in the hash key collision (e.g., 1032a or 1032b) at the memory address of free heap buffer 454 specified by collision redirection tile 1034 for a given symbol, side, and price tuple. Once immediate tile 1032a or 1032b is loaded and validated, cache manager 152 can access immediate tile 1032a or 1032b in its internal memory cache (e.g., 156 in FIG. 2) with minimal delay to obtain open order data (e.g., one or more cell access nodes) for multiple open orders with the same symbol, side, and price.

[0114] Changing market conditions may cause the price behavior of orders on a given side of a financial instrument to shift throughout the trading day. For example, if the best price for a given side and financial instrument begins to trend upward or downward, the cache manager 152 may gradually adjust the sequence of price contiguous tiles, and thus the price range of the active order area of ​​the first memory cache, to reflect such price behavior.

[0115] Specifically, the cache manager may invalidate one or more tiles from one end of a price-contiguous active order area of ​​a first memory cache of the multilevel memory cache to make space available at the opposite end of the active order area for adding one or more other tiles. Tiles added to the active order area may include newly created tiles or relocated tiles from an inactive order area of ​​a second memory cache of the multilevel memory cache. Tiles added to the active order area may represent orders with more aggressive or less aggressive prices, depending on the trend direction of price behavior. For buy-side orders, higher prices are considered more aggressive than lower prices. Conversely, for sell-side orders, lower prices are considered more aggressive than higher prices.

[0116] 11 is a flow diagram illustrating a method 1100 for gradually adjusting a sequence of price consecutive tiles in an active order area of ​​a first memory cache to include more aggressive price tiles, according to an embodiment. For buy-side orders, more aggressive prices indicate higher prices. Conversely, for sell-side orders, more aggressive prices indicate lower prices. Method 1100 may be implemented by the cache manager 152 described in connection with FIGS. 1 and 2.

[0117] At block 1110, the cash manager 152 detects prices for orders to either buy or sell the more aggressively trending financial instrument. For buy-side orders, the cash manager 152 may detect an increase in the quantity of the buy-side order at or above the best bid price. For sell-side orders, the cash manager 152 may detect an increase in the quantity of the sell-side order at or below the best ask price.

[0118] At condition block 1120, the cache manager 152 determines whether the least aggressive price tile in the active order region of the first memory cache contains any open order data (e.g., cell access nodes) representing an order to buy and / or sell a financial instrument at the least aggressive price (e.g., symbol, side, price). For buy-side orders, the least aggressive price tile is the tile with the lowest bid price in the price-contiguous active order region. For sell-side orders, the least aggressive price tile is the tile with the highest bid price in the price-contiguous active order region. In some embodiments, the cache manager can reference a symbol registry (e.g., 154 in FIG. 1 ), which may include a memory lookup table that indicates whether the tile contains any open order data corresponding to at least one order to buy or sell a stock or other financial instrument at different price levels. Referring to FIG. 3 , the memory lookup table may indicate that a tile at a particular price contains open order data if the tile contains at least one cell access node (e.g., access node 325 in FIG. 3 ) assigned to a corresponding open order cell (e.g., cell 330 in FIG. 3 ) under one of the priority lists (e.g., priority list 329 in FIG. 3 ).

[0119] If condition block 1120 determines that the least aggressive price tile is empty with no open order data, the process continues to block 1140. At block 1140, the cache manager 152 may overwrite the least aggressive price tile in the active order space with a new most aggressive price tile. The cache manager 152 may create a new most aggressive price tile with a price one tick above the most aggressive price tile. For buy-side orders, the bid price of the newly created most aggressive price tile is one tick higher in price than the highest bid price in the contiguous active order space. For sell-side orders, the ask price of the newly created most aggressive price tile is one tick lower in price than the lowest ask price in the contiguous active order space.

[0120] Conversely, if condition block 1120 determines that the least aggressive price tile includes open order data representing at least one order to buy or sell a financial instrument at the least aggressive price (e.g., the lowest / highest bid price in the active order space), the process may continue to blocks 1130 and 1140. At block 1130, the cache manager 152 copies the least aggressive price tile from the active order space of the first memory cache to the inactive order space of the second memory cache. As previously discussed, the inactive order space may be implemented in the form of a sparse hash array. At block 1140, the cache manager 152 may overwrite the least aggressive price tile in the active order space with the newly created most aggressive price tile. As previously discussed, the cache manager 152 may create a new most aggressive price tile with a price one tick above the most aggressive price tile. For buy-side orders, the bid price of the newly created most aggressive price tile is one tick higher than the highest bid price of the contiguous active order space. For sell-side orders, the ask price of the newly created most aggressive price tile is one tick lower than the lowest ask price in the price-contiguous active order region.

[0121] 12A and 12B are schematic diagrams illustrating an example of gradually adjusting a sequence of price consecutive tiles within an active buy order region of a first memory cache to include more aggressive price tiles with higher bid prices, a process sometimes referred to herein as "crawling hotter."

[0122] Specifically, FIG. 12A shows an example of an active order area 1210 within a first memory cache (e.g., 410 in FIG. 4) that stores consecutive bid price tiles for buy-side orders for a given financial instrument having symbol index SYM_0. The price range of the consecutive bid price tiles ranges from the most aggressive (highest) bid price of $315.71 to the least aggressive (lowest) bid price of $312.41. As shown in the illustrated example, the active order area 1210 may be implemented as a circular buffer array with a wrap index corresponding to the tile 1212 having order data at the lowest bid price. The best bid price in this example is $315.41. While bid prices are shown in currency format for ease of understanding, prices are preferably expressed in ticks.

[0123] To gradually adjust the price range of the active buy order area to include the newly created most aggressive price tile 1214, which has a higher bid price at $315.72, the cache manager 152 determines (e.g., in condition block 1120 of FIG. 11 ) whether the least aggressive price tile 1212 is empty. In this example, the least aggressive price tile 1212 is determined to contain open order data for at least one buy-side order at the lowest bid price and is therefore not empty. Therefore, as shown in FIG. 12B , the cache manager 152 copies (e.g., in block 1130 of FIG. 11 ) the least aggressive price tile 1212 from the active orders area 1210 of the first memory cache 410 to an empty tile location 1232 of the sparse hash array of the inactive orders area 1230 of the second memory cache 1220. The cache manager 152 can then overwrite the tile location vacated by the least aggressive price tile 1212 with a newly created most aggressive price tile 1214 with a higher bid price of $315.72. In some circumstances, the new most aggressive price tile 1214 can be a redirection tile that points to an immediate tile in the free heap buffer 1240 of the second external memory cache 1220.

[0124] 13 is a flow diagram illustrating a method 1300 for gradually adjusting a sequence of price consecutive tiles in an active order area of ​​a first memory cache to include less aggressive price tiles, according to an embodiment. For buy-side orders, less aggressive prices indicate lower prices. Conversely, for sell-side orders, less aggressive prices indicate higher prices. Method 1300 may be implemented by cache manager 152 described in connection with FIGS. 1 and 2.

[0125] At block 1310, the cash manager 152 detects prices for orders to either buy or sell less aggressively trending financial instruments. For buy-side orders, the cash manager 152 may detect an increase in the quantity of the buy-side order below the best bid price. For sell-side orders, the cash manager 152 may detect an increase in the quantity of the sell-side order above the best ask price.

[0126] In condition block 1320, the cache manager 152 determines whether the inactive order region of the second memory cache contains a tile with a price one tick above the least aggressive price tile to serve as the new least aggressive price tile. For buy-side orders, the least aggressive (or worst) price tile has the lowest bid price within the price-contiguous active order region. For sell-side orders, the least aggressive price tile has the highest ask price within the price-contiguous active order region.

[0127] If the cache manager 152 determines at condition block 1320 that the inactive order area includes a tile with a price one tick above the least aggressive price tile, the process proceeds to blocks 1330 and 1340. At block 1330, the cache manager 152 copies the new least aggressive price tile from the inactive order area (e.g., a sparse hash array) of the second memory cache and overwrites the most aggressive price tile (e.g., a circular buffer array) of the active order area of ​​the first memory cache with the new least aggressive price tile. At block 1340, the cache manager 152 marks the space vacated by the new least aggressive price tile in the inactive order area of ​​the second memory cache as free. In some embodiments, a tile location can be marked free by overwriting the tile location with a special tile having a header portion whose type field indicates that the space is free (e.g., Type==“MODE_FREE”).

[0128] Conversely, if the cache manager 152 determines at condition block 1320 that the inactive order region does not contain a tile with a price one tick above the least aggressive price tile, the process proceeds to block 1350. At block 1350, the cache manager 152 overwrites the most aggressive price tile in the active order region with the newly created least aggressive price tile. For buy-side orders, the cache manager 152 creates a new least aggressive price tile with a bid price one tick below the lowest bid price in the contiguous active order region. For sell-side orders, the cache manager 152 creates a new least aggressive price tile with an ask price one tick above the highest ask price in the contiguous active order region.

[0129] 14A and 14B are schematic diagrams illustrating an example of gradually adjusting a sequence of price consecutive tiles within an active buy order area of ​​a first memory cache to include less aggressive price tiles with lower bid prices, a process sometimes referred to herein as "crawling colder."

[0130] Specifically, FIG. 14A shows an example of an active order area 1410 in a first memory cache that stores consecutive bid price tiles for buy-side orders for a given financial instrument having symbol index SYM_0. The price range of the consecutive bid price tiles ranges from the most aggressive (highest) bid price of $315.71 to the least aggressive (lowest) bid price of $312.41. As shown in the illustrated example, the active order area 1410 may be implemented as a circular buffer array with a wrap index corresponding to the lowest bid price tile 1412. The best bid price in this example is $315.41. While bid prices are shown in currency format for ease of understanding, prices are preferably expressed in ticks.

[0131] To gradually adjust the price range of the active buy order area to include a new, least aggressive price tile with a minimum bid price of $312.40, the cache manager 152 determines whether the sparse hash array of the inactive order area 1430 of the second memory cache 1420 includes a tile 1432 with a bid price one tick lower than the current minimum bid price tile 1412 of the active order area at a wrap index (e.g., in condition block 1320 of FIG. 13 ). In this example, the cache manager 152 locates, for the given symbol and side, a tile 1432 in the sparse hash array of the inactive order area 1430 with a bid price of $312.40, one tick lower than the current minimum bid price tile 1412 at $312.41. Thus, as shown in FIG. 14B , the cache manager 152 copies a new lowest bid price tile 1432 from the sparse hash array in the inactive orders area 1430 to overwrite the highest bid price tile 1416 in the active orders area 1410 (e.g., in block 1330 of FIG. 11 ). In this example, the highest bid price 1416 has a higher price (e.g., $315.71) than the current best bid price (e.g., $315.41). Thus, the highest bid price tile 1416 in the active buy orders area 1410 may be assumed to be empty and available for overwriting when any order with a highest bid price above the current best bid price is immediately matched.

[0132] If the inactive order area 1430 sparse hash array does not contain the desired tile, the cache manager 152 may create a new tile with a lowest bid price that is one tick lower at $312.40 and overwrite the active order area's highest bid price tile 1416 with the newly created tile. The cache manager 152 may also update the symbol registry 154 to change the wrap index of the active order area's circular buffer array to correspond to the tile position of the newly added lowest bid price tile. In some circumstances, the new least aggressive price tile may be a redirection tile that points to an immediate tile in the free heap buffer 1440 of the second external memory cache 1420.

[0133] In U.S. markets, the minimum price fluctuation between prices above $1 is often one cent ($0.01), while the minimum price fluctuation between prices below $1 is often one-hundredth of a cent ($0.0001). Instead of representing currency in decimal form, most financial markets express prices as integers with implicit decimalization, referred to herein as ticks. For example, with an implicit decimalization of 4, the integer sequence for consecutive allowable prices between $0.9998 and $1.02 is 9998, 9999, 10000, 10100, and 10200. Therefore, due to the change in minimum price fluctuation, the integer sequence is not continuous after the price precision level of $1.00 (10000).

[0134] As previously discussed, each active order region in the first memory cache is organized in a price-contiguous manner. Thus, to store or fetch tiles for a target price, cache manager 152 converts the target price into corresponding ticks in a consecutive intenger sequence to identify the appropriate address of the tile in the circular buffer array. However, as previously discussed, the intenger sequence may not be a consecutive intenger sequence due to variations in minimum price fluctuations across different price precision levels.

[0135] 15A-15B are flow diagrams illustrating a method 1500 for converting target prices into ticks having successive intensifier sequences, regardless of the change in the minimum price change between successive prices, according to an embodiment. Method 1500 may be implemented by cache manager 152 described in connection with FIGS. 1 and 2.

[0136] In block 1510, the cash manager 152 receives the target price in the form of ticks (i.e., increments with a first implicit decimalization). The table below is an example list of target price ticks, each with an implicit decimalization of 4 for a price precision level of $1.00. As shown in the table below, the tick count increases successively by 1 tick up to a price precision level of $1.00. Above the price precision level of $1, the tick count increases by 10 ticks, resulting in a discontinuous tick sequence.

[0137] [Table 3]

[0138] In condition block 1515, the cash manager 152 determines whether the target price tick exceeds the price precision level. The price precision level is the price at which the minimum price change occurs. As shown in the example in Table I above, the price precision level is one dollar ($1.00), with a minimum price change equal to one-hundredth of a cent ($0.0001) below one dollar, and one cent ($0.01) above one dollar.

[0139] If the target price tick is below the price precision level, the process proceeds to block 1555. At block 1555, the target price tick may be left unchanged for use as either (i) an index into the active order area of ​​the first memory cache, or (ii) an input to generate a hash key as an index into the inactive order area of ​​the second memory cache.

[0140] Conversely, if the target price tick is above the price accuracy level, the process proceeds from block 1520 to block 1555 .

[0141] In block 1520, the cash manager 152 determines that a minimum price change has been established above the price precision level. Following the example shown in the table above, the minimum price change above $1.00 is 1 cent ($0.01), or an implicit decimalization of two decimal places.

[0142] In block 1525, the cache manager 152 converts the target price tick from the first implied decimal format to a second implied decimal format that corresponds to the minimum price change above the price precision level. According to the example shown in the table above, the cache manager 152 can convert a target price tick of $1.01 from 10100 to 101.

[0143] At block 1530, the cash manager 152 determines the total number of ticks that can be represented in a second implicit decimal format below the price precision level. According to the example shown in the table above, the total number of ticks that can be represented in an implicit decimal format with two decimal points below the price precision level of $1.00 is 99 ticks.

[0144] In block 1535, the cash manager 152 determines the total number of ticks whereby the target price ticks in the second implied decimalization format (i.e., determined in block 1525) exceed the total number of ticks that can be submitted in the second implied decimalization format below the price precision level (i.e., determined in block 1530). According to the example shown in the table above, the target price ticks of $1.01 in the two-digit implied decimalization (i.e., 101 ticks) exceed the total number of ticks that can be submitted below $1.00 in the two-digit implied decimalization (i.e., 99 ticks) by 2 ticks.

[0145] In block 1540, the cash manager 152 determines that a minimum price change has been established below the price precision level. Using the example shown in the table above, the minimum price change established below the price precision level of $1.00 is one-hundredth of a cent ($0.0001).

[0146] At block 1545, the cash manager 152 determines the total number of ticks that can be represented in the third implied decimal format that corresponds to the minimum price change that can be determined below the price precision level (i.e., determined at block 1540). According to the example shown in the table above, the minimum price change that can be determined below the price precision level of $1.00 is one-hundredth of a cent, thus an implicit decimalization of four decimal places. If the implied decimalization is four, the total number of ticks that can be represented below $1.00 is 9999 ticks.

[0147] At block 1550, the cash manager 152 converts the target price ticks from the second implicit decimalization format to a third implicit decimalization format. In particular, this conversion may be performed by adding the total number of ticks representable in the third implicit decimalization format that are below the price precision level (i.e., determined at block 1545) and the total number of ticks where the target price ticks exceed the price precision level of the second implicit decimalization format (i.e., determined at block 1535). According to the example shown in the table above, a revised target price tick of $1.01 may be represented as 10001 ticks (i.e., 2 + 9999).

[0148] Thus, as shown in the table below, the aforementioned method is able to translate target prices into ticks in successive intensifier sequences regardless of the change in the minimum price movement between successive prices.

[0149] [Table 4]

[0150] In block 1555, the cache manager 152 can use the target price tick obtained in block 1550 as either (i) an index into the active order area of ​​the first memory cache, or (ii) an input to generate a hash key as an index into the inactive order area of ​​the second memory cache.

[0151] Another methodology for reducing the overall latency of an electronic trading system can be achieved through opportunistic prefetching of tiles from an external multilevel memory cache. For example, the cache manager 152 may fetch a tile from external memory in response to a request for order data for a given symbol, side, and price, such as the best bid price or best ask price. Once a tile is loaded into the internal cache memory, the cache manager 152 can simply access the loaded tile in response to subsequent order data requests for the same symbol, side, and best price. However, once the order data from the loaded tile is exhausted (i.e., all unopen orders are filled or canceled), another tile must be loaded from external memory for orders that continue to match at the next best price for the given symbol and side.

[0152] To reduce the overall latency of the electronic trading system, cache manager 152 may be configured to prefetch a second tile into internal memory cache 156 before a first tile in internal memory cache 156 may be depleted. In a preferred embodiment, cache manager 152 may monitor which tiles contain open order data representing at least one order for a given symbol, side, and price and are therefore non-empty. Thus, rather than simply fetching the next tile with the next best price from external memory, cache manager 152 may be configured to prefetch a tile at the next best price that is not empty. This avoids fetching one or more tiles from external memory that may not have any open order data and unnecessary delays.

[0153] 16 is a flow diagram illustrating a method 1600 for proactively prefetching tiles, according to an embodiment. The method 1600 may be implemented by the cache manager 152 described in connection with FIGS.

[0154] At block 1610, the cache manager 152 may track whether each tile in the contiguous price tiles of the active order area for a given symbol and side contains open order data representing at least one open order. In some embodiments, the cache manager 152 may track this information in a memory lookup table, an example of which is shown below. Populated tiles that contain open order data are marked with a "YES" in the table below.

[0155] [Table 5]

[0156] In block 1620, the cache manager 152 may access the memory lookup table while fetching the first tile having the target price.

[0157] In block 1630, the cache manager 152 may determine from a memory lookup table the tile having the next best price that is closest to the target price of the requested tile. For example, assuming the target price of the requested tile is $10.00, the cache manager 152 may access the table entry for the next best price of $10.01.

[0158] At condition block 1640, the cache manager 152 may determine from the memory lookup table whether the next best price tile contains any open order data representing at least one open order for that symbol, side, and price. If at condition block 1640 it is determined that the next best price tile contains open order data, the process may continue to block 1650. At block 1650, the cache manager 152 may prefetch the next best price tile from the active order area. In some embodiments, the cache manager 152 may begin prefetching before the first tile begins returning from external memory. While the matching logic is operating on the first tile, the second tile has time to load in the internal memory cache. Conversely, if the next best price tile is empty, the process may return to block 1630 to identify the next best price tile that is closest to the target price tile.

[0159] In this example, the first two tiles with the symbol, side, and price closest to the target price of $10.00 are empty, so the cache manager 152 prefetches the populated tile with the fourth-best price and avoids unnecessarily prefetching the empty tiles with the second-best and third-best prices at $10.01 and $10.02.

[0160] The advantage of prefetching tiles is that the process has minimal impact on system performance, especially if the prefetch logic is executed during idle times.

[0161] 17 is a schematic diagram illustrating a processing unit for optimizing the use of cache space in multilevel memory caches 160a, 160b, 160c (collectively or individually 160), according to an embodiment. In some embodiments, the processing unit, referred to herein as a fitter tool 1710, may be implemented as a hardware component of any of the electronic trading systems disclosed herein. In some other embodiments, the fitter tool 1710 may be implemented as a separate software processor (e.g., a CPU-based processor capable of executing software).

[0162] As previously discussed in connection with FIG. 4, the amount of physical DRAM that can be allocated to the first memory cache is a finite amount in production. Furthermore, per-symbol usage of the first memory cache may be limited to only a specific price range at any given time. This price range may be further limited by increasing the tile size, thus requiring more of the limited physical DRAM for each symbol. Furthermore, any crawling adjustments to move the price level boundaries of each active order region for each symbol in the first memory cache may incur processing costs for performing the crawling operation, which may impact performance. Therefore, the fitter tool may set the aforementioned configurable variables for each symbol to maximize the efficiency of each active order region for each symbol.

[0163] An embodiment of the fitter tool 1710 may be used to determine the layout of each symbol in each active order area and also how the symbols are distributed across multiple matching engine book (MEB) servers 150a, 150b, 150c (collectively or individually 150) for load balancing purposes.

[0164] In some embodiments, fitter tool 1710 may exist as a hardware processor (e.g., FPGA, ASIC, etc.) or alternatively as a processor ancillary to the MEB server that executes software and executes a process that determines, preferably nightly, the symbol configurations to be managed by each MEB service for the next trading day. For each symbol, fitter tool 1710 may manage the following symbol configurations: (i) which MEB server maintains the order book for each symbol; (ii) The size of the tiles stored in the active order area for each symbol (e.g., single, double, quad) in the first external memory cache. Increasing the tile size allows accessing a larger amount of open order data (e.g., cell access nodes) in a single memory access, at the cost of more memory usage at each price level in the active order area. As discussed above, exceeding the tile limit at a particular price level generally incurs the time cost of a second memory access to retrieve the extended tile from the free heap buffer. (iii) The total number of tiles allocated to each active order area in the first external memory cache for each symbol. The greater the total number of tiles, the greater the symbol's memory cost, which scales multiplicatively with increasing tile size. The greater the number of tiles, the less likely it is that the sequence of consecutive price tiles in the active order area will need to be adjusted, sometimes referred to herein as "crawling." As discussed above in connection with Figures 12-15B, crawling is the act of adjusting the minimum and maximum price levels of a given symbol's active order area by removing price levels from the first memory cache to the second memory cache as needed, thereby attempting to maintain the price levels of the most active trades near the midpoint prices of the active order area. With a larger active order area, the natural fluctuations of each symbol's trade midpoints are less likely to be near the minimum or maximum price levels of a given symbol's active order area, thereby triggering a crawling operation. Avoiding crawling saves processing cycles on the MEB server and improves performance. (iv) Initial minimum and maximum price levels for the active order space for each symbol in the first external memory cache. The fitter tool may attempt to set initial boundaries for the active order space for each symbol, with the goal of adjusting limits for most trades, particularly those with minimal crawling to midpoints within the active order space.

[0165] The fitter tool 1710 can use any or all of the aforementioned symbol configuration parameters to configure the hardware of each MEB server 150. In some embodiments, the fitter tool 1710 can configure the MEB server hardware by setting any or all of the aforementioned symbol configuration parameters in a symbol registry 154 maintained in each of the MEB servers 150 for each symbol.

[0166] The fitter tool 1710 can take several factors into account to determine the symbol configuration for each MEB server. Specifically, the fitter tool 1710 can use any or all of the following factors to determine the symbol configuration parameters: (i) historical data for each symbol in the matching engine, including, but not limited to, the average number of open orders, the number of executed orders, the symbol's volatility (i.e., the mean of the minimum and maximum prices throughout the day), and the average rate of change of the midpoint price (essentially, how fast it may need to crawl); (ii) Expected future activity for a symbol. For example, if the mid-price of a stock is expected to change significantly in light of current events, a larger segment of the active order space may be allocated for a given symbol to minimize expected crawling needs. (iii) The resulting symbol configuration of all other symbols on the same MEB server, with the goal of attempting to balance the total load across MEB servers.

[0167] As discussed above in connection with FIG. 1 , an electronic trading system may include a ticker plant 140. In particular, the ticker plant may be used by various participant devices to access market data in real time. The ticker plant often reflects real-time market data managed by a matching engine book. While the foregoing describes systems and methods for minimizing the need to access external memory from a matching engine book (MEB), such systems and methods may also be incorporated into the ticker plant.

[0168] 18 is a schematic diagram illustrating an embodiment of an automated trading system 1800 including a ticker plant 1810 that maintains a separate order book in the form of an asymmetric multi-level memory cache 1810. The gateway 110, sequencer 130, open order database 170, matching engine book 150 including cache manager 152 and symbol registry 154 contained therein, and asymmetric multi-level cache 160 have been previously described in connection with FIGS. 1 and 2. For the sake of brevity, a description of these components will be omitted.

[0169] 18, ticker plant 1810 includes a cache manager 1812 and a symbol registry 1814 for managing and accessing tiles in an external multilevel memory cache 1820. Ticker plant 1810, which also includes an internal memory cache (not shown), may be implemented in fixed hardware logic such as an FPGA or ASIC. The structure and operation of cache manager 1812, symbol registry 1814, and external multilevel memory cache 1820 may be substantially identical, if not identical, to the structure and operation of cache manager 152, symbol registry 154, and external multilevel memory cache 160 of matching engine book 150, as described above in connection with FIGS. 1-17.

[0170] To maintain the current state of the order book in the external multilevel memory cache 1820, the fixed logic of the ticker plant 1810 can be configured to passively monitor for confirmation messages for various trading events from the matching engine book 150, including, but not limited to, confirmations for requests to open buy or sell orders, confirmations for requests to cancel orders, confirmations for requests to replace orders, or confirmations for requests to modify orders. The ticker plant 1810 may also passively monitor for messages indicating that a particular order has been filled. In the illustrated embodiment, such messages may be routed directly to the cache manager 1812 of the ticker plant 1810 through the sequencer 130.

[0171] Using these messages, fixed logic in ticker plant 1810 can request cache manager 1812 to modify tiles in external multilevel memory cache 1820 by adding, removing, or modifying tiles containing open order data (e.g., cell access nodes) representing open orders for a given symbol, side, and price tuple. In this manner, cache manager 1812 of ticker plant 1810 can maintain an up-to-date order book in external multilevel memory cache 1820 that reflects the order book maintained in external multilevel memory cache 160 of matching engine book (MEB) server 150.

[0172] To respond to a market data feed request from a participant device, fixed logic in the ticker plant 1810 can request open order data for a particular symbol, side, and price from the cache manager 1812. The cache manager 1812 can, in turn, fetch tiles from the external multilevel memory cache 1820 and load the tiles into the internal memory cache of the cache manager 1812, as described above in connection with FIG. 6. Once loaded, the cache manager 1812 can retrieve the requested open order data from the tiles and return the data to the requesting logic in the ticker plant 1810 for further processing as content for the responsive data feed 1830.

[0173] In some embodiments, cache manager 1812 of ticker plant 1810 may be configured to receive requests for all information related to a given symbol, side, and price. Alternatively or additionally, cache manager 1812 of ticker plant 1810 may be configured to receive requests for specific information related to a given symbol, side, and price, including, but not limited to, the number or volume of open orders or the total volume of open orders (e.g., number of shares open) at a given symbol, side, and price. In some embodiments, cache manager 1812 may be configured to respond to requests for information, including, but not limited to, the best bid and ask prices for a given symbol, which may be sourced from symbol registry 1814 or other internal information sources.

[0174] 19 is a schematic diagram illustrating another embodiment of an automated trading system 1900 that includes a ticker plant 1910 that maintains a separate order book in an asymmetric multilevel memory cache 1920. In the illustrated embodiment, the ticker plant 1910 includes a cache manager 1912 and a symbol registry 1914 for managing and accessing tiles in the external multilevel memory cache 1920. The structure and operation of the cache manager 1912, symbol registry 1914, and external multilevel memory cache 1920 are substantially identical to the structure and operation of the cache manager 1812, symbol registry 1814, and external multilevel memory cache 1820 of the ticker plant 1810, as described above in connection with FIG.

[0175] However, in the illustrated embodiment of Figure 19, the ticker plant 1910 is configured to maintain an order book in an external multilevel memory cache 1920 based on market responses 1934 transmitted over the network to participant devices (120 in Figure 1). In particular, the matching engine book (MEB) server 1930 may be any MEB server capable of performing the receiving of order entries 1932 and outputting various market responses 1934 to participant devices, including the MEB server 150 described above in connection with Figures 1-17.

[0176] As such, to maintain the current state of the order book in the external multilevel memory cache 1920, the fixed logic of the ticker plant 1910 can subscribe to and passively monitor market reactions 1934 to various trading events from the matching engine book 1930, including, but not limited to, confirmations of requests for open buy or sell orders, confirmations of requests to cancel orders, confirmations of requests to replace orders, or confirmations of requests to modify orders, and messages indicating that a particular order has been filled. Such market reactions 1934 can be received by the ticker plant 1910 over any type of external network, including public and private networks.

[0177] Using these messages, fixed logic in the ticker plant 1910 can request the cache manager 1912 to modify tiles in the external multilevel memory cache 1920 by adding, removing, or modifying tiles containing open order data (e.g., cell access nodes) representing open orders for a given symbol, side, and price tuple. In this manner, the cache manager 1912 of the ticker plant 1910 can maintain an up-to-date order book in the external multilevel memory cache 1920 that reflects the order book maintained by any matching engine book (MEB) server 1930. As discussed above in connection with FIG. 18 , logic in the ticker plant 1910 can request open order data or other market data from the cache manager 1912 in response to a market data feed request from a particular device for a particular symbol, side, and price.

[0178] It should be understood that the exemplary embodiments described above can be implemented in many different ways. Thus, the embodiments may typically be implemented in hardware, custom-designed semiconductor logic, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), firmware, software, or any combination thereof.

[0179] Furthermore, firmware, software, routines, or instructions may be described herein as performing particular actions and / or functions, however, it should be understood that such description contained herein is merely for convenience and that such operations actually result from a computing device, processor, controller, or other device executing the firmware, software, routines, instructions, etc.

[0180] It should also be understood that the block and network diagrams may contain more or fewer elements, may be arranged differently, or may be represented differently, but it should also be understood that in particular implementations, the block and network diagrams and the number of block and network diagrams may indicate that an implementation of an embodiment is being performed in a particular way.

[0181] Thus, while the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and detail can be made therein without departing from the scope of the invention as encompassed by the appended claims.

Claims

1. 1. A method for rearranging tiles in a multilevel memory cache, comprising: storing a first plurality of tiles in a first memory cache, the first plurality of tiles including open order data representing open orders for either buying or selling financial instruments at successive price levels within a defined price range, the successive price levels including a most aggressive price and a least aggressive price; storing a second plurality of tiles in a second memory cache, the second plurality of tiles including open order data representing open orders to either buy or sell the financial instrument at a price that is outside the defined price range; relocating tiles between the first memory cache and the second memory cache in response to changes in the open order data for one of buying or selling the financial instrument at the most aggressive price; A method comprising:

2. creating a new tile containing open order data representing at least one open order to either buy or sell said financial instrument at the new most aggressive price; determining whether the tile associated with the least aggressive price within the defined price range contains any open order data; in response to determining that the tile associated with the least aggressive price includes open order data, copying the tile associated with the least aggressive price from a first location in the first memory cache to a second location in the second memory cache; overwriting the first location of the first memory cache with the new tile associated with the new most aggressive price; 2. The method of claim 1, comprising:

3. overwriting the tile associated with the least aggressive price at the first location in the first memory cache with the new tile associated with the new most aggressive price in response to determining that the tile associated with the least aggressive price does not contain open order data; 3. The method of claim 2, further comprising:

4. determining whether the second plurality of tiles stored in the second memory cache includes a tile containing open order data for one of buying or selling the financial instrument at a less aggressive price adjacent to the least aggressive price in the defined price range; overwriting the tile associated with the most aggressive price in a first location of the first memory cache with the tile associated with the less aggressive price in a second location of the second memory cache; The method of claim 1 further comprising:

5. creating a new tile associated with a new least aggressive price for the defined price range in response to determining that the second plurality of tiles stored in the second memory cache does not include any tile associated with the less aggressive price; and overwriting the tile associated with the most aggressive price in a first location of the first memory cache with the new tile associated with the new least aggressive price; 5. The method of claim 4, further comprising:

6. the most aggressive price is one of a best bid price or a best ask price; 2. The method of claim 1 .

7. the least aggressive price is the price among the contiguous price levels within the defined price range that is furthest from one of the best bid price or the best ask price; 7. The method of claim 6.

8. 1. An electronic data access system for rearranging tiles in a multilevel memory cache, comprising: a cache manager coupled to a multilevel memory cache, the multilevel memory cache including a first memory cache and a second memory cache; wherein the first memory cache stores a first plurality of tiles including open order data representing open orders for one of buying or selling financial instruments at successive price levels falling within a defined price range, the successive price levels including a most aggressive price and a least aggressive price; the second memory cache storing a second plurality of tiles including open order data representing open orders to either buy or sell the financial instrument at a price that is outside the defined price range; Equipped with the cache manager is configured to reallocate tiles between the first memory cache and the second memory cache in response to changes in the open order data for one of buying or selling the financial instrument at the most aggressive price.

1. An electronic data access system comprising:

9. the cash manager is configured to create a new tile including open order data representing at least one open order for one of buying or selling the financial instrument at a new most aggressive price; the cache manager is configured to determine whether a tile associated with the least aggressive price within the defined price range contains any open order data; the cache manager is configured to, in response to determining that the tile associated with the least aggressive price includes open order data, copy the tile associated with the least aggressive price from a first location in the first memory cache to a second location in the second memory cache; the cache manager is configured to overwrite the first location of the first memory cache with the new tile associated with the new most aggressive price.

9. The electronic data system of claim 8.

10. and wherein the cache manager is configured, in response to determining that the tile associated with the least aggressive price does not contain open order data, to overwrite the tile associated with the least aggressive price in the first location of the first memory cache with the new tile associated with the new most aggressive price.

10. The electronic data system of claim 9.

11. the cache manager is configured to determine whether the second plurality of tiles stored in the second memory cache includes a tile containing open order data for one of buying or selling the financial instrument at a less aggressive price adjacent to the least aggressive price in the defined price range; the cache manager is configured to overwrite tiles associated with the most aggressive prices in a first location of the first memory cache with tiles associated with the less aggressive prices in a second location of the second memory cache.

9. The electronic data system of claim 8.

12. the cache manager is configured to, in response to determining that the second plurality of tiles stored in the second memory cache does not include any tiles associated with the less aggressive prices, create a new tile associated with a new least aggressive price for the defined price range; the cache manager is further configured to overwrite the tile associated with the most aggressive price in the first location of the first memory cache with the new tile associated with the new least aggressive price.

12. The electronic data system of claim 11.

13. the most aggressive price is one of a best bid price or a best ask price; 9. The electronic data system of claim 8.

14. the least aggressive price is the price among the contiguous price levels within the defined price range that is furthest from one of the best bid price or the best ask price; 14. The electronic data system of claim 13.

15. the cache manager is implemented using fixed logic, the fixed logic comprising one of a field programmable gate array (FPGA) and an application specific integrated circuit (ASIC); 9. The electronic data system of claim 8.

Images