nes 發表於 18-1-24 09:22

cory8249 發表於 18-1-22 17:52
我也有在收逐筆 Tick
目前是用群益的 C# API



這樣看起來群益的Tick少很多耶!不知道cory大提到的是哪天的資料?
期交所下載的資料是這樣(15:00~13:45)
Total Tick Count: 215263 (Daily_2018_01_22.csv)
total volume 163256
#Tick筆數:   75442
同秒同價併筆:30933

Total Tick Count: 231750 (Daily_2018_01_23.csv)
total volume 169011
#Tick筆數:   80656
同秒同價併筆:31610

因為cory大說期交所53000筆(與期交所落差甚大)
所以假設是只有日盤的資料(08:45~13:45)
TX-201802期交所23號的筆數為 71915 併筆則是 26077
而我這邊API交易日為23號的則是有 46735筆喲!

若以上個月TX-201712的觀察結果來看,
目前所試的API至少的都是會有4,5萬筆以上
只有換月的那天會突然冷掉才會只剩3萬多筆

所以群益35000筆真的少很多耶!!
由此可以推測群益的併筆是有跨包合併,
這也代表每筆資料收到的時間會有更大的延遲(為了合併而等待)

謝謝cory大提供的訊息


目前感覺只是想要累積資料的話下載期交所的檔案最方便
轉檔程式寫一寫,批次處理就好了,還絕對與期交所一致無法被挑剔{:4_82:}


nes 發表於 18-2-8 13:36

地震後看新聞才發現最近股市有震盪,上來紀錄一下

======= ::Program start: 13:20:06.968 =======
*** (Daily_2018_02_05.csv) *** size: 13.65 MB 篩選商品: TX
Total Tick Count: 280856      輸出方式[合併]
total volume 217828
#Tick筆數:    104953    #寫檔筆數:   41824
total volume 120
#Tick筆數:         5    #寫檔筆數:         4
total volume 10
#Tick筆數:         2    #寫檔筆數:         1
total volume 6
#Tick筆數:         4    #寫檔筆數:         3
total volume 2
#Tick筆數:         2    #寫檔筆數:         1
total volume 7886
#Tick筆數:      5130    #寫檔筆數:      3214
total volume 1070
#Tick筆數:       634    #寫檔筆數:       484
total volume 527
#Tick筆數:       416    #寫檔筆數:       320
total volume 251
#Tick筆數:       192    #寫檔筆數:       142

*** (Daily_2018_02_06.csv) *** size: 29.90 MB 篩選商品: TX
Total Tick Count: 615251      輸出方式[合併]
total volume 466704
#Tick筆數:    245491    #寫檔筆數:    101274
total volume 26
#Tick筆數:      10    #寫檔筆數:         9
total volume 2086
#Tick筆數:      74    #寫檔筆數:      70
total volume 28
#Tick筆數:         6    #寫檔筆數:         4
total volume 6
#Tick筆數:         4    #寫檔筆數:         3
total volume 22611
#Tick筆數:   15171    #寫檔筆數:      8622
total volume 2
#Tick筆數:         2    #寫檔筆數:         1
total volume 2656
#Tick筆數:      1831    #寫檔筆數:      1334
total volume 16
#Tick筆數:         4    #寫檔筆數:         3
total volume 1765
#Tick筆數:      1428    #寫檔筆數:      1052
total volume 2571
#Tick筆數:      1736    #寫檔筆數:       959

*** (Daily_2018_02_07.csv) *** size: 22.58 MB 篩選商品: TX
Total Tick Count: 464482      輸出方式[合併]
total volume 351887
#Tick筆數:    183516    #寫檔筆數:   77305
total volume 2
#Tick筆數:         2    #寫檔筆數:         1
total volume 2292
#Tick筆數:       136    #寫檔筆數:       103
total volume 110
#Tick筆數:         6    #寫檔筆數:         3
total volume 17751
#Tick筆數:   11746    #寫檔筆數:      7324
total volume 1226
#Tick筆數:       970    #寫檔筆數:       793
total volume 2
#Tick筆數:         2    #寫檔筆數:         1
total volume 608
#Tick筆數:       519    #寫檔筆數:       436
total volume 60
#Tick筆數:         3    #寫檔筆數:         2
total volume 299
#Tick筆數:       259    #寫檔筆數:       219

