From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: Hugo Tyson Cc: borg@int.spb.ru, ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] cyg_ticks_to_timespec() Date: Thu, 19 Apr 2001 14:14:00 -0000 Message-id: <3ADF5517.476DB363@redhat.com> References: <003701c0c7dc$c95976f0$7601a8c0@borg> <3ADDEE7C.4D31174C@redhat.com> <200104191010.f3JAAdn10455@masala.cambridge.redhat.com> X-SW-Source: 2001-04/msg00226.html Hugo Tyson wrote: > > > From: Jonathan Larmour > > Oh, I get it now. The code in cyg_ticks_to_timespec() is using a clock > converter to convert to whole seconds, then subtracting to get the nS part > left over! No wonder it gives a "wrong" answer, of course the whole > seconds answer is rounded. > > Use it to convert to nS and do a divide by 10^9 - that way the right answer > would emerge, that's what clock converters are meant for. > > > tweak cyg_ticks_to_timespec to fix up the value if tv_nsec is negative. > > Before I do it, I just want to check my understanding that the convertors > > are doing the right thing by rounding not truncating. > > Of course they are. Someone misunderstood the purpose of the converters. > They do conversion taking care that overflow will be avoided at all costs, > even if it means discarding trailing digits; ie. they will be right at the > cost of precision even if the conversion factor is great in either > direction and the arguments are large. [snip] I've checked in something that just post-adjusts the timespec if the nanoseconds are negative. I believe this should produce consistent results because the sec_convertor and sec_invertor used by the clock convertors _should_ be the inverse of each other, and therefore conversion in one direction should always be the inverse mapping of the other. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine