On 28.05.2013 12:54, Philip Martin wrote:
Tobias Bading<tbad...@web.de> writes:
On 27.05.2013 16:12, Tobias Bading wrote:
On 27.05.2013 16:01, Branko Čibej wrote:
Can you try this: run the following command for a couple of seconds, it
should give you an idea about the system clock precision.
{ while true; do date '+%M:%S.%N'; done; } | uniq
Redirected to a file, I get about 1250 unique timestamps per second, nicely
distributed it seems.
Hmm... a modified version of your command paints a completely different picture:
{ while true; do touch t; ls -l --full-time t; done; } | uniq
prints exactly *two* lines per second, one every 0.5 second, exact down to the
millisecond.
No idea why yet, but this explaines everything I guess. Asking Google...
An earlier mail showed us that you are using ext4 on OSX -- does OSX
have native support for ext4 now or are you using a 3rd party driver?
Sounds like a misunderstanding. On Saturday, I compiled Subversion 1.8
RC2 at home on my MacBook to check whether I could reproduce the problem
on a different platform. I couldn't, "make check" worked fine on Snow
Leopard (on a HFS+ disk).
On my Ubuntu Lucid machine at work, the problem persists on an ext4
partition.
Subversion assumes that a sub-second timestamp implies at least a
millisecond resolution but that is not the case on your ext4 filesystem.
I'm not sure where exactly the source of the problem is. So far I know:
a) 'touch -d "2013-05-27 14:27:35.069850993" t ; ls --full-time t' works
fine and shows the file's timestamp 100% correct to the nanosecond.
b) '{ while true; do echo "" >t; ls -l --full-time t; rm t; done; } |
uniq' prints exactly *two* lines per second, one every 0.5 seconds,
exact down to the millisecond.
No matter whether the test under b) uses touch or creates a new file
every time, I only get two different timestamps each second. I didn't
find an explanation via Google yet. Someone suggested that the ext4
implementation might use a cached kernel time and that time is only
updated at certain timer intervals.
We would need to modify the sleep algorithm if we are to support this
filesystem.
We could modify the sleep calculation to something like:
if timestamp has sub 1ms component
sleep for 1ms
else if timestamp has sub 10ms component
sleep for 10ms
else if timestamp has sub 100ms component
sleep for 100ms
else
sleep for 1s
or perhaps do it in base 2 rather than base 10?
From what I googled so far there doesn't seem to be a reliable way to
determine the timestamp resolution of a filesystem. And as my kind of
spooky case shows, there seem to be other dark forces at work as well... ;-)
