> -----Original Message----- > From: Martin Knoblauch [mailto:[EMAIL PROTECTED] > Sent: September 10, 2008 6:55 AM > To: Witham, Timothy D; Escobio, Roger [CMB-IT]; > [email protected] > Subject: Re: [Ganglia-general] Anyone experience petabyte > peaks in network metric in ganglia 3.x.y ? > > ----- Original Message ---- > > > From: "Witham, Timothy D" <[EMAIL PROTECTED]> > > To: "Escobio, Roger " <[EMAIL PROTECTED]>; > "[email protected]" > <[email protected]> > > Sent: Tuesday, September 9, 2008 9:42:34 PM > > Subject: Re: [Ganglia-general] Anyone experience petabyte > peaks in network metric in ganglia 3.x.y ? > > > > >I am testing ganglia in a cluster of linux but we are getting this > > >confusing peaks in the bytes/s and in the packets/s (image > attached) > > > > I have been able to minimize this significantly by using > code from svn trunk and > > building with > > > > make CPPFLAGS=-DREMOVE_BOGUS_SPIKES > > > > IMHO, that should be the default. > > > Hi Tim, > > the problem is that with NICs faster than 1000 Mbit, the > naturally occuring wrap-arounds will come too frequently > (especially for the byte counters) and will trigger the > remove mechanism and really mess up the data. The better > solution would be to bring the networking counters in the > Linux kernel to 64-bit (they are 32-bit right now). Then we > would not have to care about natural wrap-around for a few > years. I once proposed this change, but it was not greeted > with much enthusiasm :-( > > Therefore I #ifdef-ed my check. Especailly as the effect > seems to be really a very NIC specific bug. > > Escobio -> what NICs are in the systems in question (all the > same?). As I undertand, you are using some 2.6.9 kernel? > You right, we have been seeing this random peaks in HP servers with:
Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet Broadcom Corporation NetXtreme II BCM5706 Gigabit Ethernet Running 2.6.9 (redhat kernel :-) ) Kernel 2.4.9 do not seeing affect, right? How good is to have a maxvalue for bytes/s in the definition of the metrics? So if the counter's diff give more than that just discard that read I know that that will not solve the packets/s peak but it could be a safe check before add the values to stat I created a patch again linux/metrics.c (3.1.1 version) to add the counterdiff function found in *bsd/metrics.c Are you interested in it? Just let me know and I'll send it to the list Thanks roger ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general
