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.

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.)

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.

"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.

"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.)

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.

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.

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...