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 [email protected], "Paul Ho" <paul.t...@...> 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. > > [email protected], "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 [email protected], "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 [email protected], "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 [email protected], "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 [email protected], "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 [email protected], "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: <[email protected]> > > > > > > > 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: <[email protected]> > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
