search for: nanosecond

On systems using nanoseconds differences should be taken into consideration. --- a/generator.c 2014-06-14 01:05:08.000000000 +0200 +++ b/generator.c 2014-12-25 11:19:54.000000000 +0100 @@ -588,7 +588,13 @@ if (ignore_times) return 0; - return cmp_time(st->st_mtime, file->modtime) == 0; + return cmp_time(st->st...

On Thu, Dec 25, 2014 at 2:48 AM, Ingo Brückl <ib at wupperonline.de> wrote: > On systems using nanoseconds differences should be taken into > consideration. > The problem is that if you transfer from a filesystem that has nanoseconds to one that does not support it, rsync would consider most of the files to be constantly different, since the nanosecond values would only match if the source file...

Hi all, I'd like to output structured data for all of the gathered timers with the full nanosecond numbers to a file, say JSON for example. Does the timer infrastructure support this, or at least installing some custom print handlers? If not, does any of that sound like an interesting patch? David

...ptember 2014 13:48:38 Richard W.M. Jones wrote: > The existing APIs guestfs_stat, guestfs_lstat and guestfs_lstatlist > return a stat structure that contains atime, mtime and ctime fields > that store only the timestamp in seconds. > > Modern filesystems can store timestamps down to nanosecond > granularity, and the ordinary glibc stat(2) wrapper will return these > in "hidden" stat fields: > > struct timespec st_atim; /* Time of last access. */ > struct timespec st_mtim; /* Time of last modification. > */ struct timespec st_ctim;...

https://bugzilla.samba.org/show_bug.cgi?id=12742 Bug ID: 12742 Summary: a proposal: fix bogus nanosecond mtimes on transfer (patch included) Product: rsync Version: 3.1.1 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: core Assignee: wayned at samba.org...

I wrote on Fri, 02 Jan 2015 16:02:27 +0100: > --- a/generator.c 2014-06-14 01:05:08.000000000 +0200 > +++ b/generator.c 2015-01-02 15:50:30.000000000 +0100 > @@ -588,7 +588,14 @@ > if (ignore_times) > return 0; > - return cmp_time(st->st_mtime, file->modtime) == 0; > + return cmp_time(st->st_mtime, file->modtime) ==

On Wed 20 Jan 2016, Andrey Gursky wrote: > > I was just about to implement the same, since nanoseconds are taken > into account when transferring, thus making it obvious not to ignore Really? I thought the protocol only transmits seconds. Paul

Can anyone comment on the easiest way to get the PPS Kit kernel patch to work on a CentOS-5 system? I'd rather not use a plain vanilla kernel. http://www.kernel.org/pub/linux/daemons/ntp/PPS/

...strange in do_settime: x = (secs * 1000000000ULL) + (u64)nsecs - system_time_base; y = do_div(x, 1000000000); spin_lock(&wc_lock); wc_sec = _wc_sec = (u32)x; wc_nsec = _wc_nsec = (u32)y; spin_unlock(&wc_lock); The value "x" appears to be the number of nanoseconds, while the value "y" is the value in seconds. The assignments to wc_sec and wc_nsec seem backwards, though... I hope I''ve overlooked some detail, but just in case I am right here''s a patch to reverse the assignments. How did this ever work? Signed-off-by: Rik van R...

...rs, and I was trying to avoid any new issues if possible. But in my understanding, rsync 3.1.2 would have had the same problem here. This issue is in many ways similar to bug https://bugzilla.samba.org/show_bug.cgi?id=4977 and the like, and in this particular case is caused by files whose mtime nanoseconds exist on the filesystem and are broken. However, since there is a workaround to bypass a similar issue with symlinks, I believe we can do something about such files as well: with just a few broken timestamps on a large filesystem, it is very desirable to be able to avoid or suppress code 23 (...

...ba.org ReportedBy: antonio at dellelce.com QAContact: rsync-qa at samba.org tv_nsec field in stat structure is not used (source code I checked does not refer to it) if available. This results in files being not "completely" aligned because the original file will have nanoseconds set all other destinations have this portion of file information set to 0. A pratical example of when this might become a problem is Apache's ETag generation, Apache HTTPD correctly reads tv_nsec when available (Solaris,Cygwin have that feature for example) and puts the value of tv_nsec in t...

...fails: FLAC__TEST_LEVEL=1 FLAC__TEST_WITH_VALGRIND=no ./test_grabbag.sh ./test_grabbag.sh: line 39: 1N: value too great for base (error token is "1N") make[1]: *** [fullcheck] Error 1 make: *** [fullcheck] Error 2 The cause is that in test_grabbag.sh, line 39, it uses `date +%N` to get nanoseconds, which is unsupported on Mac OS X, and will produce just N instead of the nanoseconds. I am unable to find an equivalent in manpages yet. I wonder whether it is acceptable to use second instead? On Sun, May 26, 2013 at 11:00 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote: > On 26-05...

...hole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which is how Xen and VMI currently implement it. If the softlockup watchdog uses sched_clock() to measure time, it would automatically ignore stolen time, and therefore only report when the guest itself locked up. When running native, sched_clock() returns real-time nanoseconds, so the behaviou...

...hole system could have the CPU stolen from it for a long period of time. While it would be unlikely for a guest domain to be denied timer interrupts for over 10s, it could happen and any softlockup message would be completely spurious. Earlier I proposed that sched_clock() return time in unstolen nanoseconds, which is how Xen and VMI currently implement it. If the softlockup watchdog uses sched_clock() to measure time, it would automatically ignore stolen time, and therefore only report when the guest itself locked up. When running native, sched_clock() returns real-time nanoseconds, so the behaviou...

Apple File System Guide is released. https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/GeneralCharacteristics/GeneralCharacteristics.html >Nanosecond Timestamp Granularity > >APFS supports 1 nanosecond timestamp granularity, which improves >upon the 1 second timestamp granularity of HFS+. >Compatibility > >You can share APFS formatted volumes using the SMB network file >sharing protocol. The AFP protocol is deprecated and c...

...precision of timespec (which on 64 bit platforms is a 128 bit type). All file_time_type needs to model is the full range and precision of what the underlying file system libraries are capable of producing. The latest Linux file system is ext4 (https://en.wikipedia.org/wiki/Ext4) and is capable of nanosecond resolution. However its timestamp is only 64 bits. It has a range of approximately [1901-12-14, 2446-05-10]. Modeling ext4 would be a good design decision for libc++. libc++ could also model other file systems (Windows, macOS). All of these are based on 64 bit timestamps. Here is a file_clock,...

...library(microbenchmark) NN <- matrix(c(1, 2, 3, 4, 5, 6), nrow = 2, byrow = TRUE) # Example matrix lambda <- c(2, 3, 4) # Example vector colNN <- t(NN) microbenchmark( sweep = sweep(NN, 2, lambda, "/"), transpose = t(t(NN)/lambda), colNN = colNN/lambda ) Unit: nanoseconds expr min lq mean median uq max neval cld sweep 13817 14145 15115.06 14350 14657.5 75932 100 a transpose 1845 1927 2151.68 2132 2214.0 7093 100 b colNN 82 123 141.86 123 164.0 492 100 c Note that transpose is much faster than sweep...

Windows-32 has a time structure called FILETIME, a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC). That is not a typo, the year is 1601. Does anyone have a clue(or algorhithm)for how this is converted to something a little more POSIX-like ? Thank you, Derek -- Derek N. Eder Gothenburg University VINKLA - Vigilance and Neurocognition laboratory...

https://bugzilla.samba.org/show_bug.cgi?id=11521 Bug ID: 11521 Summary: rsync does not use high-resolution timestamps to determine file differences Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

...at gmail.com> >>>>> on Tue, 13 Mar 2018 10:12:55 -0700 writes: > FYI, in R devel (to become 3.5.0), there's isFALSE() which will cut > some corners compared to identical(): > > microbenchmark::microbenchmark(identical(FALSE, FALSE), isFALSE(FALSE)) > Unit: nanoseconds > expr min lq mean median uq max neval > identical(FALSE, FALSE) 984 1138 1694.13 1218.0 1337.5 13584 100 > isFALSE(FALSE) 713 761 1133.53 809.5 871.5 18619 100 > > microbenchmark::microbenchmark(identical(TRUE, FALSE), isFALSE(TRUE)...