From: Harry Lewis (harryl@us.ibm.com)
Date: Thu Feb 16 2006 - 02:14:23 EST
Inconsistency is a more serious problem (in my experience) than efficiency
(which I THINK is Paul's hot button). I think it would be great if we
addressed both, but these may require separate efforts.
----------------------------------------------
Harry Lewis
IBM STSM
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems
http://www.ibm.com/printers
303-924-5337
----------------------------------------------
"McDonald, Ira" <imcdonald@sharplabs.com>
Sent by: pmp-owner@pwg.org
02/15/2006 08:04 PM
To
"'Bergman, Ron'" <Ron.Bergman@rpsa.ricoh.com>, ptykodi@tykodi.com,
pmp@pwg.org
cc
Subject
RE: Feedback - PMP> Minutes of the MFP Teleconference 20060214
Hi,
I spoke with Rick Landau (Dell) this afternoon and he's getting
some input from Dell management software implementors who have
observed implementation inconsistencies in Printer MIB - he said
he'll pass these along pretty soon - I think that cross-vendor
management software implementors are some of the best allies for
a PWG Best Practices document on the Printer MIB.
Note that the PWG Process/2.0 requires that Implementors Guides
be subject to the full process and Formal Approval and final
publication as Best Practices in '/pub/pwg/informational'
(i.e., unlike IETF Implementors Guides they are NORMATIVE).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
> -----Original Message-----
> From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf
> Of Bergman,
> Ron
> Sent: Wednesday, February 15, 2006 12:37 PM
> To: ptykodi@tykodi.com; pmp@pwg.org
> Subject: RE: Feedback - PMP> Minutes of the MFP
> Teleconference 20060214
>
>
> Hi Paul,
>
> I have also observed poorly designed SNMP based applications
> that consume
> enormous amounts of network bandwith. For example, reading
> large portions
> of the input and output tables at a fairly high frequency to
> determine the
> available paper sources and destinations. In many cases I
> believe this is
> the result of a desire to simplify the application, through
> the use of a
> single query loop, by developers that are not experienced in
> real-time code
> practices.
>
> As chairman of the PWG MIBs Working Group I would be glad to
> work with you
> to define and present this as a project proposal to the PWG.
>
> Regards,
> Ron Bergman
>
>
> -----Original Message-----
> From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf Of Paul
> Tykodi
> Sent: Wednesday, February 15, 2006 6:13 AM
> To: pmp@pwg.org
> Subject: RE: Feedback - PMP> Minutes of the MFP
> Teleconference 20060214
>
>
> Hi Ira,
>
> I am willing to be a co-editor for such a project. Is this
> something the PWG
> would likely want to pursue in the near term future?
>
> Thanks.
>
> Best Regards,
>
> /Paul
> --
> Paul Tykodi
> Principal Consultant
> TCS - Tykodi Consulting Services LLC
>
> Tel/Fax: 603-343-1820
> Mobile: 603-866-0712
> E-mail: ptykodi@tykodi.com
> WWW: http://www.tykodi.com
>
> -----Original Message-----
> From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf
> Of McDonald,
> Ira
> Sent: Wednesday, February 15, 2006 1:06 AM
> To: 'ptykodi@tykodi.com'; pmp@pwg.org
> Subject: RE: Feedback - PMP> Minutes of the MFP
> Teleconference 20060214
>
> Hi Paul,
>
> Harry Lewis (IBM, chair of PWG) has repeatedly suggested that a
> good project would be a PWG standard "Printer MIB Implementor's
> Guide" - similar in purpose and scope to the IETF Proposed Std
> "IPP/1.1 Implementor's Guide" (RFC 3196, November 2001).
>
> Volunteer PWG editor bandwidth is the problem - that and the very
> complicated problem space of SNMP optimization biased by MIB
> optimization biased by the fact that printers (and spoolers) are
> supposed to "print first and bother me later".
>
> A first step was that Printer MIB v2 (RFC 3805) contained a great
> many improved DESCRIPTION clauses that clarified and recommended
> implementation choices for many of the columnar objects.
>
> But the problem you've identified is a whole system problem, not
> just a Printer MIB implementation problem.
>
> Cheers,
> - Ira (co-editor of Printer MIB v2)
>
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221 Grand Marais, MI 49839
> phone: +1-906-494-2434
> email: imcdonald@sharplabs.com
>
> -----Original Message-----
> From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org]On Behalf
> Of Paul Tykodi
> Sent: Tuesday, February 14, 2006 10:50 PM
> To: pmp@pwg.org
> Subject: RE: Feedback - PMP> Minutes of the MFP
> Teleconference 20060214
>
>
> Dear Bill,
>
> The host I was most recently analyzing was an IBM iSeries -
> AS/400 host. The
> MIB itself worked flawlessly. I am not suggesting that it was
> somehow the
> culprit for the slow printing or that it did not work correctly. The
> communication started OK and then the host was concerned that
> a response
> packet was not received in a timely fashion. It began a
> significant SNMP
> based questioning process to determine the current hardware
> status of the
> device and interspersed with the SNMP questions about whether
> the device was
> in error or not came a re-transmission of a potentially lost
> packet just to
> be safe.
>
> Pretty soon the majority of the communication on the wire
> revolved around
> SNMP discussions as to the device's status and data packet
> re-transmissions
> and confirmations from the printing device that it had indeed
> received the
> packet re-transmissions. As you mention, the whole idea of printing
> information had become unfortunately a secondary concern.
>
> In the end, all of the data was printed and no errors were
> reported by the
> host. Unfortunately the method utilized to determine that
> everything was
> actually fine was so intrusive on the printing process that I feel
> comfortable saying I believe that a typical customer (having
> paid a fee for
> their printing device related to its rated engine performance) would
> probably not have accepted the result as commercially viable.
>
> So my previous comment is directed more towards device
> managing software
> product's use of MIB capabilities (especially if more
> interesting things to
> check are added into future MIB's) and the impact that
> significant device
> status verifications can have on the actual process (in this
> case printing),
> which is being monitored.
>
> Thus in the future if some type of RFC or other standards
> document were to
> be produced, my suggestion would be to include some examples
> that tried to
> help steer software developers implementing use of MIB data away from
> creating the issue you outline in point b. below.
>
> Thanks.
>
> Best Regards,
>
> /Paul
> --
> Paul Tykodi
> Principal Consultant
> TCS - Tykodi Consulting Services LLC
>
> Tel/Fax: 603-343-1820
> Mobile: 603-866-0712
> E-mail: ptykodi@tykodi.com
> WWW: http://www.tykodi.com
>
>
>
> From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf Of
> wamwagner@comcast.net
> Sent: Tuesday, February 14, 2006 10:33 PM
> To: ptykodi@tykodi.com; pmp@pwg.org
> Cc: Paul Tykodi
> Subject: RE: Feedback - PMP> Minutes of the MFP
> Teleconference 20060214
>
> Paul,
>
> Thanks for sending in your observation. I have worked with
> printers and SNMP
> management for many years and have not seen anything like the sort of
> slowdown that you cite. Perhaps this is because I have worked
> with slower
> machines and printers/MFPs with separate NICs. At any rate, a
> basic SNMP
> tenet is that servicing of SNMP is secondary to the main
> purpose of the
> device. Indeed, reflecting this, I have seen missed or late
> SNMP responses
> during periods of high print activity.
>
> Of course, it is desirable to have efficient MIBs, something
> that sometimes
> gets lost in this era of "human readability". Although you may have
> contradicting data, I would suggest that the current public
> MIBs are not in
> themselves inefficient and that the problem you observed may
> be due to other
> factors such as:
> a. certain private MIBS use an indirect addressing approach,
> particularly for writes, which may make for some elegance but does
> complicate interaction
> b. many management applications are terribly
> inefficient, repeatedly
> querying the same (sometimes status) variable, and often unnecessarily
> dumping blocks of data.
> c. Drastically underpowered controllers and/or poor handling of
> priorities
>
> Although I understand that it may be difficult to release
> such information,
> it would be useful to have some information on the specifics of the
> slow-down... the condition the management station was
> querying, the objects
> being queried, etc.
>
> Bill Wagner, TIC
>
> -------------- Original message --------------
> From: "Paul Tykodi" <ptykodi@tykodi.com>
> Dear List,
>
> During the last year, I have been involved in some network
> analysis looking
> at how certain hosts use the current printer MIB to determine
> device status
> (including that of MFP's) and what effect a significant number of SNMP
> queries and responses can have on effective printing
> throughput (at times
> rather dramatic reduction in achievable throughput).
>
> In looking at the minutes from today's meeting, I would
> suggest that it
> might be a good idea to consider whether MIB optimization should be a
> category for an MFP alerts project. The idea would be to at
> least minimally
> describe some best practices for MIB usage, which would
> result in the host
> obtaining the required information using the smallest SNMP query and
> response packet transmission overhead possible.
>
> In case people are wondering how dramatic a reduction in PPM
> I have observed
> when SNMP traffic is significant (host trying to determine
> whether device is
> in error or not - multiple queries are sent asking more and
> more specific
> questions of the printer MIB), I have seen printers and MFP's
> with rated
> speeds in the 75 - 125 PPM range reduced to achieving actual
> throughput in
> the 10 to 20 PPM range.
>
> HTH
>
> Best Regards,
>
> /Paul
> --
> Paul Tykodi
> Principal Consultant
> TCS - Tykodi Consulting Services LLC
>
> Tel/Fax: 603-343-1820
> Mobile: 603-866-0712
> E-mail: ptykodi@tykodi.com
> WWW: http://www.tykodi.com
>
>
>
> From: pmp-owner@pwg.org [mailto:pmp-owner@pwg.org] On Behalf
> Of Bergman, Ron
> Sent: Tuesday, February 14, 2006 7:02 PM
> To: pmp@pwg.org
> Subject: PMP> Minutes of the MFP Teleconference 20060214
>
> The minutes can be found at:
>
> ftp://ftp.pwg.org/pub/pwg/pmp/minutes/mfp/MFP_Minutes_20060214.pdf
> Ron Bergman
> Chairman, Printer MIBs Working Group
>
>
This archive was generated by hypermail 2.1.4 : Thu Feb 16 2006 - 02:12:43 EST