討論區列表MultiCharts
第151篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-27 20:51:14
0
暱稱:PC
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   

這邊提醒一下兩家報價的架構差異

TC會做併筆資料,也就是同一時間有兩筆相同的資料,它會合併成一筆才送出,所以資料量會小一些,凱衛的不會,交易所送來什麼,它就送出什麼

另外是凱衛現在的元件會在本地做組合分K,效率較差

這部份,新報價才會在伺服器上處理後才丟出來,開盤問題也是要等新報價主機後才會去解決,目前只有內測,還沒有開放外測

======================================================================================================
客服一號老師您好:

聽起來好像要改併筆? 希望我看錯意思.
目前我有參考凱衛的一些量數據 (upticks downticks ticks)

如果要改併筆, 這些值是否能維持原來的意義? 或者至少能讓使用者選擇不要併筆?

如果貿然改成併筆, 恐怕我的程式會有問題, 凱衛應該不會硬改硬要客戶接受吧?

或者應該分成兩種商品, 原先的 TXF1 維持不動, 另外新增商品有併筆, 讓想用的跟不想用的各取所需?

 

我個人寧可都不改變, 也不要為了速度改變了upticks downticks 的算法.

(upticks downticks 是在本地端自己算的, 改版併筆表示每次的 ticks 量不同, upticks downticks 就不太可能會一樣)

感謝您

 

 

 

 


第152篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 00:02:22
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
 
--------------------------------------------------
TC會做併筆資料,也就是同一時間有兩筆相同的資料,它會合併成一筆才送出,所以資料量會小一些,凱衛的不會,交易所送來什麼,它就送出什麼
另外是凱衛現在的元件會在本地做組合分K,效率較差
這部份,新報價才會在伺服器上處理後才丟出來,開盤問題也是要等新報價主機後才會去解決,目前只有內測,還沒有開放外測
 
併筆的好處是資料量變少,有利快市
不併筆,也就是真實tick的好處是資料完整性,例如 tick K 口數K 等K棒會比較正確
--------------------------------------------------
(以上引用自一號大的第150篇,回應如下:)
 
還真可能是這個【併筆資料】的差異
我剛比較了一下今天5/27(五)KWay與TC在09:24:05與09:24:06這兩秒的Tick數
看到非常顯著的Tick數量差異,差距達10倍之多
09:24:05 -> [KWay Tick數] = 136;[TC Tick數] = 13
09:24:06 -> [KWay Tick數] = 236;[TC Tick數] = 16
 
 
 
 
 
--------------------------------------------------
就算是不同家,延遲差異也並沒有很大
--------------------------------------------------
(以上引用自一號大的第150篇,回應如下:)
 
快市時延遲差距高達400多毫秒,其實差距就算很大了
而且昨天(5/26 四)與今天(5/27 五)的盤勢比較溫吞
前天(5/25 三)的盤勢就有出現非常明顯得快市盤
可惜的是前天Touchance(TC)的Tick沒法錄(當天TC的外掛還不相容MC9.0,不過一通電話過去,下午就相容了[先給我Patch檔],這才叫效率)
當天KWay延遲高達3秒,但因為TC沒參與到,所以沒法驗證是否TC當天的延遲也如此巨大
不過沒關係,PK賽至少會持續到下星期五(6/3)
究竟不同家的延遲差異有沒有很大,就讓我們持續追蹤下去
 
以下為5/25(三)凱衛的非常快市情形
 
【快市秒Tick價量圖】
 
 
【快市凱衛延遲特寫】
 
由上圖的【快市秒Tick價量圖】內可看到綠色區塊標示起來的快市區
前四根秒K棒,一根一秒總共四秒鐘
由第一根開盤價8367跌到第四根收盤價8333,共跌掉34點,而這才花四秒鐘的時間
再由上圖的【快市凱衛延遲特寫】內可以看到此時KWay的延遲時間達到3秒多
這個報價延遲可能導致的滑價,應該不難想像得到,絕對會很有感
 
 
 
 
 
--------------------------------------------------
這部份,新報價才會在伺服器上處理後才丟出來,開盤問題也是要等新報價主機後才會去解決,目前只有內測,還沒有開放外測
--------------------------------------------------
(以上引用自一號大的第150篇,回應如下:)
 
其實自去年的9/4凱衛就已經再測新報價主機了(請參考第52篇與57篇)
不過可能凱衛有其他更重要的事要先處理,所以隔了九個月後.....
 

第153篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 00:06:54
0
暱稱:J.I.
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(5)
   

我也反對報價改為併筆

這不是進步,而是倒退的做法

沒記錯的話,國外付費的報價商都是tick by tick

若報價改為併筆這對歷史資料的品質會造成很大的影響

需要用到tick資料做交易的人影響也很大

凱衛若要改善報價速度應該從其它方面改善

而不是改為併筆這種報價品質倒退的做法

我個人對目前凱衛的報價速度是滿意的

對我而言報價資料的準確性比報價快幾ms來的重要

但每個人的需求不同

請凱衛也考量需要tick by tick報價的使用者

 


第154篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 08:13:36
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
首先,我們先客觀的來持續觀察兩家資訊源在快市時的延遲差異有沒有很大
這是我們首要要確認的事實
等確認事實後,再來討論凱衛會怎麼調整
就算凱衛要調整,肯定也不會是一天兩天(根據經驗,幾個月的時間,甚至幾年都是可能的)
所以就讓PK賽的數據來說話
我們就耐心的看下去吧,不急著下結論,讓選手跑完全場(PK賽至少還有5場,目前只到Round Two)
 
 
國外報價商如eSignal採用tick by tick的報價
對於美國S&P期貨,每天的交易量遠遠超過台指期
也不會產生這種以秒來計算的延遲吧(請參閱本文第115篇與152篇的實測貼圖)
當然這需要經驗與技術
 
 
既然提到了【併筆資料】
等一下我也來驗證一下歷史回測的績效,看是否KWay與TC的資訊源會造成明顯的報酬率出入
(註:我個人是沒用到Tick的資訊在交易,最小K棒周期也只用到1分鐘)
 

