On Thu, 27 Jul 2000, Derek Johnstone wrote:
> I ran the test with the default time (ExpDur==4hour) and the results
> were good at Req_Rate==200/sec, showing stable results throughout
> the test. Part of the testing involved running this same test for a
> greater duration to test stability. The 'ExpDur' was set to
> '10hour' and the test left to run. When I observed the results in
> the Executive Summary the following day, I saw that the results were
> not good with significant degradation of the 'Hit Ratio', and a
> significant increase in the 'hit Response Time'. Looking at the
> graphs showed that the results to be very good for the first 4 hours
> of the test, but after this there was a steady degradation in the
> results, with all graph traces increasing quite badly except the
> offered.hit.ratio.obj and the hit.ratio.obj, which when in the
> opposite direction. This is 100% reproducible.
Datacomm-1 workload is rather old and relatively "easy" on a cache. You
may want to use PolyMix-2 or even PolyMix-3, eventually.
The behavior you are seeing can be caused by the cache running out of
disk space to store useful traffic. Datacomm workload does not have a
constant working set size. The longer you run the test, the more objects
a cache has to store in order to achieve maximum hit ratio (55%).
PolyMix-2,3 workloads have a special feature that freezes the working
set size (but not the working set!) after some time, providing for a
steady state conditions. Please read PolyMix-2 discussion on the
subject:
http://polygraph.ircache.net/Workloads/PolyMix-2/#Sec:WorkSet
My guess is that the cache under test was sized to hold 4 hours of
Datacomm fill traffic, but cannot hold much more. Whether it is good or
bad is difficult to say in general. However, if you are an ISP, you
should be able to estimate how much traffic you want _your_ caches to
keep.
> So please could you let me know if there is a problem when running
> datacomm-1.pg for longer than the default 4 hours, and if this is
> so, is there any way around this problem so that longer tests can be
> executed.
You have several choices here:
- use Polygraph 2.2.9 and adjust Datacomm workload to
freeze the working set size after some time, say,
3 hours; search polymix-2.pg for "working_set_length"
- use Polygraph 2.2.9 and PolyMix-2; the working set size
will be frozen after the first 4 hours
- add more storage to your cache and run Datacomm "as is"
> Also, please could you let me know how polygraph calculate the
> 'Throughput' in the executive summary, as I would have thought this
> would be equal to the supplied Req_Rate, but is instead somewhat
> higher.
How much higher? Usually, offered load (req/sec) and measured load
(rep/sec) are the same (see the "Load" table in the "Engineer summary").
Offered load might differ slightly from the configured Req_Rate due to
the random nature of the traffic, but the difference should be
negligible.
HTH,
Alex.
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:14 MDT