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