lkml.org 
[lkml]   [2008]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: loaded router, excessive getnstimeofday in oprofile
    On Fri, Aug 29, 2008 at 11:21:26AM -0400, Joe Malicki (jmalicki@metacarta.com) wrote:
    > > But didn't you really want a "end2end" time stamp in this case,
    > > as in really at the end of all kernel/hardware queues on your side.
    >
    > No.
    >
    > That adds variance, and packets aren't comparable because they may
    > suffer different kernel/hardware delays.
    >
    > The goal is to approximate original sendtime when the application-level
    > timestamps are unreliable. The more queueing delays that can be
    > taken out of the timestamp, the better.

    Just a note from that one who really developed real-time audio and
    video processing engines: _no_one_ really relies to the timestamps
    attached to the received packet. By no one I really mean NO ONE. It is
    ust wrong, broken and stupid. There are so many queues in the data
    path, that it just can not be reliable by definition.

    Instead sending path incapsulates packet sequence number into appropriate
    packet header (like, and the most cases the only, RTP header), and
    receiving path just multiplies this sequence number by the compression
    rate and size of the packet. This numbers differ from design to design,
    but overall approach is the same: no one really depends on the hardware
    timestamp attached on the receiver, only sender's data is reliable.
    If someone depends on it, it is broken and just waits for the
    appropriate attack vector to inect broken data into the dataflow (such
    users do not use tcp, since it "introduces unneded delays" or similar
    marketing and compeltely untested things).

    So this overall discussion of the timestamp option is meaningless: we
    just bloody can not change it as is, since so many applications really
    depend on it (even if they should not).

    We can force lower resolution in terms of xtime or similar counter,
    which will be default timestamp in case of some syscall (turned off by
    default), but since so far no one sent a patch, this looks very subtle.

    --
    Evgeniy Polyakov


    \
     
     \ /
      Last update: 2008-08-29 22:47    [W:2.385 / U:1.932 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site