RE: DELAY_POOLS: How to setup

I see your point (I should have paid more attention within the ifs). So,
actually, some tweaking is needed because the aggregate pool may delay a
user even if bandwidth is available in his individual pool. When the ind.
pool is zeroed out, only then the aggregate should be used.

Evaghelos.

> -----Original Message-----
> From: David Luyer [SMTP:luyer@ucs.uwa.edu.au]
> Sent: Thursday, November 12, 1998 10:42 AM
> To: Evaghelos Tsiotsios
> Cc:
> Subject: Re: DELAY_POOLS: How to setup
>
> > Dear David,
> >
> > 1) Actually this is the piece of code I saw that made me say this:
> > Always the last nbytes value is used.
> [...]
> > delayBytesWanted(delay_id d, int min, int max)
>
> The lowest delay pool is the one used, if any pool is zero the request is
> delayed, you're right there (that's what delayBytesWanted() does, finds
> the number of bytes to read).
>
> But if you look where it actually decrements the bytes it takes them off
> all
> relevant pools, hence all pools are consulted.
>
> Oh and if you look where you were reading:
> case 3:
> if (Config.Delay.class3.aggregate.restore_bps != -1)
> <---------
> nbytes = XMIN(nbytes, delay_data.class3_aggregate);
> if (Config.Delay.class3.individual.restore_bps != -1)
> <----------
> nbytes = XMIN(nbytes, delay_data.class3_individual[position]);
> if (Config.Delay.class3.network.restore_bps != -1)
> <----------
> nbytes = XMIN(nbytes, delay_data.class3_network[position >>
> 8]);
>
> nbytes starts as the max number of bytes wanted and then is calculated as
> the
> minimum of the current number wanted and the bytes remaining in each pool.
> Hence it's the lowest delay pool, not the last one.
>
> David.
Received on Thu Nov 12 1998 - 01:55:33 MST