| Autorius | Žinutė |
| 2016-07-19 17:17 #480469 | |
|
Visi martingaile tipo robotai anksciau ar veliau sudegins saskaita,kad ir ta pacia mikro. Isitikinau galutinai,isbandziau daug robotu su sio tipo prekyba.Sugalvojau nauja robota ir zymiai saugesni. Cia nuoroda
https://www.myfxbook.com/portfolio/new-ea-sprinter-specgold/1700013 Taip pat prekyba paprastai https://www.myfxbook.com/portfolio/gintaras-mockus/1697033 |
|
| 2016-07-19 18:47 #480472 | |
|
gntrs [2016-07-19 17:17]: Sugalvojau nauja robota ir zymiai saugesni. Cia nuoroda https://www.myfxbook.com/portfolio/new-ea-sprinter-specgold/1700013 Taip pat prekyba paprastai https://www.myfxbook.com/portfolio/gintaras-mockus/1697033 Yra sukurtas pasigyrimų skyrelis. Čia prašom dėti pačius robotus, demo versijas ir jų backtestus. Žolė ta pati, žmonės tie patys, svetimo turto troškimas tas pats.
|
|
| 2016-07-19 19:51 #480479 | |
|
zinosiu dabar
|
|
| 2016-08-06 17:20 #482202 | |
|
Kažkaip visai pasimečiau kaip reikia taisyklingai nustatyti laiką, jei robotas turi dirbti ne visą parą, o tik tam tikromis valandomis. Žodžiu, robotas turi nustatymus:
Use_Auto_Time — automatinis GMT nustatymas, pagal nutylėjimą FALSE GMT_Offset— rankinis serverinio laiko nustatymas, pagal nutylėjimą 3 UseDST — paisyti vasaros laiką, pagal nutylėjimą FALSE Robotas yra naktinio skalpingo tipo, KIEK SUPRANTU, jis turėtų pradėti darbą likus vienai valandai iki Niujorko sesijos pabaigos, dabar mūsų laiku 23:00 val., ir dirbti tris valandas. Brokeris taip aprašo savo serverio laiką: "server time differs from UTC by 2 hours (UTC +2), and in summer, with a switch to daylight-saving time, the difference equals to UTC +3" (ir kas išgalvojo tą nesąmoningą laikrodžių sukinėjimą )Galbūt reikėtų nustatyti Use_Auto_Time ir UseDST abu kaip true, tada į GMT_Offset būtų galima nekreipti dėmesio. Arba jeigu nustatome Use_Auto_Time kaip false, tada GMT_Offset reikėtų įrašyti 2 (žr. brokerio serverio darbo laikas) ir nustatyti UseDST kaip true. Arba nustatyti Use_Auto_Time ir UseDST abu kaip false, tai tada GMT_Offset rankiniu būdu nustatinėti kaip 2 žiemos laiku ir 3 - vasaros. Pvz. dabar esu nustatęs Use_Auto_Time ir UseDST abu kaip false, GMT_Offset kaip 3 (gerai, kad sutapo brokerio serverio GMT_Offset ir šito parametro defoltinė reikšmė, antraip būčiau visai nežinojęs ką daryti), ir šią savaitę prekybos rezultatai buvo labai geri. Bet viena savaitė - labai jau neįtikinantis rodiklis. Reikia pasidaryti backtestą bent už penkmetį atgal. Dar neaiškiau kaip su tais laiko nustatymais. Gal tada reikia nustatyti Use_Auto_Time ir UseDST abu kaip true ![]() Nu žodžiu, atrodo elementari situacija, bet tiek neaiškumų įneša. Padėkite, kas galite, tuos neaiškumus mesti lauk. |
|
| 2016-08-06 17:58 #482204 | |
|
Parašiau, ir tik tada pastebėjau neblogą paaiškinimą:
Many Expert Advisors use a GMT Offset function for time alignments, specifically when they are active only at certain trading times. Please note that the automatic determination of GMT offset does not function in backtesting. Usually the function "Auto GMT Offset" of the selected Expert Advisor needs to be deactivated and/or the required parameter needs to be entered manually for the purpose of backtesting. Summer and winter times depending on the location of the broker must be set correctly, otherwise the simulation or optimization using wrong GMT Offsets will cause faulty results. Hence, at least 4 test runs (summer/winter time for the first year and summer/winter time for the second year) are necessary. Some brokers use servers with an all-the-year setting of GMT +/- 0. Backtests executed onMetaTrader 4 installations of this type of broker do not require an adjustment of the trading hours during the year or the GMT Offsets. - See more at: http://www.forexgermany.de/en/forex-trading/forex-trading-metatrader-backtesting.html#sthash.UCW9WOhS.dpuf Tai dėl backtesto išeina, kad turi būti Use_Auto_Time — automatinis GMT nustatymas, pagal nutylėjimą FALSE GMT_Offset— rankinis serverinio laiko nustatymas, pagal nutylėjimą 0 UseDST — paisyti vasaros laiką, pagal nutylėjimą FALSE Bet prie klausimo dalies, kaip laiką nustatyti realiai prekybai, tai pasilieku. |
|
|
|
2016-08-08 09:58 #482260
1
|
|
Astronautas [2016-08-06 17:58]: Bet prie klausimo dalies, kaip laiką nustatyti realiai prekybai, tai pasilieku. Taip, tu teisus - su tais laiko nustatymais, ypač jei naudoji dar ir BackTest'us (viskas priklauso dar ir nuo to, kokio brokerio duomenis naudoji, nuo to kada brokeris persukinėja W/S laiką ir t.t.), yra didelis galvos skausmas. Iš esmės, kiekvienas EA gamintojas šiuos nustatymus gali suprogramuoti savaip. Kadangi tu neįvardinai konkretaus EA pavadinimo, galiu rekomenduoti tik pasiskaityti roboto aprašymą ir minėtuosius laiko nustatymus suderinti tiksliai taip, kaip rekomenduoja EA autorius. |
|
| 2016-08-26 21:01 #483986 | |
|
Čia gal nebūtinai apie robotus, manau, kad problema galėtų pasireikšti ir prekiaujant rankiniu būdu, bet nežinau, į kurią temą labiau tiktų.
Žodžiu, savo prekybos log'uose randu tokius įrašus: 07:47:58.672 order #1792266 buy stop 0.01 EURUSD at 1.12942 activated at price 1.12943 07:47:58.953 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12870 tp: 1.14442 -> sl: 1.12872 tp: 1.14442 07:47:59.312 order #1792266 buy 0.01 EURUSD at 1.12943 was modified -> sl: 1.12872 tp: 1.14442 <kito pavedimo modifikacijų įrašus praleidžiu> 08:06:37.646 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12872 tp: 1.14442 -> sl: 1.12955 tp: 1.14442 08:06:39.222 order #1792266 buy 0.01 EURUSD at 1.12943 was modified -> sl: 1.12955 tp: 1.14442 08:06:42.607 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.12995 tp: 1.14442 08:06:43.106 modification of order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.12995 tp: 1.14442 failed [Invalid S/L or T/P] 08:06:45.368 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.13016 tp: 1.14442 08:06:45.634 modification of order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.13016 tp: 1.14442 failed [Invalid S/L or T/P] 08:06:47.412 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.13017 tp: 1.14442 08:06:48.083 modification of order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.13017 tp: 1.14442 failed [Invalid S/L or T/P] 08:06:48.598 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.12961 tp: 1.14442 08:06:48.769 order #1792266 buy 0.01 EURUSD at 1.12943 was modified -> sl: 1.12961 tp: 1.14442 08:06:49.658 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12961 tp: 1.14442 -> sl: 1.12969 tp: 1.14442 08:06:49.955 order #1792266 buy 0.01 EURUSD at 1.12943 was modified -> sl: 1.12969 tp: 1.14442 08:06:50.688 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12969 tp: 1.14442 -> sl: 1.12972 tp: 1.14442 08:06:50.953 order #1792266 buy 0.01 EURUSD at 1.12943 was modified -> sl: 1.12972 tp: 1.14442 08:07:19.954 order #1792266 buy 0.01 EURUSD at 1.12943 closed due stop-loss at price 1.12972 Nu va, pelnas visi 3 pipsai be vieno pipsiuko Tai dar kartą žiūrim ką turim. Robotas niekaip negali perkelti slenkančio stop-loss'o nuo 1.12955 ribos. Iš pradžių jis bandė stop-loss'ą kelti iki 1.12995, po to iki 1.13016, dar po to - iki 1.13017. Na, paskui pavyko šiaip ne taip pakelti iki 1.12961, 1.12969 ir 1.12972. Ties pastarąja riba pavedimas ir buvo uždarytas stabdant "nuostolį". Bet kas visgi konkrečiai sutrukdė robotui stop-loss'ą perkelti iš pat pradžių? Įtariu, kad kai buvo: 08:06:42.607 modify order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.12995 tp: 1.14442 08:06:43.106 modification of order #1792266 buy 0.01 EURUSD at 1.12943 sl: 1.12955 tp: 1.14442 -> sl: 1.12995 tp: 1.14442 failed [Invalid S/L or T/P] kaina per pusę sekundės buvo smuktelėjusi žemiau 1.12995, tai stop-loss'as nebegalėjo būti statomas aukščiau esamos kainos. Bet po smuktelėjimo kaina vėl pajudėjo reikiama linkme. Analogiškai galėjo būti ir kitais dviem nesėkmingo bandymo jį perkelti atvejais. Tačiau čia tik prielaidos ir spėliojimai. Nežinia, kas čia nutiko iš tikrųjų. Taip pat atkreipiu dėmesį ir į nepriimtiną latency. Nuo pagrindo pavedimui pateikti ar modifikuoti praeina pusė sekundės ar netgi daugiau, nors brokeris nurodo, kad vidutinis execution speed yra 0,17 sec. Tai gal jeigu būčiau susitvarkęs su latency taip, kad nebereikėtų pavedimo vykdymo laukti tiek ilgai, tai būtų susiaktyvinęs stop-loss ties 1.12995, nebe ties 1.12972, ir tokiu būdu pelnas būtų buvęs 2.3 pipso didesnis. Ir čia ne pirmas kartas taip, kai bandau prekiauti esant staigiam judėjimui. Gal kas žinote, kaip reikėtų tokių atvejų išvengti. FIX API įranga šiuo metu man būtų neprieinama. |
|
|
|
2016-08-26 21:17 #483989
2
|
|
Astronautas [2016-08-26 21:01]: Brokeris savo tinklapyje nurodo, kad Limit & stop levels - No limit. Kartais informacija brokerio tinklapyje prasilenkia su teisybe. Kad įsitikintum, koks Stop Level yra naudojamas tavo sąskaitoje konkrečiam fin. instrumentui, atlik tokius veiksmus: 1. Aktyvuok to fin. instrumento (pvz., valiutų poros EURUSD) grafiką; 2. Paspausk F9; 3. Type laukelyje pasirink "Pending Order"; 4. Lango apačioje bus užrašas "Open price you set must differ from market price by at least xxx points", kur xxx nurodys minimalų TP arba SL atstumą nuo rinkos kainos. Jei ten 0, vadinasi brokeris iš tikro netaiko jokių ribų; 5. Uždaryk langą, paspausdamas kryžiuką kampe arba Esc klaviatūroje. |
|
| 2016-08-26 21:36 #483991 | |
|
Egis_1974: 4. Lango apačioje bus užrašas "Open price you set must differ from market price by at least xxx points", kur xxx nurodys minimalų TP arba SL atstumą nuo rinkos kainos. Jei ten 0, vadinasi brokeris iš tikro netaiko jokių ribų; Taip ir buvo. "Open price you set must differ from market price by at least 0 points". Brokerio-melagio versija atkrenta. |
|
| 2016-08-26 22:03 #483993 | |
|
Va, dabar dar radau panašų atvejį:
15:55:47.350 delete pending order #1792267 sell stop 0.01 EURUSD at 1.12829 sl: 1.13089 tp: 1.11329 15:55:48.270 deleting of pending order #1792267 sell stop 0.01 EURUSD at 1.12829 sl: 1.13089 tp: 1.11329 failed [Off quotes] 15:55:49.050 delete pending order #1792267 sell stop 0.01 EURUSD at 1.12829 sl: 1.13089 tp: 1.11329 15:55:51.811 deleting of pending order #1792267 sell stop 0.01 EURUSD at 1.12829 sl: 1.13089 tp: 1.11329 failed [Off quotes] 15:55:54.136 delete pending order #1792267 sell stop 0.01 EURUSD at 1.12829 sl: 1.13089 tp: 1.11329 15:55:54.994 deleting of pending order #1792267 sell stop 0.01 EURUSD at 1.12829 sl: 1.13089 tp: 1.11329 failed [Off quotes] 15:56:01.234 delete pending order #1792267 sell stop 0.01 EURUSD at 1.12829 sl: 1.13089 tp: 1.11329 15:56:03.652 pending order #1792267 was deleted Kaip čia reikėtų suprasti tą "Off quotes" |
|
|
|
2016-08-26 22:06 #483995 |
|
Astronautas [2016-08-26 21:01]: ... ir, kiek galima suprasti, kainai einant reikiama linkme S/L perkelia po kiekvieno tick'o. Sulauksi perspejimo is brokerio, kad isjungtum toki robota ir neapkrautum serverio. "Baidenas neduoda, Baidenas sabotuoja."
|
|
| 2016-08-30 23:27 #484349 | |
|
Parašiau paklausimą brokeriui dėlto. Gavau atsakymą:
The most common reasons of blocking: - A continuous stream of requests for opening of an order on the account with insufficient balance for this; - Flood the server with pending orders (thousands of cycles of opening orders and immediately delete it); - Abnormally frequent disconnection and connection to the server (2-3 times per second), etc. Manau, man negresia nei vienas iš šitų punktų. |
|
| 2016-09-08 18:30 #485385 | |
|
Irgi gal ne visai apie robotus, bet kas prekyboje naudoja robotus, tas, tikriausia naudoja ir VPS. Žodžiu, išsiaiškinau, kad netinkamai buvau supratęs MT4 terminalų talpinimo rekomendacijas. Jeigu provider'is nurodo, kad į VPS rekomenduoja talpinti, pvz., 2-5 terminalus, tai nereiškia, kad sutalpinus penkis, visi jie veiks su minimalia latency. Į tokį VPS visus penkis MT4 terminalus verta talpinti nebent jei prekiausime robotais, kurie pozicijas laiko keletą dienų. Tada ir keleto sekundžių latency reikšmės vargu ar galėtų iškraipyti algoritmo veikimą. Tuo tarpu, jeigu reikalinga minimali latency, tai reikia talpinti tik 2 terminalus. Visa kas lieka per vidurį - tarpiniai variantai.
Tačiau, girdėjau pasisakant, kad prekiautojui, kuriam latency turi esminę reikšmę, iš viso verta rinktis VDS, o ne VPS. Gal kas esate naudojęs VDS, galite palyginti su VPS, kokie vieno ir kito privalumai, trūkumai. |
|
|
|
2016-09-08 21:02 #485396 |
![]() ka cia gerchikas sugalvojo?Умный сервис для создания торговых пакетов. Robox |
|
|
|
2016-09-08 22:33 #485402 |
|
Tegul pirmiau sugalvoja pinigu isvedima uz konkurencinga kaina. Nes 40e tai jau apiplesimas.
"Baidenas neduoda, Baidenas sabotuoja."
|
|
| 2016-09-15 18:23 #486058 | |
|
Astronautas: Tačiau, girdėjau pasisakant, kad prekiautojui, kuriam latency turi esminę reikšmę, iš viso verta rinktis VDS, o ne VPS. Gal kas esate naudojęs VDS, galite palyginti su VPS, kokie vieno ir kito privalumai, trūkumai. Na tiek to, kiek galiu visų visko klausinėti, pats pamėginau savo MT4 platformą talpinti ne į VPS, o į VDS. Pasirinkau https://www.vpsnet.lt/lt/paslaugos/vds VDS-1 planą. Ir nekantriai laukiau šiandienos, kai 15.30 val. mūsų laiku bus skelbiami mažmeninės prekybos duomenys ir pirminių bedarbių paraiškų per savaitę skaičius. Šiaip tai paskaičius log'us matyti, kad nuo a la "modify order" iki "order modified" praeina apie 200 ms. Tiesa, būtų 50 ms rezervas, nes tiek eina signalas iki brokerio serverio, nes mano VDS tiekėjo duomenų centras yra Vilniuje. Žodžiu, labai panašiai tiek, kiek brokeris nurodo vykdymo laiką savo tinklapyje. Ar su tokia latency jau galima eiti į news trading'ą - nežinau. Reikėtų pamėginti. Bet svarbu, kad latency tokia ir išliktų naujienų skelbimo metu. Taigi, šiandien grįžęs namo peržiūriu log'us. Nu ir Internetiniai šaltiniai apie VPS ir VDS skirtumus: OK so a VDS allocates resources upfront and can't be oversold. A VDS will give you near dedicated server performance and will cost you provider considerably more in hardware than a cheap budget VPS. To clarify: OpenVZ = VPS (Virtual Private Server) Opensource hypervisor where all machines battle for resources on a first come first serve basis. Only supports Linux operating systems. VPS CAN BE OVERSOLD which can lead to poor performance if provider is greedy. http://www.webhostingtalk.com/showthread.php?t=1085089 A VPS does offer better performance than a traditional shared hosting platform, but is prone to more performance issues than its VDS counterpart. This mainly occurs when a multitude of users are hosting on a single machine. In this environment, bandwidth and memory allocation can be affected by other virtual servers, whereas a VDS ensures that these resources are available, just like having your own server. http://www.serverschool.com/dedicated-servers/what’s-the-difference-between-vps-and-vds/ Žodžiu, kaip supratau aš tą skirtumą. VPS mane patalpina su "kambariokais". Įprastomis sąlygomis nėra problemų įeiti pro duris ir išeiti. Bet ypatingais atvejais, kai visi nori įeiti arba išeiti, tai gali tarpduryje susidaryti grūstys ir spūstys. VDS - atskiras kambarys. Įeisiu pro duris ar išeisiu greitai, kai tik norėsiu, ir jokių spūsčių ten nebus. Bet deja, šiandien grūstis buvo ir VPS. Tačiau, yra ir šaltinių, tvirtinančių, kad VPS ir VDS yra vienas ir tas pats. O gal fizinis serveris čia pagelbėtų? Bet ten jau kainos visai kitos, nebenorėčiau šiaip mėginti, neturėdamas rimto pagrindo tikėtis, kad gausiu norimą rezultatą. |
|
|
|
2016-09-15 18:32 #486059 |
|
Su 512mb ir langinemis ir MT4 - nieko doro nenuveiksi.
Jei treidini tik naujienas - geriau tada aktyvuotis brangu Amazono AWS - pasileidi, susikonfiguruoji pries naujienas, sutreidini naujienas ir istrini. Ir atsisveikinsi tik su kokiu baksu. Ekeftyvu ir neskausiminga ir dar pasirinksi geresne kolokacija. |
|
| 2016-09-15 18:38 #486060 | |
|
Nu, kodėl jau taip skeptiškai. Prekiaujant per naujienas nėra jau tokie baisūs tie spredai. Galima rinktis zero spread instrumentus. Bet ne visi brokeriai taip jau baisiai išplečia tą spredą. Pvz. šiandien per naujienas Forex4you EURUSD spredą "išplėtė" iki 0.9 pip. Nu aišku, kai kurie brokeriai plėtė ir gerokai labiau. Tik tą latency reikia kažkaip minimalizuoti.
saulius-fx: Ir atsisveikinsi tik su kokiu baksu. Ta prasme sumokėsiu tą dolerį Amazon'ui, ar patirsiu nuostolį? |
|
|
|
2016-09-15 19:13 #486063 |
|
As turiu galvoje kad naudodamsis Amazono AWS - gali serveri su reikalingais parametrais, pasileisti tik valandai ar dviems, pasirinkti galingesne konfiguracija ir susimoketi tik doleri ar dar maziau, vietoje to kad laikyti koki leisgyvi serveri ir moketi uz ji kas menesi.
Nebent ten pas tave pastoviai prekiaujantis EA. |
|
| 2016-09-15 19:47 #486068 | |
|
Šiaip tai labai norėčiau su normalia latency išmėginti robotą, gaudantį VISUS staigius judėjimus, t.y. jam būtų reikalingas nepertraukiamas veikimas. Bet galima įvairiai planuoti.
|
|


)
1 

