Private:progress-aldhamin - Revision history

Aaldhami at 22:50, 24 June 2013

2013-06-24T22:50:29Z

Aaldhami at 22:50, 24 June 2013

2013-06-24T22:50:04Z

Aaldhami at 22:49, 24 June 2013

2013-06-24T22:49:27Z

Aaldhami at 22:48, 24 June 2013

2013-06-24T22:48:47Z

Aaldhami at 02:26, 29 April 2013

2013-04-29T02:26:17Z

Aaldhami at 17:58, 15 April 2013

2013-04-15T17:58:10Z

Aaldhami at 17:57, 15 April 2013

2013-04-15T17:57:10Z

Aaldhami at 22:12, 10 April 2013

2013-04-10T22:12:35Z

Aaldhami at 04:55, 9 April 2013

2013-04-09T04:55:42Z

Aaldhami at 05:07, 26 February 2013

2013-02-26T05:07:58Z

@@ Line 13: / Line 13: @@
 == April 2013 ==
 * ''April 28:''
-* Building a simple simulation program to see the effect of the algorithm. The program will measure the SSD hit according to the action performed by the algorithm.
+** Building a simple simulation program to see the effect of the algorithm. The program will measure the SSD hit according to the action performed by the algorithm.
-* The output of the algorithm (Action Table) will be used for the simulation.
+** The output of the algorithm (Action Table) will be used for the simulation.
 * ''April 15:''
-* We have been able to trace what's causing the application to behave in such a strange way with regard to the table size. In our algorithm we generate random numbers in two places:
+** We have been able to trace what's causing the application to behave in such a strange way with regard to the table size. In our algorithm we generate random numbers in two places:
 . simulating next state (random between 0 and 1).
@@ Line 28: / Line 28: @@
 * ''April 10:''
-* We're witnessing a problem that's not directly related to the algorithm, but has a crucial impact on it. It's related to the value table size that we specify on the implementation. In some cases we need to increase the value table size to accommodate for more calculations, but when we do so the algorithm executes in a strange manner which leads the function to converges to the threshold value sooner. For example, in one of the cases we have table size set to 2M but it wasn't enough for the function to converges. However, when we increased the size into 3M, the function converges very soon say at 9000 iteration or below at other experiments. I couldn't figure out what exactly is causing this issue. But, one thing that I noticed on my recent experiments is that it occurs with the extended version of the algorithm (3-most-frequent blocks). I'm striving to resolve this issue ASAP.
+** We're witnessing a problem that's not directly related to the algorithm, but has a crucial impact on it. It's related to the value table size that we specify on the implementation. In some cases we need to increase the value table size to accommodate for more calculations, but when we do so the algorithm executes in a strange manner which leads the function to converges to the threshold value sooner. For example, in one of the cases we have table size set to 2M but it wasn't enough for the function to converges. However, when we increased the size into 3M, the function converges very soon say at 9000 iteration or below at other experiments. I couldn't figure out what exactly is causing this issue. But, one thing that I noticed on my recent experiments is that it occurs with the extended version of the algorithm (3-most-frequent blocks). I'm striving to resolve this issue ASAP.
 * ''April 9:''
-* We've been working on finding a suitable composition for both the chunk size as well as sampling period. And we think that we some good selections based on some empirical observations.
+** We've been working on finding a suitable composition for both the chunk size as well as sampling period. And we think that we some good selections based on some empirical observations.
 * We've collected a larger workload for the Postmark benchmark and we're using this as an input to our algorithms. The new workload represents the I/O traces for 6,500,000 Read/Write transactions. We're now testing the algorithm with this new workload and hopefully we can draw some good conclusions to go to next step.
 * Two crucial bugs in the code was captured and has been fixed. The first was related to calculating the cumulative probability and simulating the next state of the algorithm, whereas the second was to do with generating a row-major transition matrix instead of a column matrix. This also results on performing wrong calculations for the next state.

@@ Line 1: / Line 1: @@
 = '''Summer 2013''' =
 * '''Courses:
-* CMPT 880: Large-scale Multimedia Systems and Cloud Computing'''
+** CMPT 880: Large-scale Multimedia Systems and Cloud Computing'''
 == June 2013 ==
 * ''June 24:''
-* A memory issue related to the action table sparse matrix has been detected and fixed. With this problem resolved, the algorithm now converges smoothly (mostly towards 0).
+** A memory issue related to the action table sparse matrix has been detected and fixed. With this problem resolved, the algorithm now converges smoothly (mostly towards 0).
-* Working on different experiments to try different combination of block size and sampling interval to find where the algorithm works best. So far, the experiments I have performed show that the larger the block size with reasonable sampling period, the higher the hit ration.
+** Working on different experiments to try different combination of block size and sampling interval to find where the algorithm works best. So far, the experiments I have performed show that the larger the block size with reasonable sampling period, the higher the hit ration.
 = '''Spring 2013''' =

@@ Line 1: / Line 1: @@
 = '''Summer 2013''' =
-* '''Courses:  CMPT 880: Large-scale Multimedia Systems and Cloud Computing'''
+* '''Courses:
 == June 2013 ==

← Older revision		Revision as of 22:48, 24 June 2013
Line 1:		Line 1:
		+	= '''Summer 2013''' =
		+	* '''Courses: CMPT 880: Large-scale Multimedia Systems and Cloud Computing'''
		+
		+	== June 2013 ==
		+	* ''June 24:''
		+	* A memory issue related to the action table sparse matrix has been detected and fixed. With this problem resolved, the algorithm now converges smoothly (mostly towards 0).
		+	* Working on different experiments to try different combination of block size and sampling interval to find where the algorithm works best. So far, the experiments I have performed show that the larger the block size with reasonable sampling period, the higher the hit ration.
		+
	= '''Spring 2013''' =		= '''Spring 2013''' =
	* '''Courses: none'''		* '''Courses: none'''

@@ Line 3: / Line 3: @@
 == April 2013 ==
 * ''April 15:''
 * We have been able to trace what's causing the application to behave in such a strange way with regard to the table size. In our algorithm we generate random numbers in two places:

@@ Line 5: / Line 5: @@
 * ''April 15:''
 * We have been able to trace what's causing the application to behave in such a strange way with regard to the table size. In our algorithm we generate random numbers in two places:
-. simulating next state (random between 0 and 1)
+. simulating next state (random between 0 and 1).
 . random action (0s and 1s)
 Aside from the main program, I generated two lists of random numbers, one for each of the above. Then, I used these lists in the main program as follows:
 First, I used both of those lists in the main program and it always converged at the 1000 iterations regardless of the table size. I set it to 2M, 3M, 4M and it always converges at 1000 iterations. Second, I used the first list of random numbers and used it to generate simulating next state, and let the random action to be generated on the fly within in the main program. When doing this, the application termination iteration is dependant on the table size; when I set the table size to 4M it converges at 1000 iterations and when I set it to 3M it didn't converges even at the 3M iteration. Third, I used the second list in the main program for the random action and let the simulation generate random number on the fly. When doing this, the program always terminates at the 1000 iteration, similar to the first case.
 This observation lead me to conclude that the problem is related to random number generator for the random action. Let's meet tomorrow to discuss this and see what should we do next.

@@ Line 3: / Line 3: @@
 == February 2013 ==
 * ''February 14:''
 * The off-line version of our dynamic programming algorithm is done. We've tested few cases and it shows some good results in terms. The tests performed included different "chunk" sizes to measure the time it takes for the evaluation function to converge to some threshold we can set. Overall, the algorithm seems to perform as expected. More parameter-tuning will be performed later to ensure it meets the problem requirements.