cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [RT] Adaptive Caching
Date Thu, 17 Jul 2003 13:03:10 GMT
Stefano Mazzocchi wrote:
>> The functions as defined by your initial algorithm used the sum notation,
>> which means we needed to maintain a list of samples for the resource.  
>> I.e.
>> the cost functions identified were a function of the resource and time of
>> request.  The more samples maintained, the less efficient the cache 
>> evaluation
>> became.
> yes, I see your point. I think it's entirely possible to use a windowed 
> version of the sum without degrading much the results (but this is, 
> again, a wild guess, this should have to be tested). that means, just 
> sum the last n terms, not more.

Which comes to the conclusion I came up with last night.  In the wonderful
world of audio, average loudness is measured by a meter that reports the
RMS of a particular period.  RMS (Root Mean Square) is used because dB
is a logarithmic function of sound intensity--it matches the problem space
better.  The set of samples used depends on how quickly we want the meter
to adjust to the signal.  For example, a 100ms window will always evaluate
the last 4,410 samples with CD quality audio.  This seems to provide a
nice balance for seeing the immediate intensity of the audio, and still
not being thrown off by the peaks.  However when you are level matching,
you want your meters to adjust more slowly, so extending the window to 3s
provides a much slower changing average which allows you to more accurately
match the levels.

Taking this further, it is important to know the peaks so that we can make
sure that we are not overloading the system, so modern professional digital
meters have a peak hold function as well as an overload indicator.  It is
important to note that the overload detection can be adjusted.  For example,
one sample reaching maximum amplitude does not necessarily indicate an overload.
Even two samples are not an authoritative measure.  Three or more samples at
maximum amplitude are a certain metric that we are overloading our A/D
converters.  You will never hear the clipping of three samples, but audio
engineers interested in the best quality music they can produce will set the
overload indicator function so that they know when they absolutely have to
do a retake.

Considering that overloading is important, the raw measure of the amplitude
(i.e. peak metering) is far less useful.  Trying to match the audio intensity
using peak meters will give you a false sense of the match.  You might be
able to get the peaks to match, but your ears will tell you that one is still
louder than the other.

The concept translates over to the adaptive cache approach at almost 1:1.
The actual individual cost sample is not important.  It is the windowed average
that is important.  For our cache a simple mean would best suit our problem
space.  The size of the window for our samples will control how responsive
our cache control algorithm is.  This would affect your cache prediction
algorithm as the value k is no longer needed to control responsiveness. The
value k can be set at 0, 1, or 0.5 depending on how you want to affect the
slope.  IMO, the window size should be the determining factor at how the average
cost for a resource will converge toward the optimal point.  Large window sizes
provide slower response, while a smaller window provides faster response.

> I'm thinking about implementing the cache separately from cocoon to see 
> if the math behind it works or not. If you have code to share, that 
> would be wonderful (you can place it in the scratchpad if you want)

Ok.  Let me package this later today.  I have a meeting for the next 3 hours.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

View raw message