TWS API a dojení historických dat 1

[Fretka]

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".

[jaaan]

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

[Myk]

Dneska jsem si s tém začal hrát, takže je super, že už to má někdo přede mnou.
Narazil jsem ale na problém, a sice nemám v adresaáři c:\Program Files\Jts\ podadresář pro Javu a udíž nemám ani sample aplikaci ani package pro import. Neřešil jsi podobný problém?

[Myk]

Ten help je trochu nelogicky poskládaný, už jsem to našel.
API se instaluje zvlášť a na stránkách IB je ke stažení v Software->Fix/APi->Api software

[jaaan]

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 :-(

[Fretka]

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.

[jaaan]

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

[jaaan]

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.

[Myk]

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ší.

[jaaan]

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

[jaaan]

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

[Myk]

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;

[Myk]

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.

[jaaan]

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...

[Myk]

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.