Hello, Thankyou for your clarification and feedback.
Your description of the accumulated milliseconds (or potentially microseconds to allow for things getting a lot faster) is exactly what I had in mind. The delta of this figure divided by the delta iops, should give an approximate measure of the load the io subsystem is under. Regards, Ian West. -----Original Message----- From: Keiichi SHIMA [mailto:[email protected]] Sent: Saturday, 20 September 2014 18:03 To: [email protected] Cc: SHIMA Keiichi; ASAI Hirochika; Jürgen Schönwälder; SEKIYA Yuji; Tina Tsou; Cathy Zhou; ESAKI Hiroshi; Ian West; Michael MacFaden Subject: Re: [OPSAWG] Comments from niw.com.au operator on draft on Hello, > It would be really nice to have IO service times as well, ie something like > accumulated milliseconds of wait time for io servicing, > this might be a harder to instrument. A counter64 of cumulative ms (us?) > awaiting delivery is a really handy read/write latency metric. Let me clarify the above sentence. Is the service time, you are talking about, the time between an I/O request arrives to the storage subsystem (in a hypervisor) and the time its response is returned to the calling VM? And you want to add an entry to keep an accumulated value of those I/O request delay? > The vmStorageEntry statistics while having read operation and write operation > counters don't allow for measuring the volume of read and write traffic. It > would be useful to include 64 bit counters for read and write octets. I don’t have any particular opinion on this topic. If people in this WG support adding the above entries, then maybe it is possible to add them. Regards, --- Keiichi SHIMA (島 慶一) Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> WIDE project <[email protected]> 2014/09/18 2:45、Michael MacFaden <[email protected]> のメール： > Hi authors, > > Regarding: https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ > > Ian as allowed me to forward you his comments on the draft. > > Cheers, > Mike MacFaden > > > From: Ian West <[email protected]> > Subject: RE: Mail regarding draft-ietf-opsawg-vmm-mib > Date: September 16, 2014 at 3:18:08 AM PDT > To: 'Michael MacFaden' <[email protected]> > > > Overall I think it looks great. > > It would be really nice to have IO service times as well, ie something like > accumulated milliseconds of wait time for io servicing, > this might be a harder to instrument. A counter64 of cumulative ms (us?) > awaiting delivery is a really handy read/write latency metric. > > The cputime and memory figures look good. > > I am thinking there would be a storage object for the swap space which would > give most of the paging stats if actual byte counts were added ? > > Links back to the ifindex should also tie into vswitch I think ? My current > walks of vmware are nesting vswitch ports nicely so that’s > looking good. Network stats seem good already, its primarily the per vhost > cpu usage and io stats that are weak from a real time > perspective, this MIB looks like it should cover it really well. > > Is this intended to be a vsphere (central management) resource, or a per > physical host (or both, which would be great) ? > > If you were to query this from a vsphere central management host, I am > thinking you might want to add to the vmtable an identifier > for the physical host that the vm is currently running on. This would make > the table useful either standalone or across a bunch of > physical hosts. > > Ill think on it some more, this seems like a great step forward over whats > there now already in VMware’s implementation. > > > The vmStorageEntry statistics while having read operation and write operation > counters don't allow for measuring the volume of read and write traffic. It > would be useful to include 64 bit counters for read and write octets. > > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
