本發(fā)明涉及通信技術領域，特別涉及一種系統(tǒng)性能測試方法和裝置。

背景技術：

隨著通信領域的研究開始從4G技術向5G技術過渡，以大規(guī)模多天線陣列、超密集小小區(qū)蜂窩組網以及大帶寬毫米波通信等為代表的一系列技術成為未來研究的重點。這些技術從天線數、用戶數、總帶寬和復雜度等維度將系統(tǒng)級仿真的總體運算量提升了1-3個數量級，進而為系統(tǒng)級仿真平臺的搭建工作帶來巨大挑戰(zhàn)。

作為對仿真總體運算量增加的應對措施，仿真加速技術也逐步成為未來構建系統(tǒng)級仿真平臺的必選技術。傳統(tǒng)仿真過程的總體運算量不大，采用加速技術的仿真平臺往往僅能節(jié)省數小時至數天的運算時間，卻要在硬件購置、代碼開發(fā)、測試校準以及平臺升級等方面花費更多時間和成本。

技術實現要素：

有鑒于此，本申請?zhí)峁┮环N系統(tǒng)性能測試方法和裝置，以解決性能測試速度低的問題。

為解決上述技術問題，本申請的技術方案是這樣實現的：

一種系統(tǒng)性能測試方法，該方法包括：

獲取所述m個接收設備和n個發(fā)送設備之間的m_×n條通信鏈路用于進行性能測試處理所需的數據；所述用于進行性能測試處理所需的數據包括：預設使用GPU進行的性能測試處理所需的數據和預設使用CPU進行的性能測試處理所需的數據；其中，m和n為大于0的整數；

通過CPU以接收束結構為單元將每條通信鏈路對應的預設使用GPU進行的 性能測試處理所需的數據，通過多流傳輸的方式分批傳輸給GPU；所述接收束結構包括1個接收設備和n個發(fā)送設備之間的n條通信鏈路；

通過GPU將接收到的各批次的以接收束結構為單元的數據劃分成為該接收束結構中的n條通信鏈路對應的n份數據，并針對所述n份數據并行進行性能測試處理；當針對任一批次的所有數據處理完成時，將針對該批次的所有數據的處理結果返回CPU；

通過CPU將GPU返回的任一批次的所有數據的處理結果，以及預設使用CPU進行的性能測試處理所需的數據進行性能測試處理。

由上面的技術方案可知，本申請中將系統(tǒng)性能的測試任務劃分為多發(fā)送設備到單接收設備的接收束結構，并利用GPU同時處理一個或多個接收束結構為單元的數據，以使針對一個接收束結構單元對應的數據被同時返回CPU，能夠使CPU針對該接收束結構單元對應的接收設備進行下一步相關性能處理。上述方法能夠加快系統(tǒng)性能測試的速度。

附圖說明

圖1為本申請實施例中模擬的通信系統(tǒng)示意圖；

圖2為針對RE1的接收束結構示意圖；

圖3為本申請實施例中系統(tǒng)性能測試流程示意圖；

圖4為本申請具體實施例中不同通信鏈路對應的數據進行并行處理的示意圖；

圖5為本申請實施例中針對一條通信鏈路中的子鏈路示意圖。

具體實施方式

為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，下面結合附圖并舉實施例，對本發(fā)明的技術方案進行詳細說明。

本申請具體實施例中提供一種系統(tǒng)性能的測試方法，用于進行系統(tǒng)性能測試的設備，如服務器，PC機等。

參見圖1，圖1為本申請實施例中模擬的通信系統(tǒng)示意圖。圖1中TE₁，TE₂，…，TE_n表示n個發(fā)送設備，RE₁，RE₂，…，RE_m表示m個接收設備，每個RE均可接收各TE發(fā)送的信號，每個TE均可向各RE發(fā)送信號，因此，RE和TE之間存在m×n個通信鏈路，以RE1為例，RE1到各TE的通信鏈路分別為：

