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?

"Gretch" <gretchen@invalid.corn> writes: >In news:rd33j.10868$HH2.1077@edtnps82, >Bill Unruh <unruh@physics.ubc.ca> 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" <dwhodgins@nomail.afraid.org> writes: >On Tue, 27 Nov 2007 20:09:43 -0500, Bill Unruh <unruh@physics.ubc.ca> 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.)

Bill Unruh <unruh@physics.ubc.ca> 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...