philipz 發表於 13-3-19 16:08 static/image/common/back.gif
利用Timer來處理？是否會因不斷去計算時間而增加CPU使用量？
個人是利用收到一個TICK就去Trigger Event，沒 ...
請問P大您是不是指當收到一個TICK就把這TICK放進QUEUE中
再用另一個THREAD去處理
還是收到TICK 送出一個EVENT給處理的THREAD?
眼到手到哥 發表於 13-3-19 14:43 static/image/common/back.gif
我覺得~~ 處理K棒的thread可以用timer來處理, 比如說一秒鐘更新5次, 對人的眼睛來說已經快到跟不上了,
...
眼大
一秒五次對非快市來說很快
但是如果你有去比對用DDE或API收到的TICK
快市時可以快到一秒有100個TICK
我的系統測過如果DDE SERVER 一秒送2000 TICK
我用單THREAD 一樣可以應付的來
(前面有提到我是用NDDE SAMPLE SERVER 去不斷的送資料
這SERVER 我測的極限也只能到一秒2000 TICK
(也許是我沒調整好造成)
balance 發表於 13-3-19 17:33 static/image/common/back.gif
除了 order update, Tick 恐怕是trading platform 裡最基本要做的事，當然要給他最高優先權！
從一個完整 ...
b 大謝謝您分享
不過還是不是很清楚
您指的TRADING PLATFORM 是不是主控端
然後接收TICK 或是 BID/ASK 改變時送出
OnFundamentalData() - Called on any change in fundamental data
OnMarketData() - Called on any change in a level 1 market data stream
OnMarketDepth() - Called on any change in a level 2 market data stream
OnBarUpdate(）- Called when the price bar changes with incoming data <---- 1
EVENT然後主控端利用上面函式作處理
再來就是另一部份的收到ORDER 狀態改變的處理
不知我的認知有沒有錯
balance大說的那些，應該是Ninjatrader 這個平台的策略的事件觸發函數(或者稱interface)。
用c#，只要繼承了nt的策略的基礎類別，就可以再該事件發生的十後在自己的程式碼內處理。
b大要講的應該是說，您要自己設計平台，就應該要全盤的考量整個架構的。
最後， thread並不會讓效能增加，事實上thread是會讓效能降低的!! thread最大的優點是把事情變簡單，讓收資料的收資料、畫圖的畫圖、下單的下單。但是thread是有成本的這點要注意。
jinace 發表於 13-3-19 17:40 static/image/common/back.gif
1秒更新5次~也就是說0.2秒才更新一次~別的延遲不算就已經輸0.2秒了
0.2秒用肉眼觀察其實是很明顯可以分 ...
我想，眼大講的應該下單與策略運算應該是要優先點吧，至於是畫圖的部分就不需要配給太多的cpu。
以前我在報價軟體做過，那時代機器沒有很強，當歐元出消息的時後，每個tick都重繪會造成cpu 100%，後來解法是只更新最後兩跟k棒的畫面，那就再也沒遇到cpu100%了。
wldtw2008 發表於 13-3-19 20:45 static/image/common/back.gif
balance大說的那些，應該是Ninjatrader 這個平台的策略的事件觸發函數(或者稱interface)。
用c#，只要繼承 ...
W大
感謝您再提供說明
因為對THREADING不甚了解
經您說明就像我之前猜的MULTITHREADING可能會有效能減損
不過我應該還是會像各位建議的另外開一THREAD來處理下單部份
因為避免BLOCK住接收訊號
目前正在看MSDN有關THREADING的資料中
我提NT 的 event handling (詳情請見手冊 意思就是說，這個世界上已經很多‘smart phones' 或是 ’wheels', 而且 功能，設計遠超過樓主的。
雖然勇氣值得鼓勵，但是個人覺得有責任指出另一種思維。。。
光是用DDE這點就可以看出，還有很長的一段路要走。。W大已經很含蓄的說了方向。我只是指出事實： 這個世界上已經很多比iphone還好的 smartphones 了。。 應該看看怎麼最佳利用現有的工具，達到賺錢的目的！
wldtw2008 發表於 13-3-19 20:50 static/image/common/back.gif
我想，眼大講的應該下單與策略運算應該是要優先點吧，至於是畫圖的部分就不需要配給太多的cpu。
以前我 ...
喔~那是我會錯意了
繪圖其實也可以用異步的thread處理~再加上一些機制就可以有效提高cpu的使用效率
不過這部分要處理的漂亮確實很麻煩
jerrywang168 發表於 13-3-19 20:18 static/image/common/back.gif
眼大
一秒五次對非快市來說很快
一秒2000~~
很夠用了阿~~ 大概有萬口了吧!!!
一秒萬口~~哇...... 嘎死人了.....
很讚了~ 不需要再往這裡鑽研了~ 又不靠賣程式吃飯~~
{:4_627:}http://www.coco-in.net/static/image/smiley/onion_custom_emoticons/145.gifhttp://www.coco-in.net/static/image/smiley/onion_custom_emoticons/145.gifhttp://www.coco-in.net/static/image/smiley/onion_custom_emoticons/145.gif
balance 發表於 13-3-19 21:03 static/image/common/back.gif
我提NT 的 event handling (詳情請見手冊 意思就是說，這個世界上已經很多‘smart phones' 或是 ’wheels', ...
b大謝謝您指點
前面幾位大大也有說過MC NJ TS等等大多是給也許是高階或是一般大眾使用
中間增加了很多的功能
但是我目前的系統只是針對台指
台指有一些東西可以使用 這是無法用其他系統代替的
就像奇狐 也為了台指 修改原廠的東西
台指有委買賣可用 有預估量可參考 這些東西都可能增加獲利率
但是用那些東西都是給外國高手用的
小弟用不到那些NJ等高階的 功能
為什麼自製一方面就是需要這些東西
所以我用不到SMARTPHONE 但是我只要一般功能的手機只是有繁中介面就好了
因為我不用回測分析 我不用很強的下單功能 (事實上我的下單有特殊要求 針對台灣市場特性）
這些功能很簡單只是在處理時要加上一些特別分析
我知道我寫的系統和版上各位大大比一定差很多
更何況是國外的專業軟體
但我的目標是給我自己好用 夠用就OK了
還是非常謝謝各位的建議指教
當然策略是最重要的這點我相當明白
我的策略主要是能第一時間進場 還有停損
(最重要部份 因為我的停損點抓剛剛好 有程式處理 才夠快 其他系統+DDE只要有DELAY我都不太放心)
獲利出場可能要人工來處理(只要不貪 獲利就夠了)
再次感謝
眼到手到哥 發表於 13-3-19 22:07 static/image/common/back.gif
一秒2000~~
很夠用了阿~~ 大概有萬口了吧!!!
眼大 我知道夠用 但是實際測還是會被DDE來源給ＤＥＬＡＹ
所以才會想用多THREAD來處理下單
jinace 發表於 13-3-19 21:16 static/image/common/back.gif
喔~那是我會錯意了
繪圖其實也可以用異步的thread處理~再加上一些機制就可以有效提高cpu的使用效率
J大還是謝謝您了
我下載了一些C# THREADING 和繪圖 和Windows Form 的EBOOK
研究中
balance 發表於 13-3-19 21:03 static/image/common/back.gif
我提NT 的 event handling (詳情請見手冊 意思就是說，這個世界上已經很多‘smart phones' 或是 ’wheels', ...
補充一點
因為目前期貨商沒API報價
但是測試點金靈的DDE報價可以符合我策略需求
所以才用DDE
我還怕用API報價後我的策略不能用呢
(太多TICK影響策略)
再請教一件事
請問用THREAD來處理下單部份 會比另外寫一個專用下單程式用類似下單大師萬用DLL方式快嗎?
如果是用專用下單程式 請問下單大師兩個程式間用萬用DLL的方式大概可能是用什麼方式寫出來的 就是兩個程式怎樣溝通
謝謝
先試看看用下單大師 會不會下個月不能用再說
感謝各位寶貴意見