|
PureBytes Links
Trading Reference Links
|
Tomasz, Your explanation is very apprecriated.
I know from my experience that this type of explanation would usually only be given to a high value customer in a large commerical software company. The fact that you've given it to us here freely means we are all getting the treatment of a VIP. Now you do antaganize some of us sometimes. But none of us is perfect either!
--- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@xxx> wrote:
>
> Hello,
>
> > As far as I'm concerned, as long as we have a one second resolution. I'm happy enough.
> > But if Tomasz is going to the trouble to re-structuring the database, why not build in some margin for future growth?
> Sub-second resolution is not just restructuring database - it is a breaking change for entire API because timestamp with milisecond
> resolution AND scope of 1900-2155 would need to be 64-bit, that means adding support 64 data type to *ALL* afl functions
> effectivelly
> doubling the code (since polymorphic versions of all functions must be added) changing the way custom fixed-size allocators and many
> other details also the AmiVar structure is no longer 8 bytes
> and that means *ALL* indicator plugins written upto date (including 3rd party that I don't have sources for) need (at least)
> recompile.
> Of course all data plugins need rewrite, but that's obvious. Essentially it means flipping all lines of code (millions) upside down.
>
> I know it is my problem only but I just wanted to show that it is not just lack of "caring" as some may suggested.
>
> Best regards,
> Tomasz Janeczko
> amibroker.com
> ----- Original Message -----
> From: "Paul Ho" <paul.tsho@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Tuesday, July 14, 2009 3:00 PM
> Subject: [amibroker] Re: Per Chart Refresh Rates
>
>
> > Guys
> > There are two suggestions that should concern participants of this thread, if you're interested in changing the resolution of
> > timestamp to sub 5 seconds. please take a look at suggestion 1691 :
> > http://www.amibroker.com/feedback/view_bug.php?bug_id=1691&start_at=0 . Another one which could also be of interest is about float
> > point volume. #636 http://www.amibroker.com/feedback/view_bug.php?bug_id=636 .
> >
> > As far as I'm concerned, as long as we have a one second resolution. I'm happy enough. But if Tomasz is going to the trouble to
> > re-structuring the database, why not build in some margin for future growth?
> >
> > If you guys wants what we've talked about not gone emptied handed. take a few minute to have a look these 2 suggestions.
> >
> > Paul.
> >
> >
> > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
> >>
> >> Hello,
> >>
> >> My post was solely to point out that
> >> the Feedback Center (FC) http://www.amibroker.com/feedback/
> >> is the only place to make suggestions. Other means will be simply ignored
> >> because of the inefficiency. Only FC offers required organisation
> >> and is compatible with development environment.
> >> I simply can not afford reading through tons of talk
> >> to locate one line in which someone wants something implemented.
> >> That is a waste of time I was mentioning.
> >> So please feel free to discuss, but don't expect me to note of your suggestions
> >> spread in the middle of 10 page talk. Use the feedback center
> >> or support channel to make any requests.
> >>
> >> And to people talking about adding sub-second resolution to timestamp:
> >> you are simply forgetting one fact.
> >> No supported DATA SOURCE offers resolution higher than 1 second.
> >> They are all down to 1 second AT BEST. Not so rare are tick data with only 1-minute resolution (IQFeed until recently was such
> >> example).
> >> There is simply no sub-second data available.
> >>
> >> Why would one add a feature when there is no data available ?
> >>
> >> Please point out to single data vendor (for retail clients) that offers subsecond timestamps
> >> and offers backfill with subsecond timestamps.
> >>
> >> I don't know of any.
> >>
> >> Best regards,
> >> Tomasz Janeczko
> >> amibroker.com
> >> ----- Original Message -----
> >> From: "Julian" <juliangoodsell@>
> >> To: <amibroker@xxxxxxxxxxxxxxx>
> >> Sent: Tuesday, July 14, 2009 12:18 PM
> >> Subject: [amibroker] Re: Per Chart Refresh Rates
> >>
> >>
> >> > Ouch! What a killjoy. :)
> >> >
> >> > That's fair enough from your point of view Tomasz, but this is a user forum, and the mulling over of ideas whether ignorant,
> >> > uneducated or completely missing the point is all fair game.
> >> >
> >> > I'm well aware of the limited (probably zero) impact of these forum posts in relation to your actual development of AB, but
> >> > posting them gets a lot of ideas out and solves a lot of problems in itself. I've answered heaps of my own questions, just by
> >> > writing posts, many of which I never need to end up sending, and which in hindsight were foolish. Of course there's always some
> >> > that get through the filter. :)
> >> >
> >> > There are innumerable posts on this forum from beginners and non programmers that I think are stupid, but I don't bother
> >> > writing
> >> > to let them know!
> >> >
> >> > So my advice is to stick to development and leave the forum nonsense to us. :)
> >> >
> >> > Tongue in cheek,
> >> > Jules.
> >> >
> >> > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
> >> >>
> >> >> Hello,
> >> >>
> >> >> I am sorry to say this but this thread is just waste of time.
> >> >> You may discuss things to death yet it has zero result in terms of program itself.
> >> >> Naive views/opinions/beliefs from most participants of this thread are pretty much do not have any impact on development of
> >> >> AmiBroker
> >> >> simply because development plans are made many years ahead and features you are discussing now were planned 3 years ago long
> >> >> before
> >> >> you knew AmiBroker exists. Moreover they are on the Feedback Center for years already (if somebody bother to check already
> >> >> submitted things).
> >> >> In contrast to cheap forum talk, the program development does not occur overnight. If you think that you will
> >> >> talk for a month about some feature and it will arrive just because you talked a lot you are wrong.
> >> >> There are zillions of things (half of them are not technical at all) that decide when and what way given thing is implemented
> >> >> and you are not aware of 90% of them.
> >> >> So my advice is to stick to trading and leave the development to me.
> >> >>
> >> >> Best regards,
> >> >> Tomasz Janeczko
> >> >> amibroker.com
> >> >> ----- Original Message -----
> >> >> From: "brian_z111" <brian_z111@>
> >> >> To: <amibroker@xxxxxxxxxxxxxxx>
> >> >> Sent: Tuesday, July 14, 2009 5:12 AM
> >> >> Subject: [amibroker] Re: Per Chart Refresh Rates
> >> >>
> >> >>
> >> >> > The intention of the mother thread,"Data and PlugIn Speed", was to focus on AB's RT Performance, as opposed to its
> >> >> > capabilities
> >> >> > as
> >> >> > a Backtesting Engine.
> >> >> >
> >> >> > For me this was an educational post and IMO the discussion has progressed nicely, across threads, with contrasting emphasis
> >> >> > on
> >> >> > speculative ideas, on one hand, and hard-nosed critique, accompanied by factual observations, on the other ... it is quite
> >> >> > OK
> >> >> > with
> >> >> > me if others see the topics in a different way. or pursue other objectives/sub-objectives within them.
> >> >> >
> >> >> > To me it was always just a discussion, and not intended to be specifically critical of AB, or Tomasz, while at the sametime
> >> >> > being
> >> >> > pertinent enough to have value.
> >> >> >
> >> >> > IMO opinion using the forum as a sounding board, which provides users with the opportunity to sound off, pool our factual
> >> >> > evidence
> >> >> > and make critical assessents, prior to filing formal suggestions, is the best model for introducing progressive ideas that
> >> >> > we
> >> >> > have.
> >> >> >
> >> >> > (As a rule of thumb, we need to sound off on them several times before they start to sound reasonable to the majority).
> >> >> >
> >> >> > Keep in mind that only a fraction of the discussion will end up as a formal suggestion and that only a small % of filed
> >> >> > suggestions will ever be implemented (especially in their original format).
> >> >> >
> >> >> >
> >> >> >
> >> >> > Re RT Performance versus Backtesting Performance:
> >> >> >
> >> >> > Irrespective of what AB's BT can, or can not, do, the reality is, that for one reason or another, many of us do use it as
> >> >> > dual
> >> >> > software i.e. we do use AB as both a BT and trading platform software.
> >> >> >
> >> >> > Note that Janhaus said that he does not, and will not, use AB for high frequency trading, however, his objectives and
> >> >> > situation
> >> >> > (budget/ skills/hardware) are most likely unique compared to the AB user norm.
> >> >> >
> >> >> >
> >> >> > From the discussion, so far, it seems that RT users:
> >> >> >
> >> >> > - want a trading platform type window with different behaviour to the other windows
> >> >> > - use a dedicated machine for RT trading (or close all other programs while RT trading)
> >> >> > - if they want to run extras, while running AB in RT mode the preference would be for additional monitors (go MS, go!)
> >> >> > - use of machines with MCP's is standard (number of cores vary!) ... multicore is now standard for midrange off the shelf
> >> >> > desktops?
> >> >> > - they are prepared to buy machines, use OS etc that are particularly suited to AB use
> >> >> > - consider that CPU useage is a critical issue ... consequently they want control over GDI workflow and CPU workflow
> >> >> > - they are well informed about performance issues and typically limit indicator code and symbols traded as a trade off to
> >> >> > gain
> >> >> > CPU
> >> >> > time to drive their 'trading platform' processes.
> >> >> > - they are well informed about and want control over the amount of data processed i.e. they want execution flow control
> >> >> > - they don't want to have to reference AA ... this is seen as being irrelavent when RT trading (either they are correct or
> >> >> > some
> >> >> > intense education is required to change this view).
> >> >> >
> >> >> >
> >> >> > Speculating further, without any social or practical constraints in place (in order to learn some more or perhaps unearth
> >> >> > some
> >> >> > new
> >> >> > issues or possibilities):
> >> >> >
> >> >> > - spread trading is the most extreme trading that we could consider (one person in this forum has already indicated that
> >> >> > this
> >> >> > is a
> >> >> > strategy they are following, albeit not with AB as the software)
> >> >> > - bid/ask and tick arrival can be considered micro-events, compared to compressed data e.g sec or minute bars etc.
> >> >> > - microevents are dynamic, in time, and therefore need to be handled dynamically (indicators might need to be dynamic and
> >> >> > not
> >> >> > use
> >> >> > any lookback data at all?)
> >> >> > - it isn't practical for me (at this stage) because MarketMarkets play the spread without any frictional costs and they are
> >> >> > sitting on top of the markets with highspeed gear (compared to myself only)
> >> >> > - it might not ever be practical for the majority of traders to trade microevents OR trade them via AB .... however, like
> >> >> > AB/Tomasz, I want to gather some evidence from real world testing, to find out for myself, and not rely on others beliefs
> >> >> > about
> >> >> > whether it is viable or not.
> >> >> >
> >> >> >
> >> >> > Hypothetically to BT bid/ask scenarios:
> >> >> >
> >> >> > - bid/ask data without volume at the bid ask is of lessor value therefore to Backtest some bid/ask indicators I will need a
> >> >> > BT
> >> >> > with fields/functions that accommodate bid/ask and volume at the bid/ask at the least (full market depth history would be
> >> >> > required
> >> >> > to fully test all possible strategies)
> >> >> > - possibly historical bid/ask data could be collected, by my software, when I am not actively enaged in RT trading OR
> >> >> > perhaps I
> >> >> > could buy some historical data OR alternatively I could rely on live paper trading, using only a small number of recent
> >> >> > bid/asks
> >> >> > etc and then only save the tradeSeries/calculated indicators for historical reference
> >> >> > - in any case, leaving aside the issues of collecting/managing the extreme amount of bid/ask data generated in a single days
> >> >> > trading and assuming that testing has been managed somehow and that I have a valid bid/ask system I want to implement.
> >> >> >
> >> >> > (Perhaps that aspect requires a separate thread).
> >> >> >
> >> >> >
> >> >> >
> >> >> > Hypothetically for RT spread type trading:
> >> >> >
> >> >> > - I would need the arrival of the a new bid/ask to be an actionable event ... down to the time limits of processing etc
> >> >> > where
> >> >> > execution would revert to minimum ontime basis if the number of bid/asks that arrive exceeds processing capabilities i.e.
> >> >> > automatically execution of the bid/ask calcs would have to resort to a time absis in extreme high volume?
> >> >> >
> >> >> > - I would not want to see every 'behind the scene' bid/ask calc (is it likely that the MarketMakers, who set the spread, are
> >> >> > visually looking at every incoming bid/ask OR would they algorithmically make/take the bid/asks and only PHYSICALLY watch a
> >> >> > summary of the process instead?) .... I assume that in order to play this game I could physically look at every event when
> >> >> > looking
> >> >> > at historical data in the BT but that for RT trading I would have to handover to my faster AT computer when in trading mode.
> >> >> >
> >> >> > - so, I would elect to AT the high frequency bid/ask indicators and only render actual trades entered, or orders placed etc,
> >> >> > in
> >> >> > a
> >> >> > window that needs to be refreshed i.e. I would only physically watch timed reports on my key performance indicators /trouble
> >> >> > shooting status etc.
> >> >> >
> >> >> >
> >> >> > Hypothetically .....what would I require of my software to be able to trade the spread:
> >> >> >
> >> >> >
> >> >> > (... thinking as a layperson ... first pass/draft version only)
> >> >> >
> >> >> >
> >> >> > - everything would have to be optimized to extreme levels to achieve this extreme performance
> >> >> > - I would need finer control of what constitutes an event e.g. arrival of a bid/ask or a tick is far more important than
> >> >> > user
> >> >> > action e.g scrolling, so new bid/ask or tick quotes would need to be recorded as an actionable event in the fastest possible
> >> >> > way
> >> >> > - I would need bid/ask calculations threaded out (almost certainly to another core?) and worked in the background (no visual
> >> >> > reporting of most of this)
> >> >> > - I would need a 'trading platform' type window, or windows, to provide me with the absolute bare min of updated reports
> >> >> > from
> >> >> > the
> >> >> > algorithmic trading that is going on in the background
> >> >> >
> >> >> > (I would need the training and mindset to go with this style of trading .... it is just like the difference in flying a high
> >> >> > performance aircraft, with only virtual feedback available, and flying a hobby aircraft by looking out the window).
> >> >> >
> >> >> > - I would have to forgo 'historical saving' of bid/ask data .. even data used on the fly might have to be progressively
> >> >> > dumped
> >> >> > as
> >> >> > new data comes in (challenging to find ways to keep it all for the session if we want to do what if checks at the end of the
> >> >> > day
> >> >> > ... unless of course MCP somehow 'saves the day' in this regard).
> >> >> >
> >> >> > - I would need control over when a particular window refreshes and what drives the refresh e.g. refresh actions would need
> >> >> > to
> >> >> > be
> >> >> > parameter driven .... by default all parameters would be included (as in AB at present) but the user would elect what
> >> >> > refresh
> >> >> > actions to turn off for any particular chart (all turned off,except for slow timed refresh would == something similar to
> >> >> > commentary? ... it would just give us a, say, 10 sec update on the score == W/L, PayOffratio, open trades, net gain
> >> >> > etc)......
> >> >> > in
> >> >> > effect, a window with most actions/events disabled would function just like a static graphic (the keypoint is that users
> >> >> > should
> >> >> > be
> >> >> > able to define this, or graduations of it, for themselves).
> >> >> >
> >> >> > - I would need fine grain/extreme control over how much data to process at any time/for any event.
> >> >> >
> >> >> >
> >> >> > Realistically:
> >> >> >
> >> >> > - can AB achieve this?
> >> >> > - is it desireable for AB to achieve this?
> >> >> > - should AB keep its focus on being a cutting edge BackTesting engine, with some secondary RT charting that is only intended
> >> >> > to
> >> >> > supplement design and testing efforts, and leave RT high frequency trading to other software?
> >> >> > - at the least, shouldn't AB allow us to somehow create an extreme event database and do our testing within AB ... and do
> >> >> > this
> >> >> > with off the shelf features, so that it is accessable to all?
> >> >> > - perhaps thinking about how AB could hyptothetically trade microevents, in RT, will lead to some realisitic options that
> >> >> > will
> >> >> > end
> >> >> > up being implemented by AB, for use at subsecond timeframes (not necessarily bid/ask trading).
> >> >> >
> >> >> >
> >> >> >
> >> >> > KEYWORDS
> >> >> >
> >> >> > OPTIMAL RT PERFORMANCE
> >> >> >
> >> >> > --- In amibroker@xxxxxxxxxxxxxxx, "brian_z111" <brian_z111@> wrote:
> >> >> >>
> >> >> >> > I just believe you'll get better support for what you're asking >within the realm of tick by tick trading.
> >> >> >>
> >> >> >> I agree that the issue is best considered in the context of bid/ask OR tick trading ... hypothetically considering those
> >> >> >> propositions is where we can learn the most about where we are, where we would like to go and whether, or not, we can
> >> >> >> realisitically expect to get to any of those places (more on this in another post).
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> > May be Tomasz will implement it as it is for you, best of luck.
> >> >> >>
> >> >> >> IMO the arguments put forward by Julian, and supported by Dennis and Yofa, are compelling i.e.
> >> >> >>
> >> >> >> it is not an issue of scaling up, via application of new MS GDI features but rather one of taking the load off the GDI by
> >> >> >> removing unnecessary graphic rendering from the queue (some people seemed to mis-read Julians suggestion and kept going
> >> >> >> back
> >> >> >> to
> >> >> >> the GDI multithreading argument ... bottlenecking at the GDI is the argument that makes Julians case, rather than breaks
> >> >> >> it!)
> >> >> >>
> >> >> >> The second compelling argument, made by the proactive group, is that threading out background tasks, calculations etc from
> >> >> >> graphic rendering tasks can lead to RT improvement.
> >> >> >>
> >> >> >> I accept this generic argument (in fact I naively guessed at it myself a way back at the MultiCoreProcessing discussions)
> >> >> >> ....
> >> >> >> what I am not sure about is how it could apply in specific cases e.g. on a particular machine, where machines can have
> >> >> >> different
> >> >> >> OS and cores OR within AB in general, where the priority of subtasks could be user defined.
> >> >> >>
> >> >> >> Against this you posted the third most telling point of the discussion so far (in the top three points somewhere) when you
> >> >> >> highlighted the fact that AB only stamps bars down to a resolution of 5 secs ... I agree all RT performance theorising etc
> >> >> >> stops
> >> >> >> at that point, like a car hitting a 10ft thick concrete wall.
> >> >> >>
> >> >> >> At the end of the day, only Tomasz can make structural changes while we are left with the power to chose from the cards we
> >> >> >> are
> >> >> >> holding in our hands.
> >> >> >>
> >> >> >> >BTW with a few lines of C/C++ using windows timer you can implement >your own suppressedrefresh function which will do
> >> >> >> >exactly
> >> >> >> >what you >want.
> >> >> >>
> >> >> >> Sounds like an idea worthy of further investigation.
> >> >> >> Probably a bridge to far for me at this stage ... maybe in a year or two.
> >> >> >> In the meantime the discussion on how to bring this to the people, via AB features, is a good one.
> >> >> >>
> >> >> >> Thanks for your good pragmatic contributions.
> >> >> >>
> >> >> >> --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> >> >> >> >
> >> >> >> > I just believe you'll get better support for what you're asking within the realm of tick by tick trading. May be Tomasz
> >> >> >> > will
> >> >> >> > implement it as it is for you, best of luck. BTW with a few lines of C/C++ using windows timer you can implement your own
> >> >> >> > suppressedrefresh function which will do exactly what you want.
> >> >> >> >
> >> >> >> > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> >> >> >> > >
> >> >> >> > > Yes, I partially agree with you Paul,
> >> >> >> > >
> >> >> >> > > however just because some traders might see a feature as unnecessary and can't see a use for it, doesn't make it so or
> >> >> >> > > mean
> >> >> >> > > there isn't one. GetRTData and automatic trade entries are an example where sub-second updates could be useful.
> >> >> >> > >
> >> >> >> > > The fact that Tomasz has actually implemented a per tick update option means it must have been useful to some, unless
> >> >> >> > > he
> >> >> >> > > did
> >> >> >> > > it for fun. :) The problem is simply that this resolution is not available via requestTimedRefresh.
> >> >> >> > >
> >> >> >> > > Whether this feature is only useful to a minority of traders or not, it's such a simple (supposedly) fix, for a feature
> >> >> >> > > that
> >> >> >> > > is already supported, but is hindered in practice.
> >> >> >> > >
> >> >> >> > > Regards,
> >> >> >> > > Julian.
> >> >> >> > >
> >> >> >> > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> >> >> >> > > >
> >> >> >> > > > As long as the restiction on the resolution of timestamping of price data is set at 5 sec. There is no point in
> >> >> >> > > > trying
> >> >> >> > > > to
> >> >> >> > > > RT trade at tick level. As the requirement of unique time stamp is waived in storing tick data. tick database often
> >> >> >> > > > gets
> >> >> >> > > > corrupted, ie., later db records can have older time stamp. And together without knowing the exact timing of these
> >> >> >> > > > ticks
> >> >> >> > > > coming in. I dont believe there is anyone who is willing to trade with REAL MONEY at tick level.
> >> >> >> > > > From a practical standpoint, I have never found this refresh rate striction difficult to live with. A resolution of 1
> >> >> >> > > > second is plenty fast enough for me, even for trading futures.
> >> >> >> > > > I think Tomasz is thinking about rehashing the underlining db structure. Along with changing Volume to a floating
> >> >> >> > > > point
> >> >> >> > > > number. if he would consider expanding his PackDate to more than 4 bytes. He can then have a timestamp resolution of
> >> >> >> > > > a
> >> >> >> > > > fraction of a second. Then any request to enhance tick trading would make more sense. In the meantime. there isnt
> >> >> >> > > > much
> >> >> >> > > > point in trying to get a faster refresh rate than 1 second IMHO.
> >> >> >> > > >
> >> >> >> > > > amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> >> >> >> > > > >
> >> >> >> > > > > Yes Paul,
> >> >> >> > > > >
> >> >> >> > > > > the crux is that requestTimedRefresh only has a 1 second resolution, whereas in the preferences you can set it to 0
> >> >> >> > > > > for
> >> >> >> > > > > per tick updates, or as fast as your charts permit.
> >> >> >> > > > >
> >> >> >> > > > > What I'm requesting only applies to the instance where you have it set to 0 in the preferences.
> >> >> >> > > > >
> >> >> >> > > > > Regards,
> >> >> >> > > > > Julian.
> >> >> >> > > > >
> >> >> >> > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> >> >> >> > > > > >
> >> >> >> > > > > > Julian
> >> >> >> > > > > > It does, but only if the refresh time interval is >= 10 seconds as well.
> >> >> >> > > > > > I do that all the time with my RT trading. I have trading logic that is updated every 1 sec, and querying and
> >> >> >> > > > > > displaying of my positions as a separate chart, updating every 10 seconds.
> >> >> >> > > > > > If you put now() in your chart title, you can see how often your chart is being refreshed.
> >> >> >> > > > > >
> >> >> >> > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> >> >> >> > > > > > >
> >> >> >> > > > > > > Paul,
> >> >> >> > > > > > >
> >> >> >> > > > > > > the problem with requestTimedRefresh is that it doesn't remove that chart from the standard update queue.
> >> >> >> > > > > > > If I specify requestTimedRefresh(10), that chart is still going to be updated along with every other chart on
> >> >> >> > > > > > > every
> >> >> >> > > > > > > standard refresh, perhaps once a second, which is a waste of cpu time.
> >> >> >> > > > > > >
> >> >> >> > > > > > > What I want is for that chart to only update every 10 seconds so that other charts can be updated more quickly.
> >> >> >> > > > > > >
> >> >> >> > > > > > > Regards,
> >> >> >> > > > > > > Julian.
> >> >> >> > > > > > >
> >> >> >> > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paul.tsho@> wrote:
> >> >> >> > > > > > > >
> >> >> >> > > > > > > > I'm not sure what you're trying to do.
> >> >> >> > > > > > > > It is already possible to specify how often to update charts individually. The refresh rate in preference set
> >> >> >> > > > > > > > the
> >> >> >> > > > > > > > slowest rate and the default refresh rate. Individual chart can be refreshed at a rate set by
> >> >> >> > > > > > > > requestTimedrefresh(). the only difference between what you want (I guess ?) and what AB is doing seems to be
> >> >> >> > > > > > > > one
> >> >> >> > > > > > > > of the following
> >> >> >> > > > > > > > 1. requestedtimedrefresh does not guarantee refresh rate
> >> >> >> > > > > > > > 2. not possible to refresh more frequently than 1 second.
> >> >> >> > > > > > > >
> >> >> >> > > > > > > > Traditionally, A tick is defined as a minimum move in price that is possible in an instrument. In AB, I
> >> >> >> > > > > > > > gather a
> >> >> >> > > > > > > > tick is both defined as a course of sale as well as a 5 seconds interval,ie. 12 ticks a minute. So I'm not
> >> >> >> > > > > > > > sure
> >> >> >> > > > > > > > what you mean by rendering every tick. But if you want to render you charts for every new course of sale,
> >> >> >> > > > > > > > then
> >> >> >> > > > > > > > it
> >> >> >> > > > > > > > is more possible. Is that what you want?
> >> >> >> > > > > > > >
> >> >> >> > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Julian" <juliangoodsell@> wrote:
> >> >> >> > > > > > > > >
> >> >> >> > > > > > > > > Hi Tomasz,
> >> >> >> > > > > > > > >
> >> >> >> > > > > > > > > just to be clear from my side, as this thread has veered off course a little, I'm NOT suggesting running
> >> >> >> > > > > > > > > afl
> >> >> >> > > > > > > > > scripts without a render, or threading out the afl processing from the GDI rendering.
> >> >> >> > > > > > > > > I'm NOT suggesting any changes to the current architecture.
> >> >> >> > > > > > > > >
> >> >> >> > > > > > > > > I'm asking for the ability to set refresh rates per chart, for which the functionality already seems to be
> >> >> >> > > > > > > > > there.
> >> >> >> > > > > > > > > Running indicator calculations without rendering is a waste of cpu time, and so is rendering charts that
> >> >> >> > > > > > > > > don't
> >> >> >> > > > > > > > > need to be.
> >> >> >> > > > > > > > > If I have a chart that only needs to be updated every minute, there's no point in AB trying to render it on
> >> >> >> > > > > > > > > every
> >> >> >> > > > > > > > > tick update.
> >> >> >> > > > > > > > >
> >> >> >> > > > > > > > > Allowing us to specify at what intervals we want individual charts to update, would save countless wasted
> >> >> >> > > > > > > > > cpu
> >> >> >> > > > > > > > > time.
> >> >> >> > > > > > > > >
> >> >> >> > > > > > > > > Regards,
> >> >> >> > > > > > > > > Julian.
> >> >> >> > > > > > > > >
> >> >> >> > > > > > > > > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@> wrote:
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > Hello,
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > There is no sense in doing indicator calculation when this calculation
> >> >> >> > > > > > > > > > does not lead to actual rendering. That would be waste of CPU.
> >> >> >> > > > > > > > > > The purpose of doing indicator calculation is to actually display it (refresh it).
> >> >> >> > > > > > > > > > Indicators formulas are here to display something.
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > If you want code that does not display anything, you should run it as
> >> >> >> > > > > > > > > > automatic-analysis (scan/exploration) code.
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > Also AFL formula execution is often much faster than final GDI output,
> >> >> >> > > > > > > > > > therefore even if AFL formula was executed in parallel, it would still
> >> >> >> > > > > > > > > > face GDI contention because of Windows GDI system-wide lock.
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > Only on Windows 7 this system-wide GDI lock is removed and only
> >> >> >> > > > > > > > > > there you could see graphic performance scaling
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > Again, read the entire article:
> >> >> >> > > > > > > > > > http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > Especially figure 4 GDI Concurrency and Scalability
> >> >> >> > > > > > > > > > - as you can see in any pre-Win7 systems, GDI does not scale *at all*
> >> >> >> > > > > > > > > > with adding threads.
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > I can ensure you that I have actually *timed* many scenarios
> >> >> >> > > > > > > > > > and what I say is based on actual measurement and not on somebody's "belief".
> >> >> >> > > > > > > > > > That was one of the reasons I did not use GDI+ ("improvement" suggested by somebody on this list)
> >> >> >> > > > > > > > > > because real-world test revealed that it is 6 times slower than normal GDI.
> >> >> >> > > > > > > > > > Microsoft admitted that by the way in their recent demonstration on PDC (prof. dev. conference).
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > So, all decisions regarding development of AmiBroker are not based on beliefs but on
> >> >> >> > > > > > > > > > hard code profiling evidence.
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > Best regards,
> >> >> >> > > > > > > > > > Tomasz Janeczko
> >> >> >> > > > > > > > > > amibroker.com
> >> >> >> > > > > > > > > > ----- Original Message -----
> >> >> >> > > > > > > > > > From: "Yofa" <jtoth100@>
> >> >> >> > > > > > > > > > To: <amibroker@xxxxxxxxxxxxxxx>
> >> >> >> > > > > > > > > > Sent: Sunday, July 12, 2009 9:47 PM
> >> >> >> > > > > > > > > > Subject: Re: [amibroker] Per Chart Refresh Rates
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > >
> >> >> >> > > > > > > > > > > Hi Thomas,
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > >> Tomasz wrote in the "Data And PlugIn Speed" thread
> >> >> >> > > > > > > > > > >>I may add that the concept of independent rendering from multiple threads
> >> >> >> > > > > > > > > > >>although attractive from first look, it inevitably hits the wall of GDI
> >> >> >> > > > > > > > > > >>which in all current versions of Windows has
> >> >> >> > > > > > > > > > >> single system-wide exclusive global lock, which means that only ONE thread
> >> >> >> > > > > > > > > > >> can actually render at one time. This means that adding threads does not
> >> >> >> > > > > > > > > > >> give you better performance.
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > >>The truth is that all current releases of Windows are not particularly
> >> >> >> > > > > > > > > > >>suited for multi-core/multi-CPU
> >> >> >> > > > > > > > > > >>but good news is that Microsoft apparently have given these limitations
> >> >> >> > > > > > > > > > >>some thought and
> >> >> >> > > > > > > > > > >>many of them are removed in Windows 7.
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > > That is true for rendering only! (Apps main thread is allowed to write the
> >> >> >> > > > > > > > > > > GDI device. So rendering is limited to a single thread.)
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > > But indicator calculation (and trading logic) could get executed by any
> >> >> >> > > > > > > > > > > threads. Am I right? So doing the calculation on a background thread than
> >> >> >> > > > > > > > > > > doing chart painting with the "main" thread would increase processor usage
> >> >> >> > > > > > > > > > > and increase chart refresh reate? (I guess we all have dual and quad core
> >> >> >> > > > > > > > > > > CPUs...)
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > > How about separating "calculation refresh rate" and "chart refresh rate"? So
> >> >> >> > > > > > > > > > > I could request my panel to execute 3 times per sec without chart repaint
> >> >> >> > > > > > > > > > > (this could be executed by any threads) and refresh visible chart in every
> >> >> >> > > > > > > > > > > 3rd sec (this requires rendering, so calculation is done by a background
> >> >> >> > > > > > > > > > > thread, and painting is done by main thread))?
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > > Any thoughts?
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > > Regards,
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > > Y
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > > (I know it is not doable in a day work, but I guess all short
> >> >> >> > > > > > > > > > > term/daytraders are having trouble bacause of refresh limitations.)
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > > --------------------------------------------------
> >> >> >> > > > > > > > > > > From: "Julian" <juliangoodsell@>
> >> >> >> > > > > > > > > > > Sent: Sunday, July 12, 2009 8:14 PM
> >> >> >> > > > > > > > > > > To: <amibroker@xxxxxxxxxxxxxxx>
> >> >> >> > > > > > > > > > > Subject: [amibroker] Per Chart Refresh Rates
> >> >> >> > > > > > > > > > >
> >> >> >> > > > > > > > > > >> Hi Tomasz, I thought I'd start a new thread on this topic as I think it's
> >> >> >> > > > > > > > > > >> an interesting one.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> Tomasz wrote in the "Data And PlugIn Speed" thread
> >> >> >> > > > > > > > > > >>> I may add that the concept of independent rendering from multiple threads
> >> >> >> > > > > > > > > > >>> although attractive from first look, it inevitably hits the wall of GDI
> >> >> >> > > > > > > > > > >>> which in all current versions of Windows has
> >> >> >> > > > > > > > > > >> single system-wide exclusive global lock, which means that only ONE thread
> >> >> >> > > > > > > > > > >> can actually render at one time. This means that adding threads does not
> >> >> >> > > > > > > > > > >> give you better performance.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> In response to that Tomasz,
> >> >> >> > > > > > > > > > >> you're referring to performance on the basis of multiple charts being
> >> >> >> > > > > > > > > > >> rendered per refresh update.
> >> >> >> > > > > > > > > > >> E.g. If you have ten charts on screen, and they take a total of 2 seconds
> >> >> >> > > > > > > > > > >> to render, then there's little performance gain to be had by threading
> >> >> >> > > > > > > > > > >> them because of the GDI lock. That is fine and I get that.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> But what I'm referring to is the ability to control which charts render
> >> >> >> > > > > > > > > > >> when, so that all ten don't have to be updated every refresh.
> >> >> >> > > > > > > > > > >> The problem is that in real time mode with the refresh interval set to 0
> >> >> >> > > > > > > > > > >> in the preferences, if I have a tick chart that only takes 10ms to update,
> >> >> >> > > > > > > > > > >> it's still only going to be rendered every 2 seconds because that's how
> >> >> >> > > > > > > > > > >> long the other nine charts take to render, even though I don't need them
> >> >> >> > > > > > > > > > >> to be updated multiple times per second, but maybe only once every 5
> >> >> >> > > > > > > > > > >> seconds or even every minute.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> If we could set refresh rates per chart, then you could have time critical
> >> >> >> > > > > > > > > > >> tick charts update as fast as possible, and longer timeframe or more time
> >> >> >> > > > > > > > > > >> expensive/less critical charts only update every 5 seconds or even longer.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> By staggering chart updates, traders would have much greater control over
> >> >> >> > > > > > > > > > >> performance and not waste so much processing power updating charts that
> >> >> >> > > > > > > > > > >> don't need to be. This would trounce any other kind of performance
> >> >> >> > > > > > > > > > >> improvement that could be gained by optimizing the rendering engine
> >> >> >> > > > > > > > > > >> itself, and would require no threading or any real change to the current
> >> >> >> > > > > > > > > > >> architecture that I can see.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> Moreover, it appears this functionality is already in AB, but just that
> >> >> >> > > > > > > > > > >> there's no way for the user to control it.
> >> >> >> > > > > > > > > > >> The requestTimedRefresh() function enables you to update only the chart it
> >> >> >> > > > > > > > > > >> is applied to, so they can obviously be rendered independently of each
> >> >> >> > > > > > > > > > >> other.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> The problem though is that it is not enforceable. If I specify a refresh
> >> >> >> > > > > > > > > > >> interval of 1 in the preferences, and then requestTimedRefresh(10) on a
> >> >> >> > > > > > > > > > >> chart, that chart still gets updated every second along with all the
> >> >> >> > > > > > > > > > >> others, and then once more after ten seconds.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> Giving the option to make requestTimedRefresh() enforceable would be one
> >> >> >> > > > > > > > > > >> way of enabling this functionality. Perhaps add an enforceable parameter
> >> >> >> > > > > > > > > > >> to the function like:
> >> >> >> > > > > > > > > > >> requestTimedRefresh(10, onlyvisible=True, enforceable=false).
> >> >> >> > > > > > > > > > >> Then if I specify requestTimedRefresh(10, true, true), that chart should
> >> >> >> > > > > > > > > > >> only update every 10 seconds, irrespective of what I've set in the
> >> >> >> > > > > > > > > > >> preferences.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> Would this be as easy to implement as I think it is? If so, I think the
> >> >> >> > > > > > > > > > >> benefits would be rather large.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> Jules.
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> ------------------------------------
> >> >> >> > > > > > > > > > >>
> >> >> >> > > > > > > > > > >> **** 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
> >
> >
> >
>
------------------------------------
**** 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/
|