======= ::Programend : 13:20:11.027 =======
::Program timing: 4.06 sec(s)總算看到比較像樣的期貨交易量了! 加油!
不過三天總Tick數136萬多筆,
合併加讀寫檔一樣只需4秒就處理完了

其中6號的TX-1802成交量為 466704 口
Tick筆數有 245491 筆, 合併後仍有    101274 筆,
估計可能有些系統應該是有災情(筆數限制最多65535筆)


nes 發表於 18-2-9 16:27

kuolung 發表於 18-2-9 09:11
是的,我的系統,原本是 81920 筆,就掛了 ,現在改為 307200 筆

是為了用array比較快所以預先定好筆數限制嗎?
之前是看過tick有打序號的,看結構是用word所以才會受限於0xFFFF,
如果要收很多商品,全都用307200不是很浪費

補上8號和9號的紀錄,完整紀錄一週
======= ::Program start: 15:56:32.124 =======
*** (Daily_2018_02_08.csv) *** size: 15.88 MB 篩選商品: TX
Total Tick Count: 326431      輸出方式[合併]
total volume 229609
#Tick筆數:    122454    #寫檔筆數:   50730
total volume 11108
#Tick筆數:      1833    #寫檔筆數:      1621
total volume 324
#Tick筆數:      19    #寫檔筆數:      18
total volume 18
#Tick筆數:         2    #寫檔筆數:         1
total volume 2
#Tick筆數:         2    #寫檔筆數:         1
total volume 10906
#Tick筆數:      7713    #寫檔筆數:      4735
total volume 882
#Tick筆數:       620    #寫檔筆數:       485
total volume 130
#Tick筆數:       128    #寫檔筆數:       111
total volume 20
#Tick筆數:         3    #寫檔筆數:         2
total volume 152
#Tick筆數:      93    #寫檔筆數:      73

*** (Daily_2018_02_09.csv) *** size: 23.13 MB 篩選商品: TX
Total Tick Count: 475554      輸出方式[合併]
total volume 328566
#Tick筆數:    184144    #寫檔筆數:   81754
total volume 76
#Tick筆數:      15    #寫檔筆數:      14
total volume 29906
#Tick筆數:      2804    #寫檔筆數:      2245
total volume 284
#Tick筆數:      16    #寫檔筆數:         8
total volume 34
#Tick筆數:      12    #寫檔筆數:      10
total volume 23661
#Tick筆數:   17181    #寫檔筆數:   10499
total volume 1244
#Tick筆數:       970    #寫檔筆數:       803
total volume 482
#Tick筆數:       397    #寫檔筆數:       344
total volume 295
#Tick筆數:       269    #寫檔筆數:       245

======= ::Programend : 15:56:34.905 =======
::Program timing: 2.78 sec(s)
今天9號日盤08:45~13:45
API也有噴9萬多筆Tick出來,行情量的成績比上個月好很多
同時間期交所原始筆數為 132805 完整併筆為 53532
API為 91083 , cory大的群益API來源可以參考比較



ram 發表於 18-3-1 18:16

nes 發表於 18-2-9 16:27
是為了用array比較快所以預先定好筆數限制嗎?
之前是看過tick有打序號的,看結構是用word所以才會受限於0x ...

你好,請問是否方便提供幾天API的Tick資料檔作參考嗎?
最近剛好過年又有228假日正好瞭解逢假日的運作情形

nes 發表於 18-3-6 17:12

ram 發表於 18-3-1 18:16
你好,請問是否方便提供幾天API的Tick資料檔作參考嗎?
最近剛好過年又有228假日正好瞭解逢假日的運作情形
...

剛好過年前有跑起來擱著
因為篩選代碼有TX才要,所以有三個(TX,MTX,TXZ)
從2月7號早盤開始紀錄到剛剛3月6號16:40左右
(T+1盤交易日是3月7號了)

壓縮後11MB多,但是上傳附件限制5MB,只好分檔...



搞上傳弄好久@@"


jackaitw 發表於 18-3-6 17:48

最近台指期的資料用程式自動抓好像越來越難抓了,期交所經常改變網站機制,導致3/2日開始資料又不能自動抓歷史資料了

ram 發表於 18-3-6 21:26

