Feedback - PMP> Minutes of the MFP Teleconference 20060214

Feedback - PMP> Minutes of the MFP Teleconference 20060214

Harry Lewis harryl at us.ibm.com
Thu Feb 16 02:14:23 EST 2006


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 at sharplabs.com> 
Sent by: pmp-owner at pwg.org
02/15/2006 08:04 PM

To
"'Bergman, Ron'" <Ron.Bergman at rpsa.ricoh.com>, ptykodi at tykodi.com, 
pmp at 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 at sharplabs.com

> -----Original Message-----
> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf 
> Of Bergman,
> Ron
> Sent: Wednesday, February 15, 2006 12:37 PM
> To: ptykodi at tykodi.com; pmp at 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 at pwg.org [mailto:pmp-owner at pwg.org]On Behalf Of Paul
> Tykodi
> Sent: Wednesday, February 15, 2006 6:13 AM
> To: pmp at 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 at tykodi.com
> WWW:     http://www.tykodi.com
> 
> -----Original Message-----
> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org] On Behalf 
> Of McDonald,
> Ira
> Sent: Wednesday, February 15, 2006 1:06 AM
> To: 'ptykodi at tykodi.com'; pmp at 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 at sharplabs.com
> 
> -----Original Message-----
> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org]On Behalf 
> Of Paul Tykodi
> Sent: Tuesday, February 14, 2006 10:50 PM
> To: pmp at 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 at tykodi.com
> WWW:  http://www.tykodi.com
> 
> 
> 
> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org] On Behalf Of
> wamwagner at comcast.net
> Sent: Tuesday, February 14, 2006 10:33 PM
> To: ptykodi at tykodi.com; pmp at 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 at 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 at tykodi.com
> WWW:  http://www.tykodi.com
> 
> 
> 
> From: pmp-owner at pwg.org [mailto:pmp-owner at pwg.org] On Behalf 
> Of Bergman, Ron
> Sent: Tuesday, February 14, 2006 7:02 PM
> To: pmp at 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 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/pmp/attachments/20060216/0672caf4/attachment.html


More information about the Pmp mailing list