X-Spam-Check-By: sourceware.org
From: "Hannu E K Nevalainen" <_garbage_collector_ AT telia DOT com>
To: <Cygwin AT cygwin DOT com>
Subject: RE: stat(2) triggers on-demand virus scan
Date: Sun, 15 Jan 2006 17:00:21 +0100
Message-ID: <JAEBIEIILHAGMJNFODIEGEFMCDAA._garbage_collector_@telia.com>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <43C986F2.4010900@earthlink.net>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

pmcferrin wrote:
> Here is something a little OT....
>
> When making comparisons between multiple runs to run timing tests
> before and after a change, it there a way I can guarantee more
> consistent results?  e.g. Condider the following:
>
> 	time find . -print | wc -l
>
> I can run the above sequence 3 times in a row and get huge
> differences due to OS caching and
> probably application caching (281 secs, 11 secs, 0.8 secs
> respectively).

 I ran my tests (earlier in this thread) so many times that I got consistent
timings - this gave the figures I presented. All interference from other
software eliminated/minimized; the only way I can think of getting
consistent run times. Adding anythng at all gives uncertainty and varying
figures. Your measurements will most likely differ, even to a great extent -
dependeing on how much "junk" (i.e. SW) you have installed.
I consider this to be a "best possible" state for running the test; one
can't get any better (i.e. shorter) run times without removing selected
utilities and services - degrading the usability of the machine in the
process.

This clearly shows one known weak side of general operating systems - most
of the time there is so much different things going on that you can't count
on any predefined completion time for a given task.
 This problem is addressed in RTOS'es and the like, and also is the subject
for research - e.g. some of the projects here
http://www.sics.se/cna/software.html I believe.

 When it comes to practical cygwin use, this run time inconsistency shows
even more
 - cygwin could be considered an OS (POSIX emulation) on top of another OS
(Win => ! Loose => Not Loose => Loose Nuts ;-).

>  Is there any known way within MS XP Pro to flush
> all caching other than a reboot??

Maybe CacheSet from sysinternals.com ?
 - http://www.sysinternals.com/Utilities/CacheSet.html
I have NOT tried it on XP, and thus can't recommend it in any way.
AFAIK it should mimic the functionality of the [vcache] section settings in
older windows WIN.INI file (or was it SYSTEM.INI?).

> I run
> into similar problems when validating multiple copies of a CD-R by
> calculating the checksum.  The first checksum is valid but I can't
> trust the remainder due to OS caching.

 You don't trust the OS to do cache handling correctly on CD-R's with
exactly the same contents, well what can I say - how would you distinguish
the difference between those CD-R's?

 Somewhere long ago I've read that when running CMD.EXE - hitting CTRL-C at
the prompt should "re-read disk info" for 'CWD' IIRC (this was a long time
ago; in the age of 3.5" diskettes) ... I dunno if this still is true.

How about; Insert and briefly access a different CD in between, making the
OS/fs aware of disk changes?

> -Paul
<SNIP>

/H
--


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/