第155篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 08:21:13
0
暱稱:客服一號
信箱:folkchen.sp2@gmail.com
成就:發文(0) / 回文(0) / 推薦(96)
   

我上面寫的是 TC 用的是併筆法

並不是說 KWAY 要改用併筆法,KWAY新價主要改進的是server組K棒功能(減少本地端的loading),以後就不會有台灣K或國際K,只有一種K了

 

至於你說的快市延遲到好幾秒的問題

因為真實tick的問題,就會造成網路傳輸量的爆增

本地的處理量也會爆增,主要要看右下角有沒有紅色出現 x q/x s 的訊息

有的話,問題不在網路,而是本身的CPU來不及消化網路塞進來的資訊

圖表愈多本地處理量就會成倍的增加

併筆的好處就是它可以讓處理量減少,因此TC在快市時是有優勢的,這一點沒有錯

但我自已的STOP單比例並不高,所以我自已是覺得KWAY的報價還OK

滑價的情況並不高,在可接受的範圍內

我自已也是實單在交易的,所以並不是在幫KWAY說話

目前KWAY最大的問題在於開盤延遲那個問題,其他的,我覺得是還可以接受的,相對於其他報價而言

 

 
編輯文章 by 客服一號 2016-05-28 08:40:50

第156篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 10:53:32
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
--------------------------------------------------
至於你說的快市延遲到好幾秒的問題
因為真實tick的問題,就會造成網路傳輸量的爆增
本地的處理量也會爆增,主要要看右下角有沒有紅色出現 x q/x s 的訊息
有的話,問題不在網路,而是本身的CPU來不及消化網路塞進來的資訊
--------------------------------------------------
(以上引用自一號大的第155篇,回應如下:)
 
之前我有連續一兩個星期觀察過每天8:45到9:30的MC右下角是否出現【紅色的 xx q/xx s】
此時段Tick量最大,但觀察結果都沒出現過半次【紅色的 xx q/xx s】訊息
 
5/25(三)當天我是沒有守在電腦前面持續觀看右下角是否有出現【紅色的 xx q/xx s】訊息
所以此點我沒有眼見為憑,無法確定
 
至於CPU,我使用的是Xeon E3 1231 v3 (四核心HT時脈3.4G,超頻到3.8G)
5/25(三)當天該時段的CPU使用率如下圖【效能監視器】所示
可以看到整體最大CPU使用率最高值為36%
以個別核心來看,第4例項該時段CPU使用率最高值為67%
所以任何核心的最高使用率都低於70%
 
【效能監視器】
 
 
至於網路傳輸量是否暴增
請看下圖【網路流量報表】
其中,第五個欄位為輸入頻寬(bps),此欄位會統計五分鐘內輸入方向的最大頻寬使用程度
5/25(三)當天09:20:00~09:40:00這20分鐘內,輸入方向的最大頻寬使用程度為44.15 KByte(似乎不大)
 
註:我的電腦放置於亞太的IDC機房
 
 
【網路流量報表】
 
 
 
 
 
 
 
 
 
--------------------------------------------------
我自已也是實單在交易的,所以並不是在幫KWAY說話
--------------------------------------------------
(以上引用自一號大的第155篇,回應如下:)
 
這點我們都見識過,客服一號大與阿政大在判斷問題與分析問題都是本著客觀性的、實事求是(所以你們是很受尊重的,說的話也具分量)
所以就讓我們繼續看下去,讓PK賽的數據來說話
此次PK賽KWay與TC都跑在同一台電腦的同一個MC9.0軟體裡面,自然網路機房線路更是相同
接下來的賽事,就讓我們繼續看下去吧
 
編輯文章 by 萬年船 2016-05-28 10:54:18

第157篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 12:08:37
0
暱稱:PC
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   

併筆或是改成主機先組好K棒再傳, 我想客戶都會有一個疑問, 數據部分跟以前的意義相同嗎?

如果相同又能改進反應速度, 客戶應該不會想反對, 雖然我仍是希望以試用的方式先看改了與原先是否有差再換

不過這可以先打住

 

以下是我自己的推想, 如果沒興趣請跳過

=======================================================

以前對量的計算是, 丟一次單量, 然後本地端去計算累積的 ticks, upticks, downticks 變成多少

如果核心(ticks upticks downticks 的累積與計算)不能改, 也就是一次 ticks 只能歸屬成 upticks or downticks or 都不是

那麼對非 IOG 圖表, 主機端只要在知道本地端圖表週期後, 在 K棒 結束時丟三個 ticks, 分別是給 upticks downticks 跟剩下的量, 任務就達成了.

(丟三次是舉例, 因為丟一次無法同時更新 upticks downticks 跟 成交量, 成交量 大於等於 upticks+downticks, 丟之前要預估公式運算成 "同樣結果" 才行, 漏丟 tick 要補丟這個問題應該不用擔心, 測試中會碰到)

 

但對 IOG

不管什麼方法計算出量 (主機端送 K棒中當時的累積量 或是 單量在客戶端計算)

一定是有一次 tick 就要送一次數字, 也就是沒有減少傳送次數

那...這樣應該一樣會 lag .... 吧...
不知道改成主機算量要怎麼改善 IOG 的 lag?

 

我不是凱衛的工程師, 只是猜猜, 沒有惡意.
覺得離題或是錯誤, 也可以忽略...感謝觀賞

 


第158篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 13:58:31
0
暱稱:客服一號
信箱:folkchen.sp2@gmail.com
成就:發文(0) / 回文(0) / 推薦(96)
   

在另一篇中我有提過 CPU使用%不一定是資料會不會塞車的依據,最主要原因是在 排序處理這件事,排序資料不能拆到不同執行緒或核心去處理

一個資料沒處理完就不能處理下一個,就是CPU有空閒也一樣,除非是不同圖表才能分流

