[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dhcp-hackers
Subject:    Re: Adaptive lease time  patch
From:       "David W. Hankins" <David_Hankins () isc ! org>
Date:       2005-09-13 20:16:49
Message-ID: 20050913201649.GS54414 () isc ! org
[Download RAW message or body]

On Tue, Sep 13, 2005 at 10:51:20AM +0200, Christof Chen wrote:
> Can you give me an example?  TIME/time_t  is signed  (long int, at least on 

Yes, you're right, I was for some reason thinking in unsigned space.

> > So, the result of this statement shouldn't increase the lease time.
> I do not see how this would be possible - the
> 
>               if (lease_time > min_lease_time) {
>                        lease_time = min_lease_time; 
> 	      }
> 
> part can only decrease the lease time - down to min_lease_time.

Ah, I misread.  I didn't realize you were setting min lease time,
but rather thought it was adjusting lease time directly.

That's worse.

lease-time comes to us as 5 for whatever reason (bogus arbitrary number).

min-lease-time is 10.

The lease expires in 20.

min-lease-time = 20;

lease-time exits as 5, and gets assigned to 20.

In this case tho it should exit as the configured min-lease-time, 10.

> I'd prefer a percentage too, but looking at the 0.8125 lease-time calculation, 
> the current codebase avoids arbitrary divisions.
> Do you think both a percentage and a fixed limit would be useful?

I don't think both is useful - either one or the other.

I suspect the fixed limit will be both easier to implement and
equivalent (X% of a pool of Y leases is always Z), so I would
probably lean in that direction.


Also, it suddenly strikes me to consider failover.

The question is wether the count of free or backup leases should be
summed or if each server should only consider its own pool.

But that's not necessarily a requirement - this is easily allowed to
be a failover incompatible option.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

[prev in list] [next in list] [prev in thread] [next in thread]