Jump to content
Co nového? Mé kurzy
Komunita:
Diskuze Sledované příspěvky Žebříčky

Doporučené příspěvky

Odesláno

Zdravím,

zajímalo by mě, zda někdo používá virtuální servery pro trading? Máte případně nějaký tip? Svůj trading provozuji na vlastním serveru v ČR, ale přemýšlím, že bych zkusil pronájem serveru v Chicagu nebo NY, kvůli rychlejším exekucím. Děkuji za jakýkoliv tip.

  • Odpovědí 33
  • Vytvořeno
  • Poslední

Nejaktivnější diskutující

Nejaktivnější diskutující

Publikované obrázky

Odesláno

Zdravím Tomáši,
Neprovozuji sice trading na virtuálním serveru u nás ani v USA, ale jsem poměrně skeptický v otázce zrychlení exekucí pomocí severu přímo v Chicagu. Výsledný PING (odezva) by musel být nižší než součet PINGů které potřebujete k exekuci ze serveru v ČR popř přímo z vašeho NTB. Nemám to ověřeno, ale předpokládám, že by se mohlo jednat o zlepšení maximálně v řádech jednotek až desítek milisekund.

Jako výhodu to ovšem vidím v možném zajištění proti výpadku proudu či internetového připojení a bezpečnější vazby OCO (pokud ji nedrží Broker u sebe). Hledáte virtual server pro svoje AOS?

S pozdravem,
Vojta

Odesláno

Já. Používám virtuální server od společnosti tvujweb.net/, ale je to v ČR. Zkušenosti zde: blog.vyvojar.cz/xzajic/archive/2010/08/26/vps-hosting-kter-opravdu-funguje.aspx

Ohledně tradingu na tom využívám AOS, který jsem celý napsal sám (existující řešení mi nevyhovovala) a data tahám od Interactive brokers. Ovšem mě (na pairtrading) nějaká prodleva 2-3 vteřiny je úplně ukradená.

Otázka je, co byste pronájmem serveru v zahraničí získal. Pokud nevyžadujete vyloženě exekuci v řádu setin vteřiny, ale postačí Vám 1-2 vteřiny mezi zadáním obchodů a jeho exekucí, tak si myslím, že stačí server v ČR. Ostatně stejně se (skoro) vždy AOS rozhoduje podle toho, jak mu tečou data, tzn. buď když doputují TICKOVÁ data, nebo když doputují BAROVÁ data, a tam podle mě nějaká latence bude i v tom Chicagu.

Odesláno

Tomáši, na to je potřeba se podívat čistě prakticky. Mít svůj server blízko burzy se z hlediska času exekucí vyplatí, pokud na serveru běží AOS a neobchodujete přes něj manuálně - pokud jste na něj vzdáleně přihlášen, tak vám vzniká tak jako tak zpoždění + větší nároky na kapacitu vašeho připojení.
Pokud ale AOS běží a vy to potřebujete vzdáleně jenom spravovat a kontrolovat, tak to výhody má. Exekuce v závislosti na vašem brokerovi jsou kolem 10 - 50 ms proti cca 130 - 150 ms v ideálním případě odsud. Hlavně v rychlejším trhu to svůj význam má, protože dostanete konzistentnější slippage, které se budou (bavíme se o market příkazech) blížit obvyklému spreadu mezi ask/bid na daném instrumentu. Pro TF např. budete mít většinu výskytů slippage 1 tick a rozptyl bude o něco nižší. Pokud AOS běží zde, je rozptyl slippage vyšší, ale neznamená to, že bude nutně vyšší i absolutní číšlo.
Logika uvažování velí si myslet že delší čas mezi posláním příkazu a exekucí na trhu = vyšší slippage, ale není tomu vždy tak. Na trhu bývá často hodně příkazů typu buy/sell-if-touched a takové příkazy pokud jsou dostatečně velké, posunou trh ve váš prospěch než to tam doběhne, stačí, že tam zrovna někdo jiný pošle tick ve stejném směru jako vy. Pak se stane, že můžete mít nulovou slippage nebo dokonce pozitivní.

Před nějakou dobou jsem mluvil s lidma od Mirusu a prý chystali nějaké větší serverovny, hostování přes VM, ale nevím jak jsou daleko, tak zkusím zjistit. Pokud už by to měli přeipravené, šel bych k nim taky, jsou to profíci a mám s nima dobré zkušenosti. Jinak lze vzít cokoliv, co má dobré reference, stačí si pár hodin googlit a najít si co vám nejlíp vyhovuje..