在同一個圖表中的資料,不能分不能拆,只能排隊,而且CPU不是只有MC會去佔用,還有其他系統會佔用

雖然 windows 會去重新配置,但也不是馬上就能重配,NB的CPU反應會更慢,它要另外拉高時脈

所以我自已的PC,我是把CPU設成,永遠運作在最高時脈,不然windows會在CPU不忙時去降速、省電、降溫

需要時才去拉高CPU效能,在快市時,反應就會慢一點點,這些都是屬於windows方面的調校,跟MC無關

 

資料量也一樣,複製一個大檔,跟複制一個小檔,就算是容量一樣,但是速度也會不一樣

並不是資料量少就會比較快

資料量少,但筆數很多時,它要花更多時間去拆解封包

就像小汽車與大客車的概念一樣,一樣的人數,但是效率是不一樣的

其實這也可以去調校啦,只是我沒去調而已

 

至於新報價的部份,那是對分K以上會有明顯幫助,對tick級的幫助很有限,但還是多少可以減輕本地的報價元件的負擔

 

編輯文章 by 客服一號 2016-05-28 13:59:34

第159篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 14:25:31
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
To 一號大,
 
這些都可以理解,沒問題
 
 
註:這台PK賽用電腦的CPU也是設成永遠跑在最高時脈(超頻)
 
PK賽的場地(電腦),如網路、硬體都算是高規格的了
且整個場地(電腦)僅供兩位選手使用(當然還有我線上交易的策略也在裡面跑)
最重要的是,PK賽的場地是兩位選手共用的,所以公平應該是沒問題的
 
 
編輯文章 by 萬年船 2016-05-28 14:27:39

第160篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 15:42:34
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
剛驗證一下TC的【併筆資料】後的歷史回測的績效是否與KWay的【Tick by Tick】有顯著出入
 
驗證方式直接比較投資組合的績效
看【獲利百分比】、【獲利因子】、【交易次數】、【勝率】是否產生顯著變化
分別由【年周期分析】與【月周期分析】檢驗
結果如下圖所示
獲利百分比我遮住了(個人隱私)
以年周期來看TC的獲利百分比還比KWay高一個百分點
但這沒意義,是隨機的
就好像我同月份的線上交易與同月份的歷史回測也常常有一個百分點的出入
 
雖然兩方的數字不會完全一樣,但整體看下來,結果並無顯著差異(在這部分,我不採用完美主義)
所以TC【併筆資料】後分K棒對我沒影響
 
註:我個人是沒用到Tick的資訊在交易,最小K棒周期也只用到1分鐘
 
 


第161篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-28 17:58:27
0
暱稱:PC
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   

我猜如果不看 upticks/downticks, 併筆與否 兩者的 績效是差不多的

如果原先有三筆單 ABC 被併成 D, ABCD 可能價位非常接近, 所以績效差別不大.

 

我圖表不是開 tick, 也非都是開 IOG

只因用到 upticks/downticks, 其計算是用 tick 累計, 需要收到每個 tick.

行為跟開 tick 圖表交易差不多.

大概是這樣吧.. 我的 case 可能還是會 lag.. 

 

謝謝指教

 

 

 

 

 


第162篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-30 19:48:20
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
KWay VS TC的PK賽【2015-05-30 (一)】
 
本報價延遲檢測使用:MonitorQuote_v1.5.zip
 
先複習一下百分位數
百分位數可以看出Tick的整體延遲程度
計算方式是把所有Tick延遲或沒延遲的值由小排到大
位置由前面數過來第百分之x的延遲值即為百分位數,表示為P(x) = Y,舉例來說:
如果P(99) = 2000 (毫秒),則99% Tick延遲會在2000毫秒以內,換句話說,1% Tick延遲會超過2000毫秒
如果P(95) = 1000,則95% Tick延遲會在1000毫秒以內,換句話說,5% Tick延遲會超過1000毫秒
以此類推。
 
在MC9.0,KWay開盤會延遲好幾10秒,但Touchance於開盤瞬間準時進來第一個Tick
但為了讓兩方能有相同的比較基準,兩方同時捨棄8:45分的資料
 
【百分位數比較】
 
 
【快市特寫比較】
(快市秒Tick價量;一秒內Tick數暴增時)
(快市PK特寫)
 
 
【全時段延遲比較】
 
 
 
 

第163篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-30 21:01:04
0
暱稱:曾永政
信箱:s.y.c.tseng@gmail.com
成就:發文(0) / 回文(0) / 推薦(8)
   

剛巧我今天就有策略訊號發生在 萬年船 大特寫密集 tick 的時間

順便看一下我在這個時間點的成交狀況...

https://dl.dropboxusercontent.com/u/33732676/%E5%A0%B1%E5%83%B9%E6%BA%90%E5%BF%AB%E5%B8%82%E6%AF%94%E8%BC%83/2016-05-30.png


第164篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-30 21:38:13
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
幫阿政註解一下:
ICE.TWF.FITX.HOT是TC的台指期連續月
TXF1當然就是KWay的台指期連續月
 
另外,這說明了滑價就是這麼產生,太經典了(還好今天我沒成交在那個密集區)
 

第165篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-31 12:00:00
0
暱稱:flight99
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(0)
   

剛才詢問了TOUCHANCE,報價一年18000,但64位元的mc,只支援報價,不支援下單。所以,如果堅持要跑64位元的mc,可能得搭配下單大師使用。認真考慮中。


第166篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-31 12:58:23
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
向Touchance配合的期貨商購買,一年只要15,000,一季只要4,500
 
我是準備用下單大師,正在測試中(也支援自動轉倉)
目的是不想再被資訊源廠商綁死了(用KWay或TC的下單機,就得綁他們各自的資訊源,因為停止單洗價的關係)
哪一天KWay的資訊源變比較好,我就用KWay資訊源
哪一天TC的資訊源變比較好,我就用TC資訊源
沒有哪一家資訊源永遠是最好的,隨時可切換是最好的策略
 
編輯文章 by 萬年船 2016-05-31 13:10:00

