Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
On 01/22/2011 01:27 AM, Insan Praja SW wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph spike. It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. symux reports measurements to rrdtool, and rrdtool tries to detect rollovers. Without looking at any source I would guess that the new pfctl -f zeros the queue stat counts, which would lead to rrdtool making a false overflow detection. This should affect both 32/64 bit archs. Also note that this would be hard to fix in symon/symux; pfctl is right to reset the stats, and rrdtools overflow handling is nice for when you have overflows. I don't see a simple way of second guessing either of them in the symon/symux source. We already contacted the maintainer, still no reply though. This is the first mail I received about this subject, or are were you talking about someone else? Cheers, Willem
Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
Hi, On Sun, 23 Jan 2011 01:54:32 +0700, Willem Dijkstra w...@xs4all.nl wrote: On 01/22/2011 01:27 AM, Insan Praja SW wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph spike. It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. symux reports measurements to rrdtool, and rrdtool tries to detect rollovers. Without looking at any source I would guess that the new pfctl -f zeros the queue stat counts, which would lead to rrdtool making a false overflow detection. This should affect both 32/64 bit archs. In my last email, all 4.8 platform makes them same behavior. Also note that this would be hard to fix in symon/symux; pfctl is right to reset the stats, and rrdtools overflow handling is nice for when you have overflows. I don't see a simple way of second guessing either of them in the symon/symux source. So the solution (right now) would be using rrdtool overflow handling. We already contacted the maintainer, still no reply though. ^^^ This is the first mail I received about this subject, or are were you talking about someone else? Sorry Will, I'am talking about someone else, with less english writing skill :D Cheers, Willem Thanks, Insan Praja -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
On Sun, 23 Jan 2011 04:20:04 +0700, Insan Praja SW insan.pr...@gmail.com wrote: Hi, On Sun, 23 Jan 2011 01:54:32 +0700, Willem Dijkstra w...@xs4all.nl wrote: On 01/22/2011 01:27 AM, Insan Praja SW wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph spike. It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. symux reports measurements to rrdtool, and rrdtool tries to detect rollovers. Without looking at any source I would guess that the new pfctl -f zeros the queue stat counts, which would lead to rrdtool making a false overflow detection. This should affect both 32/64 bit archs. In my last email, all 4.8 platform makes them same behavior. Also note that this would be hard to fix in symon/symux; pfctl is right to reset the stats, and rrdtools overflow handling is nice for when you Comparing to systat(1) at queue view, when pfctl -f /etc/pf.conf was executed, the counters went *, is it zero-ed? have overflows. I don't see a simple way of second guessing either of them in the symon/symux source. So the solution (right now) would be using rrdtool overflow handling. We already contacted the maintainer, still no reply though. ^^^ This is the first mail I received about this subject, or are were you talking about someone else? Sorry Will, I'am talking about someone else, with less english writing skill :D Cheers, Willem Thanks, Insan Praja Thanks, Insan Praja -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
Hi all, On Sun, 16 Jan 2011 18:58:12 +0700, Insan Praja SW insan.pr...@gmail.com wrote: Hi, On Fri, 14 Jan 2011 10:48:24 +0700, Chris Cappuccio ch...@nmedia.net wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph spike. It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. After taking a shot at i386 4.8-stable, there are also spikes everytime pf reloaded. We already contacted the maintainer, still no reply though. Graph spike happens every time pf is reload (pfctl -f /etc/pf.conf) in an AMD64 machines, but doesn't happen on i386 4.7-stable. I see there is a difference in symux version ( 2.79 on 4.7 and 2.82 on 4.8). Thanks, Insan Praja Thanks, Insan Praja -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
Hi, On Sat, 22 Jan 2011 07:27:46 +0700, Insan Praja SW insan.pr...@gmail.com wrote: Hi all, On Sun, 16 Jan 2011 18:58:12 +0700, Insan Praja SW insan.pr...@gmail.com wrote: Hi, On Fri, 14 Jan 2011 10:48:24 +0700, Chris Cappuccio ch...@nmedia.net wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph spike. It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. After taking a shot at i386 4.8-stable, there are also spikes everytime pf reloaded. We already contacted the maintainer, still no reply though. Graph spike happens every time pf is reload (pfctl -f /etc/pf.conf) in an AMD64 machines, but doesn't happen on i386 4.7-stable. I see there is a difference in symux version ( 2.79 on 4.7 and 2.82 on 4.8). So I decided to take a look at /usr/local/share/symon/c_smrrds.sh on both version, there are differences like mbuf and sensors addition and pfq. From what I notice that: 2.79 pfq_*.rrd) # Build pfq file create_rrd $i \ DS:sent_bytes:COUNTER:$INTERVAL:0:U \ DS:sent_packets:COUNTER:$INTERVAL:0:U \ DS:drop_bytes:COUNTER:$INTERVAL:0:U \ DS:drop_packets:COUNTER:$INTERVAL:0:U ;; 2.82 pfq_*.rrd) # Build pfq file create_rrd $i \ DS:sent_bytes:COUNTER:$INTERVAL:0:U \ DS:sent_packets:COUNTER:$INTERVAL:0:U \ DS:drop_bytes:COUNTER:$INTERVAL:0:U \ DS:drop_packets:COUNTER:$INTERVAL:0:U \ DS:bytes_in:COMPUTE:sent_bytes,1,* \ DS:bytes_out:COMPUTE:sent_bytes,1,* ;; Is it possible that these changes might be the source of queue graph spike we've seen? Thanks, Insan Praja Thanks, Insan Praja Thanks Insan Praja -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
Hi, On Fri, 14 Jan 2011 10:48:24 +0700, Chris Cappuccio ch...@nmedia.net wrote: Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph spike. It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. We already contacted the maintainer, still no reply though. Graph spike happens every time pf is reload (pfctl -f /etc/pf.conf) in an AMD64 machines, but doesn't happen on i386 4.7-stable. I see there is a difference in symux version ( 2.79 on 4.7 and 2.82 on 4.8). Thanks, Insan Praja -- Using Opera's revolutionary email client: http://www.opera.com/mail/
[OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
Hi Misc@, Has anyone encountered symux rrd graph spike on an AMD64 4.8-stable? I have a Cacti installed on an amd64 4.8-stable and i386 4.7-stable. Graph spike happens every time pf is reload (pfctl -f /etc/pf.conf) in an AMD64 machines, but doesn't happen on i386 4.7-stable. I see there is a difference in symux version ( 2.79 on 4.7 and 2.82 on 4.8). Anyone had a clue? Thanks, Insan Praja DMESG (AMD64-stable): OpenBSD 4.8-stable (GENERIC.MP) #1: Sun Dec 19 01:03:57 WIT 2010 r...@ns2.mygreenlinks.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2110259200 (2012MB) avail mem = 2040262656 (1945MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf06d0 (48 entries) bios0: vendor American Megatrends Inc. version 0604 date 07/22/2010 bios0: ASUSTeK Computer INC. P5G41T-M LX acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) UAR1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) EUSB(S4) MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz, 2934.52 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,S SE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG cpu0: 3MB 64b/line 8-way L2 cache cpu0: apic clock running at 266MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz, 2934.17 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,S SE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG cpu1: 3MB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus -1 (P0P3) acpiprt3 at acpi0: bus 2 (P0P1) acpiprt4 at acpi0: bus 1 (P0P4) acpiprt5 at acpi0: bus -1 (P0P5) acpicpu0 at acpi0 acpicpu1 at acpi0 aibs0 at acpi0 acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB cpu0: unknown Enhanced SpeedStep CPU, msr 0x06160b2506000b25 cpu0: using only highest and lowest power states cpu0: Enhanced SpeedStep 2934 MHz: speeds: 2933, 1600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel G41 Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel G41 Video rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 (irq 10) drm0 at inteldrm0 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x01: apic 2 int 21 (irq 5) azalia0: codecs: Realtek/0x0887 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: apic 2 int 16 (irq 10) pci1 at ppb0 bus 1 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 2 int 23 (irq 3) uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 2 int 19 (irq 10) uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 2 int 18 (irq 6) uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: apic 2 int 16 (irq 10) ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 2 int 23 (irq 3) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xe1 pci2 at ppb1 bus 2 rl0 at pci2 dev 0 function 0 D-Link 530TX+ rev 0x10: apic 2 int 19 (irq 10), address 00:1e:58:3e:70:45 rlphy0 at rl0 phy 0: RTL internal PHY rl1 at pci2 dev 1 function 0 D-Link 530TX+ rev 0x10: apic 2 int 16 (irq 10), address 00:11:95:63:48:63 rlphy1 at rl1 phy 0: RTL internal PHY pcib0 at pci0 dev 31 function 0 Intel 82801GB LPC rev 0x01 pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) pciide1 at pci0 dev 31 function 2 Intel 82801GB SATA rev 0x01: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide1: using apic 2 int 22 (irq 11) for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: WDC WD3200AAJS-08L7A0 wd0: 16-sector PIO, LBA48, 305245MB, 625142448 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00
Re: [OOT] AMD64 4.8 -stable Symux graph spike everytime pf(4) reload
Seems obvious that symux isn't detecting rollover properly for whatever variable you are seeing a graph spike. It should be fairly easy for them to fix if you report it. The fact that it affects 64bit and not 32bit counters is a damn good clue. Graph spike happens every time pf is reload (pfctl -f /etc/pf.conf) in an AMD64 machines, but doesn't happen on i386 4.7-stable. I see there is a difference in symux version ( 2.79 on 4.7 and 2.82 on 4.8). -- Let food be thy medicine and medicine be thy food - Hippocrates
