From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <309c101f23bbb6ec6a92b2bf1c525fd7@brasstown.quanstro.net>
References: <309c101f23bbb6ec6a92b2bf1c525fd7@brasstown.quanstro.net>
Date: Fri, 20 May 2011 03:43:31 -0700
Message-ID: <BANLkTimDdG3MnLejCBdJA+Cg-OjUOEK_0g@mail.gmail.com>
From: ron minnich <rminnich@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [9fans] a pair nec bugs
Topicbox-Message-UUID: e761b27a-ead6-11e9-9d60-3106f5b1d025

I think the growing complexity of nsec() shows that the file model
doesn't work in all cases ... the thing starts to look a bit overly
complex to me. The fact that it fails due to the size of a static fd
array is also a warning flag.

I think a better interface would be one in which you read two variables:
/dev/nsecoffset
/dev/nsecdivisor

You could then apply these to the output of cycles():
nsec = (cycles()/divisor)-offset

to get time.

nsec gives you precision but dropping into a system call to read time
tosses away any hope of accuracy you might achieve. Simply put, nsec()
is not correctly named :-)

ron