Date: Fri, 13 May 2011 14:55:25 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Bartosz Woronicz <bartosz.woronicz@korbank.pl> Cc: freebsd-stable@freebsd.org Subject: Re: Unstable ARP responses times Message-ID: <20110513195524.GC7043@dan.emsphone.com> In-Reply-To: <4DCD2881.4020402@korbank.pl> References: <4DCD2881.4020402@korbank.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (May 13), Bartosz Woronicz said: > Since I moved from 7.3-stable to 8.2-stable I go strange long responses > of arp, with arping. > I.e. > root@Korbotron82|pts/3|13:35:35|/home/mastier # arping -i vlan92 > 79.110.194.140 > ARPING 79.110.194.140 > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=0 time=1.579 msec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=1 time=653.326 msec > 60 bytes from 00:15:17:a2:ea:38 (79.110.194.140): index=2 time=7.153 usec arping has a usleep(1) call in its read loop, which can cause delays like this if there are other processes running and the scheduler decides to run another process. Try removing the usleep(1) on line 916 of arping.c and see if that helps. The best solution would be to use the kernel-provided timestamps from the pcap header, rather than calling gettimeofday() in userland. If you run "tcpdump arp", you should be able to see the packet timestamps as the kernel sees them. -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110513195524.GC7043>