nes 發表於 18-3-6 17:12
剛好過年前有跑起來擱著
因為篩選代碼有TX才要,所以有三個(TX,MTX,TXZ)
從2月7號早盤開始紀錄到剛剛3月6 ...

請問是只用API的資料就能依據交易日全部正確存檔還那麼完整嗎?
{:4_82:}

nes 發表於 18-3-9 15:57

jackaitw 發表於 18-3-6 17:48
最近台指期的資料用程式自動抓好像越來越難抓了,期交所經常改變網站機制,導致3/2日開始資料又不能自動抓 ...

期交所下載Tick那邊沒發現有什麼問題耶

nes 發表於 18-3-9 16:04

ram 發表於 18-3-6 21:26
請問是只用API的資料就能依據交易日全部正確存檔還那麼完整嗎?

雖然是跑好玩的,但是比起市面上的API確實是好太多了!
不論是即時性還是穩定度都很理想,Tick筆數也比較多所以相對更即時

dido 發表於 18-3-9 16:27

nes 發表於 18-3-9 16:04
雖然是跑好玩的,但是比起市面上的API確實是好太多了!
不論是即時性還是穩定度都很理想,Tick筆數也比較多 ...

請教 這是哪家的 api ?

jackaitw 發表於 18-3-9 19:12

nes 發表於 18-3-9 15:57
期交所下載Tick那邊沒發現有什麼問題耶

nes大我是用ocelot.exe下載的,這隻程式是底下這篇文章提供的,但是現在這篇文章卻上不去了所以不知道這隻程式有沒有新的版本
Python軟體:自動下載台上市櫃日數據轉檔和期指數據執行結果如下:
C:\TXDAY>C:\TXDAY\ocelot.exe -d 20180308-20180308 -o TE,TF -a 1 -b 3 -c 2 -i 2 -f stock -p C:\TXDAY
Note: 請確認轉檔後數據的完整性和正確性!

TSE data
WARNING: file already existed: C:\TXDAY\TSECLOSE\20180308.csv
TPEX data
WARNING:Download File Except...
WARNING:retry ..0
WARNING:Download File Except...
WARNING:retry ..1
WARNING:Download File Except...
WARNING:retry ..2
WARNING:Download File Except...
WARNING:retry ..3
WARNING:Download File Except...
WARNING:retry ..4
ERROR:Exit
請按任意鍵繼續 . . .

Traceback (most recent call last):
File "ocelot.py", line 2416, in <module>
File "ocelot.py", line 2381, in Running
File "ocelot.py", line 2184, in Merge_file
FileExistsError: 當檔案已存在時,無法建立該檔案。: 'C:\\TXDAY\\FOXFile\\Tse20180308_20180308.csv' -> 'C:\\TXDAY\\FOXFile\\stock.csv'

jerry 發表於 18-3-11 00:43

NES 大我剛下載您的資料 和我的比對後發現2/9
您收的台指日盤TICK只有91000 我收的有96000

3/6 您收的有46400 我收的有47400

中間的差異應該可能是 不同API(我的是群益)
或是您收太多資料 造成
我只收大台和部份OP

至於CORY大在應該是1/22 只收到35000 TICKS
我是1/19 收到35509 1/22 収到43137

中間差我只能猜應該是CORY大也有收股票或其他資料才造成

至於您提到收資料不用幾秒就收完
事實上沒錯
盤後收很快的
但是盤中如果不併筆 太多人收 SERVER 要處理REQUEST REPLY
還是會慢的 量多時不併 那可能每個人都LAG了


nes 發表於 18-3-12 17:49

dido 發表於 18-3-9 16:27
請教 這是哪家的 api ?

來源公司並沒有真的出API,是情商高手開發的...
用馬過的方式表達可以說是某ST公司的M系統資訊源

nes 發表於 18-3-12 17:59

jackaitw 發表於 18-3-9 19:12
nes大我是用ocelot.exe下載的,這隻程式是底下這篇文章提供的,但是現在這篇文章卻上不去了所以不知道這 ...

我沒有用過這個程式,也沒用Python
是來這裡開版後,有大大提醒可以去期交所下載
才自己寫程式的,下載和轉檔都是自己寫的

那個主題進不去會不會就是因為已經不能正常運作被下架阿?

