Date: Mon, 6 Dec 2004 18:13:35 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Gerald Heinig <gheinig@syskonnect.de> Cc: freebsd-net@freebsd.org Subject: Re: ping counter overflow Message-ID: <20041206161335.GA91583@orion.daedalusnetworks.priv> In-Reply-To: <41B46D6D.7080702@syskonnect.de> References: <41B46D6D.7080702@syskonnect.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2004-12-06 15:32, Gerald Heinig <gheinig@syskonnect.de> wrote: > Hi all, > > I've run into a possible bug in ping(8) while investigating a strange > duplicate packet effect in our driver. > The effect shows up on other drivers and I believe it's due to a counter > overflow in ping. > Basically, leave ping -f on a gigabit link for a few days (for medium to > large values of "a few", ie. at least 3 or 4). Stop the ping and get > lots of duplicate packets. > I changed the 5 counter variables (nmissedmax, npackets, nreceived, > nrepeats, ntransmitted) to short (from long) to reduce the time taken to > overflow and managed to get the effect very easily - it takes about 3 > seconds on a gigabit link. > Changing these variables to their unsigned counterparts solved the problem. > My question: shouldn't these counters be unsigned? (ie. unsigned long, > instead of long) They can probably be switched to uint64_t too. I'm not sure how much time this will buy us though on links with so very high speeds. A quick calculation with a link that can push 8 Mpps indicates it will take a few dozen thousands of years to overflow a 64-bit counter, unless my Python-foo has failed me: >>> (2**64) / (365*24*3600*8000000) 73117L
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041206161335.GA91583>