該設備以接收束結構為單元劃分m個接收設備和n個發(fā)送設備之間的m×n條通信鏈路，所述接收束結構包括1個接收設備和n個發(fā)送設備之間的n條通信鏈路。在發(fā)送m×n條通信鏈路對應的用于性能測試的相關數據時，可以使用n個接收束結構單元發(fā)送。其中，m和n為大于0的整數。

仍以圖1中的RE1為例，參見圖2，圖2為承載RE1對應的通信鏈路的接收束結構的示意圖。使用圖2的結構發(fā)送RE1對應的通信鏈路對應的用于進行性能測試的數據時，包含了RE1對應的n條通信鏈路對應的數據，對于其他接收設備同樣使用圖2中的束狀結構，只是承載的數據不同而已。

本申請?zhí)峁┑南到y(tǒng)系能測試方法，可以應用于仿真系統(tǒng)的環(huán)境中，也可以應用于真實的系統(tǒng)環(huán)境中。

如果是真實的系統(tǒng)環(huán)境，直接獲取所述m個接收設備和n個發(fā)送設備之間的m×n條通信鏈路用于進行性能測試處理所需的數據；如果是仿真系統(tǒng)環(huán)境，則本申請具體實現時，先配置m個接收設備和n個發(fā)送設備，用于模擬實際應用中m個接收設備和n個發(fā)送設備的通信，再獲取所述m個接收設備和n個發(fā)送設備之間的m×n條通信鏈路用于進行性能測試處理所需的數據。

本申請具體實施例中針對一個系統(tǒng)的系統(tǒng)性能測試處理分成兩部分處理，預設使用圖形處理器(GPU)進行的性能測試處理由GPU實現完成，預設使用中央處理器(CPU)進行的性能測試處理由CPU實現完成。

因此，獲取的進行性能測試所需的數據包括：預設使用GPU進行的性能測試處理所需的數據和預設使用CPU進行的性能測試處理所需的數據。

在具體應用中，實施者可以將能夠進行大規(guī)模進行并行計算的性能測試處 理預設為使用GPU進行的性能測試處理，如計算信道大尺度衰落參數，計算信道小尺度衰落參數，計算接收機收到的某發(fā)射機信號強度，計算接收機的信干噪比(SINR)，計算接收機的誤包率或誤碼率等；其他性能測試，如邏輯處理相關的計算：處理系統(tǒng)的資源調度，處理系統(tǒng)的重傳過程，關閉或開啟某一發(fā)射機或接收機，接收機選擇主服務基站等，即不適合進行大規(guī)模并行計算的性能測試處理預設為使用CPU進行的性能測試處理。

下面結合附圖，詳細說明本申請具體實施例中如何實現系統(tǒng)性能測試。

參見圖3，圖3為本申請實施例中系統(tǒng)性能測試流程示意圖。具體步驟為：

步驟301，設備獲取所述m個接收設備和n個發(fā)送設備之間的m×n條通信鏈路用于進行性能測試處理所需的數據。

步驟302，該設備通過CPU以接收束結構為單元將每條通信鏈路對應的預設使用GPU進行的性能測試處理所需的數據，通過多流傳輸的方式分批傳輸給GPU。

所述接收束結構包括1個接收設備和n個發(fā)送設備之間的n條通信鏈路。

在Kepler架構下，CUDA提供了全新的動態(tài)并行和Hyper-Q技術，從而使CUDA程序能夠更加便利的實現多個GPU函數之間的并行。關于動態(tài)并行，簡單的講，傳統(tǒng)的CUDA程序只支持由CPU函數啟動GPU函數，而在Kepler架構顯卡下，動態(tài)并行技術允許一個GPU函數啟動另一個GPU函數，該技術減少了CPU和GPU之間不必要的信息交互，在簡化編程代碼復雜度的同時提升了程序的效率。

