Excel in 2007 has only limited support of separate cores. I think they improved upon this in 2010. Still, VBA processes are limited to a single thread....and that is hugely limiting of you are using a lot of VBA in your algo. Check this out: http://blogs.office.com/b/microsoft...ation-can-become-much-faster-in-excel-12.aspx
Speaking of Office... xp 2007, 2010... im actually on 2003. And running monte carlos with Excel, 4 cores are better than 2 cores, and I tried running 8 Excel.exe processes. As for now, the running of Excel in "Realtime" Priority does help, and I am separating the tws program(core 0/2) frm my excel.exe(core 1/3) hopefully this might help hehe.
I had been running the TOS desktop platform in REALTIME but many said it would crash the machine. It never did....it worked beautifully. Unfortunately, it couldn't solve their data delay problem, so I moved to IB. I am very surprised to see old Excel 2003 run faster in multiple cores....that's not supposed to happen with that 8 year old piece of software !
> Thanks for your reply savagemp5. Iam not running any algos or anything of that nature. All I just wanted to do is to be able to monitor the 5-min OHLC of say about 100 stocks on an excel spreadsheet at quick glance, that's all. Cheers < I think I would just get the real-time data and build my own bars in the VBA, and post them to a worksheet on a timer event or a button either based on your need for speed. kztd
Thanks for your reply KZ. I have already done this (or at least almost done). My query was what do I use as the 'Close' price, as nothing is displayed in the close column of the 'Real Time Bars' worksheet. I have already emailed IB about this and chased them up 3 times, it's been more than a month now, and I have not had any reply from them, unbelievable!!!
Here's how I would solve the original poster's problem: 1. Forget the IB integration methods with Excel. 2. Write a C# program to process the 5 min OHLC values interfacing to the TWS with their ActiveX component (TWS.ocx). 3. Send the values to Excel by DDE using the free NDde C# library. You could easily come up with a DDE item naming convention keyed off of the symbol name so the sender (C# program) and the receiver (spreadsheet) inherently know them. Caveat: If Excel doesn't need to process the data further, then instead of step 3, take Excel totally out of the loop and display the values from the C# program itself with a datagrid component. [Anyone who would want to get seriously involved with Excel programatically should probably go the Visual Studio Tools for Office approach where you have spreadsheets actually embedded within a C# program.]
Unfortunately, don't have a clue about C#. Is this something that can be easily picked up like VBA? Thanks
SteveH- that is a good idea...especially when there are more than a dozen symbols being tracked. But one question in my mind has always been regarding the threading logic: when do you establish a new thread ? Every new symbol ? Every 10 new symbols ?
Think about it this way. How much processing do you need to do for each symbol ? For the prices coming in, unless you are crushing 1000 data / sec. You just run through a standard routine and decide if its a Buy / Sell or do nothing. Im only running about 20 of them. and say like once every 15 secs for eg, not every tick. maybe because I don't do 2nd level quotes, because I dont see a reason too. Even so I wont be fast enough to capture. So i guess... depends on strategy.
Can you please clarify: 1) why is it a better approach to instantiate the ActiveX object using VBA rather than embedding the activex control in the worksheet? 2) what nasty bug are you referring to? Does it exist in office 2010? or has MSFT already released a patch for it? Thanks.