Jo, gal spredai savo dave. Ju atsikratyti per komisinius nebent, bet admiraluose ir panasiuose reiktu puse uzdarbio atiduot. O dabar nezinau kaip cia suktis, dabar reiktu pritaikyti prekyba tam tikrom valandom nebent, bet jau siandien pavargau rytoj bandysiu. Arba keltis is m5 i h1

Padėka forumo nariui Sauliui-fx. Jam patarus prisiregistravau AmazonWebService, prisijungiau prie debesų kompiuterijos paslaugos.

Kol kas vaizdas ten truputį gražesnis, nei kad susiinstaliavus robotą paprastame VPS. Paprastai nuo "modify order" iki "order modified" praeina apie 0,15 sec. Pagal algoritmą mano robotas išstato buy-stop ir sell-stop atidėtus pavedimus, ir juos kas minutę modifikuoja (palaiko 13 pip. atstumą nuo esamos kainos). Tai dabar beveik visada vieną pavedimą modifikavus, kito modifikavimas pradedamas nedelsiant nei vienos milisekundės. Testuojant robotą paprastame VPS taip pasitaikydavo retai, įtariau, kad čia latency problema. Vakare, pradėjus kalbėti M. Dragiui, kurį laiką pavedimai buvo vykdomi maždaug 0,25-0,30 sec. Gaila, kad šiandien ir rytoj neskelbiama svarbių ekonominių naujienų iš ES ir JAV, tai dar per anksti daryti išvadas. New home sales tai nors myfxbook kalendoriuje ir pažymėtas raudonai, bet iš tikro tai rinkų nesujudina. Reikia sulaukti non-farm payrolls skelbimo, tada bus viskas aiškiau matyti.

Latency iki brokerio serverio yra 11 milisekundžių. Na, šioks toks latency mažinimo rezervas. Bet gal dar ką galima padaryti. Gal AWS reikėtų daugiau resursų naudoti. Dabar naudoju nemokamą planą, bet jeigu tas padėtų - neketinu būti nachalevščikas.

Vis dar nenuleidi rankų su "Galaktiko" robotu, ar čia jau kitą testuoji?

Kol kas šitą patį. Bet dabar aš ne tiek apie konkretų robotą, kaip kad apie tai, kaip latency sumažinti iki minimumo. Juk yra ir daugiau robotų, kurių sėkmingam veikimui esminę reikšmę turi greitas pavedimų vykdymas (pvz. Sicuro-News, AmazingEA ir kt.). Tai kai sumažinsiu latency kiek įmanoma, tada ir išsirinksiu kurie iš jų geriausi.
Nors "Galaktika" čia man labai tinkamas dėlto, kad siunčia daugybę signalų modifikuoti pavedimus. Jau po keleto valandų jį paleidus dirbti realioje sąskaitoje (visgi nelabai pasitikiu demo) turiu nemaža medžiagos log'ų analizei.

Oho, įdomu kas nutiko šiandien 17:38 val mūsų laiku, kad foreksas taip sudrebėjo. Visgi dabar man nėra prioritetas sekti pasaulinius, tačiau tiesiogiai manęs neliečiančius įvykius. Užtenka, kad tokios nepaprastos situacijos yra puikus techninių prekybos galimybių testavimo laikas.
Žodžiu, rinkoms sujudėjus, mano robotas nedelsiant pagavo net 28 pipsų staigų judesį, visiškai iš karto po to - dar 14. Tiesa, paskui gaudydamas tolesnius mažesnius šokinėjimus, dalį šio pelno iššvaistė. Na, bet man dabar pelnas/nuostolis čia visiškai nesvarbu, svarbu ar neprailgėja latency periodas.
Taigi, dabar naudojuosi Amazon Web Service "debesiniu" VPS. Nors esu pasirinkęs nemokamą planą, bet rezultatai vis viena geresni nei naudojant įprastą mokamą VPS. Truputį paradoksalu, bet taip yra, kad nemokama paslauga geresnė už mokamą. Visgi, vaizdas kol kas manęs netenkina. Didžiausia latency sudarė 6 sec., greta buvo 5 sec., keletą kartų po 3 sec., dauguma - po 1 sec.
Taigi, ką dar galėčiau padaryti:
1) pasirinkti brangų AWS VPS planą. Nors dėl šito abejoju. Buvau vienu metu jį užsisakęs, bet normaliomis rinkos sąlygomis nepastebėjau, kad jį naudojant latency būtų trumpesnė. vengdamas nereikalingų išlaidų, bandymo ilgai netęsiau.
2) pasinaudoti galimybe išplėsti, "expandinti" turimą nemokamą paskyrą ("instance"). Jei šitas variantas galėtų padėti - kokius parametrus reikėtų plėsti pirmiausia?
3) Problema - netinkama serverio lokacija. Serveris stovi Frankfurte, artimiausias brokerio duomenų centras - Berlyne. na, bet prekybos platforma rodo, kad latency sudaro tik apie 10 milisec., tai kažin ar tas galėtų turėti esminės reikšmės.
4) Čia jau nebe VPS, o brokerio problema. Reikia ieškoti brokerio, galbūt ne žemų kainų lyderio, bet kursi greitai apdoroja pavedimus net tokiomis ekstremaliomis sąlygomis.
5) Čia valiutų poros problema. Reikalas tame, kad jei rinką sujudina naujienos iš Australijos, Naujosios Zelandijos ar Kanados, tai sujuda poros su AUD, NZD arba CAD. Tačiau, poromis, kuriose yra šios valiutos, prekiaujama rečiau, nei poromis, kuriose yra EUR ar USD. Todėl reikia prekiauti tokiomis poromis kaip AUDUSD, NZDUSD ar USDCAD, bet kreipiant dėmesį į naujienas ne iš JAV. Staigus judėjimas, sukeltas, pvz. naujienų iš Australijos brokerio darbo apimtis staiga padidins, bet mažiau, nei naujienos iš JAV.
Nu, žodžiu, padėkit kas nors, o tai man beliks prašyti forumo administratoriaus leidimo viešai nusikeikti.
Dar beja, brokeris Forex4you šiandien spredą išplėtė tik iki 1.2 pip. Tokiam AdmiralMarkets čia būtų ne išplėtimas, o suglaudimas.

