From sacadmin Mon Oct 15 13:56:40 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9FKueTq014832; Mon, 15 Oct 2007 13:56:40 -0700 (PDT) Received: (from dp@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l9FKuesB014828; Mon, 15 Oct 2007 13:56:40 -0700 (PDT) Date: Mon, 15 Oct 2007 13:56:40 -0700 (PDT) From: Dan Price Message-Id: <200710152056.l9FKuesB014828@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: ptime(1) Improvements [PSARC/2007/598 FastTrack timeout 10/22/2007] Status: RO Content-Length: 557 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ptime(1) Improvements 1.2. Name of Document Author/Supplier: Author: Chad Mynhier 1.3 Date of This Document: 15 October, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From dp@eng.sun.com Mon Oct 15 17:52:55 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9G0qtKc020222 for ; Mon, 15 Oct 2007 17:52:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9G0nY6D003365 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 15 Oct 2007 17:49:34 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPZ00307BMLRT00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 15 Oct 2007 17:49:33 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPZ00AWABMHO2D0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 15 Oct 2007 17:49:32 -0700 (PDT) Received: from snowdog (snowdog.SFBay.Sun.COM [129.146.228.213]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9G0nS9Q166262; Mon, 15 Oct 2007 17:49:28 -0700 (PDT) Date: Mon, 15 Oct 2007 17:51:43 -0700 From: Dan Price Subject: PSARC/2007/598: ptime(1) Improvements To: psarc-ext@sun.com Cc: Chad Mynhier Message-id: <20071016005139.GA7807@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 3830 [resending: it does not seem to have reached the case log the first time] I am very pleased to sponsor the following case for Chad Mynhier. This case enhances the ptime(1) utility to provide greater precision and adds useful features. The timer is set for 10/22/2007. Note that this is an open case submitted by a community member; please remember to CC Chad on all correspondence. Thanks, -dp ------- ------- ------- ------- ------- ------- ------- ------- ------- ptime(1) Improvements Chad Mynhier SUMMARY This fast-track enhances the ptime command to address two existing RFEs[1,2] requesting higher resolution for reporting (microseconds or nanoseconds), the option to see the full complement of microstate statistics, and the ability to see statistics for a currently running process. The new options are committed interfaces; this case seeks minor release binding. INTERFACE TABLE Interface Stability Binding ---------------------------------------------------------------- Output Uncommitted Minor -m option Committed Minor -p option Committed Minor ---------------------------------------------------------------- DETAILS Overview Currently, the ptime command reports three statistics for a process, real (i.e., wall clock) time, user time and system time, where these statistics are presented at a millisecond resolution. In addition, ptime can only report these statistics for a process started as a child of the command. It does not provide the ability to look at these statistics for an existing process. We plan to address these issues as follows: 1. We will change the default resolution for the statistics reported by ptime to nanoseconds instead of milliseconds. (Note that this may break scripts that match any number of digits to the right of the decimal point but assume that the resolution is milliseconds. But note also that the man page states that the human-readable output is unstable.) 2. We will add a -m option that will generate a report containing the full set of microstate statistics. 3. We will add a -p option to allow ptime to attach to a running process and print a snapshot of the statistics for that process. EXAMPLE This example demonstrates nanosecond-resolution reporting: # ./ptime /bin/ls > /dev/null real 0.001734904 user 0.000433082 sys 0.001190076 # This example demonstrates full microstate reporting: # ./ptime -m /bin/ls > /dev/null real 0.001680855 user 0.000430206 sys 0.001139441 trap 0.000000949 tflt 0.000000000 dflt 0.000000000 kflt 0.000000000 lock 0.000000000 slp 0.000000000 lat 0.000004242 stop 0.000007332 # This example demonstrates attaching to an existing process: # ./ptime -m -p `pgrep syslogd` real 49:06:52.585250745 user 0.035726760 sys 0.034103073 trap 0.000154120 tflt 0.000000000 dflt 0.000000000 kflt 0.000000000 lock 343:48:03.815831359 slp 245:34:21.457591100 lat 0.065530109 stop 0.000043641 # REFERENCES [1] ptime should report microseconds or nanoseconds instead of just milliseconds (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6234106) [2] ptime should report resource usage statistics from /proc for running processes (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4532599) ------- ------- ------- ------- ------- ------- ------- ------- ------- -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From jek3@sun.com Mon Oct 15 18:27:58 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9G1Rwa3021350 for ; Mon, 15 Oct 2007 18:27:58 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9G1OZCA013761 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 15 Oct 2007 18:24:36 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPZ00913D904P00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 15 Oct 2007 19:24:36 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPZ005QVD90JRC0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 15 Oct 2007 19:24:36 -0600 (MDT) Received: from [129.150.12.137] (vpn-129-150-12-137.SFBay.Sun.COM [129.150.12.137]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9G1OXoE171487; Mon, 15 Oct 2007 18:24:34 -0700 (PDT) Date: Mon, 15 Oct 2007 15:24:33 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <20071016005139.GA7807@eng.sun.com> To: Dan Price Cc: psarc-ext@sun.com, Chad Mynhier Message-id: <471412D1.30609@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20071016005139.GA7807@eng.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 4378 Seems good. Even great. However, a bit of effort has been made to provide "more user friendly" output for many utilities. For example, df(1M): -h Like -k, except that sizes are in a more human readable format. Was any thought given to this? Just a poorly thought out question from my questionable mind... - jek3 Dan Price wrote: > [resending: it does not seem to have reached the case log the first > time] > > I am very pleased to sponsor the following case for Chad Mynhier. This > case enhances the ptime(1) utility to provide greater precision and > adds useful features. > > The timer is set for 10/22/2007. > > Note that this is an open case submitted by a community member; please > remember to CC Chad on all correspondence. > > Thanks, > > -dp > > ------- ------- ------- ------- ------- ------- ------- ------- ------- > ptime(1) Improvements > Chad Mynhier > > SUMMARY > > This fast-track enhances the ptime command to address two existing > RFEs[1,2] requesting higher resolution for reporting (microseconds > or nanoseconds), the option to see the full complement of microstate > statistics, and the ability to see statistics for a currently running > process. > > The new options are committed interfaces; this case seeks minor > release binding. > > INTERFACE TABLE > > Interface Stability Binding > ---------------------------------------------------------------- > Output Uncommitted Minor > -m option Committed Minor > -p option Committed Minor > ---------------------------------------------------------------- > > > DETAILS > > Overview > > Currently, the ptime command reports three statistics for a process, > real (i.e., wall clock) time, user time and system time, where these > statistics are presented at a millisecond resolution. In addition, > ptime can only report these statistics for a process started as a > child of the command. It does not provide the ability to look at these > statistics for an existing process. > > We plan to address these issues as follows: > > 1. We will change the default resolution for the statistics reported > by ptime to nanoseconds instead of milliseconds. (Note that this > may break scripts that match any number of digits to the right of > the decimal point but assume that the resolution is milliseconds. > But note also that the man page states that the human-readable > output is unstable.) > > 2. We will add a -m option that will generate a report containing the > full set of microstate statistics. > > 3. We will add a -p option to allow ptime to attach to a running > process and print a snapshot of the statistics for that process. > > EXAMPLE > > This example demonstrates nanosecond-resolution reporting: > > # ./ptime /bin/ls > /dev/null > > real 0.001734904 > user 0.000433082 > sys 0.001190076 > # > > This example demonstrates full microstate reporting: > > # ./ptime -m /bin/ls > /dev/null > > real 0.001680855 > user 0.000430206 > sys 0.001139441 > trap 0.000000949 > tflt 0.000000000 > dflt 0.000000000 > kflt 0.000000000 > lock 0.000000000 > slp 0.000000000 > lat 0.000004242 > stop 0.000007332 > # > > This example demonstrates attaching to an existing process: > > # ./ptime -m -p `pgrep syslogd` > > real 49:06:52.585250745 > user 0.035726760 > sys 0.034103073 > trap 0.000154120 > tflt 0.000000000 > dflt 0.000000000 > kflt 0.000000000 > lock 343:48:03.815831359 > slp 245:34:21.457591100 > lat 0.065530109 > stop 0.000043641 > # > > > REFERENCES > > [1] ptime should report microseconds or nanoseconds instead of just > milliseconds > (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6234106) > [2] ptime should report resource usage statistics from /proc for running > processes > (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4532599) > ------- ------- ------- ------- ------- ------- ------- ------- ------- > > > From dp@eng.sun.com Mon Oct 15 18:47:09 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9G1l8dh021446 for ; Mon, 15 Oct 2007 18:47:09 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9G1hfB6004527 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 16 Oct 2007 09:43:46 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPZ009IJE4WYA20@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 15 Oct 2007 18:43:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPZ00F5K17YM810@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 15 Oct 2007 14:04:48 -0700 (PDT) Received: from snowdog (snowdog.SFBay.Sun.COM [129.146.228.213]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9FL4kxM114575; Mon, 15 Oct 2007 14:04:46 -0700 (PDT) Date: Mon, 15 Oct 2007 14:07:00 -0700 From: Dan Price Subject: PSARC/2007/598: ptime(1) Improvements To: psarc-ext@sun.com Cc: Chad Mynhier Message-id: <20071015210700.GB7177@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 3754 I am very pleased to sponsor the following case for Chad Mynhier. This case enhances the ptime(1) utility to provide greater precision and adds useful features. The timer is set for 10/22/2007. Note that this is an open case submitted by a community member; please remember to CC Chad on all correspondence. Thanks, -dp ------- ------- ------- ------- ------- ------- ------- ------- ------- ptime(1) Improvements Chad Mynhier SUMMARY This fast-track enhances the ptime command to address two existing RFEs[1,2] requesting higher resolution for reporting (microseconds or nanoseconds), the option to see the full complement of microstate statistics, and the ability to see statistics for a currently running process. The new options are committed interfaces; this case seeks minor release binding. INTERFACE TABLE Interface Stability Binding ---------------------------------------------------------------- Output Uncommitted Minor -m option Committed Minor -p option Committed Minor ---------------------------------------------------------------- DETAILS Overview Currently, the ptime command reports three statistics for a process, real (i.e., wall clock) time, user time and system time, where these statistics are presented at a millisecond resolution. In addition, ptime can only report these statistics for a process started as a child of the command. It does not provide the ability to look at these statistics for an existing process. We plan to address these issues as follows: 1. We will change the default resolution for the statistics reported by ptime to nanoseconds instead of milliseconds. (Note that this may break scripts that match any number of digits to the right of the decimal point but assume that the resolution is milliseconds. But note also that the man page states that the human-readable output is unstable.) 2. We will add a -m option that will generate a report containing the full set of microstate statistics. 3. We will add a -p option to allow ptime to attach to a running process and print a snapshot of the statistics for that process. EXAMPLE This example demonstrates nanosecond-resolution reporting: # ./ptime /bin/ls > /dev/null real 0.001734904 user 0.000433082 sys 0.001190076 # This example demonstrates full microstate reporting: # ./ptime -m /bin/ls > /dev/null real 0.001680855 user 0.000430206 sys 0.001139441 trap 0.000000949 tflt 0.000000000 dflt 0.000000000 kflt 0.000000000 lock 0.000000000 slp 0.000000000 lat 0.000004242 stop 0.000007332 # This example demonstrates attaching to an existing process: # ./ptime -m -p `pgrep syslogd` real 49:06:52.585250745 user 0.035726760 sys 0.034103073 trap 0.000154120 tflt 0.000000000 dflt 0.000000000 kflt 0.000000000 lock 343:48:03.815831359 slp 245:34:21.457591100 lat 0.065530109 stop 0.000043641 # REFERENCES [1] ptime should report microseconds or nanoseconds instead of just milliseconds (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6234106) [2] ptime should report resource usage statistics from /proc for running processes (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4532599) ------- ------- ------- ------- ------- ------- ------- ------- ------- -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From weeyeh@gmail.com Mon Oct 15 19:39:53 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9G2dqNn022392 for ; Mon, 15 Oct 2007 19:39:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9G2aVtZ020556 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 15 Oct 2007 19:36:31 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPZ00G01GKV7J00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 15 Oct 2007 19:36:31 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPZ0096OGKVY150@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 15 Oct 2007 19:36:31 -0700 (PDT) Received: from relay17i.sun.com (ip127.net129179-4.block1.us.syntegra.com [129.179.4.127]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9G2XxtK016689 for ; Tue, 16 Oct 2007 02:36:30 +0000 (GMT) Received: from mmp11es.sun.com ([160.41.209.21] [160.41.209.21]) by relay17i.sun.com with ESMTP id BT-MMP-346374 for psarc-ext@sun.com; Tue, 16 Oct 2007 02:36:30 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.sun.com with ESMTP id BT-MMP-178643 for psarc-ext@sun.com; Tue, 16 Oct 2007 02:36:30 +0000 (Z) Received: from an-out-0708.google.com ([209.85.132.241] [209.85.132.241]) by relay1ib.sun.com with ESMTP id BT-MMP-1142398 for psarc-ext@sun.com; Tue, 16 Oct 2007 02:36:30 +0000 (Z) Received: by an-out-0708.google.com with SMTP id c25so118246ana for ; Mon, 15 Oct 2007 19:36:29 -0700 (PDT) Received: by 10.114.176.1 with SMTP id y1mr7788458wae.1192502188480; Mon, 15 Oct 2007 19:36:28 -0700 (PDT) Received: by 10.115.19.14 with HTTP; Mon, 15 Oct 2007 19:36:28 -0700 (PDT) Date: Tue, 16 Oct 2007 10:36:28 +0800 From: Wee Yeh Tan Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <20071016005139.GA7807@eng.sun.com> To: Dan Price Cc: psarc-ext@sun.com, Chad Mynhier Message-id: <660337d60710151936q41fdb800u77b7028483401810@mail.gmail.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8Zp0Djm+mF033FXwjrBuXA)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=urG5KLRETnzza3aUALtrVswMvvzh4Uexy9r4Zt6cjtI=; b=eTl2BFbp0i2vlj6zJx/WfM6RtjfeJyr536C8+BPVT3nglbVZAjOMk3ovsSJxrVErLEhuoWN1yowcbosIQ1Ro0nah/lfS88FgOL5Dg30Gtll0CW2QkCA2UstSJjy7j9HpEwDkbHvHdSeVxRCO9/zFdxBsWxBNF6SJ3RnIDxt24pw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=f+S21Rlr50MUI3vqrsEQPLFEzd6Y+HCysaBYxZjdfJL+VEF37K7Y4fsLfE4k1KkdiuFc1QXiTiL/sGa+rnuOZM9msaMKweG1QXo8Dabw20Xu8TC+kdwoYc7ZUfKlACjKlaQhOZ2dRKEYWkEff0PRRu4D5uSEQDztFxd/2rcX5A4= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <20071016005139.GA7807@eng.sun.com> Status: RO Content-Length: 15243 --Boundary_(ID_8Zp0Djm+mF033FXwjrBuXA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Hi Dan & Chad, I will also love to have a flag, maybe "-w", to instuct "ptime -p" to wait for the attached process terminates. This will extend ptime(1) to be useful when measuring the time spent comes only as an afterthought. On 10/16/07, Dan Price wrote: > > > [resending: it does not seem to have reached the case log the first > time] > > I am very pleased to sponsor the following case for Chad Mynhier. This > case enhances the ptime(1) utility to provide greater precision and > adds useful features. > > The timer is set for 10/22/2007. > > Note that this is an open case submitted by a community member; please > remember to CC Chad on all correspondence. > > Thanks, > > -dp > > ------- ------- ------- ------- ------- ------- ------- ------- ------- > ptime(1) Improvements > Chad Mynhier > > SUMMARY > > This fast-track enhances the ptime command to address two existing > RFEs[1,2] requesting higher resolution for reporting (microseconds > or nanoseconds), the option to see the full complement of > microstate > statistics, and the ability to see statistics for a currently > running > process. > > The new options are committed interfaces; this case seeks minor > release binding. > > INTERFACE TABLE > > Interface Stability Binding > ---------------------------------------------------------------- > Output Uncommitted Minor > -m option Committed Minor > -p option Committed Minor > ---------------------------------------------------------------- > > > DETAILS > > Overview > > Currently, the ptime command reports three statistics for a > process, > real (i.e., wall clock) time, user time and system time, where > these > statistics are presented at a millisecond resolution. In > addition, > ptime can only report these statistics for a process started as a > child of the command. It does not provide the ability to look at > these > statistics for an existing process. > > We plan to address these issues as follows: > > 1. We will change the default resolution for the statistics > reported > by ptime to nanoseconds instead of milliseconds. (Note that > this > may break scripts that match any number of digits to the right > of > the decimal point but assume that the resolution is > milliseconds. > But note also that the man page states that the human-readable > output is unstable.) > > 2. We will add a -m option that will generate a report containing > the > full set of microstate statistics. > > 3. We will add a -p option to allow ptime to attach to a > running > process and print a snapshot of the statistics for that > process. > > EXAMPLE > > This example demonstrates nanosecond-resolution reporting: > > # ./ptime /bin/ls > /dev/null > > real 0.001734904 > user 0.000433082 > sys 0.001190076 > # > > This example demonstrates full microstate reporting: > > # ./ptime -m /bin/ls > /dev/null > > real 0.001680855 > user 0.000430206 > sys 0.001139441 > trap 0.000000949 > tflt 0.000000000 > dflt 0.000000000 > kflt 0.000000000 > lock 0.000000000 > slp 0.000000000 > lat 0.000004242 > stop 0.000007332 > # > > This example demonstrates attaching to an existing process: > > # ./ptime -m -p `pgrep syslogd` > > real 49:06:52.585250745 > user 0.035726760 > sys 0.034103073 > trap 0.000154120 > tflt 0.000000000 > dflt 0.000000000 > kflt 0.000000000 > lock 343:48:03.815831359 > slp 245:34:21.457591100 > lat 0.065530109 > stop 0.000043641 > # > > > REFERENCES > > [1] ptime should report microseconds or nanoseconds instead of just > milliseconds > (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6234106) > [2] ptime should report resource usage statistics from /proc for running > processes > (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4532599) > ------- ------- ------- ------- ------- ------- ------- ------- ------- > > > -- > Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - > blogs.sun.com/dp > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > -- Just me, Wire ... Blog: --Boundary_(ID_8Zp0Djm+mF033FXwjrBuXA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Hi Dan & Chad,

I will also love to have a flag, maybe "-w", to instuct "ptime -p" to wait for the attached process terminates.  This will extend ptime(1) to be useful when measuring the time spent comes only as an afterthought. 

On 10/16/07, Dan Price <dp@eng.sun.com> wrote:

[resending: it does not seem to have reached the case log the first
time]

I am very pleased to sponsor the following case for Chad Mynhier.  This
case enhances the ptime(1) utility to provide greater precision and
adds useful features.

The timer is set for 10/22/2007.

Note that this is an open case submitted by a community member; please
remember to CC Chad on all correspondence.

Thanks,

        -dp

------- ------- ------- ------- ------- ------- ------- ------- -------
ptime(1) Improvements
Chad Mynhier <cmynhier@gmail.com>

SUMMARY

        This fast-track enhances the ptime command to address two existing
        RFEs[1,2] requesting higher resolution for reporting (microseconds
        or nanoseconds), the option to see the full complement of microstate
        statistics, and the ability to see statistics for a currently running
        process.

        The new options are committed interfaces; this case seeks minor
        release binding.

INTERFACE TABLE

    Interface                   Stability             Binding
    ----------------------------------------------------------------
    Output                    Uncommitted             Minor
    -m option                   Committed             Minor
    -p option                   Committed             Minor
    ----------------------------------------------------------------


DETAILS

    Overview

        Currently, the ptime command reports three statistics for a process,
        real (i.e., wall clock) time, user time and system time, where these
        statistics are presented at a millisecond resolution.  In addition,
        ptime can only report these statistics for a process started as a
        child of the command.  It does not provide the ability to look at these
        statistics for an existing process.

        We plan to address these issues as follows:

        1. We will change the default resolution for the statistics reported
           by ptime to nanoseconds instead of milliseconds.  (Note that this
           may break scripts that match any number of digits to the right of
           the decimal point but assume that the resolution is milliseconds.
           But note also that the man page states that the human-readable
           output is unstable.)

        2. We will add a -m option that will generate a report containing the
           full set of microstate statistics.

        3. We will add a -p <pid> option to allow ptime to attach to a running
           process and print a snapshot of the statistics for that process.

EXAMPLE

        This example demonstrates nanosecond-resolution reporting:

        # ./ptime /bin/ls > /dev/null

        real        0.001734904
        user        0.000433082
        sys         0.001190076
        #

        This example demonstrates full microstate reporting:

        # ./ptime -m /bin/ls > /dev/null

        real        0.001680855
        user        0.000430206
        sys         0.001139441
        trap        0.000000949
        tflt        0.000000000
        dflt        0.000000000
        kflt         0.000000000
        lock        0.000000000
        slp         0.000000000
        lat         0.000004242
        stop        0.000007332
        #

        This example demonstrates attaching to an existing process:

        # ./ptime -m -p `pgrep syslogd`

        real 49:06:52.585250745
        user        0.035726760
        sys         0.034103073
        trap        0.000154120
        tflt        0.000000000
        dflt        0.000000000
        kflt        0.000000000
        lock 343:48:03.815831359
        slp  245:34:21.457591100
        lat         0.065530109
        stop        0.000043641
        #


REFERENCES

[1] ptime should report microseconds or nanoseconds instead of just
    milliseconds
    (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6234106 )
[2] ptime should report resource usage statistics from /proc for running
    processes
    (http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4532599 )
------- ------- ------- ------- ------- ------- ------- ------- -------


--
Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org



--
Just me,
Wire ...
Blog: <prstat.blogspot.com> --Boundary_(ID_8Zp0Djm+mF033FXwjrBuXA)-- From cmynhier@gmail.com Tue Oct 16 05:00:14 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GC0DDO001230 for ; Tue, 16 Oct 2007 05:00:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9GBuoQV009156 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 16 Oct 2007 19:56:52 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000A016IOHS00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 05:56:48 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ0008OG6INRY20@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 05:56:48 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9GBq03D004519 for ; Tue, 16 Oct 2007 11:56:47 +0000 (GMT) Received: from mms49es.sun.com ([160.41.221.233] [160.41.221.233]) by relay42i.sun.com with ESMTP id BT-MMP-379881 for psarc-ext@sun.com; Tue, 16 Oct 2007 11:56:47 +0000 (Z) Received: from relay43i.sun.com ([192.5.209.74] [192.5.209.74]) by mms49es.sun.com with ESMTP id BT-MMP-1365036 for psarc-ext@sun.com; Tue, 16 Oct 2007 11:56:47 +0000 (Z) Received: from py-out-1112.google.com ([64.233.166.181] [64.233.166.181]) by relay4i.sun.com with ESMTP id BT-MMP-26733018 for psarc-ext@sun.com; Tue, 16 Oct 2007 11:56:47 +0000 (Z) Received: by py-out-1112.google.com with SMTP id a25so3740589pyi for ; Tue, 16 Oct 2007 04:56:46 -0700 (PDT) Received: by 10.65.205.16 with SMTP id h16mr13693793qbq.1192535806327; Tue, 16 Oct 2007 04:56:46 -0700 (PDT) Received: by 10.65.214.13 with HTTP; Tue, 16 Oct 2007 04:56:46 -0700 (PDT) Date: Tue, 16 Oct 2007 07:56:46 -0400 From: Chad Mynhier Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <471412D1.30609@sun.com> To: Joseph Kowalski Cc: Dan Price , psarc-ext@sun.com Message-id: <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=syUj7vC/9UWnR+g1hAUPlqifa5SSnJp+EUjhAge0sbo=; b=uLOHPIuzxWgiXLcI9RMm8AX7RZz+fy7di0qEh0m7GJtqqp9vLXMCRnGV8ncYVTT+Z1T2lE8RyuhWwgVNiCA/ebHtc3AsYBNuhBAjNiAWpisGZEpj7KkOb9IdEvC6dZ/1Ts/KmJlxNoK4CiTR7cJD5Lypiyn+AHck4LPLZS1fPu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ll66YpMks/kyd79RbMwAqTmxATfAZh+BnC397UWMxs40mAftWF1f9KPM92q7UesqpaI7xLs1il3oJ6uYfFm8SFpttuBH9+JLTZE1lMsHdLitulK0BMoK4hjKpTHYBzX3CJp+aZd2KVywBlobH7c2Erq/UHNOqHKA0Nerw1fXi6Y= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <20071016005139.GA7807@eng.sun.com> <471412D1.30609@sun.com> Status: RO Content-Length: 1243 On 10/15/07, Joseph Kowalski wrote: > > Seems good. Even great. > > However, a bit of effort has been made to provide "more user friendly" > output > for many utilities. For example, df(1M): > > > -h Like -k, except that sizes are > in a more human readable format. > > Was any thought given to this? > > Just a poorly thought out question from my questionable mind... > > - jek3 My original thought was to provide -u (microsecond) and -n (nanosecond) options to allow users to specify the resolution. For these I would have left the default resolution at milliseconds for backwards-compatibility. That was the closest I came to the -h/-k equivalent. But I think you're actually asking for output like this: # ./ptime -m -p `pgrep syslogd` real 49h06m53s user 35.72ms sys 34.10ms trap 154.1us tflt 0 dflt 0 kflt 0 lock 343h48m03s slp 245h34m21s lat 65.53ms stop 43.64us # Part of me wants to argue against this, given that order-of-magnitude differences jump out from the default output, but this wouldn't be changing the default, so my argument would have no teeth. I'll add this to the modifications. Thanks, Chad From stacey.marshall@sun.com Tue Oct 16 06:10:32 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GDAUXq002210 for ; Tue, 16 Oct 2007 06:10:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9GD78eT009233; Tue, 16 Oct 2007 21:07:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ0006019RV5900@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 06:07:07 -0700 (PDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ00029W9RUEU50@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 06:07:07 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l9GD73tY010688; Tue, 16 Oct 2007 14:07:03 +0100 (BST) Received: from [129.156.173.199] (estale [129.156.173.199]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id l9GD72dY003610; Tue, 16 Oct 2007 14:07:03 +0100 (BST) Date: Tue, 16 Oct 2007 14:07:02 +0100 From: Stacey Jonathan Marshall - Solaris RPE Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> To: Chad Mynhier Cc: Joseph Kowalski , Dan Price , psarc-ext@sun.com Message-id: <4714B776.1080901@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20071016005139.GA7807@eng.sun.com> <471412D1.30609@sun.com> <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070828) Status: RO Content-Length: 1528 Chad Mynhier wrote: > On 10/15/07, Joseph Kowalski wrote: > >> Seems good. Even great. >> >> However, a bit of effort has been made to provide "more user friendly" >> output >> for many utilities. For example, df(1M): >> >> >> -h Like -k, except that sizes are >> in a more human readable format. >> >> Was any thought given to this? >> >> Just a poorly thought out question from my questionable mind... >> >> - jek3 >> > > My original thought was to provide -u (microsecond) and -n > (nanosecond) options to allow users to specify the resolution. For > these I would have left the default resolution at milliseconds for > backwards-compatibility. That was the closest I came to the -h/-k > equivalent. > That's makes sense to me, so why were the options dropped from the consideration? > But I think you're actually asking for output like this: > That's what I thought but only if '-h' had been provided on the command line. > # ./ptime -m -p `pgrep syslogd` > > real 49h06m53s > user 35.72ms > sys 34.10ms > trap 154.1us > tflt 0 > dflt 0 > kflt 0 > lock 343h48m03s > slp 245h34m21s > lat 65.53ms > stop 43.64us > # > > Part of me wants to argue against this, given that order-of-magnitude > differences jump out from the default output, but this wouldn't be > changing the default, so my argument would have no teeth. > > I'll add this to the modifications. > > Thanks, > Chad > Stace From cmynhier@gmail.com Tue Oct 16 06:28:04 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GDS4uJ002361 for ; Tue, 16 Oct 2007 06:28:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GDObFx027125 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 16 Oct 2007 06:24:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000G5AAL7H000@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 07:24:43 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000F3SAL7GJ20@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 07:24:43 -0600 (MDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9GDNKSS024672 for ; Tue, 16 Oct 2007 13:24:42 +0000 (GMT) Received: from mms23es.sun.com ([150.143.232.54] [150.143.232.54]) by relay23i.sun.com with ESMTP id BT-MMP-1726376 for psarc-ext@sun.com; Tue, 16 Oct 2007 13:24:42 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms23es.sun.com with ESMTP id BT-MMP-1413560 for psarc-ext@sun.com; Tue, 16 Oct 2007 13:24:42 +0000 (Z) Received: from py-out-1112.google.com ([64.233.166.176] [64.233.166.176]) by relay22i.sun.com with ESMTP id BT-MMP-40080178 for psarc-ext@sun.com; Tue, 16 Oct 2007 13:24:42 +0000 (Z) Received: by py-out-1112.google.com with SMTP id a25so3781571pyi for ; Tue, 16 Oct 2007 06:24:42 -0700 (PDT) Received: by 10.65.51.4 with SMTP id d4mr13854475qbk.1192541081418; Tue, 16 Oct 2007 06:24:41 -0700 (PDT) Received: by 10.65.214.13 with HTTP; Tue, 16 Oct 2007 06:24:41 -0700 (PDT) Date: Tue, 16 Oct 2007 09:24:41 -0400 From: Chad Mynhier Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <4714B776.1080901@sun.com> To: Stacey Jonathan Marshall - Solaris RPE Cc: Joseph Kowalski , Dan Price , psarc-ext@sun.com Message-id: <3cf3989e0710160624q61ecdf6ax747988d500a4e048@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=7dsFEUIFT8qL9EBohwr9n6rE0chlwUvCB2FxKB4MpfE=; b=UX2YTvDr92k34Ce59Yh58p3dV9VBLQCJss9W8Yni4fRZXNFMlZ+38qnv2lAK1zsuv68YQqROPLcXmtdwT/ER9j2kQyXvRBC9EShCi59ZiD5IJy6DK9o1e+NZ4F8C7xKoixon42D90boNqW9ZMhlMYXK3uTynDHP9FtIGNqQHKYM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mzaqHyw4j+VsorECtRd0HUN2n3kRsWVTcaeMcaUILeS/fugm2iXS6KMgsFroHRbqu6goFfblkmMDjX6JEr3+ab6Z1OUhTGUi0qbXvnB0yeQYBc5G9DAqMpxUvH82OiV0Kd2lSy+qhwBHkhCJw4WfWREBJNEro7TEOpyOvWdPaQE= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <20071016005139.GA7807@eng.sun.com> <471412D1.30609@sun.com> <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> <4714B776.1080901@sun.com> Status: RO Content-Length: 1910 On 10/16/07, Stacey Jonathan Marshall - Solaris RPE wrote: > Chad Mynhier wrote: > > On 10/15/07, Joseph Kowalski wrote: > > > >> Seems good. Even great. > >> > >> However, a bit of effort has been made to provide "more user friendly" > >> output > >> for many utilities. For example, df(1M): > >> > >> > >> -h Like -k, except that sizes are > >> in a more human readable format. > >> > > > > My original thought was to provide -u (microsecond) and -n > > (nanosecond) options to allow users to specify the resolution. For > > these I would have left the default resolution at milliseconds for > > backwards-compatibility. That was the closest I came to the -h/-k > > equivalent. > > > That's makes sense to me, so why were the options dropped from the > consideration? We saw a parallel to the case where ping -s output was changed to provide microsecond resolution. Millisecond resolution no longer really makes sense for modern processors, nor for microstate accounting, in much the same way that millisecond resolution no longer made sense on modern networks. It makes more sense to go ahead and change the default. If we accept that proposition, then it also makes more sense to go ahead and change the default to be the resolution that's available rather than set it to the intermediate resolution of microseconds. > > But I think you're actually asking for output like this: > > > That's what I thought but only if '-h' had been provided on the command > line. Yes, there should be a -h on that command line, like this: # ./ptime -h -m -p `pgrep syslogd` > > real 49h06m53s > > user 35.72ms > > sys 34.10ms > > trap 154.1us > > tflt 0 > > dflt 0 > > kflt 0 > > lock 343h48m03s > > slp 245h34m21s > > lat 65.53ms > > stop 43.64us > > # Thanks, Chad From dp@eng.sun.com Tue Oct 16 11:39:47 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GIdl1C011796 for ; Tue, 16 Oct 2007 11:39:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GIaOBh015565; Tue, 16 Oct 2007 12:36:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000N0LP0O0J00@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 11:36:24 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000C61P0OPWD0@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 11:36:24 -0700 (PDT) Received: from snowdog (snowdog.SFBay.Sun.COM [129.146.228.213]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9GIaOTd405522; Tue, 16 Oct 2007 11:36:24 -0700 (PDT) Date: Tue, 16 Oct 2007 11:38:44 -0700 From: Dan Price Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> To: Chad Mynhier Cc: Joseph Kowalski , psarc-ext@Sun.COM Message-id: <20071016183843.GG7477@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20071016005139.GA7807@eng.sun.com> <471412D1.30609@sun.com> <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 1076 On Tue 16 Oct 2007 at 07:56AM, Chad Mynhier wrote: > # ./ptime -m -p `pgrep syslogd` > > real 49h06m53s > user 35.72ms > sys 34.10ms > trap 154.1us > tflt 0 > dflt 0 > kflt 0 > lock 343h48m03s > slp 245h34m21s > lat 65.53ms > stop 43.64us > # > > Part of me wants to argue against this, given that order-of-magnitude > differences jump out from the default output, but this wouldn't be > changing the default, so my argument would have no teeth. I think Chad is right, except that I think his argument *does* have teeth. To me, the "humanized" output is in this case harder to read than the non-humanized output. If *anything*, a more suitable form might be scientific notation, which allows one to more readily spot orders of magnitude. But I don't think enough people are familiar with that to make it worthwhile. I believe the case is complete as-written. Folks wanting additional features out of ptime(1) should please file RFE's. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From jek3@sun.com Tue Oct 16 11:44:07 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GIi6QH011886 for ; Tue, 16 Oct 2007 11:44:07 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GIeSli029636 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 16 Oct 2007 19:40:45 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ00001RP7V1M00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 11:40:43 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000CNKP7MQ6E0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 11:40:34 -0700 (PDT) Received: from [129.150.12.137] (vpn-129-150-12-137.SFBay.Sun.COM [129.150.12.137]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9GIeVBX407201; Tue, 16 Oct 2007 11:40:33 -0700 (PDT) Date: Tue, 16 Oct 2007 08:40:29 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> To: Chad Mynhier Cc: Dan Price , psarc-ext@sun.com Message-id: <4715059D.30307@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <20071016005139.GA7807@eng.sun.com> <471412D1.30609@sun.com> <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1710 Chad Mynhier wrote: > On 10/15/07, Joseph Kowalski wrote: > >> Seems good. Even great. >> >> However, a bit of effort has been made to provide "more user friendly" >> output >> for many utilities. For example, df(1M): >> >> >> -h Like -k, except that sizes are >> in a more human readable format. >> >> Was any thought given to this? >> >> Just a poorly thought out question from my questionable mind... >> >> - jek3 >> > > My original thought was to provide -u (microsecond) and -n > (nanosecond) options to allow users to specify the resolution. For > these I would have left the default resolution at milliseconds for > backwards-compatibility. That was the closest I came to the -h/-k > equivalent. > > But I think you're actually asking for output like this: > Uh, not really. I would be equally happy with your original thought about using "-u" and "-n". Speaking just for my self, either change (or none) is acceptable. ("None" would be a little disappointing, but I wouldn't argue if you decided on that.) I'd suggest that you propose the method *you* prefer. - thanks for thinking about this, - jek3 > # ./ptime -m -p `pgrep syslogd` > > real 49h06m53s > user 35.72ms > sys 34.10ms > trap 154.1us > tflt 0 > dflt 0 > kflt 0 > lock 343h48m03s > slp 245h34m21s > lat 65.53ms > stop 43.64us > # > > Part of me wants to argue against this, given that order-of-magnitude > differences jump out from the default output, but this wouldn't be > changing the default, so my argument would have no teeth. > > I'll add this to the modifications. > > Thanks, > Chad > From dp@eng.sun.com Tue Oct 16 11:50:52 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GIoqYl011955 for ; Tue, 16 Oct 2007 11:50:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GIlUG1020275; Tue, 16 Oct 2007 12:47:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000011PJ6HO00@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 11:47:30 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000C2WPJ6Q2E0@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Oct 2007 11:47:30 -0700 (PDT) Received: from snowdog (snowdog.SFBay.Sun.COM [129.146.228.213]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9GIlUOC408762; Tue, 16 Oct 2007 11:47:30 -0700 (PDT) Date: Tue, 16 Oct 2007 11:49:51 -0700 From: Dan Price Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <4715059D.30307@sun.com> To: Joseph Kowalski Cc: Chad Mynhier , psarc-ext@sun.com Message-id: <20071016184951.GI7477@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20071016005139.GA7807@eng.sun.com> <471412D1.30609@sun.com> <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> <4715059D.30307@sun.com> User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 1060 On Tue 16 Oct 2007 at 08:40AM, Joseph Kowalski wrote: > >My original thought was to provide -u (microsecond) and -n > >(nanosecond) options to allow users to specify the resolution. For > >these I would have left the default resolution at milliseconds for > >backwards-compatibility. That was the closest I came to the -h/-k > >equivalent. > > > >But I think you're actually asking for output like this: > > > Uh, not really. > > I would be equally happy with your original thought about using "-u" > and "-n". I'll claim responsibility for this: Chad originally proposed -u and -n, but my comment was that this creates its own usability problem: the user must now *discover* the fact that ptime has greater resolution, rather than just supplying the user the higher precision result by default. As an aside, there's no difference in the way we gather the data-- only in the way it gets printed, so literally this is an argument over printf formatting :( -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From cmynhier@gmail.com Tue Oct 16 12:21:49 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GJLnr4012985 for ; Tue, 16 Oct 2007 12:21:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9GJISvC010440 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 16 Oct 2007 12:18:28 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000705QYSMH00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 12:18:28 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000LZYQYRMFB0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 12:18:27 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9GJDWk8022509 for ; Tue, 16 Oct 2007 19:18:27 +0000 (GMT) Received: from mmp13es.sun.com ([160.41.209.23] [160.41.209.23]) by relay13i.sun.com with ESMTP id BT-MMP-359579 for psarc-ext@sun.com; Tue, 16 Oct 2007 19:18:27 +0000 (Z) Received: from relay16i.sun.com (relay16i.sun.com [129.179.4.126]) by mmp13es.sun.com with ESMTP id BT-MMP-176109 for psarc-ext@sun.com; Tue, 16 Oct 2007 19:18:27 +0000 (Z) Received: from py-out-1112.google.com ([64.233.166.180] [64.233.166.180]) by relay1ib.sun.com with ESMTP id BT-MMP-1301625 for psarc-ext@sun.com; Tue, 16 Oct 2007 19:18:27 +0000 (Z) Received: by py-out-1112.google.com with SMTP id a25so3979978pyi for ; Tue, 16 Oct 2007 12:18:26 -0700 (PDT) Received: by 10.65.154.2 with SMTP id g2mr14586098qbo.1192562305904; Tue, 16 Oct 2007 12:18:25 -0700 (PDT) Received: by 10.65.214.13 with HTTP; Tue, 16 Oct 2007 12:18:25 -0700 (PDT) Date: Tue, 16 Oct 2007 15:18:25 -0400 From: Chad Mynhier Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <660337d60710151936q41fdb800u77b7028483401810@mail.gmail.com> To: Wee Yeh Tan Cc: Dan Price , psarc-ext@sun.com Message-id: <3cf3989e0710161218h3949005dhdad2b475b9866bf7@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=77PXH3vKwUdxQVV+5G3P/tWmUxsKOQULbt6I6hwtJas=; b=nKlVyu0rLmQSMTJIPYWL/XCGzDTEzZz80YY0+wVuOEg38dzrV2/upoNL2ohHN5IDmh4YURPgyLwqQ3sus1RubfAW+RQXJWioNvIoTG5AXoMOyH/v/qSFbB05qiEuL6RpLUFFgzU21vgBDVlbOKKn3/UptYKXRZ7MpFvP293G8a4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DAkCsXr3kWdgoVrPpdG9ru/3AZZbym8HOo7qrL6x+gDEtwh1yg8NUWPwNlfVsaML7nelxci9EYdQX6GT1TrIA/CCYbwyO3BnAw4FiCUK7AfPUsuoXEII69cspLwXXr0FpPHoBQcN+p+FCwfnGNbzklz6WBK+3iQsrMT3WhAFKNI= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <20071016005139.GA7807@eng.sun.com> <660337d60710151936q41fdb800u77b7028483401810@mail.gmail.com> Status: RO Content-Length: 444 On 10/15/07, Wee Yeh Tan wrote: > Hi Dan & Chad, > > I will also love to have a flag, maybe "-w", to instuct "ptime -p" to wait > for the attached process terminates. This will extend ptime(1) to be useful > when measuring the time spent comes only as an afterthought. I'd agree that this would be a useful feature, but for the moment I'll echo Dan's sentiment that the case should be considered complete as written. Chad From edward.pilatowicz@sun.com Tue Oct 16 14:43:20 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9GLhJja017985 for ; Tue, 16 Oct 2007 14:43:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9GLdnKY025944; Wed, 17 Oct 2007 05:39:56 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ000M01XIIAG00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 14:39:54 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ000D1YXIIWZC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 16 Oct 2007 14:39:54 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9GLdsAU442247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 14:39:54 -0700 (PDT) Received: (from edp@localhost) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l9GLdsSS442246; Tue, 16 Oct 2007 14:39:54 -0700 (PDT) Date: Tue, 16 Oct 2007 14:39:54 -0700 From: Edward Pilatowicz Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <20071016184951.GI7477@eng.sun.com> To: Dan Price Cc: Joseph Kowalski , psarc-ext@sun.com Message-id: <20071016213954.GA441141@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20071016005139.GA7807@eng.sun.com> <471412D1.30609@sun.com> <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> <4715059D.30307@sun.com> <20071016184951.GI7477@eng.sun.com> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: edp set sender to edward.pilatowicz@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1427 i have a quick question that's not about formatting. will all the man page be updated to explain what dflt, slp lat, and friends mean? ed On Tue, Oct 16, 2007 at 11:49:51AM -0700, Dan Price wrote: > On Tue 16 Oct 2007 at 08:40AM, Joseph Kowalski wrote: > > >My original thought was to provide -u (microsecond) and -n > > >(nanosecond) options to allow users to specify the resolution. For > > >these I would have left the default resolution at milliseconds for > > >backwards-compatibility. That was the closest I came to the -h/-k > > >equivalent. > > > > > >But I think you're actually asking for output like this: > > > > > Uh, not really. > > > > I would be equally happy with your original thought about using "-u" > > and "-n". > > I'll claim responsibility for this: Chad originally proposed -u and -n, > but my comment was that this creates its own usability problem: the user > must now *discover* the fact that ptime has greater resolution, rather > than just supplying the user the higher precision result by default. > > As an aside, there's no difference in the way we gather the data-- only > in the way it gets printed, so literally this is an argument over > printf formatting :( > > -dp > > -- > Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From cmynhier@gmail.com Tue Oct 16 18:03:50 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9H13nJM025305 for ; Tue, 16 Oct 2007 18:03:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9H10POP018315 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 17 Oct 2007 09:00:28 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQ100H096SRKI00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 19:00:27 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQ1006TX6SO8C60@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 16 Oct 2007 19:00:24 -0600 (MDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9H0raD4002266 for ; Wed, 17 Oct 2007 01:00:24 +0000 (GMT) Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay22i.sun.com with ESMTP id BT-MMP-1785548 for psarc-ext@sun.com; Wed, 17 Oct 2007 01:00:24 +0000 (Z) Received: from relay21.ob.sun.com (relay21.ob.sun.com [192.12.251.24]) by mms25es.sun.com with ESMTP id BT-MMP-2539277 for psarc-ext@sun.com; Wed, 17 Oct 2007 01:00:23 +0000 (Z) Received: from nz-out-0506.google.com ([64.233.162.225] [64.233.162.225]) by relay21i.sun.com with ESMTP id BT-MMP-31527299 for psarc-ext@sun.com; Wed, 17 Oct 2007 01:00:23 +0000 (Z) Received: by nz-out-0506.google.com with SMTP id z31so1303308nzd for ; Tue, 16 Oct 2007 18:00:23 -0700 (PDT) Received: by 10.64.156.2 with SMTP id d2mr15185059qbe.1192582823241; Tue, 16 Oct 2007 18:00:23 -0700 (PDT) Received: by 10.65.214.13 with HTTP; Tue, 16 Oct 2007 18:00:23 -0700 (PDT) Date: Tue, 16 Oct 2007 21:00:23 -0400 From: Chad Mynhier Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <20071016213954.GA441141@eng.sun.com> To: Edward Pilatowicz Cc: Dan Price , psarc-ext@Sun.COM, Joseph Kowalski Message-id: <3cf3989e0710161800k674f45d1kd00f229b62be047d@mail.gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=yNRGzWIOhaf61vEX2tNfTKCAypABym8TNrNKt68mQfc=; b=FCzH2W3r6VzbNz95hKm27ZceeUcNYi0TWFDByLyiCh+6mBoNiisVrDZ37+vttZ8HnLQT4rZixs8xh7Y6FTKQ9ZlZEFb3nmdCvWhFlYbSAoeQM4kB4qNBPnMp/hWYRN7YD85+IXnk3mNSRAW/ds8SE5RYqgAv8vA64OQuqg6MDBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qdmccdthrOVs8edFhfP5tjfI10vlc8Tz9lFVO3MxlIsVFRIa2C/EO6b3Kuow9srsgrqyTCMXCS3Nxx7z5xO2GM9ctyYfdG2nqPEtfmplKOYaxbXC92ZdHcRKRer/Vux8eVjboJMRt/mIGqOXpvcVvkLBz0nwz4Egx2usnkBlEkk= X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== References: <20071016005139.GA7807@eng.sun.com> <471412D1.30609@sun.com> <3cf3989e0710160456t7a4d4ccs360183df5f3bcdcf@mail.gmail.com> <4715059D.30307@sun.com> <20071016184951.GI7477@eng.sun.com> <20071016213954.GA441141@eng.sun.com> Status: RO Content-Length: 942 On 10/16/07, Edward Pilatowicz wrote: > i have a quick question that's not about formatting. > will all the man page be updated to explain what dflt, slp > lat, and friends mean? > ed Yes, I plan on updating the man page to explain these fields, something similar to the following: -m (ptime only) Display the full set of microstate accounting statistics. The displayed fields are as follows: real Wall clock time. user User level CPU time. sys System call CPU time. trap Other system trap CPU time. tflt Text page fault sleep time. dflt Data page fault sleep time. kflt Kernel page fault sleep time. lock User lock wait sleep time. slp All other sleep time. lat CPU latency (wait) time. stop Stopped time. Chad From MAILER-DAEMON Mon Oct 29 01:42:26 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9T8gPOZ005488 for ; Mon, 29 Oct 2007 01:42:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9T8cmPf014782 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 29 Oct 2007 08:38:52 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JQO0001R00P8F00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 29 Oct 2007 01:38:49 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JQO00D3O00C4380@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 29 Oct 2007 01:38:36 -0700 (PDT) Received: from snowdog (snowdog.SFBay.Sun.COM [129.146.228.213]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9T8cai8220597; Mon, 29 Oct 2007 01:38:36 -0700 (PDT) Date: Mon, 29 Oct 2007 01:42:33 -0700 From: Dan Price Subject: Re: PSARC/2007/598: ptime(1) Improvements In-reply-to: <20071016005139.GA7807@eng.sun.com> To: psarc-ext@sun.com Cc: Chad Mynhier Message-id: <20071029084226.GA4700@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <20071016005139.GA7807@eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 802 On Mon 15 Oct 2007 at 05:51PM, Dan Price wrote: > > [resending: it does not seem to have reached the case log the first > time] > > I am very pleased to sponsor the following case for Chad Mynhier. This > case enhances the ptime(1) utility to provide greater precision and > adds useful features. > > The timer is set for 10/22/2007. > > Note that this is an open case submitted by a community member; please > remember to CC Chad on all correspondence. > > Thanks, > > -dp > > ------- ------- ------- ------- ------- ------- ------- ------- ------- > ptime(1) Improvements > Chad Mynhier This case was approved at 10/24's ARC meeting. I've updated the case status. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp