[lkml]   [2003]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kernel timer accuracy
    On Tue, Apr 29, 2003 at 06:43:51PM +0100, Andy Whitcroft wrote:
    > My expectation of the error would be 'random' but it would depend on two
    > things. Firstly, the accuracy of the clock used to measure the time and
    > secondly, the actual source of the packets, ie. the absolute accuracy of
    > the packet injection. We may be seeing the difference between the two
    > clocks on the two machines in this combination.

    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.

    - Jay
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:35    [W:0.044 / U:18.256 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site