First of all, thank you for everybody providing me valuable information.
The above was right speculation on my timer problem. I got to know
what was wrong by checking the accuracy of the packet injection.
In my experiment, I sent a packet per second from a remote machine.
However, since the clock pacing of two different machines (the remote
packet-sending machine and the local machine) is different,
the packet injection at the local machine was not accurately
one-packet-per-second rate. Instead, in my previous experiment,
the remote machine's clock was slightly slower than the local machine's clock.
(The pacing difference is 10msec/600seconds.)
When my delay module set up a 5-ticks timer, the actual sleep time was
4 full tick time + 1 partial tick at the time of timer-setup. If a packet
arrives at the very beginning of the first tick, this packet will be
delayed for 5 full ticks (= nearly 50msec). However if a packet arrives
at the very end of the first tick, this packet will only be delayed
for about 4 full ticks. (= nearly 40msec). When time drift crosses the
boundary of 1 tick (in my experiment, after 600 seconds), it will become
the same as the former case and the same procedure is repeated.
During 600 seconds, the clock pacing difference has gradully created the time
drift of packet injection and thus induced the odd delay trend.
This was confirmed when I changed the sending machines. If the remote machine's
clock is faster than the local machine. The drift direction is backward.
If two machines' clocks are nearly synchronized, I couldn't see the
delay drift at all.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/