Odesláno

Děkuji za reakce.

Honza K., jak jsme se bavili už dříve, trápí mě EMD. Tam jsem zažil opakovaně slip i 4-6 ticků. Trochu se to zlepšilo, když jsem exit na konce dne změnil z 22:15 na 22:00, ale pořád tam ty exekuce zlobí. TF jede vcelku v předpokládaném "normálu", trochu horší to bývá ještě na Japonském Yenu, kde sice nemám větší slip než 1 tick, ale zato mám na téměř každém obchodě. Předminulý měsíc se slipy jen na JY nasčítaly na cca 1000 USD. Sice má strategie velmi vysoký AVG Trade, takže to není tak kritické, ale zjevně jakékoliv zlepšení tu prostě pomůže.

Odesláno

Aha, ono v podstatě každý trh je specifický a je třeba se s tím vypořádat. Serverhosting v USA vám možná trochu pomůže, ale nemyslím si, že nějak významně, pokud odsud máte exekuce bez větších problémů, tedy mám na mysli latence. Vyšší slippage mají všichni, co znám, vč. lidí, kteří mají svůj komp jenom několik set metrů od datacenter burz, je to dané hloubkou trhu, která je hlavně po 22 hodině už docela malá a začínají se projevovat spready mezi ask/bid i několik ticků. Spíše bych se tedy změřil na úpravu systému, možností může být několik - buď nasadit limity a jistit to změnou na makret po určité době (tipuju cca 30 - 60 sekund by se dalo risknout) nebo zkoušet zavírat v době nejvyšší likvidity mezi 21:50 - 22:00. Zavírat přesně ve 22:00 je taky dost nebezpečné, protože tam lítaj velké příkazy a můžou vám pěkně uškodit.
Podle mých zkušeností je dobré zavírat cca 21:57 nebo kolem 22:03.
Pokud i pak se vám to nebude moc líbit, tak na to mám už jedinou radu - zvyknout is na to a počítat s tím, nebo se na to vykašlat :)

Odesláno

Už jsem to tady psal v jiné diskuzi...

Zalezi na tom co s tou VPS chces delat. Na pozicni obchodovani staci jakakoliv rozumna VPS treba i tady v Cesku. Pokud jde ale o AOS na intradenni obchody (pripadne v extremu i scalping) pak je nejlepsi zvolit co-location server burzy na ktere chci obchodovat. CME ma Chicagu nove co-location centrum v Aurora, IL - puvodni (=hodne drahe) co-location servers jsou přímo na Cermak St. v Chicago-downtown vedle burzy.
"CME Group’s trading match engine, which is located in the data center, allows for the lowest latency connectivity possible for all products traded on the CME Globex platform."

Optimus Futures (+Vision Clearing + Rithmic ) ma VPS v Aurora co-loc.. od 60 $ mesicne (s Windows hostingem pro retailovy Ninja Trader). Datovy ping do 1 ms. Tomu se maloco vyrovna (za ty $).
www.optimusfutures.com/hosted_ninjatrader.html

Rychlejsi reseni nabizi Rithmic (asi pres EOT Pro? nevim jiste). Za 300 $ ... tick-to-trade 250µs . Maji svoje API pro AOSy psane primo v C++/C#/.NET bezici bez platformy. S tim uz se daji pouzivat AOSy i na scalpovani.

Jeste k tomu pozicnimu obchodovani - pri pouzivani STOP-MARKET prikazu ke vstupu mivaji lidi z evropske VPS obcas celkem velke skluzy. Kdyz se trh hybe rychle a dojde k rychlemu prurazu, tak byvaji rozdily ve skluzech i mezi jednotlivymi brokery. Zalezi taky na infrastrukture...jak je STOP prikaz reseny, jestli je zadany jen v platforme a posila se brokerovi az v okamziku prurazu a nebo jestli stop-prikaz ceka na servech brokera.

Odesláno