第167篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-31 13:15:05
0
暱稱:PC
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   

最近跟工程師聊過

大致上我對於一些認知與猜測是不太離譜的

 

如果不看量, 如果凱衛不介意開新商品, 如果客戶不介意用新商品

短時間新增一個量不正確的商品, 主機併筆處理, 定時丟單就像 DDE, 對凱衛一點都不難

(我覺得主機要看每個圖表週期多少才丟單這種作法才難, 到時候會常聽說主機沒力晚丟單)

回測就用 TXF1 就可以了, 權宜之計, 看能不能接受, 我只是從技術上面給意見.

 

只是我必須看量, 一定要連量都正確, 適當的併筆定時丟出應該不會影響到我, 因為我也沒看到 tick 那麼細.

100ms 觸發一次只要當時的價量都正確, 可能我就沒問題了. 我還得到一個不用等 next tick 就能收 close 的作用.

(每秒過後時間內沒更新的tick, 主機就丟一次沒量的資料來 close bar)

交易清淡時常常要晚個幾秒才會收K棒.. 這種也被當成 lag.. 但其實是 MC 自己的問題, "收K棒要等下一個tick"

 

真的要看到 tick 連五檔十檔報價都很在意的, 我想別家可能也無法即時提供這些資訊? 可能我要研究一下海期的資料量再說.

有沒有在別家處理 tick 很滿意但凱衛處理很慢的也可以比較看看, 也許可以知道為何別人不併筆速度很快而 MC 做不到?
 

如果 tick 圖就能沒問題, 其他圖應該也不會有問題, 不用搞一些有的沒的 併筆 或 新報價方式. 對, 現在是達不到.

我不知道換更多核心更快速度的電腦是不是也有幫助? 剛寫信去問等答案..

如果有幫助, 也許花個十萬準備一台 E5 12核16核 的我也覺得OK, 沒幫助我就一毛錢也不想花..

 

跟工程師聊聊技術, 也是不錯的, 起碼時間不是浪費在處理人性上面.
 

 


第168篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-05-31 21:07:16
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
KWay VS TC的PK賽【2015-05-31 (二)】
 
本報價延遲檢測使用:MonitorQuote_v1.5.zip
 
先複習一下百分位數
百分位數可以看出Tick的整體延遲程度
計算方式是把所有Tick延遲或沒延遲的值由小排到大
位置由前面數過來第百分之x的延遲值即為百分位數,表示為P(x) = Y,舉例來說:
如果P(99) = 2000 (毫秒),則99% Tick延遲會在2000毫秒以內,換句話說,1% Tick延遲會超過2000毫秒
如果P(95) = 1000,則95% Tick延遲會在1000毫秒以內,換句話說,5% Tick延遲會超過1000毫秒
以此類推。
 
在MC9.0,KWay開盤會延遲好幾10秒,但Touchance於開盤瞬間準時進來第一個Tick
但為了讓兩方能有相同的比較基準,兩方同時捨棄8:45分的資料
 
【百分位數比較】
 
 
【快市特寫比較】
(快市秒Tick價量;一秒內Tick數暴增時)
(快市PK特寫)
 
 
【全時段延遲比較】
 
 
 
編輯文章 by 萬年船 2016-05-31 21:08:18

第169篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-01 20:25:58
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
KWay VS TC的PK賽【2015-06-01 (三)】
 
本報價延遲檢測使用:MonitorQuote_v1.5.zip
 
先複習一下百分位數
百分位數可以看出Tick的整體延遲程度
計算方式是把所有Tick延遲或沒延遲的值由小排到大
位置由前面數過來第百分之x的延遲值即為百分位數,表示為P(x) = Y,舉例來說:
如果P(99) = 2000 (毫秒),則99% Tick延遲會在2000毫秒以內,換句話說,1% Tick延遲會超過2000毫秒
如果P(95) = 1000,則95% Tick延遲會在1000毫秒以內,換句話說,5% Tick延遲會超過1000毫秒
以此類推。
 
在MC9.0,KWay開盤會延遲好幾10秒,但Touchance於開盤瞬間準時進來第一個Tick
但為了讓兩方能有相同的比較基準,兩方同時捨棄8:45分的資料
 
【百分位數比較】
 
 
【快市特寫比較】
(快市秒Tick價量;一秒內Tick數暴增時)
(快市PK特寫)
 
 
【全時段延遲比較】

第170篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-02 13:41:32
0
暱稱:客服一號
信箱:folkchen.sp2@gmail.com
成就:發文(0) / 回文(0) / 推薦(96)
   
今天在艾揚那裡開會,剛好也討論到這個併筆資料的問題
所以在此做個整理與報告
 
艾揚的報價是併筆架構,但又不是無損式的併筆,因為無損式的併筆效益不大
為了提高效率,所以資料是有損的,也因此會有缺漏資料的情況
盤中即時模式式,有可能缺漏tick資料
但是按下回補後,可以回補到完整資料
所以若是按了回補,有可能造成盤中與盤後的訊號不一致的情況
 
優點:快市STOP時,滑價少
缺點;缺資料,訊號飄移
 
至於它的併筆規則是什麼,答案是沒有規則  XD
它是看CPU的使用率,使用率高時,就會減少tick數做併筆
至於CPU使用率的認定是什麼,我就沒有問到那麼細了
 
所以,不同的電腦併筆的結果可能會不一樣
像阿政說他比對TC與KWAY的tick量,TC大約是KWAY的70多%左右
但是不同的人去測,可能趴數會不一樣
 
就算是同一台電腦,圖表開的多或開的少,也會去影響到併筆的數量
 
兩家的差異大概就這樣了,各家廠商有自已的特色
有需要的再自行選用吧
畢竟每個人的系統的需求是不同的
選擇適合自已的就可以了
 
除了 KWAY(凱衛) 及 ICE(艾揚),還有 esignal  及  DDE 等 其他報價方式
大家自已試看看那一家的報價比較好吧
 
 
編輯文章 by 客服一號 2016-06-02 14:13:22

