早上睡到很晚才醒，感覺我不太受天氣影響，因為冷氣早就已經停止運轉很久了，可能是昨天玩水消耗不少體力吧！一起來後就開始繼續前天未完成的實驗，試了幾個組合：Consumer Thread + Producer Thread、Consumer Thread + Producer Timer、Consumer Timer + Producer Thread以及Consumer Timer + Producer Timer，表現做好的是兩個都用Timer，但在分析原因時發現一個詭異的數據，將20萬筆浮點數寫入硬碟，即便用了網路上對於Java I/O Performace改善的方法，也還是需要300ms上下，也就是說之前我覺得5ms可以應付20萬浮點數寫入硬碟應該是假象，原因是兩個Timer都呼叫到同個(Main) Thread去處理資料產生跟寫入硬碟，講簡單點就是產生資料跟寫入硬碟是交替執行，其實沒趕上5ms的Deadline，記憶體沒爆掉也是同樣的原因，當兩個都是用Thread的時候就很明顯了，Producer明顯比Consumer快，記憶體大約2分鐘內就塞爆JVM預設的64MB上限。
這可就麻煩了，雖然說以目前WiMAX模擬全部子層加進去跑，大概一秒才有2~3個Frame，換算下來大概也是350ms才會有一大筆的模擬資料送回Console端，但目前的實驗結果表示，效能改善有一定的極限，20萬筆浮點數大約是2台MS加2台BS的資料調變後的訊號量，也就是說，即便效能改善完畢，能夠模擬的環境大概也就是2台BS加上2台MS左右，想也沒用，就馬上對Console程式碼進行改造，先把SPMT的程式碼大概看了一下，了解流程後，有點傻眼，有人程式這樣寫的嗎？同樣的邏輯同樣的程式，為了Thread和Timer寫了兩個版本，這就算了，還是用comment的方式決定使用哪個版本，實在是受不了，於是先幫他們改成runtime決定執行thread還是timer，至少不是用註解來決定...
經過小幅度的改造後，以33ms一次的頻率產生假資料，模擬可持續執行大約10分鐘還不會塞爆64MB的記憶體，比之前不到10秒就塞爆要好很多，但畫面更新率還是更不上去。看樣子，第一階段的效能改善成果還不錯，不過還得繼續實驗找出瓶頸所在才行，最起碼畫面看起來要平順才行！
留言列表
