為何我覺得IB還蠻容易小小斷線
我的網路是Hinet 光世代 + IB 登陸地區"亞洲"
你們都用到企業級的嗎
或是VPN? 本帖最後由 萬年船 於 16-7-15 17:07 編輯
s00701 發表於 16-7-15 16:24
請問一下你們的網路環境是如何
為何我覺得IB還蠻容易小小斷線
我的網路是Hinet 光世代 + IB 登陸地區"亞洲" ...
我還沒開IB戶
剛開始熱身{:4_621:}
準備分散既有台指策略到其他交易所
我用的是亞太IDC機房網路
可用PingInfoView觀察比較
1.本機到IB主機閘道的網路品質
2.本機到其他主機的網路品質
本帖最後由 s00701 於 16-7-16 00:51 編輯
萬年船 發表於 16-7-15 17:04
我還沒開IB戶
剛開始熱身
準備分散既有台指策略到其他交易所
自從知道會斷線後，我有用PingInfoView測試
半夜看ES(SP500)、YM(道瓊)
==============================
平常其實沒什麼問題
大約都200ms~300ms
連續ping 5分鐘 ，次數共250次
全部成功，沒有失敗
但斷線時再Ping，就會斷斷續續有可能整個ping不到
操作上不管是下單、改價、取消......
全部都有可能卡住不執行，有可能卡住數分鐘
一個月大概會遇到5次
(數據機就在我旁邊，確定網路沒有其他干擾及使用者，168.95.1.1 都在6ms以內)
(所有網站皆正常，只有IB相關伺服器會斷線)
後來我找到一個解決方式....FlyVPN(免費VPN)
在斷線時先開啟VPN連到美國，結果...挖靠整個變超順
Tick跳出來的速度比平常還順
(因為物理限制，ping 還是200~300，但Tick感覺真的不一樣)
(此時的網路全部都先連到美國再轉出，反而台灣的網站會變慢)
所以推斷可能有以下情形
1.即使標的物相同，但對不同地區的報價伺服器是不同
美盤時段，對亞洲的報價伺服器可能會維修之類的
●解決方式：從此改用VPN環境，但金融數據用第三方VPN有它的風險
IB 好像有VPN方案，每月美金150
https://www.interactivebrokers.com/en/?f=api&p=comparison1
不知道跟我想像中的是不是同一件事情，希望有前輩能解答
2.網路優先權太低，家用網路聯國外的優先權一定最低
因此遇到重負荷時可能會被排擠
但因為斷線時沒有其他網路可以立即測試
而且改VPN後就變順，所以覺得這個因素的機率應該比較低
●解決方式：企業級網路
=================
因為一直不確定問題點在哪裡，而且也還沒到穩定獲利的階段可以改善環境
希望有能力的前輩們可以多多提點
萬年船 發表於 16-7-15 17:04
我還沒開IB戶
剛開始熱身
準備分散既有台指策略到其他交易所
你的IDC應該也是在台灣用企業級網路去連美國
如果你也遇到IB斷線，那代表我的假設1是正確的
如果你完全沒遇到斷線，那代表我的假設2是正確的
本帖最後由 s00701 於 16-7-16 02:34 編輯
wldtw2008 發表於 16-7-12 15:55
IB的TICK跳動的方式其實很特別。
1. 當此次的(成交價、單量 ) 與上一次的(成交量、單量) 相同時，IB通知總 ...
wldtw2008大大，您對IB Tick如此了解，我不知道您如何辦到的....
我最近發現將整台電腦的網路經由VPN去連美國的伺服器，再去接收IB的報價會順很多
(我用的只是免費的FlyVPN，缺點就是所有連線都會先跑到美國再轉去真正的目的)
比較過兩者的感覺
台灣直連的TAS(time and sales)感覺有被合併過再跳出來，頻率比較慢
透過美國VPN接收就有感覺紀錄是一筆一筆快速的跳出來
不知您可否協助測試看看是否有差異{:4_144:}
萬年船 發表於 16-7-14 16:39
模擬測試使用：MonitorQuote_v2.0.2 (sQuote)
測試條件如下
看了您的報告，如果沒看錯，延遲1秒以上的狀況還不少呢~
這狀況說危險很危險，說不危險並不危險，怎麼說呢?
危險的是如果用MARKET單，如果延遲了一秒，價格很可能跑遠了。
不危險的是，如果改用STOP單掛去交易所，而策略是用1min bar + next bar，那其實沒什麼差別～
只是，我覺得1秒的延遲還是有點多，畢竟MC要錢，所以我們一定盡可能在一個MC上擺上最多的商品&好多個策略，
如果哪個時候大噴發，影響就慘烈了。
其實我覺得有另外的解決方法，以ES來說，一整天40~50幾萬筆中，價格有變化的有效跳動大概不過一萬筆以內，
因此如果能有個過濾器，裝在API送來TICK之後、進MC之前，由這個過濾器去判斷現在的價格跟上次不同或超過250ms沒更新過，才放行，那就可以大幅減低TICK數了，那也就可以有效避免MC延遲、CPU 100%了。
如下：
交易所====>報價商=====>券商軟體------->API---->[過濾器]---->QM------->MC
當然，有資料潔癖的人不可能接受、做高頻的人不能接受就是了。
本帖最後由 萬年船 於 16-7-16 13:35 編輯
wldtw2008 發表於 16-7-16 10:49
看了您的報告，如果沒看錯，延遲1秒以上的狀況還不少呢~
這狀況說危險很危險，說不危險並不危險，怎麼說 ...
其實我真正的盤算是，在MultiCharts原廠論壇公開此瓶頸問題（附上sQuote報價模擬器）
當此瓶頸問題被攤在陽光下，其他大量交易ES的網友會比我們還緊張此問題
到時再集結其他原廠論壇網友的力量，強力請求原廠改善此瓶頸問題
（其實我估計原廠是有意識到此問題的，只是沒把重心放在處理此問題上）
這就是不當黑手，當消費者的好處
只需動手驗證問題，再出一張嘴，接下來就是等廠商解決問題了
{:4_665:}
只是我的優先順序會是
先搞定私人分散策略到海期的相關事情（目標商品選定、外國經紀商開戶、接數據源）
等上線後，閒暇之餘，再來Push原廠解決此問題
萬年船 發表於 16-7-16 12:24
其實我真正的盤算是，在MultiCharts原廠論壇公開此瓶頸問題（附上sQuote報價模擬器）
當此瓶頸問題被攤在 ...
坦白說，我覺得效能問題跟架構有關。
MC發展了五六年，架構底定，應該很難有很好的改善了（能做早就做了），做為一個散戶應用的平台，他們的確做到了多面討好(能吃各種報價源、能下單到各種券商)，這兩三年從7.x 8.x 9.x看他的Release Note，大概就都是又支援了什麼什麼券商、又改善了什麼什麼平台的什麼什麼委託問題。
現在他已經成為聖誕樹一樣掛了一堆閃亮飾品(功能)，多面討好就意味著他不是朝效能最佳化在調整，現在要做效能調整，就勢必動到架構，但一個產品生命週期到了後段，要做架構調整實在很投鼠忌器、動輒得咎，我覺得是很難且不樂觀的了。
wldtw2008 發表於 16-7-16 13:37
坦白說，我覺得效能問題跟架構有關。
MC發展了五六年，架構底定，應該很難有很好的改善了（能做早就做了 ...
確實有可能會動到架構
不過還是給MultiCharts原廠一個機會，試試看吧
萬年船 發表於 16-7-15 14:00
To T大,
請問你的Rithmic數據源是哪來的呢？AMP開戶附的嗎？還是另外購買的像eSignal一樣？
如有空且在非交 ...
萬大:我的rithmic 是 DDT 選的---deepdiscounttrading
http://deepdiscounttrading.com/TradingPlatforms.html
好我來跑看看 ticks/sec 的volume 看看.
頁:
1
[2]