第171篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-02 15:55:14
0
暱稱:vincez
信箱:royce1219@gmail.com
成就:發文(0) / 回文(0) / 推薦(1)
   

基本上艾揚這樣的方式已經不叫併筆了,算是類似 polling 的方式

要求資料的正確性的話,可能還不如接 DDE,至少大部份券商的 DDE 還有 total ticks 可以去算跟上一次的 diff 為多少

 

而盤後回補資料和盤中收到的不同,其實對程式交易就是一個很不友善的問題

像期交所的 rpt 檔,有去分析過的人就會發現他刻意隱藏了某些資訊 (對 tick data 來說),所以也沒什麼價值....當然看分K以上的感覺不到

 

其實要作到資料無損的合併又不用像 kway 這麼誇張的 lag 並不難,就看廠商的 server 和行情報價原件有沒有能力最佳化

 

另外 to 萬年船兄: 建議有空可以做個測試是比較把 kway 的"下單機" 停用(不能出現在工作列) 或 uninstall 前後的差異....

 

 

編輯文章 by isntrue 2016-06-02 15:56:02

第172篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-02 20:19:54
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
--------------------------------------------------
另外 to 萬年船兄: 建議有空可以做個測試是比較把 kway 的"下單機" 停用(不能出現在工作列) 或 uninstall 前後的差異....
--------------------------------------------------
(以上引用自isntrue大的第170篇,回應如下:)
 
我的測試工作快告一段落(剩下的測試工作,就交給你們了,我準備把KWay變成備援數據源,讓TC成為主要數據源)
有興趣的話,可自行下載報價檢測程式測測看吧:MonitorQuote_v1.5.zip
 
 
 
 
 
感謝一號大提供更多的資訊,讓我們來好好檢視TC可能存在的淺在問題
 
--------------------------------------------------
但是按下回補後,可以回補到完整資料
所以若是按了回補,有可能造成盤中與盤後的訊號不一致的情況
--------------------------------------------------
(以上引用自一號大的第170篇,回應如下:)
 
其實我去年接eSignal的時候
盤中即時收到的tick與盤後回補的也不一樣阿
原因是連上的主機不一樣(eSignal官方的說法是,每台主機各自儲存自己的tick,否則同步的話,loading是很重的)
如果凱衛各自的報價主機儲存各自的tick的話,盤後回補也是會不一樣的
 
其實,我是沒再回補資料的,除非當天電腦當掉
因為市場大部分是隨機的,而在這隨機當中又透露著一絲規律
所以隨機之中夾雜著不顯著的雜訊,其實不影響那些規律
 
 
 
--------------------------------------------------
所以,不同的電腦併筆的結果可能會不一樣
像阿政說他比對TC與KWAY的tick量,TC大約是KWAY的70多%左右
但是不同的人去測,可能趴數會不一樣
 
就算是同一台電腦,圖表開的多或開的少,也會去影響到併筆的數量
--------------------------------------------------
(以上引用自一號大的第170篇,回應如下:)
 
 
--------------------------------------------------
至於它的併筆規則是什麼,答案是沒有規則  XD
它是看CPU的使用率,使用率高時,就會減少tick數做併筆
至於CPU使用率的認定是什麼,我就沒有問到那麼細了
--------------------------------------------------
(以上引用自一號大的第170篇,回應如下:)
 
 
對於以下這兩個問題
(1)開太多圖表是否會影響TC併筆的數量
(2)TC併筆是否有一套有效率的規則
我想我們直接看真實的圖,比較看KWay的30秒K棒TC的30秒K棒是否有顯著的出入
註:因為大部分人其實沒直接使用到Tick交易,所以檢視到30秒的K棒其實已經很足夠了
 
 
下圖為今日的30秒K棒,既然是秒K棒,則是由Tick所組成
(今日並無回補資料,所有KWay與TC的Tick資料都是盤中即時錄製的)
我們分別來看以下兩種情況,兩家的K棒差異有多少呢
[1]Ticks比較多的時候(此時處於相對快市;CPU使用率最高)
[2]Ticks比較少的時候(此時處於相對慢市;CPU使用率最低)
 
如果大家覺得差異不顯著的話,那麼以下兩種說法就會成立:
(1)今天我共開了10個圖表(兩個是檢測用的Tick圖),開10個圖表顯然也沒影響TC併筆的數量
(2)TC併筆確實使用一套有效率的規則(有沒有可能是商業機密,人家不想多談,隨便說沒啥規則)
不顯著的K棒雜訊,快市時的不利滑價損失,何者更為重要,就看個人了
 
 
 
 
[1]Ticks比較多的時候(此時處於相對快市;CPU使用率最高)
 
 
 
 
 
[2]Ticks比較少的時候(此時處於相對慢市;CPU使用率最低)
 
編輯文章 by 萬年船 2016-06-02 20:30:37

第173篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-02 21:07:30
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
KWay VS TC的PK賽【2015-06-02 (四)】
 
本報價延遲檢測使用:MonitorQuote_v1.5.zip
 
 
先複習一下百分位數
百分位數可以看出Tick的整體延遲程度
計算方式是把所有Tick延遲或沒延遲的值由小排到大
位置由前面數過來第百分之x的延遲值即為百分位數,表示為P(x) = Y,舉例來說:
如果P(99) = 2000 (毫秒),則99% Tick延遲會在2000毫秒以內,換句話說,1% Tick延遲會超過2000毫秒
如果P(95) = 1000,則95% Tick延遲會在1000毫秒以內,換句話說,5% Tick延遲會超過1000毫秒
以此類推。
 
在MC9.0,KWay開盤會延遲好幾10秒,但Touchance於開盤瞬間準時進來第一個Tick
但為了讓兩方能有相同的比較基準,兩方同時捨棄8:45分的資料
 
註:因為今天8:53分以前的8~9分鐘電腦出現了緊急狀況,所以少開盤後的8~9分鐘的Tick資料
 