O kokia pagalba tau reikalinga? Kad pagimdyti persvara kur jos negali buti is principo?

Nu, kad kas patartų, kaip padaryti, kad niekada, net skelbiant palūkanų norma ir non-farmus latency nepailgėtų. Va, Saulius-fx patarė AWS naudoti, ir priartėjau prie problemos sprendinio. Nors, gal iš viso, čia toks labiau techninis klausimas, tai reikėtų klausti kokiame nors kompiuterių inžinierių, o ne prekiautojų forume.

Jei tau svarbus vėlinimas, iš pradžių reikia išsiaiškinti, kur yra įkurdinti tavo brokerio serveriai, į kuriuos tu jungiesi. AWS yra tikrai geras sprendimas (pats naudoju), bet nebūtinai pats geriausias, jei vėlinimas tikrai toks svarbus faktorius.

Astronautas, siūlau tau dar kartą įdėmiai perskaityti #486090 žinutę ir suprasti, kad žaisdamas su VDS/VPS, vėlinimo laiką gali sutrumpinti ne daugiau kaip 100ms. Per ~100ms informacija arba duomenys internetu gali būti pristatyti iš bet kurios pasaulio vietos į bet kurią kitą.
Suprask, kad 3-6 sekundžių vėlinimai atsiranda ne kur kitur, o tik brokerio MT4 serveryje. Ir tai - čia daugiau ne informacijos/duomenų transportavimo, o pavedimų vykdymo laiko ištęsimo problema.
Ne toje vietoje knisiesi... Vienintelis patarimas - ieškok brokerio, kurio vykdymas nestriginėja per makroekonomines naujienas.

Tai jau matyt reikės naują kom. paslaugų sąskaitos kopiją pasidarius ją kartu su paso kopija vėl visur aplinkui siuntinėti. Įtariu, kad tie brokeriai, kurie siūlo mažą spredą ir komisiją, turi taupyti ant kompiuterinės technikos. Mokesčiai brokeriui yra akivaizdus dalykas, kurį supranta ir visai nepatyręs prekiautojas, o kažkokia latency mažai kam rūpi. Tai galima ant jos ir pataupyti.

Tai, kad brokeriai dazniausia is viso neturi tos kompiuterines technikos. Nuomoja serverius kur nors pas Equinix ir ten sukasi ju metatrader serveris. Geriausia ka gali tai tame paciame serveryje issipirkti vietos savo terminalui. Tada gal but bus ir brokerio serveris, ir tavo platforma tame paciame pastate.

Aš jums siūlau dar kartą paskaityti Egis_1974 žinutę ir nebespręsti problemų ten, kur jų nėra.

Astronautas,bandyk FOREX-COM brokeri paziuret.

Padėka forumo nariams Youngcat bei Egis_1974.
Žodžiu, pamėginau derinti brokerį AdmiralMarkets ir AmazonWebService "debesėlį" (nesijuokit, kompiuteristai, dėl netikslios terminijos, manau aišku apie ką kalbu). Šiandien paskelbus non-farm payrols'ui, ir rinkai darant didįjį šuolį iš karto po naujienų, brokeris ilgiausia "užvilkino" pavedimo modifikavimą 170 milisekundžių. Šiaip tai paprastai viskas įtilpo į 100 milisekundžių. Čia rašė teisybę http://www.financemagnates.com/forex/technology/admiral-markets-adopts-advanced-ecn-solution-from-amts/ Už vis apmaudžiausia būtų, jei paaiškėtų, kad robotą "pažadinau" ne tuo laiku, kai buvo skelbiamos naujienos, todėl ir nepadidėjo latency. Bet kad ir kaip žiūriu, visiškai nepanašu, kad būčiau galėjęs taip suklysti.

