Hello Ian, > 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.
Thank you for the clarification. I got better understanding of your proposal. I tend to agree that the above usage may be useful. I again don’t have any strong support/objection for adding the above new entry to the VMM-MIB. I’d like to hear if other authors and people in this WG support this. Regards, --- Keiichi SHIMA (島 慶一) WIDE project <[email protected]> Research Laboratory, IIJ Innovation Institute, Inc <[email protected]> 2014/09/21 11:27、Ian West <[email protected]> のメール： > 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 > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
