changing cache update time

I tried having the simulation program sleep for 10 milliseconds (this would have about doubled the average cache update time) and I ran one of the traces through that I had done previously.

I compared the hit ratios and they were exactly the same which means that simply using the sleep function did not work as I wanted due to the way the simulation program simulates the flows. Basically when the program is sleeping, no packets are being processed so they just wait until the program wakes up and are handled then so the hit ratio is not effected at all by that approach.

I am going to need to look into other ways of simulating the program running on different speed processors.

The next steps

The next step in the project is to determine how the hit ratio changes based on the processor/memory that the program is being run on. We want to simulate this by changing the time that the cache management update takes to compute, more time representing a slower processor.

I am currently going through the code to try to determine the best way to increase the computation time of the rule cache update. I am trying to determine if something like a sleep function would give the desired results.

I am going to try to meet with Dheeraj to go over some changes that were made to the code.

Hit Ratios

Today I took a look at the hit ratio. The trace files are the same ones as the previous graphs that showed the cache update delay so you can see how the hit ratio corresponds to that.

I first graphed the Hit ratio of one of the traces (trace3a) as you can see here:
This is the hit ratio as it is calculated over each beacon interval (the Trace Time on the x-axis). As you can see this varies quite a bit from one interval to another. I then decided that it may be more helpful to look at the average hit ratio, or cumulative hit ratio as it says in the output of the program.

I graphed this for the three traces from the cache update time from before, the results are here:

The cumulative hit ratio seems to start out high in the warm up period and then settle around a certain percent. The ending cumulative hit ratios from the trace were 97.69% for trace3a, 97.97% for trace5a, and 97.89% for trace6a.

sampling factor

I compared the traces I ran with sampling factors of 1, 1024, and 2048 and all other parameters the same, the results were very similar. The traces with 1024 and 2048 sampling intervals both had the average update time of approximately 8.5 milliseconds. The trace with a sampling factor of 1 was just slightly better for time to calculate the update with just under 8 milliseconds.

It appears that the sampling factor size does not greatly effect the calculation of the new rule set.

Cache Update Times

I ran the simulation with three different trace files of actual traffic. All of the trace files give similar times to update the rule cache, the time starts out fairly high, around half a second and then quickly decreases to a couple milliseconds and the average seemed to stabilize between 8 and 9 milliseconds. This is the overall average of the time to calculate the new ruleset.

The traces were run with cache size of 10, window size of 1024, and a sampling interval of 1024. You can see the values for the cache update time in the graph below:

I am running one of the traces again with a sampling factor of 1 to compare the results to these traces.

update

I figured out that I was giving the simulator program on baleen a bad trace file, I have been able to run the simulator with a trace now. The problem is this takes quite a while to run, I'm going to start the program running on a trace file and let it go for a while and record the output to get the average cache update delay.

Once the simulation is done running I can graph the update delay or other various statistics like the filetrace in the previous post. I should have some results in the next post.

work summary

I tried to run the rulecache simulation on the baleen machine to get the timing with the actual traffic traces. I was unable to do so because the program would seg fault and crash.

I did discover that in the newer version of the files on baleen already calculate the average time to update the rule cache and print this value out with the other statistics.

I found some filetraces of the program that were on baleen. I took a look at the filetrace_5dims-0updatetime.out trace file. This runs the simulation with the RHL size varrying between 16 and 23. I graphed the average time to update the rule cache as the simulation was running and here are the results:As you can see the average update time starts out high and then goes down to a couple milliseconds as the simulation runs. The last average update time was 8.99 milliseconds.

I took a look at some of the other filetraces on baleen, some of them start with RHL size of 1, this had a significantly higher update time, around 2-3 seconds.

If I can't get the program to run I will next take a look at the correlation between the RHL size and the time to update the cache in the other traces.

updated timing results

The previous entry was timing over the whole window size in the simulation, we want to see how long it takes to perform the rule cache update one time, so here are some preliminary results for how long it takes per packet.
The graph is percentage of packets (Y axis) versus time to compute new the new rule set (in microseconds) on the X axis. As you can see a majority of the calculations took 2 microseconds. The average time over the packets is 2.4 microseconds. This was done on my machine (3.4Ghz P4 with HT and 1 GB Ram) using the test trace file.

I am working on getting the timing data using one of the actual trace files, those results should be up within the next few days.

Cache Management Timing

I think I managed to get the correct timing for the rule cache management delay. From the test flow record that I have, the delay seems to be between 3 ms to 7 ms running on my home computer (3.4Ghz P4 HT with 1GB RAM).

The next step is now to test this on other machines and compare the results.