Thanks Maryam, I uploaded a contribution with your suggestions on Friday, and I don't expect any resistance when TST WG meets next week.
regards, Al From: Tahhan, Maryam [mailto:maryam.tah...@intel.com] Sent: Thursday, October 26, 2017 1:05 PM To: MORTON, ALFRED C (AL) Cc: Aaron Smith; opnfv-tech-discuss@lists.opnfv.org; Mcmahon, Tony B; Power, Damien Subject: RE: [barometer] TST008 missing info from collectd Hi Al Thanks for going through this again. More comments inline below preceded by [MT] BR Maryam From: MORTON, ALFRED C (AL) [mailto:acmor...@att.com] Sent: Wednesday, October 25, 2017 2:35 PM To: Tahhan, Maryam <maryam.tah...@intel.com<mailto:maryam.tah...@intel.com>> Cc: Aaron Smith <aasm...@redhat.com<mailto:aasm...@redhat.com>>; opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; Mcmahon, Tony B <tony.b.mcma...@intel.com<mailto:tony.b.mcma...@intel.com>>; Power, Damien <damien.po...@intel.com<mailto:damien.po...@intel.com>> Subject: RE: [barometer] TST008 missing info from collectd Hi Maryam, thanks for taking another look at TST008 and collectd support! please see replies below, Al From: Tahhan, Maryam [mailto:maryam.tah...@intel.com] Sent: Wednesday, October 25, 2017 7:46 AM To: MORTON, ALFRED C (AL) Cc: Aaron Smith; opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>; Tahhan, Maryam; Mcmahon, Tony B; Power, Damien Subject: [barometer] TST008 missing info from collectd Hi Al I did an analysis based on your updates to TST008 to see what's still a gap in collectd in terms of alignment with TST 008. There's a couple of open questions below. CPU Plugin: *Tick Interval* are missing from the CPU readings --> we can add this to metadata. But an open question, as I dug into this a little more today: "The tick interval is controlled by a system parameter, "HZ", whose default value shall be 100 for measurements complying with the present document." Looking at: http://man7.org/linux/man-pages/man7/time.7.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__man7.org_linux_man-2Dpages_man7_time.7.html&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ejI6nq05jteIfofHOKihPTKWloAr2MTpM7biphbcPN0&s=kBFsPemx3t34QrvRgTIXLvAFCAyaN__JKYLkVMYvqYY&e=> "The value of HZ varies across kernel versions and hardware platforms. On i386 the situation is as follows: on kernels up to and including 2.4.x, HZ was 100, giving a jiffy value of 0.01 seconds; starting with 2.6.0, HZ was raised to 1000, giving a jiffy of 0.001 seconds. Since kernel 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) or 1000, yielding a jiffies value of, respectively, 0.01, 0.004, or 0.001 seconds. Since kernel 2.6.20, a further frequency is available: 300, a number that divides evenly for the common video frame rates (PAL, 25 HZ; NTSC, 30 HZ)". Q. So does it make sense to report both jiffies and HZ? Or do we scale something back to the 100HZ value in the plugin? [ACM] Either the Tick Interval (same as Jiffy) or the configured value of HZ would be enough (as they have a reciprocal relationship), but I think we should include the Tick Interval for sure. The units of Hz are clear for HZ, and that's an advantage when both are reported. I don't think collectd should scale the measurements; it should simply report what Jiffy, HZ was used. I specified 100 Hz as it seemed a reasonable default, but if implementations have moved on (to 250Hz or beyond), I'd be happy to update the Spec. It will make deployment easier if the TST008 default is commonly used. (we are still in maintenance mode, any change is possible!) [MT] that would be great to update. And I can make sure then both are sent from collectd. *The measurement interval*. Q. the timestamp for a metric and the interval at which to expect a new value is also sent with the collectd metric is that enough or do we need to be more explicit? [ACM] Yes. Both the Timestamp and measurement interval are required, so there is only a question about the timestamp format. Is it both time and date? [MT] yes it includes both date and time. *Processor usage results shall be reported as time in seconds* --> at the moment this is in nanoseconds... but we can add an option to the cpu plugin. [ACM] If your experience tells you that usage is more commonly reported in nanoseconds, I'd be happy to change TST008 to comply. I see that IFA027 uses Utilization in percent, exclusively. [MT] usage I've typically seen on most systems is in nano-seconds... it would be great to update. Interface/OVS/port plugins: *Interface Speed* in bits per second (with the option of a prefix multiplier) --> can be added to metadata or sent as a metric in its own right *Interface Status* --> can be added to metadata or sent as a metric in its own right [ACM] I think that the trade-off is between the clear association of metadata with a measured value, and the fixed reporting format always found in metrics. The parameters above are straightforward to report, so I think Metadata will be fine. [MT] perfect thanks Al Thanks Again! Let me know on HZ default and nanosec for usage. Anyone on CC who read this far may chime-in, too. Al BR Maryam
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