nes 發表於 18-3-12 19:13

jerry 發表於 18-3-11 00:43
NES 大我剛下載您的資料 和我的比對後發現2/9
您收的台指日盤TICK只有91000 我收的有96000



我先下載期交所的資料跑出來參考
2/9 逐筆
======= ::Program start: 17:15:52.311 =======
*** (Daily_2018_02_09.csv) *** size: 23.13 MB 篩選商品: TX
Total Tick Count: 475554      輸出方式[逐筆]
total volume 328566
#Tick筆數:    184143    #寫檔筆數:    184143
total volume 76
#Tick筆數:      14    #寫檔筆數:      14
total volume 29906
#Tick筆數:      2803    #寫檔筆數:      2803
total volume 284
#Tick筆數:      15    #寫檔筆數:      15
total volume 34
#Tick筆數:      11    #寫檔筆數:      11
total volume 23661
#Tick筆數:   17180    #寫檔筆數:   17180
total volume 1244
#Tick筆數:       969    #寫檔筆數:       969
total volume 482
#Tick筆數:       396    #寫檔筆數:       396
total volume 295
#Tick筆數:       268    #寫檔筆數:       268

======= ::Programend : 17:15:54.094 =======
::Program timing: 1.78 sec(s)
2/9 同秒同價合併======= ::Program start: 17:17:21.623 =======
*** (Daily_2018_02_09.csv) *** size: 23.13 MB 篩選商品: TX
Total Tick Count: 475554      輸出方式[合併]
total volume 328566
#Tick筆數:    184144    #寫檔筆數:   81754
total volume 76
#Tick筆數:      15    #寫檔筆數:      14
total volume 29906
#Tick筆數:      2804    #寫檔筆數:      2245
total volume 284
#Tick筆數:      16    #寫檔筆數:         8
total volume 34
#Tick筆數:      12    #寫檔筆數:      10
total volume 23661
#Tick筆數:   17181    #寫檔筆數:   10499
total volume 1244
#Tick筆數:       970    #寫檔筆數:       803
total volume 482
#Tick筆數:       397    #寫檔筆數:       344
total volume 295
#Tick筆數:       269    #寫檔筆數:       245

======= ::Programend : 17:17:23.213 =======
::Program timing: 1.59 sec(s)
3/6 逐筆
======= ::Program start: 17:15:24.670 =======
*** (Daily_2018_03_06.csv) *** size: 12.28 MB 篩選商品: TX
Total Tick Count: 252866      輸出方式[逐筆]
total volume 186255
#Tick筆數:   91924    #寫檔筆數:   91924
total volume 52
#Tick筆數:         2    #寫檔筆數:         2
total volume 46
#Tick筆數:      10    #寫檔筆數:      10
total volume 24
#Tick筆數:         6    #寫檔筆數:         6
total volume 16
#Tick筆數:         8    #寫檔筆數:         8
total volume 3702
#Tick筆數:      2633    #寫檔筆數:      2633
total volume 322
#Tick筆數:       292    #寫檔筆數:       292
total volume 170
#Tick筆數:       160    #寫檔筆數:       160
total volume 42
#Tick筆數:         1    #寫檔筆數:         1
total volume 128
#Tick筆數:       117    #寫檔筆數:       117

======= ::Programend : 17:15:25.485 =======
::Program timing: 815.235 ms3/6 同秒同價合併
======= ::Program start: 17:18:04.201 =======
*** (Daily_2018_03_06.csv) *** size: 12.28 MB 篩選商品: TX
Total Tick Count: 252866      輸出方式[合併]
total volume 186255
#Tick筆數:   91925    #寫檔筆數:   39129
total volume 52
#Tick筆數:         3    #寫檔筆數:         2
total volume 46
#Tick筆數:      11    #寫檔筆數:         9
total volume 24
#Tick筆數:         7    #寫檔筆數:         3
total volume 16
#Tick筆數:         9    #寫檔筆數:         7
total volume 3702
#Tick筆數:      2634    #寫檔筆數:      1853
total volume 322
#Tick筆數:       293    #寫檔筆數:       252
total volume 170
#Tick筆數:       161    #寫檔筆數:       153
total volume 42
#Tick筆數:         2    #寫檔筆數:         1
total volume 128
#Tick筆數:       118    #寫檔筆數:      96

