模擬系統按照自身的時間來處理其他進程運行時所收集和儲存的報價。進程手機的數據現在已經稱為歷史數據，進程記錄的報價頻率可以差別很大，這主要是因為以下兩個因素：

      1、原始進程為之收集報價的金融工具的個數。
      2、運行原始進程的計算機系統的速度。

       這兩個因素的影響源于報價過程的本質以及大多數交易系統的實現方式。大多數系統中都包含一個客戶端（報價收集和/或交易應用程序），該客戶端接收報價以及服務器（提供報價的經紀運營自營商應用程序）信息。客戶端常常是在“本地”運行的“本地”程序：即其運行的電腦硬件完全處于交易員的掌控之下。經紀自營商的服務器端幾乎都是遠程應用程序，這意味著客戶必須通過遠程連接，比如互聯網，才能與服務器進行通信。為了接受報價，客戶端程序常常需要與服務器程序之間建立如下的通信：

       1、客戶端向服務器發送一條或一系列包含以下內容的消息：

       a、客戶身份認證（由掌管服務器的經紀自營商提供給客戶的）
       b、請求報價的金融證券名稱
    

       2、服務器將會做出回應，確認客戶端的消息。服務器的回應還將說明是否因為某些原因不允許客戶端接收某些請求的報價。

        3、服務器開始把報價源源不斷的輸出給客戶端。報價流的輸出通常采取“不同步”的方式，也就是說，只要有新的可用報價，服務器就會將它們發送給客戶端。有些證券的報價頻率比其他的證券高一些。例如，在經濟信息發布前后的高波動階段，歐元/美元匯率報價頻率達到每秒30次也不算稀奇。然而與此同時，一些鮮為人知的股票可能在一個交易日只產出一次報價。因此在設計程序中接收報價的部分時，很重要的一點是記住報價的預期頻率。

        4、接下來經常會發生報價失真。所有報價一到客戶端計算機就進行收集和處理，這是客戶端的責任。此處有可能發生若干問題。在客服端的機器里，所有到來報價都會按它們的到達順序放到一個隊列里，最早的報價里處理器最近。我們可以將此隊列看做是機場辦理登記手續的隊列。然而，與機場隊列不同的是，此隊列的長度或者容量往往是有限的；因而任何報價到來時發現隊列已滿，此報價會被丟掉。這里就產生了第一個問題，當客戶端系統隊列長度不同，而其他所有系統特征完全一樣時，不同客戶端的報價時間序列可能會彼此不同。

       一旦報價已在隊列中，系統會從隊列中選取最早到達的報價進行處理；接著隊列中所有的報價會挪動，使之更靠近處理引擎。就像前面講的一樣，報價的到達速度可能要比客戶端的處理速度更快，這樣報價會填滿隊列，從而導致系統丟棄新到達的報價，直到舊的報價處理完畢。