Prastas? Dabar ziuriu i Admiralus, normaliomis rinkos salygomis, EURUSD, USDJPY tai kad vidutiniskai kokie 2-3 tickai per sekunde tik ir yra, o pas Vipro dar maziau. Tai kur jums 5-6 mazai?




Grafike tickai ir neatsiranda. Na yra tas tickinis laikinas grafikas, bet mes ne apie ji tikrausia. O istorines zvakes susisinchronizuoja su serveriu, jokiu ticku nesiuncia, kad sudarytu M1. Buna, kad pastringa, nestabilus rysys "kazkur' tai pasidaro "nepilnos" zvakes, arba ju nebuna, tai paspadziu desini peles klavisa > Refresh ir atsiranda, susisinchronizuoja.

"Grafike tickai ir neatsiranda"

Einama M1 zvake jis greiciausiai piesia is tu savo ticku streamo, to pacio kuri patiekia i EA start(). Ant bet kokios zvakes matai realiu laiku kaip ji keicias, is cia ir "tickai ant grafiko".

"kokie 2-3 tickai per sekunde tik ir yra, o pas Vipro dar maziau. Tai kur jums 5-6 mazai?"

Nezinau kokiu metu ten printino ^la, ir nezinau ant kiek gali iskreipt rezultata vidutinis paskaiciavimas (todel kad Azija neaktyvi), bet tokie skaiciai normalaus aktyvumo metu yra juokingi Pasiziurek kiek ticku pazeria fjuceriai, to paties euro fjucerio, kuris sudaro gal tik koki 10% cash apyvartos. Nezinau gal OTC FX'e ir realiai tiek mazai sandoriu sudaroma Bet labiau panasu kad tokie skaiciai neatspindi realybes.

Pamenu kokiu milzinisku greiciu vaziuodavo T&S juostele ant kokio nors ES fjucerio. Jeigu eurodoleris tuo paciu metu daro 5-6 tickus - nu tai sry

Kazkur skaičiau, kad apie 2000 tickų per sekundę turėtų būti. Gal ten per api juos ir gaudo.

Anksčiau buvo toks Birt's Patch MT4 terminalui. Jo pagalba buvo galima naudoti Tick'inę duomenų istoriją su MT4 tester'iu... Tačiau, šis sprendimas veikė tik su senesniais terminalo Build'ais. Specialiai vien šiam tikslui aš vis dar laikau 409 Build'o MT4 terminalą.
Be abejo, tokiam testavimui, reikia pačiam turėti kokybišką Tick'inių kotiruočių istoriją...

Paskutine M1 zvake piesiama is ticku streamo, bet tickus ant grafiko as suprantu sitaip ir pas mt4 jie grafike neatsiranda.

Mt4 net nėra latency langelio, kaip pas mt5. Įsivedus brokerio pingą, dar šis tas arčiau realybės. Galima aišku programiškai bandyti viską imituoti.

As ziurejau ne vidutini su azija, o UK, UK-USA, USA sesiju metu. Azijos gali buti ir i minute keli tickai.



Kad rimciau atrodytu galima tu ticku prikurti su pluginais.




Nezinau kur pasiziureti.



Nedaro 5-6 ticku, tik 2-3 normaliomis salygomis. "Nenormaliomis", pvz penktadieni 20:00 pirmaja minute, pas AM - 490 ticku, ty 8.2 ticko per sekunde. Pas Dukascopy irgi panasus skaiciai.
Zinau tik tiek:
1.rimtas brokeris, gauna kotiruotes is keliu provaideriu, tada prafiltuoja ir isrenka geriausias, kurias jis naudoja darbui su retailu. Jis ju per sekunde gal gauna ir 10 ar 20, bet issirenka pacias geriausias. Kitos - velniop.
2.kad jei truktu tu ticku ir truktu svarbiu ticku, tai jau gali atsirasti arbitrazo galimybes.
3.nenormaliomis rinkos salygomis, per naujienas, kai isplestas spread, tai tu ticku brokeris gauna tiek daug, kad galima sakyti darbui naudoja prafiltruotas ir "averagintas" kotiruotes. Ten jos taip virpa, kad ju net neimanoma visu perduoti.

"rimtas brokeris, gauna kotiruotes is keliu provaideriu, tada prafiltuoja ir isrenka geriausias, kurias jis naudoja darbui
su retailu. Jis ju per sekunde gal gauna ir 10 ar 20, bet issirenka pacias geriausias."

Kaip suprast - pacias geriausias Tai gal shudiniausias, jei skirtos retailui

"kad jei truktu tu ticku ir truktu svarbiu ticku, tai jau gali atsirasti arbitrazo galimybes."

Tai jos ir yra, bet per spreda nieko ten nepriarbitrazinsi. Kotiruociu asimetrija - senas SuperTonio irankis, bet turbut dabar jau nebenaudojamas.

Suprast tiesiogiai. Jis darbui atsirenka pacias geriausias, o kiek prie ju po to prisideda ar neprisideda, tai jau jo reikalas. Pvz USDJPY daznai buna nulinis spreadas, tai ka jis dar gali tuo momentu prisideti. Ir aplamai Vipro dabar panasu, kad retailui pradejo duoti institucines kotiruotes ty kokias gauna is likvidatoriu. Admiralai arodo, kad irgi didziaja laiko dali tokias tiekia retailui.




