On 28.05.2013 15:24, Tobias Bading wrote:
> On 28.05.2013 15:15, Philip Martin wrote:
>> Are you running some non-standard kernel?
>
> Depends on your definition of 'standard'. ;-)
> I'm using the default kernel linux-image-2.6.32-46-generic from the
Ubuntu Lucid repositories.
Harmless little joke... and that's when the real fun started...
I checked a few older build directories. One had these 16 timestamps:
2012-03-27 11:00:38.000594290 +0200
2012-03-27 11:00:38.020593756 +0200
2012-03-27 11:00:38.170593413 +0200
[...]
2012-03-27 11:00:38.780593824 +0200
2012-03-27 11:00:38.790594918 +0200
2012-03-27 11:00:38.830594476 +0200
I guess on March 27th last year, the world was still spinning at the
proper speed ;-). Next I checked my installation history in Synaptic
Package Manager to see what Ubuntu kernel I was running back then:
linux-image-2.6.32-39-generic. After installing and booting into this
kernel, I ran the '{ while true; do echo >t; ls --full-time t; rm t;
done; } | uniq' test again... take a guess... now I'm getting exactly
100 unique timestamps per second. WTF?!?? 'diff_tests.py 60' works just
fine now without patching svn_io_sleep_for_timestamps.
sysconf(_SC_CLK_TCK) returns 100 in both kernel versions, so the HZ
value shouldn't be the cause. I'll try to find the proper channels to
ask the Ubuntu kernel gurus for a comment. If anyone knows the proper
channels, please let me know.
Summary (or "What have I learned so far?"):
The "if (finfo.mtime % APR_USEC_PER_SEC)" block in
svn_io_sleep_for_timestamps seems a bit too simplistic. Even with the
100 timestamps per second I get now, sleeping just 1 millisecond might
not be enough if the following action is fast enough to use the same
timestamp as the last action prior to the short nap. Brane and Philip
already mentioned possible ways to implement this differently. Maybe you
could discuss this in the dev mailing list?
Kind regards & thanks for all the help,
Tobias
PS: I'll keep you updated regarding the kernel problem.
Received on 2013-05-29 13:57:23 CEST