======= ::Programend : 17:18:04.934 =======
::Program timing: 732.911 ms
首先為了玩系統,所以架構故意弄的比較複雜
地點1: VM1(XP, 384MB ram) 跑API收資料篩選商品重新打到VM2
地點2: VM2(2K Server, 384MB ram), 於Host中再跑程式連到VM2上收資料存Tick紀錄

VM1的API是接收全部商品的資料,包含
TSE:全部的股票/權證/大盤/類股/指數等
OTC:全部的股票/權證/興櫃/櫃檯/類股/指數等
TFE:全部的現貨/期貨/期貨選擇權/股票選擇權等
其他:包含國際指數,摩台指/期貨等

由於就只想觀察一下台指的部分,
所以綁API的程式會篩選代碼有TX的TFE商品打到VM2
因此VM2就只剩TX,MTX,TXZ等商品
跑VM2的HOST上的接收程式也又只會紀錄VM2上有的商品而已

然後是資料筆數作觀察,
因為此API為ST公司的M系列,就表示為 API(ST/M)
群益的API,就表示為API(Capital) 吧

2/9台指日盤期交所有132805筆(同秒同價合併只剩53532筆)
API(ST/M) 91083 API(Capital)的有96000

3/6台指日盤期交所有68172筆(同秒同價合併只剩25335筆)
API(ST/M) 46424 API(Capital)的有47400

也就是API的部分明顯都有併筆的機制,既然都是要併筆
那就是看快市瞬間併筆的效率好還是差了,可能要切細去比較,
而ST/M的併筆之前就抓到他有個毛病,同價跨秒時的邏輯有點問題,
也可能是這部分多併了也有蠻大的影響

就架構而言,源頭接收機收資料併筆再打給前端服務器,
併筆的行為只需接收機上處理一次
跟我跑程式分析所有TFE的Tick明細是相同的,只是需瞬間處理更龐大的資料量
接收機則是整個盤間慢慢消化資料,
然後要處理用戶REQUEST REPLY的是前端服務器,它是不用併筆處理的
所以接收機會有併筆與轉格式和提供前端伺服器架構中通訊同步所有市場行情的工作
前端伺服器則是依格式Update轉發給有需求的用戶端
用戶端應該最輕鬆,看註冊那些商品指處理那些商品的Update(姑且不論策略與其他分析)

而用戶端LAG的原因在哪呢?
1.用戶端本身就有問題
2.前端服務器有問題
3.接收機就已經有問題

為何1. 用戶端快市時loading就衝高,
因為程式效能差阿,收的資料量遠不如前端伺服器和接收機,
接收機吃的下全市場行情,用戶端吃不下部分商品行情?

為何2. 前端伺服器快市時未必有高loading卻會有lag?
因為是TCP通訊,有一個用戶卡,Server的如果是同步的架構就大家一起等卡吧

接收機就不說了,自己用盤後資料測試壓力看看吧!!!!!

為何盤後相對有效率? 一般的設計
因為盤中一直收新資料而這些資料需要要求記憶體,
陸續增加記憶體用量的處理機制差,就效能差
這是不論接收機,前端服務程式或用戶端都會碰到相同情況
而盤後記憶體用量已固定,所以就沒有記憶體用量激增的處理邏輯
就像群益的用戶端盤後才上線回補大量Tick時也是會衝高loading,
多跑幾份就跟死了沒兩樣一樣的意思,都是資料一直在新增的處理效率問題

而有時候併筆是另有考量,為了省頻寬省記憶體用量

我跑盤後資料分析則是跟盤中記憶體越吃越大的運作方式是一樣的,
並不是預先留好足夠大的array方便存放資料來讓程式變的有效率,所以才會拿來比較,
而其中反而還得先模擬期交所把資料送出的樣子來打進去處理機制中運作

像是ST/M的API,不論08:45還是09:00從來沒有特別lag過
負載也都很低,VM1從2/6 00:00 跑起來 API只用CPU時間16小時,系統Idle則是690小時
API記憶體有超過6萬檔商品,tick不放記憶體,所以只需不到6MB的記憶體使用量

其實有很多可討論的部分,只是略提一些容易觀察到的
















頁: 1 [2] 3
查看完整版本: 關於台指期的成交Tick的筆數