Jump to content
Co nového? Mé kurzy
Komunita:
Hledat v
  • Více možností...
Najít obsah, který ...
Hledat výsledky v ...
Diskuze Sledované příspěvky Žebříčky

TWS API a dojení historických dat 1


okolo

Doporučené příspěvky

jaaan Napsal:
-------------------------------------------------------
> Napriklad kdyz chceme vterinova data, je mozne je
> skutecne obdrzet i rok nazpatek, ale ne za cely
> rok najednou, pouze za cca 1000 vterin (musim rict
> "dej mi data z 12.3. od 9:00 do 17:00). Sekvenci
> techto pozadavku samozrejme muzu poskladat
> historii za cely rok, ale zase IB API omezuje
> frekvenci, s jakou muzu pozadavky posilat - moc
> rychle nasledujici pozadavky odmitne obslouzit.

Ja jsem pokusne zjistil, ze je mozne stahnout naraz presne 2000 vterinovych baru (coz nemusi odpovidat 2000 vterinam). Ja jsem pro jednoduchost stahoval vzdy 1800 baru (obvykle odpovida pul hodine vterinovych dat). Po kazdem requestu jsem delal tri vteriny pauzu, pak nedochazi k "pacing violation".

Link to comment
Sdílet pomocí služby

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

Nejaktivnější diskutující


Fretka:

Vyborne, to je mozne, ja jsem zkusil 1000 to slo, pak 3000, to uz neslo, presnou mez jsem nehledal :-) A pokud tri vteriny pauza funguje spolehlive, tak by sla cela rocni historie vterinovych dat vygrabovat za pul dne, to zni lakave a stoji to za usili. Zkousel jste to stahovat takto masivne? Nebyly nejake problemy ze strany IB? Neporusujeme tim nejaka jejich pravidla?

willtrader:
Presne tak. Vyhodou, pokud se to dotahne do konce, bude napriklad moznost automatickeho stazeni libovolneho mnozstvi dat (treba zminena rocni historie vterinovych baru), jejich automaticky pravidelny update a export ve formatu citelnem pro jine simulacni nebo chartovaci programy. Jak jsem zminil, excelove reseni jsem nezkousel, ale podle toho, co pise uzivatel okolo v uvodnich prispevcich, by toto v excelu obnaselo budto nekonecnou posloupnost manualnich kroku, anebo napsani vlastniho makra, ktere asi bude slozitosti prinejmensim srovnatelne s java programem.

Jan Marek

Link to comment
Sdílet pomocí služby


