[GNUnet-developers] Re: 0.4.6 before 0.4.9?

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 27 August 2002 01:38 am, you wrote:
> Besides, I noticed oscillative behaviour with the bandwidth limiter
> now. It seems that its very easy for the current mechanism to end
> up in an oscillative behaviour, that is, at one time all packets
> are sent, because load is 0, and next time no packets are sent,
> because load is large. Priorities do not affect that because
> blasting during the 'no load' phase can bring the system to
> 'overload' if there is not much room between them.
>
> This atleast is something I'll have to do something about.

Well, this gets me towards a piece of code that I would have liked to see a 
while a go but never got to myself. Maybe someone else wants to pick it up, 
so here it is. 
The current implementation of cron (src/util/cron.c) only works in intervals
of 1s. Also, the thread wakes up every second to check the queue instead of 
sleeping exactly the time until the next job must be run. This is because a 
new job may be scheduled while the thread is sleeping -- we would need a
mechanism to wake up the thread 'early' to indicate that the head of the queue 
has changed.
What I would like to see is a cron where I can specify cron-jobs in much 
shorter time-intervals, like milliseconds (even if the "real" 
timer-resolution is just 10th of milliseconds). This would allow quite a bit 
more randomness, better local load balancing (not every second one big blast 
and then nothing for a second) and at the end better response times for the 
overall system. 

This would be my approach to solve one of the problems with load peeks...

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9a6VT9tNtMeXQLkIRAow3AJwOO6tkPEi+etYPM1nYJlk8Buk8CACfRFkT
tl61qJJHqgCJYqiRNZj2EOw=
=ICYQ
-----END PGP SIGNATURE-----