On Thu, 10 Aug 2000, Guy Harris wrote:
> On Thu, Aug 10, 2000 at 08:23:24AM +0200, Uwe Girlich wrote:
> > It looks like in the protocol we have a 64 bit number which holds the number
> > seconds * 100000, which is good for 5 fraction digits. But to interpret
> > the lnglng overlaying 2 uint is an assumtion about the order of the 2 uint
> > in the guint64. It will work on little-endian systems only.
> >
> > The first timestamp (ts.lnglng / 100000L) should be obviously the number of
> > seconds (ctime() needs it so) but what is the second timestamp (ts.lng[0]).
> > From the following lines (hours = ...) it should probably be the originally
> > value ts.lnglng, because every following statement has its own division
> > by 100000.
>
> I'm suspicious of this; the Gryphon protocol is documented at
>
> http://www.dgtech.com/gryphon/docs/html/GCprotocol/
>
> and says, of the CMD_GET_TIME command the code in question dissects:
>
> Response data length is four bytes.
>
> TIME -- 8 bytes -- Timestamp, in units of .00001 sec. (Lower
> four bytes correspond to Gryphon Data Frame timestamp, upper
> four bytes add more significant bits.)
>
> I suspect "Response data length is four bytes." is the result of cutting
> and pasting without editing.
>
> By "more significant bits" I'd assume they provided higher resolution;
> given that elsewhere in the protocol time resolution is also .00001 sec,
> though, I suspect it really means "larger range".
>
> The sample output in the documentation for the "gryphrx" utility":
>
> http://www.dgtech.com/gryphon/docs/html/utils/gryphrx.html
>
> shows times with more than 32 bits of data, although they seem to show
> that as part of the header time stamp, which is only 32 bits wide.
>
> So I don't know what the heck is going on here - I'm CCing Steve
> Limkemann of Dearborn Technology Group, to see if he can explain this.
>
> > > (BTW, this indicates that we should provide "pntohll()" and "phtonll()"
> > > routines, and tvbuff versions of them, at least on platforms where we
> > > have "gint64" and "guint64".)
> > That would at least clean the first mentioned problem.
>
> I've checked that in.
>
I'm not sure what to respond to so I'll add my comments here. The
function resp_time() is called only to decode the response of the
CMD_GET_TIME command. CMD_GET_TIME used to return the standard Gryphon 4
byte timestamp. Application programmers here at DG wanted the ability to
relate the timestamp value, which also appears in other messages, to a
time and date. This was accomplished by changing the response of
CMD_GET_TIME to be 8 bytes.
As stated, this 8 byte value is in tens of microseconds (seconds times
100,000). The lower 4 byte value is the standard Gryphon timestamp which
is dealt with correctly by converting ts.lng[0]. There is an endian
problem with the union of ts.lng[] and ts.lnglng, however.
The conversion routine displays both the date and time derived from the
full 8 byte value and the Gryphon timestamp derived from only the lower 4
bytes.
gryphrx, and some other DG programs show the timestamp as microseconds
rather than tens of microseconds as a human interface concession. The
trailing zero is artificial in that it is supplied by the program, gryphrx
in this case.
I have been fixing some conversion bugs and adding new conversion code
to the plugin locally. I've been a bit busy and have not gotten around to
asking the ethereal team about how to roll my changes back into the
source. From my point of view, having write access to CVS would be ideal.
I could include a fix for the endian problem with my current version of
the plugin. I am not subscribed to any of the ethereal mailing lists and
I really don't have the time to keep up with any of them.
Steve
---
Steve Limkemann
Dearborn Group
(248) 488-2080 ext. 322
