Re:Re:Re: FddiTime (Time and Time again)

[Pablo Brenner <[e-mail]>]

> From imp!uunet!CS.UTK.EDU!owner-fddi-mib Wed Jul 29 07:37:14 1992
> Return-Path: <imp!uunet!CS.UTK.EDU!owner-fddi-mib>
> Received: from imp.UUCP by FibHaifa.com (4.1/SMI-4.1)
> 	id AA20040; Wed, 29 Jul 92 07:37:14 IDT
> Received: by imp.HellNet.org (/\==/\ Smail3.1.21.1 #21.8)
> 	id <[e-mail]>; Wed, 29 Jul 92 05:23 IDT
> Received: from CS.UTK.EDU by relay2.UU.NET with SMTP 
> 	(5.61/UUNET-internet-primary) id AA13791; Tue, 28 Jul 92 17:19:07 -0400
> Received:  by CS.UTK.EDU (5.61++/2.8s-UTK)
> 	id AA01417; Tue, 28 Jul 92 16:38:13 -0400
> Received: from relay1.UU.NET by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK)
> 	id AA01302; Tue, 28 Jul 92 16:35:46 -0400
> Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP 
> 	(5.61/UUNET-internet-primary) id AA22487; Tue, 28 Jul 92 16:34:01 -0400
> Date: Tue, 28 Jul 92 16:34:00 -0400
> From: imp!uunet!dsiinc!rem
> Message-Id: <[e-mail]>
> Received: from dsiinc.UUCP by uunet.uu.net with UUCP/RMAIL
> 	(queueing-rmail) id 161755.28894; Tue, 28 Jul 1992 16:17:55 EDT
> To: [e-mail]
> Subject: Re:Re:Re: FddiTime (Time and Time again)
> Content-Type: text
> Content-Length: 5426
> Status: RO
> 
> After seeing this discussion going in circles, I'm sorry I brought 
> the whole thing issue!  :-)
> 
> I'd like get past this, but I don't think I've seen consensus for 
> ANY proposal yet.  I don't think this is that important of an issue,
> and am surprised it's taking this long to resolve.
> 
> SMT currently uses three types for representing time:
> 
>     A.  FddiTimeStamp - 64-bit integer : semantics of 80 ns units.
> 
>     B.  FddiTime - 32 bit integer : semantics of 80 ns units.
> 
>     C.  FddiTimerTwosComplement - 32 bit integer: semantics of unsigned 
> 	    twos complement 80 ns units.
> 
> To simplify things in rfc-1285, we omitted all FddiTimeStamp variables
> and converted FddiTimerTwosComplement types to FddiTime.  
> For the new mapping, the idea is to restor the FddiTimeStamp variables
> and nail down a good representation for the other two types.
> As I understand the discussion, the new mappings fall
> into the following categories:
> 
>     1.  FddiTimeStamp:  There seems to be only one proposed encoding:
> 
> 	A.  OCTET STRING (SIZE (8)), with semantics indicating that
> 	    it is really a 64-bit INTEGER, encoded in network order.
> 	    The real concern is that everyone encodes (and decodes) 
> 	    the same way.  No one seems to care that these are not
> 	    in microsecond resolution.
> 
> 
>     2.  FddiTime:  There are two proposed encoding rules:
> 
> 	A.  INTEGER, with semantics of 80 ns units.
> 	    Advantage:  Most closely matches SMT.
> 	    Disadvantage:  Values with high bit set may show up on "dumb" 
> 	        manager stations a negative.  This is not a problem, since 
> 		there are only a few variables that use this encoding and 
> 		they typically won't need anything in that range.
> 		
> 	B.  INTEGER, with semantics of 1 microsecond units. 
> 	    Advantage:  Easier to read on management stations.  No
> 	        problem representing large values.
> 	    Disadvantage:  Loss of resolution.  It would be impossible
> 		to specify exact timer values as the minimum resolution
> 		of the 1 microsecond timer would be (12.5) 80 ns units.
> 
> 
>     3.  FddiTimerTwosComplement:  There are at least three proposed encodings:
> 
> 	A.  INTEGER, with semantics of unsigned twos complement 80 ns units.
> 	    Advantage:  Most closely matches SMT.
> 	    Disadvantage:  Almost every value will have its high bit
> 	        set.  "Dumb" managers will always display negative numbers.  
> 		"Hard" to convert to format non-FDDI people understand.
> 
> 	B.  INTEGER, with semantics of 1 microsecond units. 
> 	    Advantage:  Easier to read on management stations.  No
> 	        problem representing large values.
> 	    Disadvantage:  Loss of resolution.  It would be impossible
> 		to specify exact timer values as the minimum resolution
> 		of the 1 microsecond timer would be (12.5) 80 ns units.
> 		Potential confusion for people who understand FDDI 
> 		networks and who are using management station to
> 		diagnose problems.
> 
> 	C.  OCTET STRING (SIZE (4)), as with FddiTimeStamp
> 	    with semantics of either 80 ns units or unsigned
> 	    twos-complement units.  
> 	    Advantage:  Gets around the "negative" number issue.
> 	    Disadvantage:  Hexs strings may be harder to convert.
> 	
> I agree with James Reeves (Synoptics) that, if possible, the encodings
> should match SMT as closely as possible.  There is no point in trying
> to second guess ANSI and try to determine a "new, improved" encoding when
> the ones we have are sufficient.  I don't understand why people (or
> SNMP managers) who don't understand FDDI will care what form the numbers 
> are in, as they would have no meaning to them in any form.  The people 
> (or SNMP managers) that do understand FDDI will have to understand
> whatever format we decide on, so it doesn't really matter to them.
> All the conversions we are talking about are simple 1-line conversions.  
> This is not rocket science.
> 
>     80 ns -> microsecond		: (number / 12.5)
>     uns. two comp. 80 ns -> microsecond	: ((~number + 1) / 12.5)
> 
> The other reason why I'm opposed to this is that we haven't yet
> addressed the other issues, and I'd hate to specify something
> (with the intent of making it more friendly) that actually makes
> FDDI harder to manage.  Are we sure the loss of resolution going
> from 80 ns units to microseconds is acceptable in all cases?  
> I'm not trying to make a major issue, but people designing real-time,
> large, or high utilization networks will not have the ability to
> set hardware timers with as much accuracy as they can with SMT.
> 
> If we switch to microseconds, there is no way to exactly represent the 
> values commonly used by the hardware.  Unless someone wants to tell me 
> why that a resolution of 12.5-byte clocks is never important in 
> synchronous or priory transmission, I don't see how we can justify 
> the conversion.
> 
> In summary, my opinion is that since we can't seem to decide, the best 
> thing we could do is represent everything as closely as possible to the
> SMT format as possible and move on to the next issue.  
> 
> Thus, for the vote counters, I vote for:
> 
>     FddiTimeStamp encoded as OCTET STRING (size (8)) representing 80 ns units.
> 
>     FddiTime encoded as INTEGER that represents 80 ns units.
> 
>     FddiTimerTwosComplement encoded as INTEGER that represents
> 	unsigned twos complement 80 ns units, regardless of the fact 
> 	that with "dumb" managers it will appear as a negative number.
> 
> Ron Mackey			Distributed Systems International, Inc.
> [e-mail]			531 W. Roosevelt Road, Suite 2
> 708-665-4639			Wheaton, IL 60187-5057
> 

Agree with Ron,
	from my experience: the only people that look at these values are
people who DO understand FDDI, and are trying to tune or diagnose a network,
in the case of network diagnosis the resolution (and more important the
option of identifying these values when looking on an FDDI analyzer) are 
extremely important.
"Dumb" managers who don't understand FDDI have nothing to look there!

--Pablo
--------------------------------------------------------------
Pablo Brenner
R&D Dept.
Fibronics Ltd., Matam Industrial Park, Haifa 31905, ISRAEL
phones: [phone]            Fax: [phone]
e-mail: [e-mail]   or  [e-mail]
Wireless: CX5YI/4X
---------------------------------------------------------------
=============== Usual disclaimers apply =======================