|
PureBytes Links
Trading Reference Links
|
> since their server is, say tick based, when we use it at a >different timeframe
>(as the base timeframe in AB) then AB must compress ticks, on the >fly in memory
>UNLESS they keep different timeframes on different servers, or >sections of
>servers, but that doesn't seem likely.
Actually, now that I think about it the most likely scenario appears to be that the providers compress their tick data according to our needs (AB communicates with them via the plugin and 'tells' the provider what timeframe we want to use).
--- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@xxx> wrote:
>
> Tomasz,
>
> Thanks.
>
> I am starting to understand now because I have read a few of the posts on refresh etc (thanks to Herman/Dennis .. who seem to be the leaders on this, and others plus, of course, your good replies, here and there).
>
> I seem to have moved on to AFL 201, without even noticing.
>
> I don't understand why you did not tell me this stuff in the manual... I could have learnt it years ago instead of suffering it out in silence.
> I had to access posts to find it out ... it took me a few hours .. will I remember what I read, or do I have to archive the posts .. maybe try to find them again if I forget (more precious time gone) ... * how many users have to do this per year?
>
> In general I agree with your philosophies and approach ... I give AB a tick for QuickAFL and setting the default to 0.1 sec refresh with > 0.1 chart redraw required. This is practical and logical and a very good yardstick for non-programmers. Most long term users will want to go further though ... even the non-progamming group will start asking questions eventually.
>
> I don't agree with all of your answers though ... some are questionable ... not technically questionable but in terms of your objectives, yes questionable .... but at this stage I haven't made a final decision:
>
>
> I don't need this stuff myself, not at the moment, but I have to go along with any investigation into the power of the logic.
>
>
> (The Holy Grail for my style is to make 1000%PA, in consecutive years, and only need a little bit of code in an AB chart OR maybe no AB at all ... except that AT is permissable because it is only a tool to ease the administrative burden).
>
> For this discussion I referenced the following posts:
>
> http://finance.groups.yahoo.com/group/amibroker/message/137507
> http://finance.groups.yahoo.com/group/amibroker/message/122464
> http://finance.groups.yahoo.com/group/amibroker/message/109672
> http://finance.groups.yahoo.com/group/amibroker/message/125914
> http://finance.groups.yahoo.com/group/amibroker/message/136087
> http://finance.groups.yahoo.com/group/amibroker/message/135943
>
>
>
> KEYWORDS
>
> OPTIMAL RT PERFORMANCE
>
>
>
> OT Commentary:
>
> Don't worry, Tomasz.
>
> Even if you wrote an explanation of the zillion of things that make AB work there are too many nice things to do with my life to sit down and read them all.
>
> I think that, in general, people only want to know, and need to know the basics of the core processes.
>
> You could easily add a chapter, on this subject, to the manual and add a flowchart or two (BTW the 'flowchart' for Database Management, in the manual, is too basic (junior school level).
> Do you realize the power that flowcharts have, to convey information?
> In the mining industry I have seen examples where all of the core information in a 1000 page manual was contained, in detail, in 20 drafted charts ... a whole processing plant, covering 100's of hectares, summarized in around 100 - 200 charts (I could tell you exactly what was going on in any section of the plant without leaving my office).
>
>
> Re data collection:
>
> I was thinking about this yesterday, in the back of my mind.
> It is amazing how, after you formalize a question the answer starts to form in your mind, all by itself.
>
> I came to the following speculative construction in my imagination (that is the picture in my head for laypeople) ... the picture is constructed by relying on what is the most likely or at least a feasible way that soemthing could be done:
>
> - streaming data can be collected passively ... I imagine it is like water, in a tap, that is under pressure, and if we tap into it then it will flow to us (don't know how it would work technically). I imagaine that providers would use this method as it would be an efficient way to get the data to many users (it requires less activity on their servers?)
>
> - in AB, data collection is managed by the program ..... the plugins are relatively dumb (they just have the docking protocols etc?)
>
> - routines to manage each plugin are included in AB, and are activated when we install the plugin OR when we install the plugin it adds a little bit of plugin control code to AB so AB can interact with it
>
> - IQ, for example, is streaming data, and the data flows from their server into our on board cache, when we are connected via the plugin
>
> - ticks go into the on board memory in the order they arrive (park them on the end of the queue for each symbol)
>
> - tick history in memory is rendered as Time&sales
>
> - tick history is only rendered for the QuoteWindow and charts according to refresh rates, so while tick history is there (for Time and Sales and historical work) we don't see it in RT work.
>
> - Tools > Preferences > Intraday > Realtime Chart Refresh interval (sec) is the default for chart and QuoteWindow refresh/
>
> - RequestTimedRefresh over-rides the preference setting for charts (not sure about QuoteWindow ... I guess not).... it accepts any input but in practice it is limited to 0.1 sec by AB
>
> - newly arrived tick data, in the onboard cache, is only saved to the historical database, on the disc, when we hit save OR when we exit the database/session (only if autosave is set in our preferences?)
>
>
> - IQ, for example, is a streaming RT tick provider ... each new tick must pulse to us but at the same time go to their historical database so that we can download historical (backfill) by sending a request to their server
>
> - since their server is, say tick based, when we use it at a different timeframe (as the base timeframe in AB) then AB must compress ticks, on the fly in memory UNLESS they keep different timeframes on different servers, or sections of servers, but that doesn't seem likely.
>
> - after hours, when traffic is light, AB changes over to the default of 'polling' the server once every sec (like requesting a backfill of historical data).
>
> Of course, this could all be wrong ... it is only speculation.
>
> We only speculate, in an effort to gain understanding, in the absence of truth (we are all driven towards achieving understanding, or meaning, fo the world around us, or our current environment. This is hardcoded into humans).
>
>
> Why do I want to know this stuff?
>
> - so that I can use AB in better ways (if I understand the design limits I will know how far I can push it in any one direction).
> - and so that I don't have to ask stupid questions in the forum
> - because quite a few experienced AB users are sometime confused by/interested in this subject
>
> for example:
>
> in 3-4 years of owning AB I have never used PerformanceCounter, or debug or CodeProfile and check etc ... not once, because you didn't put it in pictures in the manual. In the first years, because of my computing inexperience, I couldn't absorb this info, by the 'no hand holding here' method because there was too much other stuff to learn ... my brain couldn't cope with that kind of workload i.e. you have answered questions on Refresh before but I didn't follow the answers because I didn't realize the significance (you need your specs to find your specs) ... on the other hand if your write about it in the Help maual then I know that it must be significant so then I will pay more attention e.g. if you don't write about Code Profile and Check then I guess that it is not a significant part of AB.
>
> Why do I ask these questions here?
>
> - because it would be very selfish, and an inefficient use of AB time (== bad karma!) if I emailed support and kept the answers to myself.
> - because I am a NewAgeGuy (not a sensitive one though) I am committed to my ethical imperatives ..... group effort and sharing, transparent communication and full disclosure/availability of information.
>
>
> I do notice your admonitions, and guidance, in this forum, not to do certain things in AB e.g. I saw your post advising that total execution (redraw time) should be under 0.1 sec and this fits nicely with your default time of 0.1 sec for refresh.
> I really appreciate your guidance in these areas.
> I have learnt a lot about the IT side of trading, from you ... taking not of the things you put in and left out of AB and also the forum discussions.
> I should have archived some of your answers but once again that is additional work to compile my own private Help manual.
>
>
> FTR
>
> why do you only give your answers informally, via the forum, instead of compending them somewhere, for the benefit of newcomers and for reference ... why do youkeep on answering the same questions in the forum ... over and over again?
>
> Do you ever feel the urge to answer these questions once and for all and then the users can move on?
>
>
>
>
>
>
>
>
>
> --- In amibroker@xxxxxxxxxxxxxxx, Tomasz Janeczko <groups@> wrote:
> >
> > Hello,
> >
> > Chart refresh is independent from data collection.
> > It means that plugin can collect even 1000 updates (ticks) per second
> > per symbol,
> > while chart will refresh 10 times per second.
> >
> > If that happens, during 0.1 sec you will see 100 new ticks arrived and
> > displayed
> > on chart.
> >
> > It does not make sense to update chart more often than about 10 times
> > per second
> > because human perception is limited to that rate.
> >
> > Best regards,
> > Tomasz Janeczko
> > amibroker.com
> >
> > brian_z111 wrote:
> > > Going by what Tomasz said:
> > >
> > > Plugins do send updates if certain market is closed because
> > > a) if you open AmiBroker on sunday, you still want to see most recent quote,
> > > without waiting till Monday.
> > > b) plugins not only send updates on quotes but also on some other info that is
> > > not related to market activity
> > > c) there can be corrections sent later
> > > d) other markets may be open
> > > e) the bacfill may be in progress, etc.
> > >
> > > For the reasons above, most plugins sent "general update" every second.
> > >
> > > AND "real-time data refresh (can be as often as every tick, but not more often
> > > than 10 times per second)"
> > >
> > > For IQ RT data:
> > >
> > > - when the market is quiet we are receiving general updates, in our charts, every sec and when the market is busy we are receiving updates every 1/10th sec, at best i.e. if watching a fast market and we have no programmatical or preferences set to refresh AND we don't touch our mouse).
> > >
> > > This seems to indicate that our data is polling the IQ server for a timeslice of historical tick downloads.
> > >
> > > Presumably our quote database and the T&S window is the same ... unless the plugin is a 'two in one' i.e. it does it one way for charts and another way for T&S or quote database.
> > >
> > >
> > > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> > >
> > >> RT speed (trading in charts) seems to be limited,at the core, by data speed.
> > >>
> > >> There are some things I don't understand about data and the way we collect it, via our plugins.
> > >>
> > >> I am referencing info from a previous discussion:
> > >>
> > >> http://finance.groups.yahoo.com/group/amibroker/message/136651
> > >>
> > >> I understand that these are hard questions to answer so if I get no answer I will send the question to support.
> > >>
> > >> Assuming that for speed work, true tick data is the best (not 1 -5 sec snapshot like some data providers).
> > >>
> > >>
> > >> Assuming that the plugins are not all the same ... they are matched to the data type.
> > >>
> > >> Is it possible for software to be a passive receiver of RT data i.e. the provider 'sends' out the ticks, like a pulse, and we just hook up our pipe (via the plugin) and the data streams into our software (is that what is called streamed data?)
> > >>
> > >> If so, would they 'pulse' every tick but not supply historical ticks live?
> > >>
> > >> Opposed to 'streaming' data I imagine that the provider could just give us access to the historical ticks (with RT update) and we have to proactively get the data i.e. our plugin would initiate a download of the last few ticks or secs of tick data.
> > >>
> > >> I am a bit confused about this.
> > >>
> > >> Using IQFeed as the example:
> > >>
> > >> - it appears that our IQ plugin 'polls' the IQ server OR holds the streaming data for a while and then sends it to us in packets.
> > >>
> > >> Tomasz said that
> > >>
> > >> "real-time data refresh (can be as often as every tick, but not more often
> > >> than 10 times per second)"
> > >>
> > >> but in a test, Conrad Joach (using IQ RT data) with refresh in the preferences set to zero, found that the plugin was updating to AB every second (this is plugin initiated activity ... completely independent of refresh settings and not requested refresh in the AFL formula).
> > >>
> > >> Is the IQ plugin streaming every tick OR polling every 10 secs OR polling every 1 sec Or something else?
> > >>
> > >> To make things even more confusing Tomasz also said that
> > >>
> > >> "On MSFT you can easily have more than 200 new ticks per second.
> > >> Use Time&Sales window to display actual ticks."
> > >>
> > >>
> > >> If MSFT has > 200 ticks per second does that mean we can never see true RT tick by tick charts because our plugin only updates, at best 1 per sec or 1 per 10 sec (not sure which is correct).
> > >>
> > >> Also, how can we see ticks for say, MSFT, in the Time&sales window (I don't use it so I am not sure if we can or not)..... are we really only seeing historical bites in the T&S window OR is the plugin somehow streaming ticks to the T&S window while not streaming ticks to our charts?
> > >>
> > >>
> > >> (I am using Pro 5.20 on an XP machine)
> > >>
> > >>
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > **** IMPORTANT PLEASE READ ****
> > > This group is for the discussion between users only.
> > > This is *NOT* technical support channel.
> > >
> > > TO GET TECHNICAL SUPPORT send an e-mail directly to
> > > SUPPORT {at} amibroker.com
> > >
> > > TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
> > > http://www.amibroker.com/feedback/
> > > (submissions sent via other channels won't be considered)
> > >
> > > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > > http://www.amibroker.com/devlog/
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> >
>
------------------------------------
**** IMPORTANT PLEASE READ ****
This group is for the discussion between users only.
This is *NOT* technical support channel.
TO GET TECHNICAL SUPPORT send an e-mail directly to
SUPPORT {at} amibroker.com
TO SUBMIT SUGGESTIONS please use FEEDBACK CENTER at
http://www.amibroker.com/feedback/
(submissions sent via other channels won't be considered)
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|