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