|
PureBytes Links
Trading Reference Links
|
> be easily 50MB per day per symbol. Just imagine one month of data >for 100 symbols. That would be 125GB.
> Processing such huge files in real-time (note that for 100 symbols >that can be peaks of 10000 new bid/asks per second)
> is not feasible with ordinary desktop computer.
I think the 'optimal RT performance' discussion shows that realistically we have to trade off 'fast trading' against 'accurate trading' ...... so for RT indicators based on T&S I suggest we would do best, and possibly manage it all, if we work with one symbol at a time and don't try to keep historical data for BT ..... just use paper trading to compile our historical performance records over time.
Trading is a business .... porbabaly we need, and are prepared to maintain, computing power above and beyond what the normal household maintains. Even lay computer users can pay for technical assistance/maintenance and achieve this if there is a justifiable payback.
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>
> Hello,
>
> If you mean trades tick-by-tick - it is available. Configure your database so base time interval is set to "Tick"
> and normal Close array will give each trade (tick).
>
> If you mean bid / ask - I could do that, but since there are way more bid/asks than trades, the resulting file could
> be easily 50MB per day per symbol. Just imagine one month of data for 100 symbols. That would be 125GB.
> Processing such huge files in real-time (note that for 100 symbols that can be peaks of 10000 new bid/asks per second)
> is not feasible with ordinary desktop computer.
>
>
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "Julian" <juliangoodsell@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Wednesday, July 08, 2009 12:19 PM
> Subject: [amibroker] Re: Data And PlugIn Speed
>
>
> > Tomasz,
> >
> > is it too much trouble for you to log the Time & Sales data to file as it comes in? This would at least enable us to read that
> > data and construct charts based on the info, as it's not possible to accurately gather this data through chart scripts.
> >
> > I tried for a while using GetRTData so I could track trades hitting the bid vs ask, but the fact that I can't get this info for
> > every tick makes the data invalid. If Time & Sales was logged (ala eSignals file format for saving replay data), I could then
> > process that file to strip all the data I needed from it.
> >
> > Regards,
> > Julian.
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
> >>
> >> Brian,
> >>
> >> You asked:
> >> > ...is there any way to know when a quote (tick) has arrived other
> >> > than Status("redrawaction")? ... this seems to be a generic trigger
> >> > so we can't separate new quote from the other possible causes of
> >> > actioned refresh.
> >>
> >> Of course there is. There may be a simpler method, but you could save
> >> the Time Stamp and Volume of the last bar in a static variable at the
> >> end of each pass (Time Stamps have to be set to start of bar), then on
> >> the next pass check to see if the Time Stamp or Volume has changed.
> >> If they are the same, then the refresh is for some other reason than a
> >> new quote. Just checking the Time Stamp will indicate a new bar. If
> >> the bar has not changed, then the Volume is checked for additional
> >> trades. The OHLC may not be any different even though more trades
> >> have been made. What you check is based on what you need to know for
> >> your algorithm.
> >>
> >> BR,
> >> Dennis
> >>
> >>
> >> On Jul 5, 2009, at 7:10 PM, brian_z111 wrote:
> >>
> >> >> If you go to the data provider's sites, they tell you exactly what
> >> >> they provide and archive.
> >> >
> >> > Thanks for your summary.
> >> > You have saved me a lot of research time.
> >> > In fact your answer is about all of the info I need really (perhaps
> >> > I will check the detail on my provider eSignal).
> >> >
> >> >> BTW: The backtests (on historical intraday data) can show good
> >> >> >trading performance that is not
> >> >> duplicated in realtime.
> >> >
> >> > Yes, I made a mental note of that point when Herman brought it to
> >> > our attention earlier on (I missed a lot of the other discussion on
> >> > RT performance though because I was focused elsewhere).
> >> >
> >> >> For very high speed
> >> >> trading Herman has many more caveats in the UKB.
> >> >
> >> > Yes, I can see what he is on about now.
> >> > He has made a pretty decent contribution to the AB community and
> >> > even the general trading community.
> >> > I doubt if there is a better AT training ground anywhere.
> >> >
> >> > Of course I will go and read it ... lots of code tends to scare me
> >> > off but the UKB format is the best support for the code that we have
> >> > (outside of Howard's books .. go Howard go!)
> >> >
> >> >> RequestTimedRefresh ....has two other useful modes that are not
> >> >> >time based. The 0.1 second refresh minimum time can only be
> >> >> >achieved when refreshes are triggered by new quotes (ticks) in the
> >> >> >data stream at a rate equal or less than 0.1 sec.
> >> >
> >> > That is the final piece of the jigsaw puzzle that I was looking for.
> >> > I noticed that Herman talks about executing when new quotes are
> >> > received ... is there any way to know when a quote (tick) has
> >> > arrived other than Status("redrawaction")? ... this seems to be a
> >> > generic trigger so we can't separate new quote from the other
> >> > possible causes of actioned refresh.
> >> >
> >> > My first impression is that progammatically creating panes with
> >> > functions to specify different refresh the individual panes would be
> >> > on the short wishlist of RT high performance traders, or not?
> >> >
> >> > I noticed that a lot of your posts are educational.
> >> > Thanks once again to you and Herman for your efforts to educate
> >> > others (there were some good contributions from others in the posts
> >> > I read to).
> >> >
> >> > Correction to my previous post:
> >> >
> >> > It seems that the best way to go is to work with an amount of data
> >> > that fits into the cache (I think that is for all symbols in the
> >> > database).
> >> > So, it follows that the best case is to only save new data that
> >> > arrives in memory at the end of the session.
> >> > This could vary though ... perhaps AB does this on time OR it would
> >> > be forced to do this if data starts to overflow the cache (the
> >> > unknown factor there is how AB differentiates new data in memory
> >> > from the data that we loaded into the cache from the disc. Most
> >> > likely it marks start of the new data in some way ... I don't think
> >> > the optimum method would be to save all the data in memory by
> >> > default i.e. overwrite the data that we loaded in the first place).
> >> >
> >> > --- In amibroker@xxxxxxxxxxxxxxx, Dennis Brown <see3d@> wrote:
> >> >>
> >> >> Brian,
> >> >>
> >> >> If you go to the data provider's sites, they tell you exactly what
> >> >> they provide and archive. In general a RT data provider will keep a
> >> >> number of days of tick history. From those they compress into one
> >> >> minute bars that they keep for many months or a few years. From
> >> >> those, they compress into daily bars that they keep for many years or
> >> >> decades. They will provide historical downloads based on one of
> >> >> these
> >> >> saved formats. Some also compress ticks into volume bars of various
> >> >> denominations for certain tickers that they archive like minute bars.
> >> >> They just have these few historical formats and everything else has
> >> >> to
> >> >> be aggregated from these, either by the server, or the client. WIth
> >> >> storage becoming less expensive, the tendency is to keep larger
> >> >> historical archives.
> >> >>
> >> >> It is possible that for efficiency, they might choose to cache other
> >> >> tick derived timeframes like 5 second, etc., so they don't have to
> >> >> duplicate the computations on every request. However, that is
> >> >> internal and may or may not take place based on their internal
> >> >> engineering designs, and it may change at any time. They also scrub
> >> >> their databases for bad ticks during the day and also at night. This
> >> >> obviously means that the data you get served for a historical
> >> >> backfill
> >> >> will not match the data that actually occurred in real time.
> >> >>
> >> >> BTW: The backtests can show good trading performance that is not
> >> >> duplicated in realtime. This is a possible indication of an over
> >> >> optimized algorithm. I try to avoid such algorithms in practice.
> >> >> The
> >> >> way you find out is to run the algorithm in realtime for a day, then
> >> >> backfill over the day's data the next day and see if the performance
> >> >> changes significantly. I learned this lesson early on the hard way.
> >> >> This was actually a major driver for me to trade only the ES futures
> >> >> -- the data feeds are very high quality with very few errors, so my
> >> >> backtests match the realtme trading performance. For very high speed
> >> >> trading Herman has many more caveats in the UKB.
> >> >>
> >> >> RequestTimedRefresh can only specify down to 1 second in 1 second
> >> >> increments. It also has two other useful modes that are not time
> >> >> based. The 0.1 second refresh minimum time can only be achieved when
> >> >> refreshes are triggered by new quotes (ticks) in the data stream at a
> >> >> rate equal or less than 0.1 sec. To have timed refreshes at 0.1
> >> >> second increments is only something that has been requested at this
> >> >> point.
> >> >>
> >> >> BR,
> >> >> Dennis
> >> >>
> >> >> On Jul 5, 2009, at 5:14 AM, brian_z111 wrote:
> >> >>
> >> >>>> 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@> 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
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> > ------------------------------------
> >> >
> >> > **** 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
> >
> >
> >
>
------------------------------------
**** 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/
|