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
>>