Do HFT asi nemá cenu moc zabíhat, pro "běžného" tradera je spíš důležité, aby neměl výpadky a nestabilní připojení. Se slippage se dá rozumně počítat a pokud zrovna neposíláte příkazy přímo bez prostředníka (broker) a skrz svoje vlastní superrychlé AOS schopné využít mikrosekundových intervalů na servery burzy, jsou pro vás benefity z takto rychlých připojení v podstatě nulové. Bylo by to jako s procesorem v PC, ten taky většinu času jenom čeká, až se ostatní části PC rozhoupají a pošlou mu intrukce k rychlému vyřízení :)

Odesláno

tak sem chtel pridat ale posledni dva prispevky to vpodstate odpovedeli, DMA s co location je dnes mozne do tis dolaru poridit viz optimus ci advantage futures, kdo hleda urcite najde i jine lepsi firmy. Taky si myslim ze pokud neni AOS napsany tak aby primo poslilal prikazy do trhu, vyuzival detailni strukturu a pravidel implementace order booku, je to zbytecne honit se za co nejnizsi rychlosti. Staci mrknout na nanex.com

Odesláno

Nkde jsem videl srovnani slipage STOP prikazu u IB a Mirus. Oboje obchodovano z jedne VPS, IB/java-TWS a Mirus/web-platform. Rozdily ve slipage u stejnych prikazu tam byly i 10 pipsu na rychle CL. Slo o prurazy dennich high/low na rope CL. Podle me se treba u stop prikazu vyplati mit VPS co nejbliz. Jsou v tom rozdily.

Odesláno

Díky za srovnání, nepřekvapuje mě to, IB je známé tím, že má větší slippage, notabene když čekáte se stp příkazy na průraz u rychlého trhu. No narazil jste na dobrou věc, doposud jsme se bavili na úrovni jednoho brokera, ale pravdou je, že HODNĚ záleží, jakého brokera máte a je pravda, že vyšší slippage nemusí být způsobeny jenom vaší vzdáleností a připojením, ale mezičlánkem - totiž vašim brokerem a jeho infrastruktuře. A v tomhle směru mě TS po upgradu jejich infrastrukuty (kdy to vlastně dělali... tuším minulý rok někdy na jaře) nikdy nezklamalo. Což např. o IB říct nemůžu.

Odesláno

mala poznamka k rychlosti a slippage, tak jak dnes funguji vetsina trhu globalne a usa, kde market makeria a liquidity providers jsou ve vetsine pripadu HFT firmy, ktere operuji v radu jednotek milisekund a neustale zvysuji zvoji rychlost exekuce. V momente kdy clovek za obrazovkou zada prikaz dle ceny co vidi, muze byt cena na trhu uplne nekde jinde. Dle jedne studie sachovy mistr je schopen se rozhodnout zhruba v 650mili sekundach, normalni bezny smrtelnik samozrejme rozhoduje o trochu dele. OK at rozhodjue pocitac vas pocitac prijme data v case 0 trva mu vyhodnoceni a zaslani prikazu nekolik ms, prikaz jde k borkerovi a pak do trhu, toto prodleni trva svuji cas, opet zalezi na infrastrukture brokera, v momente kdy se objevi na trhu uz doslo k prodleve. Behem tohoto casu trzni cena je, dle situace blize ci dale od vasi ceny. Samozrejme pokud vyuzivate limit tak by teoreticky melo dojit k exekuci na dane cene a k lepsimu plneni. Opet nanex vyborny zdroj info o soucasnem trznim prostredi.

Odesláno

Zdravím všetkých traderov.
Len taká myšlienka pre Tomáša.
Neišlo by urobiť u AOS breakout systémov vstupovanie do obchodu bez slippage tak, že by AOS nedával povel na vstup až po splnení filtra (väčšinou nejaká úroveň na ďalšej úsečke), ale by na tejto ďalšej úsečke rovno pri open zadal limit buy (pre long)? Myslím rovno brokerovi a nedržať to v platforme. Vychádzam z toho, že pri BO systémoch musia byť na "nejakej" úsečke splnené "isté" podmienky a na následnej úsečke sa už len čaká na prerazenie "určitej" úrovne. Jediný problém vidím v tom, že by asi muselo byť v kóde aj zrušenie u brokera tohoto čakajúceho príkazu v prípade, že by sa daná úroveň neprekročila, čo neviem ako je komplikované. K tomu by sa mohli vyjadriť tí, čo programujú napr. v TS alebo NT.
Pekný deň.
Vlado


×
×
  • Vytvořit...