How to send out a packet urgently? - Mandriva

This is a discussion on How to send out a packet urgently? - Mandriva ; Is there any way of telling the system to send out a packet urgently? ntp timestamps a packet, delivers it to the network subsystem. That packet is then sent out to the other computer, and timestamped there at receipt and ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: How to send out a packet urgently?

  1. How to send out a packet urgently?

    Is there any way of telling the system to send out a packet urgently?
    ntp timestamps a packet, delivers it to the network subsystem. That packet
    is then sent out to the other computer, and timestamped there at receipt
    and transmission. The problem is that Linux seems to take its time about
    actually sending out the packet. I have looked at the timestamp on the
    packet, and compared it to the time reported by tcpdump for the packet, and
    they differ by from 10s of microseconds to many many milliseconds. While
    the first is fine, the second is attrocious. Note that I do a pre ping of
    the source so that there should not be an arp cache problem.

    Is there some way of labeling a packet so that it is sent out urgently by
    the networking subsystem?



  2. Re: How to send out a packet urgently?

    In news:rd33j.10868$HH2.1077@edtnps82,
    Bill Unruh wrote:

    > Is there some way of labeling a packet so that it is sent out
    > urgently by the networking subsystem?


    Assign a higher priority: "man nice" for more information.

  3. Re: How to send out a packet urgently?

    On Tue, 27 Nov 2007 20:09:43 -0500, Bill Unruh wrote:

    > Is there some way of labeling a packet so that it is sent out urgently by
    > the networking subsystem?


    Not that I'm aware of, however if you are running the ntpd daemon, it
    souldn't matter. If you read the description, from the man page of
    ntpdate, it uses multiple samples. Getting it out, and back fast,
    is much less important, than consistent processing, of all packets.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  4. Re: How to send out a packet urgently?

    on Wednesday 28 November 2007 12:31
    in the Usenet newsgroup alt.os.linux.mandriva
    Gretch wrote:

    > In news:rd33j.10868$HH2.1077@edtnps82,
    > Bill Unruh wrote:
    >
    >> Is there some way of labeling a packet so that it is sent out
    >> urgently by the networking subsystem?

    >
    > Assign a higher priority: "man nice" for more information.


    There are many steps in the chain. It is also possible to
    "jump the queue" at the network level, but exactly how
    to do it is beyond my knowledge.


    --
    sig goes here...
    Peter D.

  5. Re: How to send out a packet urgently?

    "Gretch" writes:

    >In news:rd33j.10868$HH2.1077@edtnps82,
    >Bill Unruh wrote:


    >> Is there some way of labeling a packet so that it is sent out
    >> urgently by the networking subsystem?


    >Assign a higher priority: "man nice" for more information.


    ?? That is a priority on the program. Not on the packet it creates. The
    program is clearly running when it creates the packet, and hands it off to
    the networking routines. It is the subsequent handling of that packet by
    the kernel that is at issue.

  6. Re: How to send out a packet urgently?

    "David W. Hodgins" writes:

    >On Tue, 27 Nov 2007 20:09:43 -0500, Bill Unruh wrote:


    >> Is there some way of labeling a packet so that it is sent out urgently by
    >> the networking subsystem?


    >Not that I'm aware of, however if you are running the ntpd daemon, it
    >souldn't matter. If you read the description, from the man page of
    >ntpdate, it uses multiple samples. Getting it out, and back fast,
    >is much less important, than consistent processing, of all packets.


    The problem is that the processing is not consistant. Thus, on one packet,
    you will get the internal timestamp, then the packet waits for 5ms, and is
    finally sent out onto the net, while the next packet will be timestamped,
    and be sent out 80us later(as measured by comparing tcpdump time for the
    packet with the timestamp on the packet). The delay in being sent out is interpreted by
    ntp as a clock problem-- the local clock being early-- since mean time
    between outgoing timestamp and receipt is earlier than the actual time the
    packet was sent out. At times this delay can be almost a second, which
    makes accurate timing absurd.



    >Regards, Dave Hodgins


    >--
    >Change nomail.afraid.org to ody.ca to reply by email.
    >(nomail.afraid.org has been set up specifically for
    >use in usenet. Feel free to use it yourself.)


  7. Re: How to send out a packet urgently?

    Unruh writes:

    > "David W. Hodgins" writes:
    >
    >>On Tue, 27 Nov 2007 20:09:43 -0500, Bill Unruh wrote:

    >
    >>> Is there some way of labeling a packet so that it is sent out urgently by
    >>> the networking subsystem?

    >
    >>Not that I'm aware of, however if you are running the ntpd daemon, it
    >>souldn't matter. If you read the description, from the man page of
    >>ntpdate, it uses multiple samples. Getting it out, and back fast,
    >>is much less important, than consistent processing, of all packets.

    >
    > The problem is that the processing is not consistant. Thus, on one packet,
    > you will get the internal timestamp, then the packet waits for 5ms, and is
    > finally sent out onto the net, while the next packet will be timestamped,
    > and be sent out 80us later(as measured by comparing tcpdump time for the
    > packet with the timestamp on the packet). The delay in being sent out is interpreted by
    > ntp as a clock problem-- the local clock being early-- since mean time
    > between outgoing timestamp and receipt is earlier than the actual time the
    > packet was sent out. At times this delay can be almost a second, which
    > makes accurate timing absurd.


    What definition of accurate are you using?
    Did you observe a problem?

    The combination of the system clock, and the small adjustments
    that ntpd does should give you a very accurate time of day.

  8. Re: How to send out a packet urgently?

    Unruh writes:

    > "David W. Hodgins" writes:
    >
    >>On Tue, 27 Nov 2007 20:09:43 -0500, Bill Unruh wrote:

    >
    >>> Is there some way of labeling a packet so that it is sent out urgently by
    >>> the networking subsystem?

    >
    >>Not that I'm aware of, however if you are running the ntpd daemon, it
    >>souldn't matter. If you read the description, from the man page of
    >>ntpdate, it uses multiple samples. Getting it out, and back fast,
    >>is much less important, than consistent processing, of all packets.

    >
    > The problem is that the processing is not consistant. Thus, on one packet,
    > you will get the internal timestamp, then the packet waits for 5ms, and is
    > finally sent out onto the net, while the next packet will be timestamped,
    > and be sent out 80us later(as measured by comparing tcpdump time for the
    > packet with the timestamp on the packet). The delay in being sent out is interpreted by
    > ntp as a clock problem-- the local clock being early-- since mean time
    > between outgoing timestamp and receipt is earlier than the actual time the
    > packet was sent out. At times this delay can be almost a second, which
    > makes accurate timing absurd.


    You can look up MSG_OOB but I don't know that any ntp servers
    are going to support it.

  9. Re: How to send out a packet urgently?

    Bill Unruh wrote:
    > Is there any way of telling the system to send out a packet
    > urgently? ntp timestamps a packet, delivers it to the network
    > subsystem. That packet is then sent out to the other computer, and
    > timestamped there at receipt and transmission. The problem is that
    > Linux seems to take its time about actually sending out the
    > packet. I have looked at the timestamp on the packet, and compared
    > it to the time reported by tcpdump for the packet, and they differ
    > by from 10s of microseconds to many many milliseconds. While the
    > first is fine, the second is attrocious. Note that I do a pre ping
    > of the source so that there should not be an arp cache problem.


    I keep forgetting - on linux is tcpdump getting the timestamp from the
    kernel, or calling gettimeofday() itself? If the latter, then
    scheduling delays in running tcpdump itself could be giving a false
    indication of delay in packet transmission. If you have more than one
    core in the system it might not be a bad idea to use taskset (iirc) to
    make sure that the ntpd and the tcpdump process run on different
    cores.

    I'm reasonably certain that an outbound packet will be sniffed before
    the transmit completion interrupt takes place (because otherwise there
    is a really nasty ordering problem for tcpdump), but it might not be a
    bad idea to triple check that - with interrupt avoidance schemes in
    various NICs these days, it can be quite a while from when the packet
    is actually transmitted, and when the transmit completion happens.
    Disabling the interrupt avoidance might be an interesting experiment.
    Depending on the type of NIC that would be either via ethtool or
    module parameters.

    Just how busy is the NIC out which the NTP traffic is being sent? How
    far across the network is the packet going - just local LAN, or out
    across the big bad internet?


    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

+ Reply to Thread