Date: Mon, 14 Jan 2002 11:23:01 -0500 From: "James E. Housley" <jeh@FreeBSD.org> To: Bosko Milekic <bmilekic@technokratis.com> Cc: Terry Lambert <tlambert2@mindspring.com>, Thomas Hurst <tom.hurst@clara.net>, arch@FreeBSD.org Subject: Re: 64 bit counters again Message-ID: <3C4305E5.65BB32A6@FreeBSD.org> References: <Pine.BSF.4.41.0201132057560.62182-100000@prg.traveller.cz> <3C41F3FD.4ECC8CD@mindspring.com> <20020113231459.GA30349@voi.aagh.net> <3C42390A.F9E9F533@mindspring.com> <3C42E899.CB21BD0A@FreeBSD.org> <20020114105859.A24635@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic wrote: > > On Mon, Jan 14, 2002 at 09:18:01AM -0500, James E. Housley wrote: > > Terry Lambert wrote: > > > > > > My personal opinion is that the utility of the counters is > > > mostly in the examination of small deltas, or delta measurement > > > over intervals (c.v. the recent "sar" discussion); is there a > > > particular reason that making them more expensive to get 64 > > > bits of accuracy is needed to fulfill? > > > > > > > Right now I am trying to do network usage on the overflows the 32 bit > > counters in 60 120 seconds. That means the netstat values are useless, > > mrtg and other programs that poll for results every 5 minutes or so are > > useless. If I want to get good data I have to get the counts every 10 > > seconds or so to get reasonable results. > > You know, if you have a counter overflowing in 60 to 120 seconds, > then perhaps what it's counting should not be counted to begin with. I am just trying to count bytes in and out, too keep track of usage and head off a large overage and a larger bill then necessary. Counting packets is worthless. But just do the math. With a GigE NIC, at what data rate do you start overflowing the counters too quickly. I suppose there is another possibility, that the ti GigE driver is counting the data multiple times. But I don't think so, because at 200Mbits/sec the counter should overflow in 172 seconds. And this machine is easily doing this most of the day. > > I stumbled upon several statistics issues while writing mb_alloc and > I tried to the best of my abilities to group the manipulation of the > counters under some common already existing lock. In some odd cases, > this was impossible. But I refused to introduce a bus-locked instruction > or, worse, a whole new lock just to deal with the statistics. It's > too much overhead for mere statistics and, in the latter case, it's > even very bug-prone. To be honest, after actually examining more > closely what the counters collected statistics on, I realized that they > were pretty much totally redundant and am considering removing those > few problematic ones some time in the future. > That all sounds reasonable. And it make sense to move the counters under existing locks. But, 32-bit machines are going to be around for awhile longer and fast network connections are going to get faster and more common. Maybe the counters should be completely removed from the 32-bit arch.s since they give such misleading results and only have them on the 64-bit machines. That way no one will be confused by the data. Of course I am not completely serious about removing the counters, but it is not hard to make them very wrong. Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ ----------------------------------------------------------------- jeh@FreeBSD.org http://www.FreeBSD.org The Power to Serve jim@TheHousleys.Net http://www.TheHousleys.net jhousley@SimTel.Net http://www.SimTel.Net --------------------------------------------------------------------- PC hardware is the ductape of the computer inustry... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C4305E5.65BB32A6>