Gaila truputį, kad AdmiralMarkets brokeris netinkamas naujienų prekybai dėl didelių spredų. Pvz. myfxbook tinklapio duomenimis, šiandien skelbiant naujienas EURUSD spredas buvo išplatėjęs iki 12 pip., paskui dar keletą minučių vidutiniškai buvo apie 3 pip. Kiek galima suprasti, čia Admiral.Markets sąskaitos duomenys, tikriausia Admiral.Prime sąskaitoje tie spredai būna ir mažesni, bet didelis pradinis depozitas ir kad nėra galimybės prekiauti mikrolotais, šį sąskaitos tipą daro nekonkurencingą.
Bet niekis, yra tų brokerių, tik reikia juos tikrinti. Forex.com brokeris, kurį pasiūlė zemaituks, kiek matau, irgi nustato didelius spredus, nors jo tinklapyje, taip, radau nemaža vilčių teikiančios informacijos, kiek tas susiję su pavedimų vykdymo sparta.

Vo blyn, buvau atsitraukes, ziuriu vienoj temoj padeka, kitoj net ir pinigus gruda
Del Admiral Pro saskaitu, tai is principo ten spread turi buti didesnis nei paprastoje. Siandien nebuvau prie PC, bet anksciau tai ir virs 30.0pip per NFP. Pro saskaitose jau orderiai kartais nukeliauja tolyn, rizikos neprisiima ir bonusu depozitui neduoda. O kadangi nukeliauja iki banku, tai tie jau nepraleidzia tokios progos pasipinigauti. Tokiais momentais bankai uzsiima tikru arbitrazu, ne tokiu kaip Tonis, bet tikru tikriausiu. Per NFP yra labai didelis perkanciuju ir parduodanciuju kiekis. Tai bankai tuo paciu momentu is vieno perka, o kitam parduoda su 10, 20, 30 pip skirtumu be jokios rizikos. Todel jie suinteresuoti spread isplesti kuo daugiau, geras biznis, ane.

Tiek jau to tie Admiral'ai. Va, žiūriu šiandien per NFP EURUSD spredą buvo išplėtę OneTrade iki 1.0 pip., o dar tvirtina, kad jų latency yra ultra-low, nes naudojasi Equinix serveriais. Atrasiu brokerį, tinkamą naujienų prekybai ir dėlto, kad būtų neplėšrus spredui, ir būtų gera latency. Juk pasaulyje jų keletas šimtų yra.

Kartais atrodo, kad iki gralio truksta tiek nedaug, kad jis jau pasiekiamas ranka.

Daugelis forex robotų turi nustatymą "max. spread". Šiandien visą dieną mėginu įsivaizduoti, kokią apsaugą šis nustatymas teikia realiai. Imkime sekančias situacijas:

Ketiname sudaryti sell sandorį. Rinka rami, spredas įprastinis, maksimalios ribos neviršija. Žodžiu, atidarome sell poziciją. Tačiau tada spredas ima ir išsiplečia tiek, kad viršija "max. spread" nustatymą. Tuo tarpu roboto algoritmas kaip tik generuoja signalą pozicijos uždarymui (nesvarbu su pelnu ar nuostoliu). Kas toliau? Jei visgi poziciją uždarome, tai gaunasi, kad faktiškai sumokėjome spredo daugiau, nei ketinome, t.y. apsauga nesuveikė. Jeigu laukiame kol spredas sunormalės, tai iki to laiko kaina gali nueiti nežinia kur, ir taip iškraipyti visą strategijos logiką.

Su pirkimais yra kiek kitaip. Forex teorija moko, kad buy sandorio atveju, spredą sumokame jo atidarymo momentu, o sell sandorio atveju - uždarymo. Išeitų, kad atidarius buy sandorį, mums nebeturėtų rūpėti ar spredas didės, ar mažės. Juk įprasta praktika, kad savo mark-up brokeriai užsideda dirbtinai paaukštindami ask kainą. Spredą jau sumokėjome, ir mus turi dominti tik kainos judėjimas, o ne "išsiskėtimas". Tačiau, pažiūrėkime kas nutinka penktadienio vakare, užsidarant rinkoms. Tada ask staigiai šoksta į viršų, o bid krenta žemyn. Tai vargu, ar turint atvirą buy poziciją galime būti ramūs dėl spredo. Tačiau, kaip tokiu atveju veiktų "max. spread" apsauga.

Tai gal kas žino, gali atsakyti į šį klausimą, nes spredas dažnai yra pelno ar nuostolio klausimas.

Tokia "apsauga" priklauso nuo konkretaus roboto "apsaugos" algoritmo. Kaip programeris padare, taip ir veiks. Speju, kad dazniausiai tai naudojama del entry - jei spread virsina maximuma, tai sandoris neivykdomas/ praleidziamas, arba nukeliamas iki kol susinormalizuos spread.



Tiesiog kvaila teorija ir daugiau nieko.

Tyrinėju vieną robotą, siekdamas išsiaiškinti ką duoda ar atima tas max. spread nustatymas. Preliminariais duomenimis, tas nustatymas ne tik kad neleidžia įeiti į poziciją, kai spredas viršija nustatytą reikšmę, bet ir išeiti iš jos, kol spredas liks neleistinai didelis. Čia jau visiškas algoritmo iškraipymas gaunasi. Nors aišku, kiti robotai su tokiu nustatymu gali elgtis kitaip.