【百分位數比較】
 
 
【快市特寫比較】
(快市秒Tick價量;一秒內Tick數暴增時)
(快市PK特寫)
 
 
【全時段延遲比較】

第174篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-03 09:57:40
0
暱稱:flight99
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(0)
   

錄了一小段凱衛與touchance同時傳輸的報價畫面。參考看看囉

 

https://youtu.be/ADZG5BmkLtY

 


第175篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-04 12:22:27
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
KWay VS TC的PK賽已經於2016-06-02(四)全部結束
總共PK了六個交易日:2016-05-26(四) ~ 2016-06-02(四)
有了這六個交易日的PK賽數據後,該是時候對這兩位選手的整體效能做個總評了
 
【KWay VS TC的PK賽總評】
 
KWay選手:
  優點
    (1)Ticks較為完整 (tick by tick,當使用幾個tick來組一根K棒時,完整性較好)
    (2)盤後重新回補的Tick與盤中即時收到的Tick差異不大
    (3)盤後重新回補的分K棒與盤中即時收到的分K棒幾乎無異
    (4)提供10年的歷史資料
    (5)若搭配使用該家的交易接口,可配合的期貨商較多,且可設自動轉倉
    (6)慢盤時,報價較即時(tick by tick,左手收進來,右手立刻送出去)
  缺點
    (1)快市時(每秒兩百個ticks)測到的延遲巨大,數秒鐘的報價延遲,此時下單必然產生不利滑價
    (2)MC9.0 開盤時,會延遲好幾10秒才產生K棒,此時下單會受到嚴重延遲
    (3)價格較貴,數據源一年20,000元台幣
 
TC選手:
  優點
    (1)六個交易日(含快市時)測到的最高延遲也只有0.314秒(314毫秒),快市時測到的延遲更小,比較不會產生不利滑價
    (2)盤後重新回補的分K棒與盤中即時收到的分K棒幾乎無異
    (3)MC 9.0開盤時,能瞬間準時進來第一筆Tick,此時下單不受延遲影響
    (4)價格較便宜,數據源一年18,000元台幣
  缺點
    (1)Ticks較不完整 (併筆資料,但幾乎無損30秒K棒,更是絲毫無傷分K棒的完整性,但不適合以幾個tick來組一根K棒交易)
    (2)盤後重新回補的Tick會跟盤中即時收到的Tick差異較大
    (3)僅提供6個月的歷史資料
    (4)若搭配使用該家的交易接口,可配合的期貨商較少,且不能設自動轉倉
    (5)慢盤時,報價會略慢幾個毫秒數(併筆資料,不會左手收進來,右手立刻送出去,而是會等幾個適當的毫秒後,再由右手送出去)
 
抉擇考量
  快市時,價格常常是呈現90度的垂直上升或下降,此時報價延遲必然導致不利的滑價
  反之,慢盤時,價格不上不下,或隨機上下,此時報價延遲未必會導致不利的滑價
  所以當符合以下條件時,適合挑選TC選手
  (1)下單會用到停止單(突破型策略)
    請注意:MC內建的Set指令私底下會使用停止單
  (2)圖表K棒不使用以幾個tick來組一根K棒的方式
  (3)交易頻繁(此類交易每次獲利的期望點數是很少的,滑價甚為敏感)
  (4)部位大者(如果期貨商手續費都需要爭取調降,那滑價更是需要)
 
