John,
I have done some of my testing with some surprising results.
My system:
P4 2.4GHz
1GB RAM
120GB 7200rpm 8MB Cache HDD
Windoze XP Pro SP2
PCCillian AV and Firewall
Test1:
Long entry and exit criteria as discussed.
01/01/1929 until 30/12/2005.
Points only test.
NOT a quick test.
Store the best 20 results.
MS installed (as normal) on HDD
DJI data on HDD
Rationale: this one of the original test prospects.
Test2:
Long entry and exit criteria as discussed.
01/01/1929 until 30/12/2005.
Points only test.
NOT a quick test.
Store the best 5000 results.
MS installed (as normal) on HDD
DJI data on HDD
Rationale: this is to test whether it takes longer to write to the ST_DATA.mdb file if there are more results to store. It shouldn't take any longer to write to a Jet Database containing 1 record or 10000 records, that's the whole idea of databases!
Test3:
Long entry and exit criteria as discussed.
01/01/1929 until 30/12/2005.
Points only test.
NOT a quick test.
Store the best 20 results.
MS installed in RAM Drive
DJI data in RAM Drive
Rationale: one of the originaly propsed tests.
Test4:
Long entry and exit criteria as discussed.
01/01/1929 until 30/12/2005.
Points only test.
NOT a quick test.
Store the best 20 results.
MS installed (as normal) on HDD
DJI data oin RAM Drive
Rationale: one of the originaly propsed tests.
Conditons:
With the exceptionof Test2, each test was run with a completely empty ST_DATA.mdb (with the exception, of course, of the system test being performed). It contained no results of any kind. Test2 was conducted with the ST_DATA.mbd containing the 20 results from Test1.
The RAM Drive was created and maintained using a trial version of RAMDiskXP from
www.cenatek.com The disk was 100MB and was carefully monitored during the testing to ensure it was never completely 'full'. There were a couple of issues trying to get MS installed in this space, as standard installation (and installations when not paying full attention) also includes the .wmv files, .pdf instructions, .doc advertising etc which are all extraneous to the requirements of running MS. Once I had cut down the fluff, we were left with the smallest working instalation of MS.
Results:
During the running of each test, I noted the progress of the test and plotted these in Excel to predict the finishing time for each test and to provide a graphical representation of all of the tests versus each other test. During the progress of each test, I wa able to see how closely each test 'fitted' to the predicted performance.
If the correlation was close to my estimates, I stopped the test at 50% complete to save my time and sanity. The assumption made is that the performance of each of the tests is the same in the second 2500 tests as the first 2500 tests. I could not see any reason why this would no be the case, but there is one issue that I will mention shortly.
The results surprised me. There was no apparent speed advantage using a RAM Drive over standard physical memory, IN MY COMPUTER!
During the tests involving the RAM Drive I observed the HDD access was significantly less than when the data/application is being taken from the HDD. The accesses 'seemed' appropriate with each of the tests being conducted.
Attached is the Excel graph and the raw data:
Notice that all the tests conducted would have completed in just under three hours. This is regardless of wheher the application is running from the HDD or RAM, and the data.
Why is this so?
Professor Julius Sumner Miller made this quote famous in Australia, but it is still very relevant today as we ask the same question of just about everything we do.
I believe the speed of the EST is dependent on a lot more than just MS. I believe the Operating System has a lot to answer for in this regard. The cache control imposed/implemented in my version of Windows XP needs further investigation?
JohnS wrote:The EST uses 3 types of files. The source data files (stored in the "\\MetaStock Data" folder), the ST_DATA.MDB "quick results and systems" file (stored in the "\\Equis\\MetaStock" folder) and the full results files (stored in the "\\Equis\\MetaStock\\Results" folder).
Correct. Lets note, the .mdb is a Jet Database, yet the results files are .dta files located in folders 1-10 under folders 1-10, so there is 100 folders containing the full system results. Databases are supposed to have dymnamic data coming to and going from the database on a regular basis, however, writing the results to a .dta file seems to be the biggest slowdown in the entire process. This is the reason that "Quick Tests" are sooo much faster than full system tests.
If Equis were going to redevelop the EST, this is the part where they need to spend some time?
JohnS wrote:When the EST starts a test, it opens the source data file, loads its content into the RAM, works from there and closes the source data file at the end of the test. Maybe it is not working exactly like that. But anyway, the EST doesn't make an intensive use of the source data file. The very low improvement in running times when working with the source data in the RAM drive is there to confirm it. (BTW, I still don't understand how my first results could give me an improvement of 75%. I must have made a mistake...)
The earlier improvemtn did seem a bit strange, but it was not beyond the realm of possibility.
I agree the source data is 'uploaded' into RAM for rapid access, but the full affect of this process and the efficient RAM employment is not going to be visible when running a test on a single security. To really test out the spec, I suggest that and entire market be subjected to the test. My data file for all ASX equities is about 69MB, so installing this small amount of data when I have 1GB of RAM (less OS overheads and RAM Disk space) is going to be insignificant. To stress the system, we need a lot more data and a lot less RAM!
JohnS wrote:When the EST starts a test, it also opens the ST_DATA.MDB file. But unlike with the source data, the EST uses intensively this file. Every time that an iteration is finished, it compares the result with the ones stored and if it is better than one of them, it replaces it with the new result. In addition if you decided to store full results, it will delete the full result files attached to the worse result stored (3 files per result) and it will write new full results files corresponding to the new result stored. Then when the test is over, the EST closes the ST_DATA.MDB.
Personally I think it would be more efficient to run the entire test, storing the results in a temporary area or RAM or physical memory in the order in which they occurred. At the end of the test, sort the results and return the required values. This will cut down on processes, but increases the memory requirement for the tests. This would of course mean the results writing procedure would have to be seriously modified also!
JohnS wrote:Second, because of the CPU Usage chart in the Task Manager. When the results are in the RAM drive, the CPU usage is at 100% all the time. When the results are on the HDD, the CPU usage chart looks like a sinusoid, with a low at the end of each iteration. I concluded from this that there must be a slow disk access that leaves the CPU "jobless" for some time.
My CPU was at or very nearly at 100% for the duration of the test. The was the occasional dip to about 98% but this did not occur regularly, nor did it seem to correspond with any particular progree of the EST tests.
AAARRRGGHH - Damn phpBB trimmed my post!