關于Hyper-Q，簡單的講，在使用流的形式在CPU和GPU之間拷貝數據時，傳統(tǒng)架構顯卡中不同流之間的數據要在硬件隊列中排隊，而Hyper-Q允許GPU能夠同時并發(fā)執(zhí)行最多32個活動的任務，并且增加了硬件隊列的數量，從而極大提升了數據拷貝效率和程序的運行速度。

因此實現本申請的具體實施例時，可以使用Kepler GPU，但是本申請對此并不做限制。

步驟302實現時，每個流傳輸的接收束結構單元的個數為預設值，所述預設 值根據GPU的性能確定。每批次傳輸的流的個數也由CPU個數、GPU個數，以及GPU性能確定。無論設備支持幾個CPU，幾個GPU，針對一個CPU和一個GPU之間流的傳輸，根據該GPU的性能確定。

步驟303，該設備通過GPU將接收到的各批次的以接收束結構為單元的數據劃分成為該接收束結構中的n條通信鏈路對應的n份數據，并針對所述n份數據并行進行性能測試處理；當針對任一批次的所有數據處理完成時，將針對該批次的所有數據的處理結果返回CPU。

GPU接收到1批次發(fā)送的流時，將該批次的流中的以接收束結構為單元的數據劃分為n份數據，每份數據相當于該接收束結構對應的接收設備與其中一個發(fā)送設備之間的通信鏈路對應的數據。

各CPU可以為同一CPU，也可以為不同CPU，GPU可以為同一GPU，也可以為不同GPU，本申請具體實施例中不限制CPU和GPU的個數。

如果是一個GPU，該GPU串行處理各批次流；如果多個GPU，各GPU分別串行執(zhí)行自身接收到的流。

以一個CPU向一個GPU發(fā)送一批次的流為例，參見圖4，圖4為本申請具體實施例中不同通信鏈路對應的數據進行并行處理的示意圖。圖4中該批次流發(fā)送了5個接收束結構單元，且n為10，即共10個發(fā)送設備，則劃分后的通信鏈路對應50份數據。針對這50份數據進行并行處理。

當這50份數據均處理結束時，將處理結果一同發(fā)送給CPU，繼續(xù)進行相關處理。

當通過GPU對任一通信鏈路上的數據進行預設使用GPU進行的性能測試處理包括DFT計算時，針對該通信鏈路上的數據啟動p×q×v個線程并行進行DFT計算，p為該通信鏈路對應的發(fā)送設備當前發(fā)送信號的天線的天線數，q為該通信鏈路對應的接收設備當前接收信號的天線的天線數，v為針對該通信鏈路上的信號的頻域的采樣點的個數。

該設備為當前發(fā)送設備上發(fā)送信號的天線分配序列號；為當前接收設備上接收信號的天線分配序列號；

當針對啟動的每個線程使用二維索引，針對每個DFT計算使用三維索引時，若線程索引為(Idx_x，Idx_y)，則該線程索引對應的DFT計算索引(N_AT，N_AR，N_k)；

其中，N_AT為發(fā)送設備的發(fā)送天線的序列號，N_AR為接收設備的接收天線的序列號，N_k為頻域采樣點的編號。

針對線程索引與DFT計算索引的對應關系，本申請還提出如下映射方式：

若線程索引為(Idx_x，Idx_y)，則該線程索引對應的DFT計算索引(N_AT，N_AR，N_k)；

其中，N_AT為發(fā)送設備的發(fā)送天線的序列號，N_AR為接收設備的接收天線的序列號，N_k為頻域采樣點的編號。

參見圖5，圖5為本申請實施例中針對一條通信鏈路中的子鏈路示意圖。圖5中，以RE1和TE2之間的通信鏈路為例，當前以RE1的3根天線和TE2上的2根天線為例，即p為2，q為3。

若線程索引為(0,0)，則由上述公式獲得DFT計算索引為(1,1,0)；如果線程索引為(5,10)，則由上述公式獲得DFT計算索引為(2,3,10)。

