Hmmm...our math is a bit different... A 1,000 RPM disk would take 1ms to spin around once (there are 1000ms in a second, correct?)
10,000 RPM would take .1ms. 7200 RPM would take .138ms And...if I reduce the buffer size to 1 byte I see this...around 2-3X of rotation time with the sleep enabled. fsync time: 0.00040 fsync time: 0.00033 fsync time: 0.00028 fsync time: 0.00027 fsync time: 0.00027 fsync time: 0.00058 fsync time: 0.00032 fsync time: 0.00042 fsync time: 0.00029 fsync time: 0.00035 fsync time: 0.00033 fsync time: 0.00030 fsync time: 0.00027 fsync time: 0.00027 Remove the sleep though and the times drop to .04ms which indicates the my fsync() is probably write cached. I'm a telecommuter so I can't check the BIOS settings on this particular box....but I'll bet it's write cached. I believe my original point stands...if your fsync() does nothing you'll see something close to zero all the time. Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Jay A. Kreibich [j...@kreibi.ch] Sent: Sunday, May 20, 2012 7:53 AM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] sqlite Commit C API On Sun, May 20, 2012 at 12:04:33PM +0000, Black, Michael (IS) scratched on the wall: > Another more indirect way to test is this utility: > > http://kerneltrap.org/mailarchive/linux-ext4/2009/3/22/5215824 > > Which...if your fsync doesn't work at all will return something really > close to zero. > > On my RedHat system I get this which indicates fsync actually takes a > little of time...therefore it must be doing something....although it > doesn't prove that it's actually on the disk yet. > > fsync time: 0.0022 > fsync time: 0.0019 > fsync time: 0.0019 > fsync time: 0.0022 > fsync time: 0.0019 > fsync time: 0.0019 > fsync time: 0.0020 > fsync time: 0.0020 Assuming this is spinning disk, that takes a *very* little amount of time... A 10K RPM disk takes about 6 ms to spin around once. A more conventional 7600 RPM drive takes 7.9 ms. Ignoring seek times, device I/O times, and all the rest, it should still take, on average, about half those times just for the right sector to come around underneath the heads. But that's just an average-- it should vary from write to write. I doubt sleep() is accurate enough to keep the program in sync with the spindle rotation over a full second. That doesn't seem to match the consistent, 2 ms times you're seeing. Both the low time, and the consistency of them, make me suspect of these numbers-- unless it is an SSD device. > And I do believe if you take the sleep() out of the loop that you should > see constant times. I would suspect that loop is faster than a disk rotation, so assuming there isn't much other I/O going on in the system, I would also expect to see somewhat more consistent times without the sleep(). > Otherwise you'll see a much bigger time once in a > while when you overrun the buffers and it has to pause to really flush. > > Again...on my system I see this...one value 3 times as large as the > others...suspicious. Yes... but not so much that one number is larger, as the fact that all the other numbers are consistently small. Of course, you can also see large changes in fsync() times if anything else on the system needs to do I/O. Again, assuming we're talking about spinning disk, if you have random I/O from other processes, you're going to see seeks and random rotation delays that should be even larger than this. -j > sort fsync.dat | tail -n 5 > fsync time: 0.0025 > fsync time: 0.0025 > fsync time: 0.0026 > fsync time: 0.0027 > fsync time: 0.0059 > -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
