problem

Tom Carly tcarly at esat.kuleuven.ac.be
Sun Mar 30 19:22:18 EST 2003


Hi,

I manipulated DRIVER_TASKS_PER_ITER and for the smallest value (1) it gave the 
best results, concerning variation in delays. But the high peaks still remain 
the same. This does not have anything to do with my own elements, because 
when I just use the classical elements the same phenomenon is observed. But 
hey, we're still looking further :-)

Tom



Op woensdag 26 maart 2003 23:19, schreef u:
> Hi Tom,
>
> > I have made some kind of emulator in Click that can delay incoming
> > packets. It works fine, except for one thing. I must say that I work in
> > userlevel because files have to be loaded and I needed several standard C
> > functions that didn't work in kernel mode. When I monitor how much the
> > packets are delayed, for most of the packets this delay is almost perfect
> > (a few micro seconds). But periodically, for example every second there
> > are one or two packets which get 1 till 2 milli seconds too much delay. I
> > suppose that it is because the processor gets other interrupts from other
> > processes. I have already set Click as highest priority and all other
> > processes as lowest priority but I see no difference. Is there some way
> > to decrease this influence or do I have to be satisfied with these
> > results?
>
> Hmm. On the one hand you may have to deal with this. But have you tried
> manipulating the parameters in lib/routerthread.cc? If you raised
> DRIVER_TASKS_PER_ITER and/or DRIVER_ITER_OS, you would go for longer times
> without giving up control. Are you sure there isn't some periodic process
> within the Click script itself?
>
> Eddie





More information about the click mailing list