Senas irankis, bet dabar jau pasenes ir apie retaila as ne nekalbu. Arbitrazo galimybiu jau seniai nelike. Jei tu butum stambi kompanija, tu gautum institucini srauta ir galetum arbitrazinti. Spread 0.0-0.3, plius gautum dar po kazkiek baksu uz kiekviena suprekiauta lota, rebatus is tiekejo. Gautusi neigiamas spread, bet vistiek nesigautu arbitrazinti.

Priklauso nuo to, kokio sudėtingumo algoritmas naudojamas ir kokia kalba realizuotas.


Tokia reikšmę, kad algoritmas įvykdys trade'ą arba jo neįvykdys.

Ką daryti su tick'ais jei procesorius užsiėmęs? Agreguoti ir taip mažinti apdorojamų tick'ų kiekį. Aš taip ir darau.

Grafikai formuojami ne pagal gautus tick'us (t.y. ne tik pagal juos), bet ir parsisiunčiant iš serverio užbaigtas istorines žvakes.

Bandžiau tick'us su MQL pagalba skaičiuoti ir šiuo būdu. Rezultatas praktiškai identiškas Print(). Print() tikrai nėra "brangi" funkcija. Tokio pobūdžio užduotims nereikia greito HW. Tiesiog reikia naudoti tiesioginius API kanalus, o ne MT/MQL metakalbą, kurį yra visiškai neefektyvi.

Čia tipo žvakės iš kelių tick'ų? Galima ir su mql. Kalba kaip kalba, po paskutinių patobulinimų nuo C++ nesiskiria, tik gal pati platforma viską lėtina. Tai tenka pačiam ir EMA's su ATR'ais susiprogramuoti? Iš techninės pusės žinoma įdomu. Tik kažin ar pas tokią Oandą ar kitą populiarų brokerį galima efektyviai tickinti su jų praslydimais.

Panašiai. Pvz. gaunu 12 tick'ų per sekundę ir vietoj to, kad siųsčiau visus juos strategijos procesui, siunčių tik vieną: MAX(bid)/MIN(ask) arba MIN(bid)/MAX(ask). Nors tuo pačiu kitas procesas, kuris rašo tick'us į failą (kaupiu istorinę informaciją strategijų testavimui ir pan.) gauna pilną neagreguotą srautą.

Tokiu būdu pavyksta realiu laiku analizuoti 120+ instrumentų. Ir šį darbą puikiai sugeba atlikti beveik pigiausias AWS serveris (t2.micro).

Kai pritruks MT/MQL efektyvumo ir kai tai bent kiek itakos P/L kreive, tai imsimes API kanalu. O dabar, is tavo atprintintu ticku, matau, kad ta P/L kreive labai itakotu toks dirbtinai sukeltas spread. Su tokiomis kotiruotemis tikrai, kad yra ka veikti.

Programuotojas klausia manęs, ar tiks jeigu FIX API connection jis man suprogramuos Java kalba. Ar čia yra didelis skirtumas, kokią programavimo kalbą jis pasirinks?

Java tinka, svarbu, kad teisingai suprogramuotų.
O tu pagalvok, kas ir už kiek visa tai supportins, jeigu kartais programuotojas dings Nepigūs Java programuotojai.

Jeigu labai svarbu performansas, tada managed kodo kalbu reiketu vengt. Tokiu atveju C/C++

Kalbant apie managed koda, JAVA anksciau nusileisdavo performansu .NET/C#. Kaip yra dabar, nezinau

Programuotojas sąžiningas, pripažįsta kad suprogramavus connection c ++ kalba sandoriai galėtų būti vykdomi sparčiau - bet čia jau labai svarbu programuotojo kvalifikacija. Kad vien tik c ++ savaime dar ne rodiklis.
Kitas tai pačia primityviausia kalba suprogramuotų nieko neaiškinęs...

Bet tai jeigu konkrečiau: kiek milisekundžių maždaug, ir nuo ko priklausomai, pailgėtų vykdymas per FIX API, jeigu pasirinkčiau Java, o ne c ++?

O is kur zinot ? Jeigu nera kazkokiu public pasiekiamu testu, reikia paciam darytis tokius testus ir matuot. Bet kokiu atveju reikia ismanyt minimaliai bent abi kalbas, kurias nori sulygint.

C++ yra sudetingesne kalba, ir kvalifikacijos reikia daugiau. Klausimas isviso dar, kiek ten kodo realiai gaunas.

Nepamirškit, kad JAVA turi savo virtualią mašiną (VM) ant kurios sukasi kodas, tuo tarpu C kodas vykdomas tiesiogiai. Vis dėlto, veikimo greitis daug priklauso nuo naudojamų bibliotekų kokybės. Šiais laikas jei kokybiškai parašytas kodas, didelio skirtumo neturėtų būti. Kitas klausimas kiek resursų "valgys" viena ir kita programa. JAVA turėtų naudoti daugiau RAM'o vien dėl VM. Šiaip, forumuose žmonės iki šiol sutaria tik dėl to, kad tai priklauso nuo aplinkybių