<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Saran,<div><br></div><div>I would also recommend to run your simulation with different seed:</div><div> --RngRun=<N> parameter in command line or </div><div> Config::SetGlobal ("RngRun", IntegerValue (Run)); in the scenarion</div><div><br></div><div>I have a suspicion that "similar" results you're observing for Lfu and Lru is that the only user of random stream is Zipf and Random policy on node1. So, in both cases, for the same RngRun parameter, you are getting exactly the same sequence of "random" numbers, and of course the results are exactly the same. When you install Random on the other node, you're basically getting something different, since sequences are different now.</div><div><br></div><div>So, for your small experiment, try to make at least 10-20 independent runs with different RunRun (1, 2, 3, 4..., 20: this will properly initialize up NS-3 seeds), and then calculate measurement error and confidence intervals. I hope you get more explainable results then.</div><div><br></div><div>---</div><div>Alex</div><div><br></div><div><div><div>On Jun 9, 2013, at 8:15 PM, Saeid Montazeri <<a href="mailto:saeid.montazeri@gmail.com">saeid.montazeri@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Dear Saran,</div><div><br></div><div>I think if you try with different seeds and get the average, the difference may be disappeared even for s=1.0.</div><div><br></div><div>Best Regards,</div><div>Saeid<br><br><div class="gmail_quote">
On Fri, Jun 7, 2013 at 11:06 PM, Saran Tarnoi <span dir="ltr"><<a href="mailto:sarantarnoi@gmail.com" target="_blank">sarantarnoi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Dear Saeid and All,<div><br></div><div>The exact number of the content objects in the network is 10,000 different objects (one interest for one content object.)</div><div>The Zipf parameters q = 0 and s = 0.5, 1.0, 1.5, and 2.0. In other words, Zipf-Mandelbrot is simplified to Zipf distribution.</div>
<div>There is no link bottleneck due to the redundant link capacity, so all the interests are satisfied.</div><div><br></div><div>The differences of hit rate depend on Zipf parameters.</div><div>The summary of the cache hit percentage of node 1, which uses Random as replacement policy (the replacement policy of node 2 is varied), is below.</div>
<div><br></div><div> s Lfu Lru Random</div><div>0.5 1.865 1.865 2.572<br></div><div>1.0 33.123 33.123 36.467</div><div>1.5 86.542 86.542 86.025</div>
<div>2.0 98.646 98.646 98.348</div><div><br></div><div>The difference is obvious when s=1.0.</div><div>If you need more information, please let me know.</div><div>Thank you.</div><div>
<br></div><div>Regards,</div><div>Saran</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/7 Saeid Montazeri <span dir="ltr"><<a href="mailto:saeid.montazeri@gmail.com" target="_blank">saeid.montazeri@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Saran,<div><br></div><div>1. May we know the total number of contents in the network. In addition, what is the size distribution of the contents. (in total how many different Data packets exist in the network).</div>
<div>
2. What is the difference between cache hit ratios?</div><div><br></div><div>Best Regards,</div><div>Saeid<div><br><br><div class="gmail_quote">On Fri, Jun 7, 2013 at 7:52 PM, Saran Tarnoi <span dir="ltr"><<a href="mailto:sarantarnoi@gmail.com" target="_blank">sarantarnoi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Saeid and All,<div><br></div><div>Thank you very much for your helpful answer. :)</div><div>I also agree with your first thought. Two nodes may use the same generated sequence of random seed.</div>
<div><br></div><div>In my experiment, the number of generated interests was quite small, 200,000 interests with 60,000 interest warm up period.</div><div>The cache size is 100 objects.</div><div>The scale is tiny but the difference of results obviously appears.</div>
<div><br></div><div>I'm running simulation for 2,000,000 interests with 1,000,000 interest warm up period to see whether or not the interest number can help. </div><div>Thank you again.</div><div>
<br></div><div>Regards,</div><div>Saran Tarnoi</div><div> </div></div><div class="gmail_extra"><div><br><br><div class="gmail_quote">2013/6/7 Saeid Montazeri <span dir="ltr"><<a href="mailto:saeid.montazeri@gmail.com" target="_blank">saeid.montazeri@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Saran,<div><br></div><div>Would you please let us more about your experiment setting: how long the consumer generates Interests or how many requests are generated?</div>
<div><br></div><div>Meanwhile, my guess is that the problem may be because of the sequence of the random number that is used by random replacement policies. <b>If both policies in node 1 and 2 use the same random number generator(or at least dependent random number generators)</b>, the problem is because of that. If we assume that is the case, suppose that a random number sequences for cache size equals 2 be 1,2,1,2,2,1. (3 means that incoming Data packet will not be written to the cache). If only one replacement policy is random then 1,2,3,1,3,2,2,1 will be the replaced slots in the first node. However, if both of the nodes have random replacement policies, the replaced slot in the first node depends on the misses in the second node. <b>If the policies in node 1 and 2 use independent random generators</b>, I have no idea. </div>
<div>In any case, would you please let us know for how many requests you did the experiment. Because I think it should be related to the transient behavior of the system and if you run the simulation for enough long period of time, you may get pretty close results.</div>
<div><br></div><div>Best Regards,</div><div>Saeid</div>
<div><br></div><div><br><br><div class="gmail_quote"><div>On Fri, Jun 7, 2013 at 4:19 PM, Saran Tarnoi <span dir="ltr"><<a href="mailto:sarantarnoi@gmail.com" target="_blank">sarantarnoi@gmail.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr">Hello Alex and All,<div><br></div><div>I did some experiments and found some wired results.</div>
<div>The experimental setup is as follows.</div>
<div><br></div><div><div>(Random, Lru, or Lfu) node 2 <--- (producer)</div>
<div> l</div><div> l</div><div> (Random) node 1 <--- (consumer, Zipfmandelbrot)</div></div><div><br></div><div>The cascading network has 2 nodes.</div>
<div>These nodes has the same size of Content Store.</div><div>Consumer and producer are installed in nodes 1 and 2, respectively.</div><div>Zipfmendelbrot is set as the Interest traffic model for consumer.</div>
<div><br></div><div>Random is the replacement policy for node 1 while either Random, Lru, or Lfu is the replacement policy of node 2.</div><div><br></div><div>The cache hit rate at node 1 (the first-hop node) should be consistent and independent of the replacement policy deployed in node 2.</div>
<div>However, the results don't follow the above logic.</div><div><br></div><div>The cache hit rate at node 1 when either Lru or Lfu is set as the replacement policy of node 2 are exactly the same but different from when Random is the replacement policy of node 2.</div>
<div><br></div><div>In addition, I don't see any problem when Lfu or Lru is set as replacement policy of node 1.</div><div><br></div><div>Is it a bug or random seed problem?</div><div>Could you give me any idea?</div>
<div>Thanks a lot for your time.</div><div><br></div><div>Regards,</div><div>Saran Tarnoi</div></div>
<br></div>_______________________________________________<br>
ndnSIM mailing list<br>
<a href="mailto:ndnSIM@lists.cs.ucla.edu" target="_blank">ndnSIM@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div></div><span><font color="#888888">-- <br>Regards,<div>Saran Tarnoi</div><div>Graduate Student</div><div>Department of Informatics</div><div>The Graduate University for Advanced Studies (Sokendai)</div>
<div>Tokyo, Japan</div><div><a href="http://sarantarnoi.blogspot.jp/2012/11/my-profile.html" target="_blank">http://sarantarnoi.blogspot.jp</a><br></div>
</font></span></div>
</blockquote></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<div>Saran Tarnoi</div><div>Graduate Student</div><div>Department of Informatics</div><div>The Graduate University for Advanced Studies (Sokendai)</div>
<div>Tokyo, Japan</div><div><a href="http://sarantarnoi.blogspot.jp/2012/11/my-profile.html" target="_blank">http://sarantarnoi.blogspot.jp</a><br></div>
</div>
</div></div></blockquote></div><br></div>
_______________________________________________<br>ndnSIM mailing list<br><a href="mailto:ndnSIM@lists.cs.ucla.edu">ndnSIM@lists.cs.ucla.edu</a><br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndnsim<br></blockquote></div><br></div></body></html>