TC的難題與克服方法
  當決定要使用TC時,會面臨幾個難題
  (1)無法自動轉倉:可改用有提供自動轉倉的下單機【下單大師】
  (2)可交易的期貨商少:可改用有支援12家期貨商的下單機【下單大師】
    (之前都以為存取檔案的下單機會因為I/O與偵測的關係,容易比較慢,但其實不太會,我有數據,之後再分享給大家)
  (3)歷史資料只有6個月:這應該不算難題,網路資源那麼多
  (4)萬一訊號不一致:盤後可用ChangeMarketPosition指令同步策略部位
    (我以前到現在接KWay的報價,盤後留倉策略都是人工檢察部位是否有差異,有的話還是得靠ChangeMarketPosition來同步
     可參考http://www.multicharts.com/trading-software/index.php/ChangeMarketPosition)
  以上這些TC的難題都是使用者可自行克服的
  唯獨KWay快市時的報價延遲,無論如何,使用者也無法自行克服,除非改變策略模式,避開快市(但可能只有天曉得何時會快市)
 
 
註:
  已問過艾揚(Touchance廠商),並確認以下兩點事實
  1.Tick併筆資料是在Touchance的客戶端電腦的AP進行的,所以盤後重新回補Tick才會跟盤中即時收到的Tick產生差異
  2.分K棒的開高低收量等資訊,是在機房伺服器計算好才丟到客戶端的,所以縱使盤後重新回補分K棒也不會跟盤中即時收到的分K棒有差異
 
 
 
以下把這六個交易日的延遲程度以圖表的方式呈現給大家
(請注意,這是交易日一整天延遲較大的程度比較,不等於快市時的延遲
 要比較快市延遲,請參考前幾篇文章PK日的【快市特寫比較】)
 
 
單日最大延遲【P(100)】比較
 
 
 
單日最大千分之一延遲【P(99.9)】比較
 
 
 
單日最大百分之一延遲【P(99)】比較
 
 
 
 

最後能有多家數據源真是件好事,比較與競爭下,廠商的產品才會越來越好

另外,因為PK賽已全部告一段落
如有網友需要驗證或測試的可上Touchance官網申請帳號,可免費試用14天
之後再使用此報價延遲檢測軟體:MonitorQuote_v1.5.zip

 

編輯文章 by 萬年船 2016-06-04 14:41:35

第176篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-04 14:54:18
0
暱稱:KRZ
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(0)
   

萬大,請教一個問題,您的#175篇回覆中

==========

註:

  已問過艾揚(Touchance廠商),並確認以下兩點事實
  1.Tick併筆資料是在Touchance的客戶端電腦的AP進行的,所以盤後重新回補Tick才會跟盤中即時收到的Tick產生差異
==========

依據您過去的測試來分析,我的理解是這樣:

客戶端電腦的TC數據源元件是接收到大部分的TICK,然後才在客戶端進行併筆。就是說每天TC比KW少TICK數的主要原因是因為併筆,而非收到較少的tick報價。然而,TC的延遲是比較均勻的,快慢市的延遲比較沒有太大差異。因此,TC的可能併筆機制是:

A. TC的併筆機制與快慢市無關,即並非因為快市的CPU或GPU負載高低而決定是否併筆。

B. TC的併筆機制越接近快市,CPU或GPU負載越高,併筆的數量會越增加。

 

關於A的方式:

以往也許是顧及有些客戶的電腦配備較差而採用這種方式,但是經過這麼多年了,我看大家的配備都在比高檔的,居然不讓客戶端有選項取消併筆? 也許是因為架構設計的因素或是商業考量吧。  但是,TC是否採用這種無條件併筆的方式,我有點存疑,因為如果是無條件的併筆,照理說快慢市的延遲應該還是可以觀察出明顯的差異。難道這個併筆的動作對於慢市時候造成的影響與快市時所能加速的部分是相同的?

 

關於B的方式:

如果使用這種方式,表示TC會在負載高的時候,反而更會增加併筆的動作,讓負載更增加?   而負載稍微增加的結果是能夠大幅降低(相對於KW)未併筆所帶來的延遲?  那負載的增加到底對於報價延遲的影響性為何?   這是不是好像也不太合理?

 

當然這些部分並不是您的業務,只是好不容易有人也在認真思考這些問題,想請教一下您的看法如何? 謝啦。

 

=====

另外,你說不使用凱衛數據源+凱衛下單機無法用stop單,是指內建的stopxxx那些出場函數嗎?

我用DDE或其他數據源+凱衛下單機,stop order的確是可以下單的,但是MC內建的stoploss、stopprofit那些函數的確是無法使用的 (因為我之前沒在用這些函數,沒有考慮到這個)。


第177篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-04 15:40:27
0
暱稱:KRZ
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(0)
   

無聊的上班日,從萬大這些測試所觀察到的現象,從另一個角度來思考。

以10幾年前還在做通訊系統的system modeling的經驗類推一下,希望別落後時代太多,哈哈。

1. 所有的東西,我們就先簡化成兩個完美的部分:報價 + 報價以後的所有系統。現在要考量的是,在上述的兩部分中間加入現實的TC跟KW這兩個數據源後,分別造成的影響。

2. 首先從頻域(frequency domain)來分析:

  • TC併筆,如果視為是down-sample,那就是低通濾波器,信號處理上來看的確可以降低一些雜訊。
  • KW的報價延遲,加個delay,仍舊是個低通濾波器,信號處理上來看也是可以降低雜訊。
  • 因此,如果你的交易分析是需要報價的高頻成分,兩者都有影響。

3. 其次從時域(time domain)來分析:(jitter請想成時間的延遲就好)

  • 以TC較均勻的延遲分佈情況,我會判斷比較接近white noise的方式來模擬報價上的jitter。(也不算white,畢竟不會有負延遲)。
  • 而KW的延遲分佈,除了white noise的jitter,另外比較嚴重的是跟報價相關的jitter,而且可能越快市、報價越重要,所造成的jitter越大。此時,KW Jitter的模擬,除了white noise的部分,應該還要加上一個報價絕對差值成正相關的成分。
  • 由於現實世界的jitter一定存在,TC的white noise jitter是一般系統模擬者較偏好的。然而,KW的jitter應該算可以看成signal dependent intereference了,甚至是jammer (你的信號重要,我的干擾隨之放大),哈哈。 因此,除非短時間的大幅報價變動對你的交易分析並不重要,否則使用KW數據源應該要在回測時加入適當的機制評估其影響。

4. 建議的jitter模擬方式,由於如果先用個模型幫每個報價分別計算延遲加入每個tick實在太厚工,況且還要考慮到期交所送出報價的方式及數據源廠商的這些實際細節。  我覺得可以這樣,white noise部分(大概300ms)先忽略,但是至少用秒做細部回測,並且增加判斷式,若干時間內的報價變動絕對值大於一個特定值時,將下單時間延遲個1~2秒(依據萬年船大的上述測試結果)。  回測看看對你的策略績效影響有多少。

 

歡迎指教,謝謝。

編輯文章 by KRZ 2016-06-04 15:43:06

第178篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-04 18:02:02
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
--------------------------------------------------
客戶端電腦的TC數據源元件是接收到大部分的TICK,然後才在客戶端進行併筆。就是說每天TC比KW少TICK數的主要原因是因為併筆,而非收到較少的tick報價。然而,TC的延遲是比較均勻的,快慢市的延遲比較沒有太大差異。因此,TC的可能併筆機制是:
A. TC的併筆機制與快慢市無關,即並非因為快市的CPU或GPU負載高低而決定是否併筆。
B. TC的併筆機制越接近快市,CPU或GPU負載越高,併筆的數量會越增加。
--------------------------------------------------
(以上引用自KRZ大的第176篇,回應如下:)
 
 
1.併筆肯定Tick會變少是確定的,但有沒有可能也會少收到Tick,這點就不確定了
2.CPU的使用率或許是一個併筆的條件,但絕非唯一條件,不然收下來的Tick組成的秒K棒肯定是不能看、也不能用的
 (我的估計是(a)CPU使用率 + (b)定時併筆,但這只是我的猜測,不過沒看過他門的Code,也不曉得)
3.這六個交易日測下來,每秒最多大概就只有20幾筆ticks
4.凱衛下單機綁凱衛的數據源,指的是buy xxx at 8500 stop這類指令,當然也含set指令,但精確如何綁,細節我就不知道了
 
由5/30(一)與5/31(二)這兩天的快市那秒的即時Ticks如下(沒經過手動回補)
請注意微秒是百萬分之一秒,比毫秒(千分之一秒)更小一階的單位
可以觀察到,快市時,TC每100毫秒(100,000微秒)至少會有1~2個tick以上
所以會因為併Ticks而導致延遲的時間是很短的
 
 
 
 

第179篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-05 15:41:25
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
用KWay或TC所提供的下單接口,都必須綁同一家的數據源(因停止單洗價的緣故)
為了不被任何一家數據源綁死
昨天6/4(六)已成功把凱衛的下單機這顆輪胎卸下來
換成下單大師這顆新輪胎了(可自動轉倉)
 
我使用的策略部位寫檔的模組是參考阿政大所分享的原型來改良的(原文請參考MultiCharts文字檔_下單大師版DLL)
 
其實阿政大提供的已經可以直接用了
但仍有幾點是有空間可改良的,索性我就一次修改好,分享給也需要的人
(1)快市時,每秒有幾百筆Ticks,但仍每筆Tick都寫檔(RamDisk),恐會產生些延遲時間
  (把最近報價寫到檔案是有目的的,可讓下單大師存取到報價,判斷報價是否停止與其他用途)
(2)因為要等下一個Tick才能判斷上一個Tick的部位,所以會慢一個Tick,如果兩個Tick時間隔好幾秒,下單就不即時了
  (請參考此篇http://www.multicharts.com.tw/MCGetFile.aspx?file=Kway-12.ppt)
 
針對以上兩點,改良後的程式行為如下:
1.盤前開啟圖表時,把最後的部位與收盤價寫檔
2.盤中收到即時的Tick時
 2.1 如果部位有變更,則立刻把最新部位與即時價寫檔
 2.2 如果部位沒變更,但距離上一次寫檔已超過3秒鐘,則把最目前部位與即時價寫檔
 2.3 如果部位沒變更,但距離上一次寫檔少於過3秒鐘,則不執行寫檔動作
 2.4 最後如果系統時間還沒到收盤時,請求0.5秒後重新計算本程序(0.5秒可自行調整RecalculationTimeout參數,最低值為0.1秒)
4.收盤時,把最後的部位與收盤價寫檔
 
 
 
可匯入的.pla檔,請點此下載
使用前請先參考阿政大的教學說明http://www.yctseng.net/2013/02/multicharts.html
把他提供的原型指標,換成此訊號即可,其他都沒變
程式如下圖所示:
 
 
 
使用前請先
1.建立目錄 C:\OrderMaster\Positions\Library
2.把OMSignTxt.zip裡面的dll複製到C:\OrderMaster\Positions\Library
3.在交易圖表使用此訊號DumpPositionToFile,再把FileName參數改成你的訊號檔名即可
 
 
為提高I/O效能,請一定要裝一套RamDisk,再把C:\OrderMaster搬到RamDisk磁碟機,步驟如下:
(以下假設你的RamDisk裝在A:磁碟機)
1.把C:\OrderMaster複製到A:\OrderMaster
2.刪除C:\目錄底下的整個OrderMaster目錄
3.用管理員權限開啟cmd,並輸入如下指令
 mklink /d "C:\OrderMaster" "A:\OrderMaster"
 
 

第180篇:[發表] 報價延遲檢測報告(每周更新)  by 2016-06-05 17:23:00
0
暱稱:萬年船
信箱:不顯示
成就:發文(0) / 回文(0) / 推薦(10)
   
以下這篇是關於如何提高【下單大師】的效率
 
提高後,使用下單大師與各家數據源內建的下單機,在下單效率上幾乎無異
 
下單大師的不管是使用檔案(RamDisk)或萬用API,都是定時進行偵測的
而偵測頻率最低可設到千分之一秒(1毫秒),在【策略管理】頁籤的下圖所示的地方
 
 
 
 
然而,縱使你設定1毫秒偵測一次,卻未必真的1毫秒偵測一次
系統內有個計時器解析度(Timer Resolution),Windows作業系統預設是15.6毫秒(每秒中斷64次)
換句話說,縱使你設1毫秒偵測一次,但其實還是15.6毫秒才偵測一次(不管是訊號檔或萬用API都一樣)
 
 
 
所以可下載TimerTool此工具,強制把計時器解析度改成1毫秒
如要自動化執行,在開機時,批次檔只需執行以下這行即可
start C:\TimerTool.exe -t 1 -minimized
 
 
測試結果,請參考下面兩個圖(15.6毫秒與1毫秒的差異)
以下測試的訊號檔,全部都使用RamDisk
 
 
 
 
 
 
 
 
 
 
 
 
 
 
不過要留意的是,把計時器解析度設為1毫秒,如果策略較多的話,CPU的使用率會略微增加
請確認CPU剩餘的使用率是否足夠應付盤中交易
 
 
另外,由上面兩個圖可看到,從準備寫檔到下單大師偵測到約為1毫秒或16毫秒(視計時器解析度而異)
其實有試過,當採用萬用API時,也是這個數據,RamDisk訊號檔與萬用API還真沒差
 (除了第一次RamDisk寫檔會稍慢幾毫秒,但盤前就會寫第一次了,所以沒差)
且萬用API還要求同步前,要先呼叫初始化,不像RamDisk檔案方便,建議不使用萬用API,沒那個價值
 
測試用的TestWriteFile程式,可由此下載 (需安裝Java才能執行)
 
 
 
編輯文章 by 萬年船 2016-06-05 17:33:35

第一頁上一頁1234567下一頁最後頁
討論區列表MultiCharts
  MultiCharts│ 討論區│ 會員專區│ 教學講座│ 支援與服務│ 產品購買│ 申請試用 All rights for MultiCharts Trading Software are reserved by MultiCharts, LLC
凱衛資訊股份有限公司 著作權所有 本網站最佳瀏覽解析度為 1024 x 768 隱私權政策 │ 網站安全政策 │ 著作權說明
驗證碼
若不清楚點選圖片更新驗證碼
註冊帳號
忘記密碼
解除鎖定