Hello, And it is also possible to have 500 symbols in each of Real-Time Quote window in AmiBroker and switch instaneously using tabs. http://www.amibroker.com/guide/w_rtquote.html
But... in all of this you are missing one very important point. Watching real-time quotes is fundamentally different from running exploration or watching a chart because for that you need BOTH historical AND real-time data matched (coalesced) together. So you need data from TWO sources (real-time stream AND backfill) and match them together. Only ONE source (real time stream) is used to display RT quote (as QT portfolios) and you don't need to do ANY processing / keeping data in memory as RT quotes show just current data that you get from the RT stream without any processing or any need to keep in memory. That is making huge difference. Best regards, Tomasz Janeczko amibroker.com On 2010-05-21 21:36, kurasake wrote: > You can think of a QuoteTracker portfolio as a sheet/tab in Excel. If you > switch to a different sheet/tab that becomes the "active" one. > > "Fetch Quotes for All Portfolios" simply means that only the symbols in the > currently selected/active sheet are updated with data. If it's turned on, > then all the symbols in all the sheets/tabs would be updated, in essence it > treats the entire Excel workbook as one sheet. So if you had 25 symbols in > one sheet and 50 in another and 100 in another, "Fetch Quotes for All > Portfolios" would update all 175 symbols, regardless if it's in the currently > selected/active sheet or not. If it's turned off then only 50 symbols (or 25 > or 100 depending on the selected/active sheet) would update. > > This goes off topic for an AB forum but QT saves all data that it receives > (and I would suspect all investment programs that have a graphing/chart > function do as well). If however, you don't have "Fetch Quotes for All > Portfolios" set, there will be a gap in data for the time period when the > symbol was not in an active portfolio. In that case, you have to do a > (manual) backfill for that symbol. > > There are definitely similar paradigms at the Application layer that you > would find at the lower layers... after all, whether it's electrical signals, > light pulses or bits and bytes, it's all just about storing/sending/using > data... > > Cheers and have a good weekend! > > > --- In [email protected], "pragaon"<whereis.myk...@...> wrote: > >> I think that makes sense. >> "Fetch quotes for all portfolios" turned off means No backfill. (I guess.) >> With that way, it is possible to switch symbols without affecting much >> performance. >> I would use such feature with Excel. One column with all live prices and >> others doing formulas. >> In this mode, the server's job is to give the latest data only. Symbol limit >> (number) is the only thing it will check. >> >> But when you use it with graphic application, you will need backfill and >> then the calculation becomes challenging. >> The server does not know which symbol needs how much back fill etc and the >> total bandwidth per user should not exceed. >> >> I can relate it to Frame relay technologies (layer 2). >> Frame relay is old technology, before DSl and cable. There are concepts like >> CIR (committed information rate), burst rate, peak rate, Discard eligibility >> etc. >> All this is to make sure that quality of service is maintained for all >> clients fairly and as per clients subscription level. >> I am sure at application level, they won't be using layer 2 concepts, >> exactly...but similar. >> >> Regards, >> Prakash. >> >> --- In [email protected], "kurasake"<kurasake@> wrote: >> >>> Hi Prakash >>> >>> As far as my conversation with IQFeed Support goes, I can have 500 (or 400 >>> or 50 or whatever number) symbols monitored at a time and can freely switch >>> to 500 new symbols and switch to 500 more and 500 more etc, etc. The only >>> limit they impose is 500 at a time. >>> >>> As an example, in QuoteTracker, let's say I have 5 different portfolios >>> consisting of 1 symbol, 15 symbols, 50 symbols, 100 symbols and 500 symbols >>> if I switch between the different portfolios, the symbol subscription count >>> in the IQFeed Connection Manager appropriately goes up and down to reflect >>> the number of symbols I have in the current/active portfolio. Switching >>> between portfolios is pretty much instantaneous (note: this is with "Fetch >>> Quotes for All Portfolios" turned off). >>> >>> So I can't speak for IB but as far as IQFeed is concerned, it doesn't >>> appear that there's any intent to limit me to 500 symbols a day in any way, >>> practically or otherwise. >>> >>> As for how it's implemented, I honestly don't know but I would doubt it's >>> constructing 100 tunnels. There are far more efficient ways to send data >>> streams. >>> >>> Cheers! >>> >>> >>> --- In [email protected], "pragaon"<whereis.mykake@> wrote: >>> >>>> >>>> >>>> Hi, >>>> >>>> I don't want to take any side, but would like to tell you my experience on >>>> similar topic with Interactive broker. >>>> IB allows 100 streaming quotes. I *tried* to switch that active 100 list >>>> in real time to see if it works. >>>> >>>> Below is what I have learned from it. >>>> It may be a wrong understanding, but I had made my peace with the fact of >>>> "symbol limit" from any real time data source. >>>> >>>> Here it goes: >>>> ========= >>>> when a RT service provider says streaming quotes limit is 100 it means, in >>>> all "practical" sense you have to make your mind for the 100 list once you >>>> start at the beginning of trading day. and it is better to keep it >>>> untouched till trading day ends. Though, quote provider do not say so in >>>> words. >>>> What may be happening is, you (client) have to authenticate with user id >>>> and your 100 list with server at Service provider. >>>> Once authentication process completes, it builds individual 100 tunnels >>>> through which it can send 100 streams. Now each stream will have it's own >>>> buffer at client as well server side so that the flow can be kept smooth. >>>> (Think of sliding window in TCP/IP.) >>>> >>>> Now the authentication, tunnels built up and buffering to happen takes a >>>> "very significant" time and resources. >>>> consider that if streaming 1 symbol takes 1 unit of cpu and 1 unit of >>>> bandwidth, then authentication and tunnel built up, buffering takes 4 >>>> units of CPU and 4 units of bandwidth. >>>> So when you change few symbols from the 100 list in the middle of the day, >>>> it severely affects the "momentum" at the server side. >>>> Now how bad it gets depends on how the server handles such situation. >>>> The quote provider will never say that, "you can not change the "100" >>>> list". Off course you can. but at the cost of severe performance >>>> degradation in service for some time at least. >>>> >>>> Solution? >>>> >>>> Surrender. I will subscribe for 1000. I will make the list of 950 before >>>> beginning of trading day. Start streaming at least 10 mins before the >>>> market starts to get the streaming flow smooth and keep it untouched till >>>> end of the day. The remaining 50 empty slots is for ad hoc adding of more >>>> symbols during day, so that 950 streams stays smooth. >>>> I look at the situation like a Automobile's claimed mileage. >>>> The road has to be smooth, weather has to be nice, No AC ...blah blah blah… >>>> Once again, I may becompletely wrong in assessing and analyzing the >>>> situation here. But I had my peace with it. >>>> >>>> Regards, >>>> Prakash. >>>> >>>> >>>> --- In [email protected], "kurasake"<kurasake@> wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> I have read and re-read all your responses many times over, so please >>>>> believe me that I'm not ignoring anything that you've written. In each >>>>> of my responses, I think I've carefully outlined my understanding of what >>>>> you wrote as well as where I think there's still a disconnect or >>>>> lingering issues/questions. >>>>> >>>>> I understand you when you say that there's an issue of speed about >>>>> getting data from an already subscribed symbol vs having to subscribe and >>>>> then get the data and that the difference in arrival times may lead to >>>>> problems. >>>>> >>>>> I should first note that I've _only_ run Explorations with "wait for >>>>> backfill" set so all my experiences and examples refer to "wait for >>>>> backfill" selected scenarios. I can not speak about situations where 4 >>>>> simultaneous backfills are issued but I can see how that might quickly >>>>> become a problem. I think this might clear up at least one >>>>> misunderstanding. >>>>> >>>>> Next, I think we agree that (in the case of "wait for backfill" set) the >>>>> problem with data corruption only occurs when the subscription limit is >>>>> reached. So even if you have a mix of symbols that are already >>>>> subscribed vs not subscribed, and even though there would still be >>>>> "timing differences" between the two, there is _no_ data corruption as >>>>> long as the symbol limit has not been reached. If data corruption >>>>> occurred before then, it would be happening all the time, which it's >>>>> clearly not. >>>>> >>>>> >>>>> >>>>> It appears then, that the root cause of data corruption when the "wait >>>>> for backfill" set, is when we've reached the subscription limit counter. >>>>> >>>>> >>>>> Before I go further, I'd like to settle the whole "greed" issue >>>>> regarding paying for 500 symbols and asking for more. I've spoken >>>>> directly with IQFeed support regarding this. >>>>> >>>>> Hopefully I've outlined in my previous message that even though from a >>>>> programmer's perspective, there may not seem to be a difference between >>>>> (what I've called) "True" real-time, simultaneous data access (like what >>>>> you might see in the RealTime Quote window) vs maxing out the >>>>> subscription limit via an Exploration, from the paying customer's >>>>> perspective, there are very big differences. >>>>> >>>>> In case you missed what I wrote earlier, the basic difference is: >>>>> >>>>> - In "True" real-time, simultaneous data access, you actually are >>>>> _constantly_ getting data for _all_ 500 symbols simultaneously in >>>>> real-time. If I populated the RealTime Quote window with 500 symbols, >>>>> IQFeed would be updating symbol data for 500 symbols, constantly, in real >>>>> time, simultaneously. Where as in the situation of the Exploration, >>>>> since request for symbol data is essentially sequential, you're only >>>>> getting data for one symbol at any given time. >>>>> >>>>> I can understand that from the programmer's perspective it's the same >>>>> thing because in _both_ situations 500 subscription slots are used. But >>>>> from the paying customer's perspective as well as IQFeeds comments, they >>>>> are _not_ the same thing. >>>>> >>>>> Again, I've spoken directly with IQFeed Support to confirm and my >>>>> agreement with them is for 500 "True" real-time, constant, simultaneous >>>>> symbol data. They acknowledge that "browsing" through and getting >>>>> backfills for _thousands_ of symbols is _NOT_ a breech of contract, >>>>> _NOR_ is it being greedy or trying to get more then what I'm paying for >>>>> etc. Sequentially "browsing" through symbols one at a time (which is >>>>> essentially what the Exploration with "wait for backfill" turned on does) >>>>> is perfectly legal, permissible, no problem and well within my rights. A >>>>> programming analogy is 500 threads getting data constantly in the >>>>> background and using up 500 subscription slots vs 1 thread filling up 500 >>>>> subscription slots one symbol at a time. >>>>> >>>>> Let's say as another example, that each symbol's data is 1kb (I don't >>>>> know how much it really is and I know it varies depending on things, I'm >>>>> just using this number as an example). What I'm paying for is (500 x 1kb) >>>>> = 500kb of data streaming constantly at the same time but what I'm >>>>> actually getting with an Exploration is just (1 x 1kb) = 1kb of data at >>>>> any given time. All subscription slots are used up so from the >>>>> programmer's perspective I can see how you'd think that I'm asking for >>>>> more than what I'm paying for but the reality is I"m only getting 1kb of >>>>> streaming data vs 500kb of streaming data. >>>>> >>>>> Since all but one subscription slot is actually getting data, I shouldn't >>>>> have to pay for more symbols. It's only because AB hasn't released the >>>>> slots for unselected, "inactive", "dormant" symbols that the subscription >>>>> limit is reached. Even if I delete all the symbols in AB and I'm getting >>>>> 0kb of data, it's still registered that the subscription limit is reached. >>>>> >>>>> The truth is, if I run an Exploration on 500 symbols and I'm using 500 >>>>> subscription slots but I'm only getting data for one symbol at any given >>>>> time, I'm _NOT_ getting what I paid for. If anything, it's the opposite >>>>> of being greedy. >>>>> >>>>> And to reiterate, as far as IQFeed is concerned, I can go through and >>>>> backfill as many symbols as I want. so long as I'm not going for more >>>>> than (500 x 1kb) of streaming data at a time. If I ever have a need for >>>>> more than 500kb of streaming data at a time, I will gladly pay for it. >>>>> But what you are telling me is that I should pay for (1300 x 1kb) = >>>>> 1300kb of streaming data when I'm currently only using 1kb of streaming >>>>> data. >>>>> >>>>> Also, I may have been guilty of using the phrase "_exceed_ the >>>>> subscription limit" but that isn't entirely correct. The IQFeed client >>>>> actually makes sure that the subscription count is never "exceeded" and >>>>> that's how they make sure that I'm not asking/getting more then what I'm >>>>> paying for. If IQFeed's intention was to only limit me to 500 symbols >>>>> per day, and not browse through as many symbols as I want, I'm pretty >>>>> sure they wouldn't have added an API to unsubscribe symbols. >>>>> >>>>> I'm as fallible as anyone so if my logic is flawed, please tell me so. >>>>> >>>>> >>>>> The case you make for not unsubscribing the symbols immediately after >>>>> each use is because of the speed difference between getting data for the >>>>> subscribed vs un-subscribed symbols. The former takes a few milliseconds >>>>> and just a little bit of data and the later a few seconds with a lot more >>>>> data (though in my tests it only seems to take at most a second or so per >>>>> un-subscribed symbol to do a backfill). And to confirm, I believe we can >>>>> conclude that (with "wait for backfill") data corruption only occurs when >>>>> the subscription limit is reached. >>>>> >>>>> Unless I'm missing something, I think the Pros of unsubscribing symbols >>>>> immediately after each use far outweight the Pros of unsubscribing only >>>>> after the subscription limit has been reached. >>>>> >>>>> If we wait to unsubscribe a symbol until the subscription limit is >>>>> reached, we are practically _guaranteed_ that data corruption will occur. >>>>> >>>>> Since data corruption obviously has serious consequences in a stock >>>>> investment program, the somewhat awkward "workaround" is the user has to >>>>> take many extra steps to keep track of the number of symbols he's >>>>> importing, the number of symbols already being tracked in other programs, >>>>> make sure the Exploration is only run on X number of symbols for every >>>>> run, close and reconnect the connection to IQFeed to reset the >>>>> subscription count, select the next group of symbols, make sure that >>>>> there isn't more than X symbols etc. For those of us who import symbols >>>>> from various screeners, this can become quite a chore _AND_ there's >>>>> still the possibility that somewhere along the line, the number of >>>>> symbols were mis-counted and we end up with corrupt data without >>>>> realizing it. That's the worst case scenario but it's also a very likely >>>>> one. >>>>> >>>>> In addition, waiting to unsubscribe until the subscription limit is >>>>> reached means that there's a chance that AB is going to "monopolize" all >>>>> of the subscription slots and not "share" these slots with other programs >>>>> running on the computer (in my case QuoteTracker). Again, the user has >>>>> to keep constant count of how many symbols are being monitored in _all_ >>>>> the programs that are using the data feed. And if somewhere along the >>>>> way, there's a mis-count it can again have serious consequences with >>>>> symbols not getting updated. For example, if AB had run an exploration >>>>> on 450 symbols and 51 symbols are added to QuoteTracker (or whatever >>>>> other program), that last symbol in QT would not get updated and the user >>>>> may not realize it until it's too late (esp if it's a symbol with low >>>>> volume). >>>>> >>>>> And as mentioned ealier, this scenario has the additional problem in that >>>>> while AB is holding on to 450 subscription slots, it's only getting >>>>> real-time data for the currently selected symbol... which is really not >>>>> what I'm paying for. >>>>> >>>>> Lastly, if I understand you correctly, AB will never unsubscribe a symbol >>>>> _unless_ the subscription limit is reached ie. it does not unsubscribe >>>>> symbols in any other situation except for when subscription count = 500. >>>>> This is the case even if you delete symbols in AB. >>>>> >>>>> What I've interpreted from your messages is that AB is holding on to the >>>>> subscription slots because in the event another exploration is run, it'll >>>>> get data faster for the already subscribed symbols... which I can >>>>> appreciate . >>>>> >>>>> But, if the only case for waiting to unsubscribe a symbol until >>>>> absolutely necessary is speed (are there other reason's I missed?), then >>>>> I would say it's far more preferable to unsubscribe symbols immediately >>>>> after each use and have future backfills run slower vs. run the risk of >>>>> getting corrupt data and cause all the other issues... Or to at least >>>>> give the user the option to select. I would think that running the risk >>>>> of getting bad data is the last thing you, the developer and we the >>>>> users, would want. >>>>> >>>>> That is unless there are other issues regarding unsubscribing that >>>>> haven't been mentioned (are there other technical limitations on IQFeed's >>>>> side regarding unsubscribing symbols?) or another possibility is, >>>>> there's an entirely different source for the problem. >>>>> >>>>> >>>>> - As far as I can tell, there's proper flow-control/handshaking >>>>> between AB, the AB Plugin and the IQFeed data client (again, I only run >>>>> Explorations with "wait for backfill" set). While watching all the status >>>>> windows, AB appears to wait for each backfill to complete before moving >>>>> on to the next symbol. According to the AB Plugin Status Window, there >>>>> never appears to be more then "1" pending backfill during an Exploration. >>>>> And, as far as I can tell, the IQFeed client is not being overwhelmed >>>>> with backfill requests. If this is all true, then the timing issue >>>>> between subscribed data coming quickly and unsubscribed data coming >>>>> slowly shouldn't impact AB's processing, correct? >>>>> >>>>> - We've established that there's no data corruption if we're below >>>>> the subscription limit. So doesn't it make sense to unsubscribe the >>>>> symbol after each use because this would prevent the condition when data >>>>> corruption is guaranteed to occur? >>>>> >>>>> In conclusion, even if the trade off is that it might make _future_ >>>>> backfills slow, I think it makes sense to unsubscribe the symbol after >>>>> each use as it prevents >>>>> - the subscription limit from being reached and thus resulting in the >>>>> condition where data corruption occurs, >>>>> - fixes all the other issues mentioned above related to reaching the >>>>> subscription limits. >>>>> >>>>> I know you're a small operation and deal with a million things from a >>>>> million users as well as all the other things in life, so I do appreciate >>>>> your responses. I do however, think that this is a non-trivial issue >>>>> worth pursuing since even if I buy a subscription to more symbols and try >>>>> to do all the work-arounds, it can still very easily result in getting >>>>> corrupt data. And you've built an extremely powerful, terrific, >>>>> world-class program, I can't imagine you would want the possibility of >>>>> corruption occurring or even to have this restriction on symbol counts. >>>>> >>>>> With Respect and Best Regards. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --- In [email protected], Tomasz Janeczko<groups@> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> The plugin ***DOES*** unsubscribe oldest symbol already if you exceed >>>>>> the limit. >>>>>> >>>>>> Please guys, I wrote everything in my first response. Just read what I >>>>>> wrote as >>>>>> all these questions were answered. >>>>>> >>>>>> The issue is that if you unsubscribe then given symbol is no longer >>>>>> updated >>>>>> and if you access it again, you need to backfill again. Minimum backfill >>>>>> in IQFeed >>>>>> is ONE DAY, even if you just missing few minutes. eSignal for example >>>>>> does not have such limitation - you can get backfill for just few >>>>>> minutes, making >>>>>> it much faster. >>>>>> Now if you re-subscribe the symbol and issue backfill request, the >>>>>> subscribed >>>>>> data arrive way earlier (hunderds of milliseconds) than backfill data >>>>>> (many seconds) >>>>>> and that difference in arrival times may lead to problems. eSignal again >>>>>> does not have that problem >>>>>> because eSignal API provides a way to specify exact (down to a minute) >>>>>> start and ending times >>>>>> for backfill. Also if you do not use "wait for backfill" flag, you will >>>>>> hit the limit of simultaneous backfills that can be run >>>>>> (4 at the same time), so you may not receive backfill data and you get >>>>>> the data hole. >>>>>> I wrote before - there are TECHNICAL limitations of IQFeed that decide >>>>>> how it works >>>>>> and that's why you should NOT exceed, IQFeed subscription limits, if you >>>>>> want clean data. >>>>>> >>>>>> Accept that, or buy more symbols (you can have 1300 with IQFeed). >>>>>> Don't you understand that you need to pay more for more data ? >>>>>> The subscription limits are for a reason. Why do you think that feed >>>>>> providers would be so stupid to allow >>>>>> reliably getting 30000 symbols on 500 symbol subscription??? >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Tomasz Janeczko >>>>>> amibroker.com >>>>>> >>>>>> On 2010-05-19 23:25, Rob wrote: >>>>>> >>>>>>> This may be a silly question... but does the IQ Feed API allow AB to >>>>>>> 'unsubscribe' a symbol once it has been subscribed to...?? >>>>>>> Or does that required an AB shutdown...? >>>>>>> >>>>>>> >>>>>>> --- In [email protected], "kurasake"<kurasake@> wrote: >>>>>>> >>>>>>> >>>>>>>> Hello Tomasz. >>>>>>>> >>>>>>>> I don't mean any disrespect, so please don't take anything I've >>>>>>>> written that way. I'm not that great of a writer and it can be >>>>>>>> challenging to properly convey my thoughts via text. I really >>>>>>>> appreciate the time you take in these forums. >>>>>>>> >>>>>>>> You wrote: >>>>>>>> >>>>>>>> "because the backfill from IQFeed is SLOW, IQFeed is literally >>>>>>>> unable to keep up with exploration or any automatic scan" >>>>>>>> >>>>>>>> And >>>>>>>> >>>>>>>> "AmiBroker on the other hand is able to scan thousands of >>>>>>>> symbols in one second, therefore IQFeed is not able to deliver data >>>>>>>> fast enough (via backfill) if you exceed subscription limits. Because >>>>>>>> of the time IQFeed needs to do the backfill (if you exceed >>>>>>>> subscription counts), you may end up with data holes" >>>>>>>> >>>>>>>> So I'm interpreting this to mean that problems occur because, when >>>>>>>> subscription limits are exceeded, IQFeed can't service backfill >>>>>>>> requests to AB fast enough. And because an AB Exploration is so much >>>>>>>> faster than IQFeed, it just continues to send requests for backfills >>>>>>>> to the IQFeed client regardless of whether or not IQFeed has fulfilled >>>>>>>> the previous request(s). >>>>>>>> >>>>>>>> Please correct me if I'm not understanding correctly. >>>>>>>> >>>>>>>> >>>>>>>> There are two points I'm trying to make. What I'm saying is: >>>>>>>> >>>>>>>> - 1 - There is still an issue of AB not releasing IQFeed >>>>>>>> subscription "slots" even after it's done using it. In the example I >>>>>>>> gave in my earlier email, when I click on a symbol in AB, it takes up >>>>>>>> a subscription slot in IQFeed. This is expected behavior. However, >>>>>>>> if I move on to another symbol or even if I _delete_ that symbol from >>>>>>>> AB, the subscription slot in IQFeed is _never released_. This means >>>>>>>> that if I run an Exploration on 500 symbols, and then delete all 500 >>>>>>>> symbols from AB, IQFeed still thinks that all 500 subscription >>>>>>>> "slots" are used up. >>>>>>>> >>>>>>>> You write: >>>>>>>> >>>>>>>> " if you exceed the subscription limit AmiBroker will unsubscribe >>>>>>>> oldest symbol (the one that was accessed first) and subscribe new and >>>>>>>> will request backfill" >>>>>>>> >>>>>>>> So why not simply "unsubscribe" the symbol as soon as it's done with >>>>>>>> it instead of waiting for the subscription limit to be reached? Is >>>>>>>> there a big hidden cost for unsubscribing a symbol that prevents this? >>>>>>>> >>>>>>>> _I'm beginning to think that unsubscribing the subscription slots >>>>>>>> after use might be the solution to everything_ Please allow me to >>>>>>>> explain. >>>>>>>> >>>>>>>> When I actually run an Exploration and I open up the IQFeed Connection >>>>>>>> Manager and the AB IQFeed Plugin Window, I can watch what symbols are >>>>>>>> being requested& serviced and how fast the requests are issued etc >>>>>>>> as well as how many IQFeed subscription "slots" are being used. >>>>>>>> >>>>>>>> _As far as I can tell, everything appears to be very orderly._ The >>>>>>>> AB "Checking for Signals..." dialog box shows the symbol that AB is >>>>>>>> processing as well as what% of the symbols it's processed. This >>>>>>>> symbol pretty much syncs up with the AB Plugin Window which shows the >>>>>>>> actual backfill request being fulfilled. And the rate at which the >>>>>>>> symbols are being processed in AB syncs up with how fast the #of >>>>>>>> Symbols counter in the IQFeed Connection manager goes up. >>>>>>>> >>>>>>>> _So it looks like there's proper flow-control between AB, the AB >>>>>>>> Plugin and the IQFeed Client._ The counter in the "Running Backfills" >>>>>>>> in the AB Plugin Window never goes over "1". So as far as I can tell, >>>>>>>> AB is waiting for backfill requests to be fulfilled before moving on >>>>>>>> and it doesn't appear to be overwhelming IQFeed at all. All backfill >>>>>>>> requests appear to be being serviced at a rate of about one second or >>>>>>>> so. This is whether or not I've exceeded the subscription limit or >>>>>>>> not. >>>>>>>> >>>>>>>> Since there seems to be proper flow control and the problems with data >>>>>>>> corruption only appear to happen when the subscription limit is >>>>>>>> reached, one solution would be to simply unsubscribe the symbol >>>>>>>> immediately after each use. >>>>>>>> >>>>>>>> This would also alleviate the problem of sharing the limited number of >>>>>>>> subscription slots with other programs. Even if the cost of >>>>>>>> unsubscribing takes one second, I think it would be well worth it and >>>>>>>> certainly a better alternative to data corruption. >>>>>>>> >>>>>>>> But since I can't possibly know all the internals going on, assuming >>>>>>>> there's some programming stuff in the background going on that's not >>>>>>>> visible in these status windows... >>>>>>>> >>>>>>>> - 2 -. Why not add an option which the user can select/de-select, >>>>>>>> which would add some "negotiation" features so it doesn't overwhelm >>>>>>>> IQFeed? Maybe send 2 or 3 or 4 requests for backfills, wait for one >>>>>>>> or more requests to be completed and then send the next requests etc. >>>>>>>> Isn't waiting for requests to be serviced before moving on a pretty >>>>>>>> common protocol in applications that require data from an external >>>>>>>> data source? >>>>>>>> >>>>>>>> >>>>>>>> What I mean by "...I'm not asking for more than 500 _simultaneous_ >>>>>>>> symbol updates at a time..." is that I don't have the need to view 500 >>>>>>>> symbol updates in realtime like what you see in the RealTime Quote >>>>>>>> window. The RealTime Quote Window is what I would call "true" 500 >>>>>>>> simultaneous symbol updates. >>>>>>>> >>>>>>>> An exploration may _eventually_become_ 500 pending requests because of >>>>>>>> the speed difference (though according to all the status windows that >>>>>>>> doesn't appear to the case), but I'm guessing that requests for data >>>>>>>> in an Exploration isn't the same thing as requests for data in the >>>>>>>> RealTime Quote Window. This is what I might call "situational" 500 >>>>>>>> symbol backfill "requests" because it all depends on the number of >>>>>>>> requests pending in the queue as well as the request rate and sevice >>>>>>>> rate. >>>>>>>> >>>>>>>> Also, in this case, although all subscription slots are filled, only >>>>>>>> one symbol at a time is actually updating data. >>>>>>>> >>>>>>>> Aren't requests for backfills in an Exploration executed sequentially, >>>>>>>> albeit at a very, very fast rate? Or are 500 threads spawned and >>>>>>>> actually executing 500 backfill requests at once? And once an >>>>>>>> Exploration is "done" with a particular symbol, it's no longer >>>>>>>> receiving data for it in the background, correct? I don't mean this >>>>>>>> facetiously, I'm assuming all these things but I really don't know. >>>>>>>> >>>>>>>> So while the end result might mean that in both cases, all 500 >>>>>>>> subscription slots are used up, using up slots via the RealTime Quote >>>>>>>> window is not the same as using up slots via an Exploration. And from >>>>>>>> a functional stand point, nor should they be. >>>>>>>> >>>>>>>> So, as far as my contract with IQFeed goes, once an Exploration is >>>>>>>> finished, it may look like I'm still doing 500 simultaneous, real time >>>>>>>> data updates (because all the IQFeed subscription slots are used) but >>>>>>>> I'm actually only updating data for one symbol (the currently selected >>>>>>>> one). >>>>>>>> >>>>>>>> This might not seem like a big deal from the programming perspective, >>>>>>>> but as the paying customer, I'm paying for "real" 500 simultaneous >>>>>>>> updates as in the RealTime Quote window and I don't want to pay for >>>>>>>> subscription slots that are merely being "held open" but "dormant" or >>>>>>>> even, "orphaned". >>>>>>>> >>>>>>>> >>>>>>>> In the last example I give in my previous email, I ask what happens if >>>>>>>> I'm monitoring 50 or 100 or 400 or 499 symbols in QuoteTracker and >>>>>>>> then want to run an Exploration in AB? Wouldn't releasing each IQFeed >>>>>>>> resource after each use and some form of flow-control enable AB to run >>>>>>>> an exploration (albiet only as fast as IQFeed is able to keep up) no >>>>>>>> matter how many of the 500 slots are already in use by another program? >>>>>>>> >>>>>>>> I've spoken to IQFeed support and I'm well within my rights to : >>>>>>>> - ..."browse" as many symbols as I desire so long as it's not 500 >>>>>>>> simultaneous and continuous requests like in the RealTime Quote window. >>>>>>>> - ...connect as many programs to the IQFeed client as I want. So >>>>>>>> connecting QuoteTracker and AB to the same IQFeed client at the same >>>>>>>> time is completely legal. This makes the IQFeed client a limited and >>>>>>>> shared resource, just like computer memory or just about anything else >>>>>>>> inside a computer. >>>>>>>> >>>>>>>> Thank you for your time. >>>>>>>> >>>>>>>> Truly, With Respect and Best Regards. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --- In [email protected], Tomasz Janeczko<groups@> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> "But when I run an Exploration, I'm not asking for more than 500 >>>>>>>>> _simultaneous_ symbol updates at a time. " >>>>>>>>> >>>>>>>>> Yes you DO. >>>>>>>>> This is so because of technical limitations of IQFeed API I described >>>>>>>>> earlier. >>>>>>>>> >>>>>>>>> I wrote everything I wanted to write previously and you should re-read >>>>>>>>> what I wrote. >>>>>>>>> >>>>>>>>> If you think what I wrote is not correct, go on take free AmiBroker >>>>>>>>> Development Kit and >>>>>>>>> take IQFeed API and write your own better plugin. If you think that >>>>>>>>> IQFeed staff knows better >>>>>>>>> - ask them to write better plugin. And make sure you tell me what is >>>>>>>>> their response. >>>>>>>>> I would have a good laugh. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Tomasz Janeczko >>>>>>>>> amibroker.com >>>>>>>>> >>>>>>>>> On 2010-05-18 21:39, kurasake wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi Tomasz >>>>>>>>>> >>>>>>>>>> Thank you for your response. I sincerely appreciate the time you >>>>>>>>>> take to monitor these forums and answer questions. >>>>>>>>>> >>>>>>>>>> What I'm paying IQFeed for is real time data for 500 _Simultaneous_ >>>>>>>>>> symbol access. I am allowed to view as many symbols as I want so >>>>>>>>>> long as I don't view more than 500 at the same time. (I've confirmed >>>>>>>>>> this with IQFeed support). So, if I were to add 500 symbols to the >>>>>>>>>> Realtime Quote window, I wouldn't expect anything more. But when I >>>>>>>>>> run an Exploration, I'm not asking for more than 500 _simultaneous_ >>>>>>>>>> symbol updates at a time. >>>>>>>>>> >>>>>>>>>> As I understand it, an Exploration and Automatic Scan in AB is not >>>>>>>>>> _continually_ requesting data for 500 symbols simultaneously even >>>>>>>>>> after it's done with the exploration. Rather, (again, as I >>>>>>>>>> understand it), an Exploration and Automatic Scan goes through the >>>>>>>>>> list of symbols sequentially, requests data from IQFeed one at a >>>>>>>>>> time, and then goes on to the next symbol. >>>>>>>>>> >>>>>>>>>> So, once an Exploration is done backfilling a symbol, it's no longer >>>>>>>>>> requesting or getting data for that symbol. That means the whole >>>>>>>>>> _simultaneous_ and _realtime_ part that I'm paying for is being >>>>>>>>>> wasted since I'm _not_ actually updating data for 500 symbols with >>>>>>>>>> an Exploration. In effect, an Exploration takes a "snapshot" of >>>>>>>>>> the symbol's data and that's it. As far as AB is concerned, until >>>>>>>>>> another Exploration is run or the user selects another symbol or the >>>>>>>>>> Realtime Quote window is used to monitor symbols etc it really has >>>>>>>>>> no need for IQFeed except for the currently selected symbol. >>>>>>>>>> >>>>>>>>>> Clearly the IQFeed client provides the means for users to "look" at >>>>>>>>>> as many symbols as they want as long as it's not 500 symbols viewed >>>>>>>>>> _simultaneously_. And as IQFeed support personnel confirms, I'm >>>>>>>>>> well within my rights to view as many symbols as I want so long as >>>>>>>>>> it's not more than 500 at the same time. So, whether or not I >>>>>>>>>> exceed my 500 symbol subscription limit depends entirely on the >>>>>>>>>> stock investment programs to release each slot/ resource when it's >>>>>>>>>> done using it. >>>>>>>>>> >>>>>>>>>> If I open up the IQFeed Client, it will display how many symbols are >>>>>>>>>> currently being tracked/monitored by IQFeed. And if I go into >>>>>>>>>> QuoteTracker and remove symbols from the list of symbols I want to >>>>>>>>>> monitor, the IQFeed Client will reflect that change and show that >>>>>>>>>> I've freed up those slots and that I'm now able to replace those >>>>>>>>>> symbols with new ones. However in AB, once I select a symbol, it >>>>>>>>>> holds on to an IQFeed "slot" even if I _delete_ the symbol from the >>>>>>>>>> AB database. So in this case, AB is still holding on to the IQFeed >>>>>>>>>> resource even though it can not possibly have any use for that >>>>>>>>>> resource. ( Or it may not "technically" be AB that's holding on to >>>>>>>>>> the resource but it clearly hasn't told IQFeed to free up that >>>>>>>>>> resource, so the end result is the same.) >>>>>>>>>> >>>>>>>>>> Using another example, let's say I run an exploration on 500 symbols >>>>>>>>>> in AB. After the Exploration runs, that means all 500 "slots" that >>>>>>>>>> I'm contracted for are filled up but are _NOT_ actually being used >>>>>>>>>> for simultaneous realtime updates. All 500 slots are in effect, >>>>>>>>>> used but dormant. Now, lets say in this state, I decide to run >>>>>>>>>> QuoteTracker on the same machine using the same IQFeed data source. >>>>>>>>>> Since AB is still holding on to the 500 slots, QuoteTracker would >>>>>>>>>> be unable to get any data, _EVEN THOUGH_ AB is not actually actively >>>>>>>>>> getting real time data for any symbol (except the currently >>>>>>>>>> selected). >>>>>>>>>> >>>>>>>>>> I've confirmed with IQFeed support that I'm allowed to connect as >>>>>>>>>> many programs to the IQFeed client as I want. This makes each >>>>>>>>>> "slot" in IQFeed is a limited and _shared_ resource. If an >>>>>>>>>> Exploration in AB ran through 500 symbols but didn't release those >>>>>>>>>> IQFeed slots, this would be analogous to a program using up all the >>>>>>>>>> memory and disk drive space so other programs are unable to run even >>>>>>>>>> though it's not really using any of it . So, if AB no longer uses a >>>>>>>>>> "slot", why not release it after each use? I think this is >>>>>>>>>> reasonable? >>>>>>>>>> >>>>>>>>>> I can appreciate that AB is too fast for IQFeed to handle. I think >>>>>>>>>> it's fantastic that you've made AB so fast. But with the backfill >>>>>>>>>> option in an Exploration turned on, I would think it would be better >>>>>>>>>> if there were a level of flow-control/handshaking between AB and >>>>>>>>>> IQFeed so that they "play nicely" with each other. >>>>>>>>>> >>>>>>>>>> If one of the main functions of any stock analysis/monitoring >>>>>>>>>> program is to provide accurate data to the user then I would think >>>>>>>>>> that AB should wait for IQFeed to "catch up" instead of continuing >>>>>>>>>> on and leaving IQFeed "behind" since we know that if AB keeps going >>>>>>>>>> for a large number of symbols, there's going to be corrupt data >>>>>>>>>> appearing in AB. The two programs must work nicely together in >>>>>>>>>> order to produce the desired result. The role of IQFeed is to >>>>>>>>>> service requests for data and to provide that data. The role of AB >>>>>>>>>> is to make requests for data from IQFeed and display and analyze >>>>>>>>>> that data accurately. In this case, IQFeed is clearly the >>>>>>>>>> bottleneck but as you mention, the data provider is always going to >>>>>>>>>> be the bottleneck, even if I switched to a faster provider. And >>>>>>>>>> clearly corrupt data has a major effect on things like buy/sell >>>>>>>>>> triggers and is an undesired problem. IQFeed, however slow, is >>>>>>>>>> still the data provider and AB is reliant on data from the data >>>>>>>>>> provider. Everything should work fine if there's proper >>>>>>>>>> communication/flow control between the two. >>>>>>>>>> >>>>>>>>>> This would be somewhat analogous to a computer with a near >>>>>>>>>> infinitely fast CPU working with a very, very slow disk drive and a >>>>>>>>>> very, very slow system bus and very, very slow memory etc. No >>>>>>>>>> matter how fast the CPU is, it must still wait for all the other >>>>>>>>>> components in order for it to produce the correct result. It's >>>>>>>>>> unfortunate that everything else isn't fast enough for the CPU but >>>>>>>>>> the CPU can not just go off and keep going on it's own just because >>>>>>>>>> everything else is too slow. I think this is a reasonable point as >>>>>>>>>> well? >>>>>>>>>> >>>>>>>>>> I think it would be fair if... : >>>>>>>>>> >>>>>>>>>> - AB released each IQFeed slot/resource as soon as it's done >>>>>>>>>> using it, since each IQFeed slot is a shared resource. >>>>>>>>>> - an Exploration waited for IQFeed (or any data provider) to >>>>>>>>>> "catch up" so that data corruption doesn't occur. Or perhaps have a >>>>>>>>>> switch that let's the user choose between having AB wait for the >>>>>>>>>> data provider or to just keep going. >>>>>>>>>> - or perhaps as another option, an ability for the user to >>>>>>>>>> release unused IQFeed resources via AFL/OLE etc... Though I would >>>>>>>>>> think that to ensure that the correct data is always displayed, AB >>>>>>>>>> should wait for the data provider to catch up. >>>>>>>>>> >>>>>>>>>> Otherwise, the user would need to change stock trading behavior to >>>>>>>>>> suit the limitations of the program. Constant symbol maintenance >>>>>>>>>> and tracking in AB would be a nightmare. This is especially true >>>>>>>>>> if for example I'm using up a lot of IQFeed slots in QuoteTracker >>>>>>>>>> and the available "free" slots left for Amibroker is far less then >>>>>>>>>> 500. What if I'm already tracking 499 symbols in QuoteTracker? >>>>>>>>>> Should this condition cause AB to start displaying corrupt data on >>>>>>>>>> Explorations on 10, 20, 50 symbols? >>>>>>>>>> >>>>>>>>>> Clearly these are limitations that don't need to exist (ie: there's >>>>>>>>>> nothing technically preventing AB from working well with IQFeed). >>>>>>>>>> Nor would I think that this is the type of behavior you would want >>>>>>>>>> in your program. >>>>>>>>>> >>>>>>>>>> I've talked over the 500 symbol limit issue with IQFeed Support and >>>>>>>>>> confirmed that I'm not asking for anything out of bounds . I'm not >>>>>>>>>> sure if my explanation were clear (I hope they were) but I think >>>>>>>>>> what I'm asking for is very reasonable and expected behavior for a >>>>>>>>>> stock monitoring/investing/trading program. >>>>>>>>>> >>>>>>>>>> Thank you for your time. >>>>>>>>>> >>>>>>>>>> With respect and best regards. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --- In [email protected], Tomasz Janeczko<groups@> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Simply speaking: you paid for 500 symbols and you receive 500 >>>>>>>>>>> symbols. >>>>>>>>>>> It is that simple. >>>>>>>>>>> If you buy Fiat do not expect it to be Bugatti Veyron. >>>>>>>>>>> >>>>>>>>>>> a) you are not allowed to exceed your subscription limits with >>>>>>>>>>> IQFeed. >>>>>>>>>>> IQFeed simply won't allow you to get data for more symbols at the >>>>>>>>>>> same time >>>>>>>>>>> (subscription to any more symbols will simply fail and you won't >>>>>>>>>>> get data) >>>>>>>>>>> >>>>>>>>>>> b) if you exceed the subscription limit AmiBroker will unsubscribe >>>>>>>>>>> oldest symbol >>>>>>>>>>> (the one that was accessed first) and subscribe new and will request >>>>>>>>>>> backfill, >>>>>>>>>>> BUT .... because the backfill from IQFeed is SLOW, IQFeed is >>>>>>>>>>> literally >>>>>>>>>>> unable to >>>>>>>>>>> keep up with exploration or any automatic scan. >>>>>>>>>>> IQFeed (and many other RT sources) takes many seconds to backfill >>>>>>>>>>> ONE symbol >>>>>>>>>>> (as IQFeed was designed to display CHARTS, not to perform whole >>>>>>>>>>> market >>>>>>>>>>> scans) >>>>>>>>>>> and is designed with "manual", i.e. *SLOW* operation in mind (so you >>>>>>>>>>> manually select the chart >>>>>>>>>>> and watch it) - the way how QuoteTracker works - MANUALLY (slowly) >>>>>>>>>>> adding/removing symbols >>>>>>>>>>> instead of running automated scans on huge portfolios. >>>>>>>>>>> AmiBroker on the other hand is able to scan thousands of symbols in >>>>>>>>>>> one >>>>>>>>>>> second, therefore >>>>>>>>>>> IQFeed is not able to deliver data fast enough (via backfill) if >>>>>>>>>>> you exceed >>>>>>>>>>> subscription limits. Becuase of the time IQFeed needs to do the >>>>>>>>>>> backfill >>>>>>>>>>> (if you exceed subscription counts), >>>>>>>>>>> you may end up with data holes (if you exceed the subscription >>>>>>>>>>> limit). >>>>>>>>>>> >>>>>>>>>>> Why do you expect receiving more data that you paid for ? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Tomasz Janeczko >>>>>>>>>>> amibroker.com >>>>>>>>>>> >>>>>>>>>>> On 2010-05-14 22:12, kurasake wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'm running AB 5.30pro using IQFeed as my RT data feed on a Core >>>>>>>>>>>> i7 w/4gig ram. >>>>>>>>>>>> >>>>>>>>>>>> In a different post, I'd been describing a problem I've been >>>>>>>>>>>> having when performing an exploration on a large number of >>>>>>>>>>>> symbols. The problem was that if I scanned too many symbols, I >>>>>>>>>>>> would start to get bad data appearing in AB. >>>>>>>>>>>> >>>>>>>>>>>> After some feedback, it appears that this problem occurs when I've >>>>>>>>>>>> scanned more symbols then what my contract with IQFeed allows. In >>>>>>>>>>>> other words, my contract with IQFeed allows me to monitor 500 >>>>>>>>>>>> symbols simultaneously at a time and if I exceed that 500 symbol >>>>>>>>>>>> limit, I would start getting bad data in AB. I haven't confirmed >>>>>>>>>>>> this "scientifically" yet but the problem does seem to happen >>>>>>>>>>>> after I've scanned somewhere in the neighborhood over 500 symbols. >>>>>>>>>>>> >>>>>>>>>>>> The question I have though is if I've only "looked" at a symbol in >>>>>>>>>>>> AB and I'm not actively monitoring it, like say in the Realtime >>>>>>>>>>>> Quote window, should AB still be holding on to an IQFeed >>>>>>>>>>>> "slot"/resource/token? I would think that if I'm not actively >>>>>>>>>>>> collecting data on a symbol and I've only "looked" at it for a >>>>>>>>>>>> brief moment, that AB should release this slot back to IQFeed. Or >>>>>>>>>>>> is AB still collecting data on that symbol even if it's not in the >>>>>>>>>>>> Realtime Quote window? >>>>>>>>>>>> >>>>>>>>>>>> If I open up the IQFeed Connection Manager, I can see how many >>>>>>>>>>>> symbols IQFeed is "tracking" for me. Every time I click on a >>>>>>>>>>>> symbol in AB and it backfills that symbol with data, the Number of >>>>>>>>>>>> Symbols counter in the IQFeed Connection Manager goes up. The >>>>>>>>>>>> counter however, never appers to go down unless I either break the >>>>>>>>>>>> connection from AB to the IQFeed client or I exit from AB. >>>>>>>>>>>> >>>>>>>>>>>> This puts a rather strong restriction on how I use AB as I can >>>>>>>>>>>> only scan/explore/look at 500 symbols in a single AB session and >>>>>>>>>>>> IQFeed thinks I'm using up my entire allotment when I'm not. >>>>>>>>>>>> >>>>>>>>>>>> Incidentally, if I run QuoteTracker on the same machine and have >>>>>>>>>>>> it connect to the same IQFeed client, it will "release" an IQFeed >>>>>>>>>>>> slot for every symbol I remove from the active QT portfolio. So >>>>>>>>>>>> it should be possible to do this in AB as well. >>>>>>>>>>>> >>>>>>>>>>>> If I perform a Reconnect or Shutdown from AB by right clicking in >>>>>>>>>>>> the status bar where it displays the client connection status, the >>>>>>>>>>>> IQFeed symbol count drops back down to what it was before I >>>>>>>>>>>> started AB. Does anyone know if there's any way to do this >>>>>>>>>>>> "reset"/release using COM objects or other programming means? >>>>>>>>>>>> Maybe I can write a vb script or something that keeps calling this >>>>>>>>>>>> obj method? Or is this a feature request that I need to place >>>>>>>>>>>> with AB? >>>>>>>>>>>> >>>>>>>>>>>> Many thanks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------ >>>>>>>>>>>> >>>>>>>>>>>> **** 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: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
