Conference azur::mcc

    This is a guess - someone please tell me if I'm wrong.
    
    There is protocol overhead to consider.
    The Octets (I hope the spelling error is yours and not ours!) In and
    Out probably refer to the actual data that was sent inside the protocol
    data units. Each message would have a protocol wrapper (eg. 14 bytes)
    which takes up line utilization, but does not contribute towards the 
    data the protocol's client is sending and receiving.
    
    Thus, to compute line utilization usually requires taking the data
    bytes transmitted (and received) and adding the protocol overhead
    (bytes/message) for each message transmitted (and received), then
    calculating the ratio of the bits sent (and received) on the wire to
    the theoretical maximum for the line.
    
    Colin

    Thanks for the reply.
    
    I understand that In and Out probably do refer to only the data which
    was received (or sent) and that there is an overhead to be added on to
    that figure to take into account headers etc. 
    
    I'm still not sure however what you do to an IN figure of 1,396,068 and 
    an OUT figure of 700,065 to get a Total of 1,498,877. 
    
    Also, even taking into account the protocol overhead, how would a peak
    bytes/sec of 11,697 equate to a bandwidth utilization of 131% on a 256K
    line.
    
    
    Jim.
    
    P.S. The spelling of "Octetes" is as generated by the Reports package.
           

    Would anyone like to comment on this, please?
    
    Regards,
    	    Jim.
    

 I guess having a CLD posted against this problem of 'Total' not
 equaling 'In' + 'Out' would get a response.  So below I will provide
 you with a snippet of the algorithm used to generate the values 
 presented on the report.  (I will use Datatrieve as the example,
 but the same should be true with the SQL reports).

   First, once the database is readied:

	DECLARE TOT_BYTES_COMPUTED COMPUTED BY
	    CHOICE (PROTOCOL NE 6) AND (DUPLEX = 0) AND 
		     (OUTBOUND_BYTES > INBOUND_BYTES) THEN
              		OUTBOUND_BYTES
		   (PROTOCOL NE 6) AND (DUPLEX = 0) AND
		     (OUTBOUND_BYTES < INBOUND_BYTES) THEN
			INBOUND_BYTES
		   ELSE
			(INBOUND_BYTES + OUTBOUND_BYTES)
	    END_CHOICE.

   Note I personally do not know what protocal value of 6 or duplex 
   value of 0 represents, but later in the algorithm it states the
   following when determining the 'Line Mode'.

	CHOICE (PROTOCAL = 6) THEN "N/A"
	       (PROTOCAL NE 6) AND (DUPLEX = 0) THEN "Full Duplex"
               (PROTOCAL NE 6) AND (DUPLEX = 1) THEN "Half Duplex"
               ELSE "N/A"
        END_CHOICE.

  (Note CHOICE is similar to a 'switch' or a series of 'if' statements 
   in the 'C' programming language.)

   The 'In', 'Out', and 'Total' values are computed as follows:
      "In:"  FN$FLOOR(TOTAL INBOUND_BYTES/1000)
      "out:" FN$FLOOR(TOTAL OUTBOUND_BYTES/1000)
      "Total:" FN$FLOOR(TOTAL TOT_BYTES_COMPUTED/1000)

   
   For those who do not know how to read datatrieve and since I cut a
  lot of the code out for this answer, let me give a quick explanation
  of what the above statements mean: (Note INBOUND_BYTES and 
  OUTBOUND_BYTES are declared in the schema)
    
        For every record found based upon the selection criteria of
	the specific line, the start time, stop time, and node id
        the above computations will be performed.

	That is to say that the inbound Octets is the sum of ALL 
	INBOUND_BYTES.  This value is converted to kBytes, and then
        rounded to the nearest whole number.

        The outbound Octets is the sum of ALL OUTBOUND_BYTES.  Then 
        this value is converted to kBytes and rounded to the nearest
        whole number.

        The 'total' octets is the sum of ALL TOT_BYTES_COMPUTED.  Then
        this value is converted to kBytes and rounded to the nearest
        whole number.  BUT if you note above, there is a special way
        that the TOT_BYTES_COMPUTED are computed.  For *EACH* record
        found, if one is using 'Full Duplex' then TOT_BYTES_COMPUTED
        will be the larger of either the INBOUND_BYTES or OUTBOUND_BYTES
   	and this value will be accumulated into the 'total' value.  
        Otherwise it will be the sum of the INBOUND_BYTES + OUTBOUND_BYTES

  If you wish for the expected mathematical value of 'Total' = 'In' + 'Out'
  then don't use 'Full Duplex' mode!  

  Maybe it would be more appropriate to change the word 'Total' to 
  something more meaningful such as 'Maximum'

  I hope this clears things up for you. 

				- Darrell

QUESTION:

  How does a peak of 11,697 bytes/sec equate to a peak utilization of
 131%, given that the line speed is 256 kbytes/sec?

ANSWER:

  Again, this is taken from the Datatrieve commands, but the same
 should be similar in SQL.

  Below I will provide you with a snippet of the algorithm used to
 generate the values in question.

     First, once the database is readied:

	DECLARE TOT_UTIL_COMPUTED COMPUTED BY
	    CHOICE (PROTOCOL NE 6) AND (DUPLEX = 0) AND 
		     (OUTBOUND_UTILIZATION > INBOUND_UTILIZATION) THEN
			 OUTBOUND_UTILIZATION
		   (PROTOCAL NE 6) AND (DUPLEX = 0) AND
		     (OUTBOUND_UTILIZATION < INBOUND_UTILIZATION) THEN
			 INBOUND_UTILIZATION
		   ELSE (OUTBOUND_UTILIZATION + INBOUND_UTILIZATION)/2
	    END_CHOICE.


    See previous answer (.-1) for PROTOCAL NE 6, DUPLEX = 0 clarification.

    For *EACH* record found: 

	The 'Utilization of Total Bandwidth' is computed by:
	  (TOTAL TOT_UTIL_COMPUTED / COUNT)

	The 'Peak %Utilization based on Bandwidth' is computed by:
	   (MAX TOT_UTIL_COMPUTED)

	The 'Peak Bytes/Sec' is computed by:
	   (FN$FLOOR(TOT_BYTES_COMPUTED)/DURATION)		    

   I am not sure where COUNT or DURATION are calculated, but I think
   it is either declared in the schema, or a calculation tool set by
   DATATRIEVE when it collects records.

   As with the previous answer, TOT_UTIL_COMPUTED will be the larger
   of either OUTBOUND_UTILIZATION or INBOUND_UTILIZATION since you
   are using 'Full Duplex' mode.  *NOTE* TOT_UTIL_COMPUTED changes
   value for *EACH* record found!

   I hope this clears things up...