Myk: presne tak, taky jsem hledal, kde jsou ty knihovny, nez jsem zjistil, ze se instaluji zvlast :-)
Jinak velice doporucuju ono zminene wiki
chuckcaplan.com/twsapi/
Ruzne parametry metod, chybove kody, atd. jsou tam popsany mnohem podrobneji nez v oficialni dokumentaci. Skoro bych si troufnul tvrdit, ze podle oficialni dokumentace se neda nic naprogramovat :-(
Link to comment
Sdílet pomocí služby

Zajimalo by me jak se chystate vyrovnat s nasledujicim problemem. Jeden request (o velikosti 1800 vterinovych baru, napr do 18:00:00) vam da 1800 baru ktere ma IB v datech tak aby posledni bar byl z 18:00:00, tozn. ze prvni bude obvykle v 17:30:01. Problem je v tom slove obvykle. Pokud je v te pulhodine nejaky gap (treba z duvodu maleho volume, nebo doby kdy se vubec neobchodovalo), je ten prvni bar mnohem starsi. Pokud stahuju po sobe jdouci pulhodinove useky, pak se v nich data mohou prekryvat.

Napada me nekolik algoritmu jak to resit, ale zadny z nich neni uplne optimalni.

Link to comment
Sdílet pomocí služby

Fretka:

Vzhledem tomu, jak jsou dnes pocitace rychle a pamet velika, tak se optimalnimi algoritmy vetsinou nezabyvam a udelam to co nejjednodussim zpusobem. Navic tady jsme stejne omezeni 3 vterinami na davku, pod ktere se nedostanem a mergovani davek zabere jen zlomek tohoto casu.

Jednoduche reseni, ktere me napadlo jako prvni, je zhruba takto:

Budu si drzet TreeMap. Kazdy prichozi zaznam (EWrapper.historicalData(...)) proste ulozim do te mapy.

Tim, ze je to v mape, se mi eliminuji duplicitni zaznamy (prekryvani vysledku z nasledujicich requestu). Mapa musi mit dostatecnou velikost, aby bylo zaruceno, ze se vsechny duplicity najdou.

Zacinam s prazdnou mapou, jakmile ma mapa velikost 3600 zaznamu (tj. mam 3600 unikatnich, neduplicitnich zaznamu), vezmu prvnich 1800 (TreeMap je utridena, takze normalne pres iterator), odstranim je z mapy a zapisu do databaze, atd.

Maximalni prekryv libovolnych dvou requestu je 1800 zaznamu, a vzhledem k tomu, ze mapa obsahuje stale prinejmensim poslednich 1800 zaznamu, obsahuje veskere mozne duplicity vzhledem k aktualnimu requestu. a tyto duplicity tak budou odstraneny.

Jan Marek

Link to comment
Sdílet pomocí služby

dalsi jednoducha moznost: pouzivat nejakou embedded relacni databazi, udelat si tabulku ve ktere bude cas jako primarni klic, a u kazdeho obdrzeneho zaznamu v WErapperu se podivat, jestli uz v databazi je zaznam pro dany cas. Po skonceni celeho procesu vyexportovat tabulku treba do CVS nebo libovolneho jineho formatu.

Link to comment
Sdílet pomocí služby

Díky za ten odkaz, je to opravdu super.
Utvrdil mě v tom, že místo v JAVě to zkusím rozchodit nejdřív v Jythonu, který je pro mě výrazně pohodlnější, neb jsem příznivec Pythonu a JAVu bych se musel učit od nuly. Takže pokud to rozchodím, bude možné používat JAVa classy dodané od IB, ale v syntaxi Pythonu. Na tom odkazu jsem našel, že někdo udělal APIcko přímo v Pythonu, takže do Jythonu by to mělo být ještě snazší.

Link to comment
Sdílet pomocí služby

Myk:

jsem rad ze odkaz pomohl a jsem rad ze jsem tu nasel dokonce python programatora. ja naopak pisu z jave a o python se zajimam, pac je to hezci jazyk, ale v jave mam praxi a prejit na python by vyzadovalo spoustu usili, ktere ted nechci investovat.

To je na IB super, ze se otevreli nekolika mainstreamovym jazykum a pres ne se otevrou vsem silencum na vsech obskurnich platformach (napr. pres javu do pythonu a ruby). kdyz vidim, jak hladce funguje integrace, skoro me mrzi, ze nedelam AOS. naprogramovat robota, ktery stahuje z netu data a podle nich kupuje a prodava. sen programatora.

Jen jsem po par mesicich testu ruznych AOS a ladeni parametru dosel k zaveru, ze jsou to jen cisilka, ktera v ramci 20ti let vydelavaji, ale tezko se jim rozumi a potazmo duveruje. Tak jedu diskrecni system s nadeji, ze po nejake dobe zkusenosti ho mozna naprogramuju. Takze z toho API zatim pouziju jen to sosani historickych dat.

... tak se to tu zacina podobat programatorskemu foru.

Jan Marek

Link to comment
Sdílet pomocí služby


Narazil jsem na problem. Historicka data stahuji od jineho poskytovatele, ktery mi dava nejake sluzby navic. ovsem dava mi data s puldenni zpozdenim. Tak jsem si chtel udelat jednoduchy programek, ktery nacte data od onoho poskytovatele, potom od IB, a primerguje tam ten chybejici pulden navic. to perfektne funguje, pokud data taham jednou za cas. Pokud chci ale data treba za 5 kontraktu najenou (pro graf, ktery mi ukaze potencialni spready), po 2-3 requestech mi to odmitne data dat. Nikoli na "pacing violation", jako u vterinovych dat, ale na absurni chybu "invalid security specification". Setkal se s tim nekdo, da se to obejit? samozrejme by to slo obejit pauzou mezi requestama, ale je nepohodlne cekat 15 vterin nez se mi zobrazi graf.

Jan Marek
Link to comment
Sdílet pomocí služby

Udělej si dvě tabulky. Jednu historickou a jednu, kam nasypeš příchozí záznamy. Pak spusť SQL příkaz, který provede insert jenom toho, co je nové. Bude to jednodušší a asi i rychlejší, než kontrolovat každý záznam, jestli už je uložený v historii.

Např.:
Insert into H
select * from A
left outer join H
on a.timestamp = h.timestamp
where h.timestamp is null;

Link to comment
Sdílet pomocí služby

Tak jsem si napsal programek v Jythonu, ktery stahuje data od aktualniho casu rok zpatky. Uvedeny problem jsem vyresil tak, ze si pamatuji nejstarsi cas, ktery mi vratila TWS a pri dalsim requestu pozaduji data s EndDate = zapamatovanemu casu, takze data na sebe plynule navazuji a nemely by tam byt prekryvy. Pro jistotu si v metode historicalData() ukladam data do hashe podle parametru date, takze se mi pripadne duplicity prepisou. Pro jistotu si po dokonceni kazdeho requestu reqHistoricalData ukladam starsi zaznamy do souboru a ponechavam si pouze 2 posledni requesty, ktere merguju dohormady a odstranuju v nich duplicity.

Problemu s vykonem se nemusite obavat, protoze IB omezuje pocet dotazu na historicka data, aby mu stahovaci nepretizili servery. Nekde v diskusi jsem narazil na nazor, ze je povoleno maximalne 60 requestu behem 5ti minut. Dal jsem si tedy mezi jednotlive requesty pauzu 5 vterin (plus jeste cekam, nez historicalData() vrati celou sadu pozadovanych dat) a bylo to stene malo. Pri 60tem requestu mi TWS hodila Pacing violation error a ukoncila connection. Pak se musi cca 5 minut pockat, nez je mozne otevrit novou connection. Takze zkusim 60 requstu za 10 minut.

Omezeni stahovani dat je trosku neprijemne, protoze napriklad rocni historie vterinovych dat (pouze opening hours) se musi stahnout cca 3000 requesty a omezeni 60 requestu za 10 minut to prodluzuje na cca 8 hodin. Da se to zkratit tim, ze si clovek stahne delsi bary. Ale od 1minuty jsem zase narazil na problem, ze parametr Duration ve funkci reqHistoricalData() muze byt maximalne 86400 sekund. To znamena, ze na jeden request se da stahnout jen 1440 1minutovych baru nebo 288 5ti minutovych baru. Navic, pokud by nekdo chtel stahovat ASK, BID a TRADE, musi pouzit trojnasobny pocet requestu.

Takze vyuzitelnost IB jako zdroje dat je dosti omezena. Predstava, ze si napisu programek a zacnu sosat jeden symbol za druhym narazi na to, ze to dlouho trva. Ale urcite se to da vyuzit napriklad k tomu, ze si nekdo muze stahnout vterinova data a podivat se, jestli se mu podtatne slepsi presnost back testu oproti vetsim time frames.

Link to comment
Sdílet pomocí služby


Za temi omezenimi rychlosti stahovani bude nejaka tezka magie, zda se, ze se to chova kazdemu jinak (napr. Fretka uspesne stahuje 2000 baru v jednom requestu). Mozna se omezeni meni dynamicky podle toho, jak je server zatizen.

Pridam svoji zkusenost, treba se bude nekomu hodit. Ja pro kazde volani requestHistoricalData() oteviram novou session, stahnu vysledek, zavru session, a tak dokola. Celkem spolehlive mi funguje, ze 3 volani po sobe uspeji a vrati mi data, dalsi volani vyhodi zcela nesmyslnou chybu "invalid security specification", pak 10 vterin pockam, a zase 3 volani uspeji...
Link to comment
Sdílet pomocí služby

To si asi nerozumime, ja take stahuji 2000 baru na jeden request. Ale jen pro 1 sec, 5sec, 15sec a 30sec. Pak uz ale 2000 baru stahnout nejde, protoze pri volani reqHistoricalData se Duration da zadat pouze v sekundach nebo dnech. Pokud tedy chci stahovat napriklad minutove bary, mel bych zadat Duration 2000*60 = 120000 sekund. Duration ma ale omezeni na 86400 sekund, takze muzu stahnout pouze 1440 baru.

Ten security alert se podle diskuse na IB buletin board objevuje, kdyz se zadavaji requesty prilis rychle za sebou. Pokud se mezi jednotlive requesty vlozi pauza cca 3 sekundy, tak se ten problem neobjevuje. Ja mam pauzu 5 sekund a tenhle problem jsem nemel.

Jinak magie v tom neni, omezeni na 60 requestu za sebou popisuje na IB boardu hodne lidi. Zkus si Martine pustit 60 dotazu za sebou a pravdepodobne na ne narazis take.

Link to comment
Sdílet pomocí služby


×
×
  • Vytvořit...