Date: Mon, 26 Mar 2007 13:02:47 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-chat@FreeBSD.ORG, deeptech71@gmail.com Subject: Re: 64bit timestamp Message-ID: <200703261102.l2QB2lKL008129@lurza.secnetix.de> In-Reply-To: <4606D88E.4080503@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
deeptech71@gmail.com wrote: > Oliver Fromme wrote: > > What's your problem? In your first mail you seemed to be > > complaining that there isn't sufficient range and accuracy > > in the time stamps. I explained to you that there is > > indeed more accuracy than you thought, and now you complain > > that there's too much of it? > > I am in not complaining. Just wanted to talk about something, it's > what freebsd-chat is for. I raised a topic, we started talking about > it. OK. it wasn't clear from your first mail what your actual intent was, and your comment sounded a bit unfriendly. > Let me rework my comment, to get the more real meaning of it: IMO, > that is redunant. (Don't you think so?) No, I don't think so. First of all, it's always desireable to have as much accuracy as possible, as long as the overhead for it is not prohibitively large. Second, the operating system should not make arbitrary assumptions about the accuracy requirements of any applications. Sure, there are certainly applications that don't care about one second more or less. But there are also applications that require high accuracy. For example, ntpd(8) requires a high precision of the system clock, while make(1) benefits from high precision of file time stamps. Therefore, applications should be able to get the accuracy they require, and not be limited by the operating system if possible. > > To answer your question: Modern hardware is already fast > > enough that sub-microsecond accuracy is required. Also > > keep in mind that it is undesirable to change the on-disk- > > format of a file system every year. When the UFS2 format > > was designed, it should be sufficient at least for the > > needs of ten years in the future, possibly even more. > > So the provision for nanosecond accuracy is not far off. > > Don't know if I'm right, but in the hardware used nowadays, the time > can change every several hundred nanoseconds. No, it can change within picoseconds. For example, the TSC counters in modern GHz processors increase several times per nanosecond (i.e. once every few hundred picoseconds), depending on their clock rate. > > Ideally, two consecutive, non-parallel operations should > > give two different timestamps. That applies to creating or > > touching a file or other kind of resource, or even just > > calling the gettimeofday() function from within the same > > thread, or whatever. In reality that isn't the case today > > for FreeBSD for other reasons, but the timestamp accuracy > > of UFS2 would certainly be sufficient for that. > > Actually, my intend wasn't to use it in filesystems, Well, you mentioned time stamps, so I assumed that they were your primary concern. > but server-client apps, such as games, where 32bit integer timers > must be restarted every 3 weeks I don't understand qwhat you're saying there. Why do they have to be restarted every three weeks? I don't see a reason for that. If an application (game or other, doesn't matter) requires time stamps with certain properties, then they should use appropriate types for it. If it doesn't, then it's a bug in that application. The operating system should only provide ways to retrieve sufficiently accurate time stamps. It's the responsibility of the applications to use and store them appropriately, according to their equirements. > Giorgos Keramidas wrote: > > On 2007-03-25 01:36, deeptech71@gmail.com wrote: > > > Oliver Fromme wrote: > > > > FreeBSD's UFS2 already uses 96bit timestamps, where 64 bits are used > > > > for seconds and 32 bits are used for nanoseconds. Is that sufficient > > > > for you? > > > What the hell for? > > > > ``Just because it can.'' > > Good. :] 2x64bit for x64? No, the file system has to be portable between different architectures, so the storage format must be the same on 32bit and 64bit architectures. > > Seriously now, please show some more respect to Oliver and the time he > > spent to research and write up a very informative reply. It's not very > > nice to post an original email like the one you posted, posing a > > relatively unintelligible question, and then reply ``what the hell > > for?'' to Oliver's email. At least *he* tried to find out something by > > reading the source, he wrote a reply with details pointers to places > > where you can find out more for yourself, and was enough of a gentleman > > to *avoid* using potentially offensive words. > > > > Let's be a little more cordial to the ones who help us, shall we? > > And I appreciate your hard work trying to help me. Perhaps my comment was > somewhat offensive. I appologize. OK, no problem. I was just a little confused what your actual intention was. Best regards Oliver PS: Giorgos, thanks for your help. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703261102.l2QB2lKL008129>