Re: RFC3728 : vdslPerfDataTable

[email protected]
Newsgroups gmane.ietf.adslmib
Message-ID <OF625A3A7B.C029CC49-ONC22570B5.004C4F7E-C22570B5.004DF5F1@ecitele.com>
Ambiga,

I'm not the RFC editor of that MIB, however I think I can help.

You probably misunderstood the role of the two objects. They do not count
incrementally since last reset but refer to the current state of the
relevant PM table.
In particular, the vdslPerfDataValidIntervals counts the number of
intervals for which the agent has at least some data (i.e., meaningful
entry). This may be at least 0 (no interval) and at most 96 (all entries
have meaningful data). Similarly the vdslPerfDataInvalidIntervals counts
how many intervals have no data. This of course may be also 0 (if all
entries are meaningful) and cannot be more than 96 (i.e., immediately after
reset no entry has information).
In certain cases there are disruptions in collecting PM info, so some
entries may be marked as invalid. In such a case the
vdslPerfDataValidIntervals will indicate the highest entry number with
meaningful info which the agent can provide and the
vdslPerfDataInvalidIntervals will indicate how many invalid entries are
found from entry #0 to entry number (vdslPerfDataValidIntervals-1).

Best Regards,
Moti Morgenstern

Senior Systems Engineer
ECI Telecom Ltd.
Broadband Access Division
30 Hasivim St.
Petach Tikva, Israel 49517
Tel.: +972-3-9266258
Fax: +972-3-9287342
Cell: +972-54-5786258
e-mail: [email protected]
www.ecitele.com




                                                                           
             "Ambiga                                                       
             Karthikeyan"                                                  
             <Ambiga@amedianet                                          To 
             works.com>                <[email protected]>                  
             Sent by:                                                   cc 
             adslmib-bounces@i         [email protected]             
             etf.org                                               Subject 
                                       [Adslmib] RFC3728 :                 
                                       vdslPerfDataTable                   
             09/11/2005 18:45                                              
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Dear RFC Editors,

In vdslPerDataTable I see the following mib variables

     VdslPerfDataEntry ::=
     SEQUENCE
         {
         vdslPerfDataValidIntervals         HCPerfValidIntervals,
         vdslPerfDataInvalidIntervals       HCPerfInvalidIntervals,
            …
          vdslPerfData1DayValidIntervals     HCPerfValidIntervals,
          vdslPerfData1DayInvalidIntervals   HCPerfInvalidIntervals,
            …
            }
From RFC3705 definition of HCPerfValidIntervals, I see that it can take
value 0-96 (number of 15 min interval in 1 day).

I understand vdslPerfDataValidIntervals  ,   vdslPerfDataInvalidIntervals
means the total number of valid/invalid intervals since the last reset. So
we can have value > 96 and so shouldn’t it be defined as Unsigned32 ? Only
vdslPerfData1DayValidIntervals and vdslPerfData1DayInvalidIntervals will be
limited by 0..96 .

Thank you very much,
Ambiga

 _______________________________________________
Adslmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/adslmib

_______________________________________________
Adslmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/adslmib
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.