Autorius | Žinutė |
2016-07-20 21:00 #480626 | |
Kam reikalingas VPS tai nezinau, bet galima prisigalvoti ivairiu priezasciu. Orderiu vykdymo tai nepagreitinsi, bet ta pirmaja dali, ty komandos nusiuntima i serveri tai butu galima sutrumpinti. Bet ir tas VPS serveris turi buti tam paciam severyje arba salia kaip ir brokerio.
The Power of Technical Analysis
Margin Call |
|
2016-07-20 21:09 #480627 | |
Vps serveris gerai pagalbinems programoms visa para 24/7. Nes kai androidas upgradinasi ar kas gali is remote kompo uzsokt, kaipo atsarga.
|
|
2017-12-01 23:31 #541636 | |
^la: Kalbant apie vykdymo greičius, 150ms (0,15 sek.) yra labai prastas rodiklis. Geras vykdymas yra iki 20ms. Labai geras vykdymas yra 2.5 - 3.5ms. youngcat: Bendra orderiu vykdyma reiketu suskirstyti bent jau i 3 dalis. Pirmoji dalis tai nuo komandos sugeneravimo iki perdavimo serveriui. Antroji - serveris komanda gavo ir vykdo. Trecioji - patvirtinimas apie komandos ivykdyma. Pirmaja dali siek tiek itakoti gali patys klientai, programines irangos ir tinklo deka. Antroji dalis yra svarbiausia, nuo kliento jau nepriklausoma ir tai yra tikrasis orderio vykdymo laikas. Apie ja ir raso ruseliai - 3-4ms. Trecioji dalis - patvirtinimas, tai ne prioritetine dalis. Zinoma, kad klientas noretu ir jos kuo greitesnes, bet tai jau roles nevaidina. youngcat: Pabandziau specialiai is mt4 tiesiogiai atidaryti ir uzdaryti pozicija. Visi trys etapai (komandos nusiuntimas, orderio vykdymas, patvirtinimo sugrazinimas) gavosi atidarymui - 195ms, uzdarymui - 177ms. Ir be jokiu VPS serveriu. Kažkiek daugiau aiškumo atneša MT5 platformos naudojimas. Dirbant su MT4 taip ir lieka neaišku nei kiek laiko trunka, kol serveris gauna nurodymą, nei kiek ilgai jį vykdo, nei kaip greitai patvirtinama apie įvykdymą. Tuo tarpu, MT5 Journal'e vykdymo laikas išskaidomas į sudėtines dalis. Pvz.: 2017.12.01 23:03:23.237 Trades '8515125': market sell 0.01 EURUSD 2017.12.01 23:03:23.280 Trades '8515125': accepted market sell 0.01 EURUSD 2017.12.01 23:03:23.280 Trades '8515125': deal #81102801 sell 0.01 EURUSD at 1.18949 done (based on order #97130851) 2017.12.01 23:03:23.280 Trades '8515125': order #97130851 sell 0.01 / 0.01 EURUSD at 1.18949 done in 43.435 ms Šiuo atveju, taip išeina, kad orderio įvykdymui ir patvirtinimui bendrai imant neprireikė ir 1 ms. Matyt, tą ir turi mintyje brokeriai, kai reklamuojasi, kad orderį įvykdo per 2-3 ms. Tačiau, kaip sutrumpinti tas 42 ms, kurias orderis keliauja iki serverio. Gal FIX API įrangos esmė ir yra panaikinti tą laikotarpį nuo "market sell" iki "accepted market sell". |
|
2017-12-02 01:12 #541659 | |
Aš per daug nesistengdamas optimizuoti vykdymo laikų sandorius vykdau per 12-13ms. Tinklo vėlinimas iki brokerio 8-9ms (RTT). Taigi, gaunasi apie 5ms/sandorį. Iš kurių 1ms yra brokerio vidinis transakcijos vykdymo laikas, o likusias 4ms turbūt būtų galima priskirti mano kodo (ne)efektyvmui.
Perkėlęs prekybos serverį iš Šiaurės Virdžinijos į Equinix NY4 duomenų centrą, tinklo vėlinimą galėčiau sumažinti iki <1ms. Taigi, labai norint ir be didesnių pastangų sandorius retail'ui įmanoma vykdyti per 5-6ms. Ar man tai svarbu? - Ne. Mano vienintelis "pralaidumo" reikalavimas - 28 transakcijos per sekundę, o tam pilnai pakaktų ir 35ms/transakciją. Common sense is not very common
|
|
2017-12-02 09:24 #541678 | |
Tai žiūrim ką turim. Youngcat sandorius atidaro/uždaro su latency apie 186 ms, Astronautui pagaliau pavyko išgauti 45 ms., o ^la suspėja per 13 ms.
^la: Taigi, labai norint ir be didesnių pastangų sandorius retail'ui įmanoma vykdyti per 5-6ms. O tai čia su kokia platforma? Gal reikalinga FIX API ar dar kokia nors speciali įranga? Nes su Metatrader5 geriausiu atveju man gaunasi 10 kartų ilgesnė sandorio vykdymo trukmė (apie Metatrader4 tai jau patyliu). |
|
2017-12-02 12:56 #541699 | |
Reikalinga: tiesioginė API prieiga, programavimo žinios ir patirtis, ne per daug nuo brokerio API prieigos taško nutolęs serveris, kuriame leisite savo kodą.
Tamsta kažkodėl teikiate labai didelę svarbą transakcijos vykdymo trukmei. Nemanau, kad transakcijos vykdymo trukmės sumažinimas nuo 45ms iki 13ms ar 5ms esmingai pagerins tavo pelningumą. Mano manymu, kur kas svarbiau yra vykdymo kokybė brokerio pusėje ir ypač transakciniai kaštai. Common sense is not very common
|
|
2017-12-02 13:53 #541714 | |
Jei sandorį laikome sudarytą bent keletą valandų, mėgindami pagauti swing'ą, tai vykdymo greitis taip, turi tik visiškai neesminę įtaką. Tačiau, kad imtis HFT, ar tuo labiau arbitražo, tai pirmiausia reikia užsitikrinti minimalią latency. Juk tada vykdymo sparta tampa pelno ar nuostolio klausimu.
|
|
2017-12-02 14:04 #541719 | |
Arbitražo strategiju įgyvendinimui reikia gan gerų matematikos ir IT žinių. Dažnas retail brokeris apskritai draudžia tokias strategijas.
Beje, ką vadinate HFT? Kaip įsivaizduojate tokią prekybą? Jei vistik vėlinimas toks svarbus Jūsų prekybai, visų pirma reikėtų atsisakyti MT4 ir MT5 platformų. Jos tam neskirtos "by design". Common sense is not very common
|
|
2017-12-02 14:25 #541723 | |
HFT - tai ir būtų prekyba per žinias, mėginant pagauti greitą kainos judėjimą vos tik paskelbus naujieną. Dėl arbitražo, tai turiu mintyje triangle arbitražą, ne latency. Klausiau keleto brokerių supporto, ir visi atsakė, kad leidžia tokią prekybą. Na, galbūt dėl visa ko reikėtų neleisti, kad pelno (sėkmės atveju) sąskaitoje daug susikauptų, reikėtų jį nuiminėti laikas nuo laiko.
Dabar tyrinėju Metatrader5 platformą, žiūriu, ką iš jos būtų galima paimti geriausio, tačiau visgi iš anksto esu gana skeptiškas jos atžvilgiu. Panašu, kad mėginsiu kaip nors pasinaudoti cTrader platformos teikiama FIX API galimybe. |
|
2017-12-02 14:41 #541727 | |
Sėkmės HFT vandenyse.
Common sense is not very common
|
|
2017-12-02 15:05 #541737 | |
Astronautas [2017-12-02 13:53]: Tačiau, kad imtis HFT, ar tuo labiau arbitražo, tai pirmiausia reikia užsitikrinti minimalią latency. Juk tada vykdymo sparta tampa pelno ar nuostolio klausimu. O tai klasikineje prekyboje jau viskas issemta, kad link HFT patrauke? The Power of Technical Analysis
Margin Call |
|
2017-12-02 15:21 #541740 | |
Kas yra klasikinė prekyba?
Common sense is not very common
|
|
2017-12-02 15:24 #541741 | |
youngcat: Astronautas [2017-12-02 13:53]: Tačiau, kad imtis HFT, ar tuo labiau arbitražo, tai pirmiausia reikia užsitikrinti minimalią latency. Juk tada vykdymo sparta tampa pelno ar nuostolio klausimu. O tai klasikineje prekyboje jau viskas issemta, kad link HFT patrauke? Ne viskas. Bet siekiu būti multithreaded. |
|
2017-12-02 18:26 #541762 | |
Labai abejoju ar tau per naujienas, dėl išsiplėtusių spread'ų, pavyks pagauti ir, svarbiausia, įvykdyti triangle arbitražą. Rinkoje nemokamų pietų nėra.
Dėl siekio būti multithreaded, man tai priminė tokį IT terminą: premature optimization. Common sense is not very common
|
|
2017-12-03 14:46 #541883 | |
Arbitražinės situacijos pavyzdys, iš karto po to, kai penktadienį buvo paskelbti Kanados nedarbo duomenys. Tie duomenys buvo žymiai geresni nei tikėtasi, todėl CAD vertė labai greitai šoko į viršų visų kitų valiutų atžvilgiu. Ir matome, kokie šiuo konkrečiu atveju spredai: EURCAD - 12.1 pip, NZDCAD - 7.8 pip.
Time = 2017.12.01 15:30:06 Bid "EURCHF / NZDCHF" (1.73396) > (1.73208) Ask "EURCAD / NZDCAD", Difference = 18.8 pips EURCHF: 1.16853 1.16867 NZDCHF: 0.67368 0.67391 EURCAD: 1.52806 1.52927 NZDCAD: 0.88291 0.88369 Bet kaip spredas gali trukdyti pagauti arbitražinę situaciją? Jeigu pagauname bid'ą, kokio mums reikia, tai koks skitumas kur tuo metu buvo ask'as ir atvirkščiai? Na, nebent nepavyksta pagauti, tada turime sandorius EURCAD bei NZDCAD sudarę su milžiniškais spredais ir ką mums su jais toliau daryti Bet kad tokią riziką apriboti, tai juk galima įvesti nustatymą max.spread. Būna juk arbitražinių situacijų ir su normaliais spredais, ir be kažin kokių naujienų skelbimų, pvz.: Time = 2017.12.01 15:37:16 Bid "GBPJPY / GBPUSD" (112.62876) > (112.60400) Ask "USDJPY", Difference = 2.5 pips GBPUSD: 1.34635 1.34645 GBPJPY: 151.649 151.655 USDJPY: 112.601 112.604 |
|
2018-01-03 22:09 #547158 | |
^la: Reikalinga: tiesioginė API prieiga, programavimo žinios ir patirtis, ne per daug nuo brokerio API prieigos taško nutolęs serveris, kuriame leisite savo kodą. Svarstau galimybę pasinaudoti cTrader FIX API galimybėmis, būtų kas atlieka programavimo darbus. Serverį tai kur reikės, ten ir pasirinksiu, problema čia mažiausia. Bet rimtai sunerimau paskaitęs čia: https://ctdn.com/forum/ctrader-support/11106 Gal tas cTrader FIX API yra nieko vertas ir verta dairytis kitų variantų |
|
2018-01-03 22:34 #547167 | |
Uzmeciau aki i ta diskusija - toks vaizdas FIX API yra vaistas nuo visu ligu daugeliui. Itarciau tiesiai FXAll and Currenex'a naudojant laikas pageretu automatiskai. Tik kad pinigu reikes saskaitai daugiau.
O ten kolektyvas su kelias ar keliasdesimt tukstanciu lygiu teisiu su HFT reikalauja. |
|
2018-01-08 22:12 #548050 | |
Kaip viena pagrindinių priežasčių, kodėl retail'iniams prekiautojams prekyba per naujienas yra apsunkinta, paprastai įvardijama praslydimai. Įdomu peržiūrėti tick'us, kokie jie būna iš karto paskelbus lauktą naujieną. Tick'ų istoriją galime rasti kiekvienoje MT5 platformoje. Ir tikrai, matyti, kad paskelbus naujieną du gretimus tickus gali skirti net keliolika pipsų. Tačiau, forex brokeriai tick'ų srautą, kurį gauną iš savo likvidumo tiekėjų, "iškarpo", todėl prekiautojai mato ne kiekvieną tick'ą, o tik kai kuriuos jų. Tai gal dirbot kas brokerio kontoroje, todėl žinot ar tik nebus taip, kad paskelbus naujienas brokeriai tick'us imasi "karpyti" ypač aktyviai ir specialiai prekiautojams nepaduoda viso jų ruožo per keliolika pipsų. Tai todėl ir gaunasi šitie praslydimai. Jei taip, tai tada FIX API ir šitą problemą turėtų labai lengvai ištaisyti, nes čia jau gauname pipsus tiesiai iš rinkos, nebe iš brokerio malonės.
Astronautas: Bet rimtai sunerimau paskaitęs čia: https://ctdn.com/forum/ctrader-support/11106 Gal tas cTrader FIX API yra nieko vertas ir verta dairytis kitų variantų Manau, kad tas veikėjas nesuprato reikalo esmės. Jis nesinaudoja FIX API, pagalvojo, kad jeigu platforma teikia tokią galimybę, tai nieko daugiau daryti ir nereikia. Neprašė programuotojo aplikaciją sukurti. Tai iš nežinojimo ir uždavė tokius naivius klausimus. |
Norėdami rašyti forume, turite užsiregistruoti, o jei jau registravotės- prisijungti.