關於台指期的成交Tick的筆數
最近挖了一個10年前的報價API出來試,發現還能用,想問一下版友們目前台指期TX的Tick筆數大約是多少筆呢?
近2日的觀察 TX-201712
交易日 2017-12-15 總口數 175141 Tick筆數 54464 (15:00~13:45)
交易日 2017-12-18 總口數 16856 Tick筆數 6347 (15:00~05:00 僅夜盤)
希望有資料的版友可以提供出來作為參考, 謝謝!
我可以告訴您我的經驗
1.各家API不知是怎樣的來源 基本上如果有六家提供API
可能有四種結果
都是因為併筆的問題
2.如果再加上MC TOUCHCHANCE那可能有六種結果
3.你應該是看你要這資料是要TICK運算還是一般K棒運算
如果一般K棒運算 說真的指標上沒差多少
4.如果是TICK運算我是習慣用群益
一直以來我的策略用群益也都很好用
比對這個真的沒什麼意義
期交所盤後給的一定沒併筆
你想從盤中的去找出期交所盤後的是不可能的
那如果國外期貨那量更誇張你怎辦呢
嗨！我是覺得答案一定是相同的啦，據觀察，總口數總是一模一樣，只是筆數合併過，應該是非常可信的資料源。冒昧請問一下，您為什麼非得比對得這麼仔細才能放心？萬一中間有與期交所稍有出入的資料，會造成怎樣的影響嗎？ 我剛好在分析，列出一部分供您參考。我是從期交所抓下來的，2017-12-15 日盤就有 76286 筆
2017-12-18 的還沒去下載，您可以自己抓來比較看看
http www taifex.com.tw/chinese/3/dl_3_1_3.asp
>>> f[(f['date_time'] > '2017-12-15 06:00:00') & (f['date_time'] < '2017-12-15 14:00:00')]
date_time product monthweek pricevolume
2017-12-15 08:45:00 TX 20171210510.0 936
2017-12-15 08:45:00 TX 20171210510.0 2
2017-12-15 08:45:00 TX 20171210510.0 2
2017-12-15 08:45:00 TX 20171210509.0 2
2017-12-15 08:45:00 TX 20171210509.0 2
2017-12-15 08:45:00 TX 20171210510.0 2
2017-12-15 08:45:00 TX 20171210510.0 2
2017-12-15 08:45:00 TX 20171210510.0 2
2017-12-15 08:45:00 TX 20171210510.0 2
2017-12-15 08:45:00 TX 20171210510.0 2
2017-12-15 08:45:00 TX 20171210510.0 12
2017-12-15 08:45:00 TX 20171210509.0 2
2017-12-15 08:45:00 TX 20171210509.0 2
2017-12-15 08:45:00 TX 20171210509.0 2
2017-12-15 08:45:00 TX 20171210509.0 2
2017-12-15 08:45:00 TX 20171210509.0 6
...
2017-12-15 13:44:59 TX 20171210485.0 2
2017-12-15 13:44:59 TX 20171210484.0 2
2017-12-15 13:44:59 TX 20171210485.0 10
2017-12-15 13:44:59 TX 20171210486.0 2
2017-12-15 13:44:59 TX 20171210486.0 30
2017-12-15 13:44:59 TX 20171210485.0 2
2017-12-15 13:44:59 TX 20171210486.0 2
2017-12-15 13:44:59 TX 20171210486.0 2
2017-12-15 13:44:59 TX 20171210484.0 2
2017-12-15 13:44:59 TX 20171210485.0 2
2017-12-15 13:44:59 TX 20171210484.0 4
2017-12-15 13:44:59 TX 20171210483.0 4
2017-12-15 13:44:59 TX 20171210485.0 2
2017-12-15 13:44:59 TX 20171210485.0 2
2017-12-15 13:44:59 TX 20171210485.0 2
2017-12-15 13:45:00 TX 20171210485.0 2
雖然不是很清楚J大是要表達什麼?
但是群益我也知道,國外期貨我也很熟,
尤其群益的國外期貨在白天沒什麼資料也常偶爾會延遲超過5~10秒,
而群益的國內經過精X代理的S商品平台運作就弱掉了,
版上大家大部分都會選擇另一家券商不是嗎?
至於MC以前海期V1如果是券商版還好現在V2就算了甭用,
國內就更不用說了只有一種K喂來源吧!
然後大家都要靠自己想辦法接其他的不是嗎?
Tick習慣用群益的也要小心,
特別是海期,尤其是需要透過回補的部分,
如果是較久的,要注意補的是不是完整的資料!!
以ES1803 12/22為例:
如果開盤的一分鐘資料只有2筆帶過就是不完整的
17:00:00.39 Last: 268700,280
17:01:00.91 Last: 268675,4
完整的開盤一分鐘資料:
17:00:00.39 Last: 268700,280
17:00:00.42 Last: 268700,4
17:00:00.45 Last: 268675,9
17:00:00.48 Last: 268675,4
17:00:00.52 Last: 268700,1
17:00:00.52 Last: 268675, 30
17:00:00.62 Last: 268700,2
17:00:00.66 Last: 268675,1
17:00:01.08 Last: 268675,132
17:00:01.11 Last: 268650,3
17:00:01.20 Last: 268675,2
17:00:01.23 Last: 268675,1
17:00:01.30 Last: 268675,2
17:00:01.41 Last: 268650,4
17:00:01.41 Last: 268675,7
17:00:01.55 Last: 268700,1
17:00:01.70 Last: 268675,2
17:00:01.73 Last: 268675, 12
17:00:01.77 Last: 268675,1
17:00:02.16 Last: 268650,1
17:00:02.19 Last: 268675,1
17:00:02.22 Last: 268650, 10
17:00:02.25 Last: 268675,2
17:00:02.36 Last: 268675,1
17:00:02.78 Last: 268675,4
17:00:02.86 Last: 268675,4
17:00:02.92 Last: 268675,3
17:00:03.03 Last: 268675,3
17:00:03.23 Last: 268675,1
17:00:03.34 Last: 268675,1
17:00:03.48 Last: 268650,1
17:00:03.61 Last: 268675,1
17:00:03.84 Last: 268675,2
17:00:03.98 Last: 268675,2
17:00:04.02 Last: 268675,1
17:00:04.08 Last: 268675,1
17:00:04.23 Last: 268675, 11
17:00:04.30 Last: 268675,6
17:00:04.34 Last: 268675,3
17:00:04.34 Last: 268675,4
17:00:04.41 Last: 268675,1
17:00:04.45 Last: 268675,2
17:00:04.52 Last: 268675,5
17:00:04.67 Last: 268675,3
17:00:04.73 Last: 268675,2
17:00:04.73 Last: 268675,7
17:00:04.81 Last: 268675,3
17:00:04.81 Last: 268675,7
17:00:04.89 Last: 268675,9
17:00:04.95 Last: 268700,2
17:00:05.00 Last: 268700,5
17:00:05.06 Last: 268700, 16
17:00:05.14 Last: 268700, 11
17:00:05.23 Last: 268700,2
17:00:07.16 Last: 268700, 24
17:00:07.31 Last: 268700,1
17:00:08.02 Last: 268700,4
17:00:08.41 Last: 268700, 26
17:00:08.55 Last: 268700,6
17:00:08.64 Last: 268700,1
17:00:09.02 Last: 268725, 10
17:00:10.09 Last: 268725,1
17:00:10.75 Last: 268725,1
17:00:11.06 Last: 268725,3
17:00:14.05 Last: 268725,1
17:00:14.41 Last: 268700,4
17:00:14.72 Last: 268700,1
17:00:15.52 Last: 268725,1
17:00:15.64 Last: 268725,6
17:00:16.47 Last: 268725,2
17:00:16.72 Last: 268725, 11
17:00:16.78 Last: 268725,3
17:00:16.81 Last: 268725,1
17:00:16.84 Last: 268725,1
17:00:16.91 Last: 268725, 24
17:00:17.97 Last: 268750,2
17:00:18.11 Last: 268750,6
17:00:19.14 Last: 268750,1
17:00:19.91 Last: 268750,1
17:00:22.27 Last: 268750,5
17:00:22.44 Last: 268750,4
17:00:22.75 Last: 268725,1
17:00:22.78 Last: 268725, 23
17:00:23.14 Last: 268725,4
17:00:23.91 Last: 268725,4
17:00:24.47 Last: 268700,2
17:00:26.05 Last: 268700, 94
17:00:27.31 Last: 268700,1
17:00:29.44 Last: 268700,1
17:00:29.64 Last: 268700, 27
17:00:30.06 Last: 268725,1
17:00:30.55 Last: 268700,1
17:00:33.19 Last: 268700,1
17:00:34.16 Last: 268725,1
17:00:37.28 Last: 268700, 44
17:00:37.46 Last: 268700,1
17:00:38.80 Last: 268700,1
17:00:38.97 Last: 268700,1
17:00:39.78 Last: 268700,1
17:00:42.94 Last: 268700,2
17:00:43.89 Last: 268675,1
17:00:48.16 Last: 268700,1
17:00:48.57 Last: 268675,1
17:00:48.75 Last: 268700,1
17:00:48.96 Last: 268700,2
17:00:51.92 Last: 268675,2
17:00:52.33 Last: 268700,6
17:00:52.55 Last: 268700,1
17:00:52.72 Last: 268700,2
17:00:52.92 Last: 268700,1
17:00:53.11 Last: 268700,1
17:00:55.68 Last: 268700, 24
17:00:57.72 Last: 268700,1
17:01:00.91 Last: 268675,4
而他們主機很多,不同主機Tick時間會略有不同,
其實國外期貨並不誇張,(要看來源)就是資料量多而已,
一個契約100萬筆Tick實在也沒什麼,
旦如果是手機上看的就不說了,Tick0066的(很差的來源),
反倒是國內比較誇張整天全市場不到30萬筆Tick,
資料那麼少還要搞合併,更何況大家電腦性能很好又不是用手機,
然後我認為資料的正確性和即時性會影響策略執行的精準度,
就像有人都要多加3點當作成本去估算就是因為精準度不夠,
尤其以Tick或KD作為觸發的機制,便是以成交作為依據,
而既然成交就已經是歷史,觸發的結果將是新的結果,
這樣的策略當然難以和回測的數據一致,
反過來想,如果把成本放在看委買賣價來作策略是否會更好?
期交所的資料沒合併我也幫它合併了,合併後的比API還少筆,
而用意也不在資料是否有合併,而是在發現資料的正確性有無問題,
然而筆數多寡也代表的就是資料(反應)的即時性,
(如果因為資料量大造成系統會卡網路會慢那又是另外一回事)
倘若有人連下單速度200ms和20ms都要非常在意,
那麼報價隨便都會有500ms的延遲狀況又怎麼能毫不在意呢?
搶市價就是先成交先贏,滑價情形就相對少囉!
如果報價比別人快0.5秒收到那麼就算下單慢200ms也是會還比報價慢的人先完成成交不是嗎?
所以對一個不清楚的資料來源先瞭解資料的正確性應該也很正常,
當然不會無聊到想用API盤中去獲得出期交所盤後的正確結果,
而是利用期交所的資料來檢驗API收的資料是否有哪些問題,
現在得到的結果就是併筆邏輯在同價跨秒時有問題,
這問題是可以改正的,只是不是我來改,
這個問題有看到的自然會有想法,認為無關緊要的也無所謂,
重點是'發現'到這個狀況
而對於K棒或Tick運算,其實價值是相同的,除非所用的K棒不即時,
不然即時K棒的收和量其實就是Tick,每筆Tick都應該更新K棒,
因為即使價沒有變但是量也已經又累積,
所以當每個人用法不同或是來源與工具就有不一樣,
會有相異的見解也是很正常
過來看看資料量和處理速度,先看22號的資料
9萬多筆Tick從讀檔/篩選/分商品逐筆開檔寫檔(未合併)不超過0.5秒,
看到全市場才13萬多筆成交資料不覺得很香菇嗎?
由原始檔觀察,15號的資料還比較有看頭
(不太瞭解下面這個圖貼上來為什麼這麼小又模糊)
23萬多筆Tick從讀檔/篩選/分商品逐筆開檔寫檔也不超過0.8秒,
如果經過合併
寫檔的資料量變少則不超過0.7秒(這表示寫檔的loading比作合併處理還重)
假如整天全市場的資料根本不用1秒就能處理完,
實在不知道國內常在喊快市快市快市是個怎樣的快法阿?
這樣比較一下之後,大家覺得延遲還有理由嗎?
假如我跑即時是為了要累積歷史資料根本沒意義,
應該下載交易所的資料就好了吧,所以我收即時行情當然是為了快!!!
然後,我真的好無聊阿,想想這些資料的處理都只是一瞬間的事,
弄成自動化後就根本沒事做了,因此上來這裡想到什麼寫什麼就會寫很多,
但是回到最初開版其實是想知道有其他方式接收的,是否能提供Tick筆數供參考,
結果連續幾天下來都沒有人要分享(或許是都沒人看吧!)
如果大大提到說有6種,是否能提供出來,滿足我小小無知的心願一下呢?
sidetalker 發表於 17-12-16 17:08
我剛好在分析，列出一部分供您參考。我是從期交所抓下來的，2017-12-15 日盤就有 76286 筆
2017-12-18 的 ...
期交所的資料口數好像是即時行情收下來的2倍
看csv檔頭是寫 成交數量(B+S)
所以是把買賣雙方重複算(買1口 + 賣1口 該筆交易成交算作是2口)
用夜盤(筆數比較少) 最後一秒的資料來看
期交所3筆,口數 16+2+2=20
成交日期,商品代號,到期月份(週別),成交時間,成交價格,成交數量(B+S),近月價格,遠月價格,開盤集合競價
20171215,TX ,201712 ,045959,10514,16,-,-,
20171215,TX ,201712 ,045959,10514,2,-,-,
20171215,TX ,201712 ,045959,10514,2,-,-,
即時行情1筆,口數 10
時間,,,成交價,口數,總口數
045959,,,10514,10,12335
上面期交所的3筆成交價格都相同,
所以即時行情合併成1筆出現大致上沒什麼問題
再比對最後幾秒8筆 (只有29秒時期交所有出現2筆)
20171215,TX ,201712 ,045929,10514,2,-,-,
20171215,TX ,201712 ,045929,10514,2,-,-,
20171215,TX ,201712 ,045931,10514,2,-,-,
20171215,TX ,201712 ,045938,10514,4,-,-,
20171215,TX ,201712 ,045949,10514,12,-,-,
20171215,TX ,201712 ,045951,10514,2,-,-,
20171215,TX ,201712 ,045956,10514,2,-,-,
20171215,TX ,201712 ,045957,10514,10,-,-,
即時行情 7筆 (看起來29秒的資料剛好也是同秒同價合併)
045929,,,10514,2,12309
045931,,,10514,1,12310
045938,,,10514,2,12312
045949,,,10514,6,12318
045951,,,10514,1,12319
045956,,,10514,1,12320
045957,,,10514,5,12325
找時間來寫個程式把期交所的資料作合併處理再比對看看,
如果筆數能趨近於期交所的結果那就太好了!
TX資料剛剛弄出來了...以12/15為例
交易日 2017-12-15 總口數 175141 Tick筆數 54464 (15:00~13:45)
期交所 Daily_2017_12_15.csv
[原始逐筆]
交易日 2017-12-15 總口數 175141 Tick筆數 83280 (15:00~13:45)
[連續同秒同價合併]
交易日 2017-12-15 總口數 175141 Tick筆數 30001 (15:00~13:45)
所以 54464 筆明顯比[連續同秒同價合併]的結果 30001 多很多
推論API是同包同秒同價合併 (期交所即時行情格式封包,同一包中的同秒同價合併)
因此一秒內有多個封包的話,查API行情確實有即使同秒同價也是多筆資料的情況
(偷笑)看來試的這個API頗有看頭,
而且跑著都不用管他,完全不會有行情中斷的情形,
每天的Tick都存的很完整!
接下來要先找個環境成為常態運作,
繼續後續的一些可能計畫
To sidetalker
謝謝提醒期交所,太久沒碰忘了還有期交所網站
下載可以用這樣的網址(直接針對想要的日期下載)
rpt
http：／／www．taifex．com．tw/DailyDownload/DailyDownload/Daily_2017_12_18.zip
http：／／www．taifex．com．tw/DailyDownload/DailyDownload/Daily_2017_12_15.zip
csv
http：／／www．taifex．com．tw/DailyDownload/DailyDownloadCSV/Daily_2017_12_18.zip
http：／／www．taifex．com．tw/DailyDownload/DailyDownloadCSV/Daily_2017_12_15.zip
(因12/16是星期六 實際歸戶成交日為12/18星期一)
另外zip解開後,
觀察rpt檔和csv檔的內容根本是一樣的,只有副檔名不同
持續記錄一下便於觀察, 12/18的結果
交易日 2017-12-18 總口數 128892 Tick筆數 42083 (15:00~13:45)
期交所 Daily_2017_12_18.csv
[原始逐筆]
交易日 2017-12-18 總口數 128892 Tick筆數 62796 (15:00~13:45)
[連續同秒同價合併]
交易日 2017-12-18 總口數 128892 Tick筆數 25151 (15:00~13:45)
12/19的結果
交易日 2017-12-19 總口數 138459 Tick筆數 42804 (15:00~13:45)
期交所 Daily_2017_12_19.csv
[原始逐筆]
交易日 2017-12-19 總口數 138459 Tick筆數 66781 (15:00~13:45)
[連續同秒同價合併]
交易日 2017-12-19 總口數 138459 Tick筆數 25023 (15:00~13:45)
12/20的結果, TX1712已經冷掉了
交易日 2017-12-20 總口數 97478 Tick筆數 33239 (15:00~13:45)
期交所 Daily_2017_12_20.csv
[原始逐筆]
交易日 2017-12-20 總口數 97478 Tick筆數 46809 (15:00~13:45)
[連續同秒同價合併]
交易日 2017-12-20 總口數 97478 Tick筆數 19647 (15:00~13:45)
目前程式是把期交所的資料轉成依商品與API存檔的格式相同,
如果再弄個程式把Tick檔轉成分價量表的資料,
那麼把期交所的結果和API相比,
就能對API資料的完整性與正確性更加以確認...
sidetalker 發表於 17-12-20 21:28
嗨！我是覺得答案一定是相同的啦，據觀察，總口數總是一模一樣，只是筆數合併過，應該是非常可信的資料源。 ...
其實發這帖原本是想要知道大家的各種來源和接收方式下,實際記錄到的tick筆數情形分別狀況如何,想從中獲得一些比較作參考,不過都看沒有人回應,而既然最源頭期交所有提供原始資料下載,就先作一些分析比對看看哪邊有出入與可能原因,而既然有標準答案,所有資料就應該經得起驗證,只是資料筆數那麼多又可能要經常性的作檢驗,就須想一些方便的方法來歸納分析,如果是解數學習題,或許作法很多種而答案也都一樣正確,但有些作法或想法可能是不正確的,所以在某些情形下可能會錯掉,就像有些老師就會非常在意學生的答案是怎麼出來的,雖然總口數總是一模一樣,但是還沒完全確認是否有漏價的情形,至於會有什麼影響可能大家見解不同,像是如果漏價發生在新高或新低時可能相對影響比較大,但是如果不會漏價就不會有這種問題,因此如果能先知道會不會有漏價的問題,就知道有沒有可能發生漏掉最高價或最低價的問題了,就如同現在硬碟有分功用和等級,為了速度快拿監控碟來放程式或存資料,雖然滿足了速度但是就會很不安心吧!
12/21的結果, 改觀察TX1801囉
交易日 2017-12-21 總口數 135156 Tick筆數 43353 (15:00~13:45)
期交所 Daily_2017_12_21.csv
[原始逐筆]
交易日 2017-12-21 總口數 135156 Tick筆數 66311 (15:00~13:45)
[連續同秒同價合併]
交易日 2017-12-21 總口數 135156 Tick筆數 25914 (15:00~13:45)
統計PQ的的程式還沒著手寫,
不過前面提到了最高最低,想到可以用KD先比比看
剛好網路上有現成的程式可以用
格式是JSON,它的標記是
CHARTITEM中
T 為 時間(HHMM)
O 為 Open
H 為 High
L 為 Low
C 為 Close
V 為 增量
N 為 成交筆數
先看1HR的
{"CHARTDATAS":
{"TYPE":"60Min"
,"TIME":"2017-12-21 05:45:01.111 GMT"
,"CHARTDATA":"1801TX"
,"CHARTITEMS":[
{"T":"1600",O:10513,H:10524,L:10513,C:10523,V:1535,N:657},
{"T":"1700",O:10523,H:10523,L:10516,C:10523,V:1130,N:414},
{"T":"1800",O:10523,H:10524,L:10519,C:10521,V:582,N:237},
{"T":"1900",O:10521,H:10522,L:10518,C:10522,V:317,N:160},
{"T":"2000",O:10522,H:10522,L:10517,C:10519,V:477,N:178},
{"T":"2100",O:10519,H:10522,L:10519,C:10521,V:317,N:138},
{"T":"2200",O:10521,H:10523,L:10520,C:10521,V:667,N:208},
{"T":"2300",O:10521,H:10522,L:10499,C:10511,V:3610,N:1305},
{"T":"2400",O:10510,H:10513,L:10492,C:10499,V:3214,N:1214},
{"T":"0100",O:10500,H:10512,L:10497,C:10508,V:1428,N:546},
{"T":"0200",O:10508,H:10518,L:10508,C:10514,V:798,N:323},
{"T":"0300",O:10514,H:10519,L:10513,C:10516,V:247,N:126},
{"T":"0400",O:10516,H:10517,L:10509,C:10512,V:180,N:97},
{"T":"0500",O:10512,H:10517,L:10507,C:10508,V:647,N:205},
{"T":"0900",O:10492,H:10495,L:10475,C:10494,V:11650,N:3627},
{"T":"1000",O:10495,H:10539,L:10485,C:10523,V:49920,N:16514},
{"T":"1100",O:10522,H:10529,L:10491,C:10502,V:25556,N:7690},
{"T":"1200",O:10503,H:10515,L:10497,C:10500,V:9844,N:3064},
{"T":"1300",O:10500,H:10505,L:10491,C:10501,V:10820,N:2823},
{"T":"1400",O:10501,H:10506,L:10492,C:10497,V:12217,N:3827}
]}}
[期交所-同秒價合併]
{"CHARTDATAS":
{"TYPE":"60Min"
,"TIME":"2017-12-21 06:40:30.830 GMT"
,"CHARTDATA":"TX-201801"
,"CHARTITEMS":[
{"T":"1600",O:10513,H:10524,L:10512,C:10523,V:1535,N:584},
{"T":"1700",O:10523,H:10523,L:10516,C:10523,V:1130,N:321},
{"T":"1800",O:10523,H:10524,L:10519,C:10521,V:582,N:208},
{"T":"1900",O:10521,H:10522,L:10518,C:10522,V:317,N:148},
{"T":"2000",O:10522,H:10522,L:10517,C:10519,V:477,N:153},
{"T":"2100",O:10519,H:10522,L:10519,C:10521,V:317,N:117},
{"T":"2200",O:10521,H:10523,L:10520,C:10521,V:667,N:189},
{"T":"2300",O:10521,H:10522,L:10499,C:10511,V:3610,N:962},
{"T":"2400",O:10511,H:10513,L:10492,C:10499,V:3214,N:983},
{"T":"0100",O:10499,H:10512,L:10497,C:10508,V:1428,N:465},
{"T":"0200",O:10508,H:10518,L:10508,C:10514,V:798,N:270},
{"T":"0300",O:10514,H:10519,L:10513,C:10516,V:247,N:116},
{"T":"0400",O:10516,H:10517,L:10509,C:10512,V:180,N:94},
{"T":"0500",O:10512,H:10517,L:10507,C:10508,V:647,N:181},
{"T":"0900",O:10492,H:10495,L:10475,C:10494,V:11650,N:2046},
{"T":"1000",O:10495,H:10539,L:10485,C:10523,V:49920,N:8516},
{"T":"1100",O:10522,H:10529,L:10491,C:10502,V:25556,N:4422},
{"T":"1200",O:10503,H:10515,L:10497,C:10500,V:9844,N:1996},
{"T":"1300",O:10500,H:10505,L:10491,C:10501,V:10820,N:1876},
{"T":"1400",O:10501,H:10506,L:10492,C:10497,V:12217,N:2267}
]}}
[期交所-原始逐筆]
{"CHARTDATAS":
{"TYPE":"60Min"
,"TIME":"2017-12-21 07:14:19.971 GMT"
,"CHARTDATA":"TX-201801"
,"CHARTITEMS":[
{"T":"1600",O:10513,H:10524,L:10512,C:10523,V:1535,N:816},
{"T":"1700",O:10523,H:10523,L:10516,C:10523,V:1130,N:625},
{"T":"1800",O:10523,H:10524,L:10519,C:10521,V:582,N:335},
{"T":"1900",O:10521,H:10522,L:10518,C:10522,V:317,N:202},
{"T":"2000",O:10522,H:10522,L:10517,C:10519,V:477,N:297},
{"T":"2100",O:10519,H:10522,L:10519,C:10521,V:317,N:193},
{"T":"2200",O:10521,H:10523,L:10520,C:10521,V:667,N:313},
{"T":"2300",O:10521,H:10522,L:10499,C:10511,V:3610,N:2194},
{"T":"2400",O:10511,H:10513,L:10492,C:10499,V:3214,N:1985},
{"T":"0100",O:10499,H:10512,L:10497,C:10508,V:1428,N:747},
{"T":"0200",O:10508,H:10518,L:10508,C:10514,V:798,N:415},
{"T":"0300",O:10514,H:10519,L:10513,C:10516,V:247,N:157},
{"T":"0400",O:10516,H:10517,L:10509,C:10512,V:180,N:132},
{"T":"0500",O:10512,H:10517,L:10507,C:10508,V:647,N:333},
{"T":"0900",O:10492,H:10495,L:10475,C:10494,V:11650,N:5505},
{"T":"1000",O:10495,H:10539,L:10485,C:10523,V:49920,N:23978},
{"T":"1100",O:10522,H:10529,L:10491,C:10502,V:25556,N:12624},
{"T":"1200",O:10503,H:10515,L:10497,C:10500,V:9844,N:4651},
{"T":"1300",O:10500,H:10505,L:10491,C:10501,V:10820,N:4885},
{"T":"1400",O:10501,H:10506,L:10492,C:10497,V:12217,N:5923}
]}}
果真抓到了差異了!
只看期交所有無合併的部分只會在筆數N上面不一樣而已,OHLCV完全一致!
API的部分於 2400 和 0100 兩筆資料的Open則發現與期交所不同,
{"T":"2400",O:10510,H:10513,L:10492,C:10499,V:3214,N:1214},
{"T":"0100",O:10500,H:10512,L:10497,C:10508,V:1428,N:546},
[期交所]
{"T":"2400",O:10511,H:10513,L:10492,C:10499,V:3214,N:1985},
{"T":"0100",O:10499,H:10512,L:10497,C:10508,V:1428,N:747},
如果改看5Min的則有三筆不同
(每兩筆為API在前,期交所在後)
1555
{"T":"1555",O:10521,H:10523,L:10521,C:10523,V:56,N:23},
{"T":"1555",O:10522,H:10523,L:10521,C:10523,V:56,N:32},
2305
{"T":"2305",O:10510,H:10512,L:10508,C:10509,V:277,N:131},
{"T":"2305",O:10511,H:10512,L:10508,C:10509,V:277,N:175},
0005
{"T":"0005",O:10500,H:10504,L:10497,C:10504,V:258,N:100},
{"T":"0005",O:10499,H:10504,L:10497,C:10504,V:258,N:151},
其中2305與0005跟1HR的2400與0100是相對應的可以理解,
不過切細之後多發現了1555這筆不同的結果,
那代表我原本以為這個API給的TICK時間是交易所提供的資料,這個想法錯了!
所以現在懷疑是API系統的接收端收到期交所資料時打的時間資料,
只是這個API的系統校時作的還不錯,然後資訊也不太會有延遲的狀況而已...
現在只好回歸TICK觀察(用交易所的資料回看API的併筆行為)
5Min,1555的開時間點是15:50:00開始的
154951,,,10522,1,1431
155050,,,10521,12,1443 <==總量直接跳到1443,併筆量12口,1555的第一筆,開10521
[期交所]
154951,,,10522,1,1431
155050,,,10522,4,1435 <== 1555的第一筆,開應該是10522
155050,,,10522,1,1436
155050,,,10522,1,1437
155050,,,10522,1,1438
155050,,,10522,1,1439
155050,,,10522,1,1440
155050,,,10522,1,1441
155050,,,10521,2,1443 <== 總量1443在這裡 (API併筆 4+1+1+1+1+1+1+2=12)
依經驗推測這個API系統的併筆邏輯有問題!
因為15:50:50開始的價位10522與前一筆15:49:51也是10522都沒有變,所以一直處於併筆的狀態flag ON
直到10521的價位出現,就把155050開始累計的10口量,合併10521的2口才一起送出,
因此變成是第一筆TICK有12口所以KD的開為10521
結果,我的看法又變了,
這個API系統的TICK應該是直接用交易所給的時間資料,
只是他的合併機制有bug,沒人去發現與修正!!!
5Min,2305的開時間點是23:00:00開始的
情形同1555,跨分時價位沒變(10511)處於併筆的狀態flag ON,直到價位異動才送出
225959,,,10511,1,8635
230001,,,10510,2,8637 <==API的開10510 (累記總量8637)
[期交所]
225959,,,10511,1,8635
230001,,,10511,1,8636 <== 正確的開應該是10511
230001,,,10510,1,8637 <== 累記總量8637 在這裡 (API併筆 1+1=2)
5Min,0000的開時間點是00:00:00開始的
情形也是類似,跨分時價位沒變(10499)處於併筆的狀態flag ON,
不過這裏是直到'秒'異動(00:00:00->00:00:01)才送出
235959,,,10499,2,11849
000001,,,10500,9,11858 <==API的開10500 (累記總量11858)
000001,,,10500,1,11859
[期交所]
235959,,,10499,2,11849
000000,,,10499,4,11853 <== 正確的開應該是10499
000000,,,10500,1,11854
000000,,,10500,2,11856
000000,,,10500,1,11857
000001,,,10500,1,11858 <== 累記總量11858 在這裡 (API併筆 4+1+2+1+1=9)
000001,,,10500,1,11859
000001,,,10500,1,11860
000005,,,10499,1,11861
結論就是,當每分鐘的一開始,API的系統併筆有明顯邏輯上的bug!!!!!
更可以推至每秒跨秒時,該併筆的邏輯都會造成秒KD可能產生錯誤的開
感謝大大分享自己的研究, 比對的結果可以釐清報價生成邏輯, 對觀念及操作很有幫助. nes 發表於 17-12-23 23:07
雖然不是很清楚J大是要表達什麼?
但是群益我也知道,國外期貨我也很熟,
尤其群益的國外期貨在白天沒什麼資料 ...
感謝分享,原來行情量並不是問題只是藉口阿!
假如整天全市場的資料根本不用1秒就能處理完,
實在不知道國內常在喊快市快市快市是個怎樣的快法阿?
這樣比較一下之後,大家覺得延遲還有理由嗎?
假如我跑即時是為了要累積歷史資料根本沒意義,
應該下載交易所的資料就好了吧,所以我收即時行情當然是為了快!!!
超級認同兜++
我也有在收逐筆 Tick
目前是用群益的 C# API
期交所 53000筆
我這邊只收到 35000筆
跟樓主大大的情況差不多