在DFT計算時，會根據信道模型生成某一子鏈路對應的信號的時域離散采樣點。這些時域離散采樣點通常需要利用DFT轉為頻域采樣值后才能繼續(xù)進行下一步處理。DFT的計算公式如下：

$X\left[k\right]=\underset{n=0}{\overset{N-1}{\mathrm{\Σ}}}x\left[n\right]e^{j2\mathrm{\π}\frac{k}{N}n}$

其中，x[n]是時域上的N個采樣點，X[k]為轉化后的頻域上的采樣值。根據歐拉公式，可以得到，

$e^{j2\mathrm{\π}\frac{k}{N}n}=\cos \left(2\mathrm{\π}\frac{k}{N}n\right)+j\sin \left(2\mathrm{\π}\frac{k}{N}n\right)$

由以上兩個公式可得：

$X\left[k\right]=\underset{n=0}{\overset{N-1}{\mathrm{\Σ}}}x\left[n\right](\cos \left(2\mathrm{\π}\frac{k}{N}n\right)+j\sin \left(2\mathrm{\π}\frac{k}{N}n\right))$

從該公式可以看出，無論是不同子徑上的X[k]，還是同一子徑上不同采樣點的X[k]，其計算過程都是彼此無關的，可以并行處理；因此，本申請的具體實施例中的上述劃分是完全合理、可行的。

線程是CUDA程序處理一個任務的最基本單元，CUDA程序通過啟用多個線程并行處理一個大任務中的不同部分，以實現加速效果。CUDA的線程通過Grid、Block和Thread三個級別來進行組織，每個線程都可以通過其所在的三級組織編號得到自己唯一的線程編號，該編號可以是一維、二維或三維的。CUDA加速的核心原理是將一個計算任務分解成若干個子任務，并根據線程編號設計每個線程和子任務的對應關系。程序執(zhí)行過程中會根據任務需要啟動合適數量的線程，這些線程根據其線程編號和預設對應關系去自動并行處理其所對應子任務，以達到加速效果。

因此，將任務分解并建立線程和分解后子任務的關系，是使用CUDA加速的核心問題。由于其不同子徑和不同采樣點的DFT公式形式均相同，每一采樣點的求取過程運算量不大且很難再進一步分解成可以并行執(zhí)行的子任務，因此非常適合采用線程級并行加速。

在進行DFT任務并行處理過程中，盡管CUDA支持對線程的三維編號，本部分依然將收發(fā)天線壓縮成一維，主要是考慮經過如此方式壓縮后，輸入輸出數據都可以比較方便的采用二維矩陣存儲，后繼處理也可以利用MKL、CuBLAS等矩陣運算工具，可以降低開發(fā)難度。

步驟304，該設備通過CPU將GPU返回的任一批次的所有數據的處理結果，以及預設使用CPU進行的性能測試處理所需的數據進行性能測試處理。

本申請?zhí)峁┑膶嵤├袑邮帐Y構單元對應的通信鏈路相關的數據分批次處理，能夠提高GPU的處理效率，并且進行多批次處理，也有利于將處理后的結果及時傳回CPU，從而使CPU在GPU處理下一批接收束時能夠 同步處理本次返回的結果。并且采用多流技術傳輸，即通過多個流的復用可以顯著節(jié)省程序中的數據拷貝時間。

綜上所述，本申請通過將系統(tǒng)性能的測試劃分為多發(fā)送設備到單接收設備的接收束結構，并利用GPU同時處理一個或多個接收束結構為單元的數據，以使針對一個接收束結構單元對應的數據被同時返回CPU，能夠使CPU針對該接收束結構單元對應的接收設備進行下一步相關性能處理。上述方法能夠在降低性能測試的復雜度的基礎上，加快系統(tǒng)性能測試的速度。

以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發(fā)明保護的范圍之內。