Photoshop blur tool Vs expensive lenses

John Navas wrote:
> On Thu, 27 Dec 2007 09:19:27 GMT, "David J Taylor"
> <david-taylor DeleteThis @blueyonder.not-this-bit.nor-this-bit.co.uk> wrote in
> <z6Kcj.68527$c_1.35012@text.news.blueyonder.co.uk>:
>
>> John Navas wrote:
>> []
>>> Any good Windows defragger uses the Windows Defrag API to move
>>> files. The problem with this is that prior to Vista, Windows didn't
>>> have the concept of I/O priority.
>>
>> Eh? Have you looked at task scheduling and scheduler states in
>> Windows?
>
> What I wrote is well-documented by Microsoft; e.g.,
> <http://www.microsoft.com/technet/technetmag/issues/2007/02/VistaKernel/>
>
> While Windows has always supported prioritization of CPU usage, it
> hasn't included the concept of I/O priority. Without I/O priority,
> background activities like search indexing, virus scanning, and disk
> defragmenting can severely impact the responsiveness of foreground
> operations. A user launching an app or opening a document while
> another process is performing disk I/O, for example, experiences
> delays as the foreground task waits for disk access. The same
> interference also affects the streaming playback of multimedia
> content like songs from a hard disk.
>
> Windows Vista introduces two new types of I/O prioritization in
> order to help make foreground I/O operations get preference:
> priority on individual I/O operations and I/O bandwidth
> reservations. ...

Thanks for that pointer. It may explain one reason why I'm starting to
like Vista more the more I use it. I'm sure that a well-written defrag
program can take steps to alleviate such issues.


>>> Thus if a background defragger tells Windows
>>> XP to move a 4 GB file, which requires well over 100,000 reads and
>>> writes,
>>
>> so only 40KB per I/O operation? Wrong!
>
> 64 KB. Ibid:
>
> One final change in the I/O system worth mentioning relates to the
> size of I/O operations. Since the first version of Windows NT, the
> Memory Manager and the I/O system have limited the amount of data
> processed by an individual storage I/O request to 64KB. Thus, even
> if an application issues a much larger I/O request, it's broken into
> individual requests having a maximum size of 64KB. Each I/O incurs
> an overhead for transitions to kernel-mode and initiating an I/O
> transfer on the storage device, so in Windows Vista storage I/O
> request sizes are no longer capped. Several Windows Vista user-mode
> components have been modified to take advantage of the support for
> larger I/Os, including Explorer's copy functionality and the command
> prompt's Copy command, which now issue 1MB I/Os.

Precisely my point: 4GB in 64K chunks is 64K read and 64K write
operations, Not "over 100,000". Although perhaps you meant 128K total?
However, there are optimisations which can be done, at least on the read
operations, to reduce the overhead. Some of the device drivers, and even
the disk hardware can reduce the impact.

Thanks to the Vista pointers, though. It was either so long ago that I
had forgotten about them, or perhaps I never read about them in the first
place!

>>> the disk is going to be very busy for a long period of time no
>>> matter what the CPU priority of the background defragger task,
>>> severely impacting any foreground task that needs the same disk.
>>
>> Who says the defragger would want to move such a file in one
>> continuous operation. Maybe on such a large file it moves it in
>> chunks?
>
> No -- it's a limitation of the Windows Defrag API. Haven't you
> noticed how long it sometimes takes to pause or stop a defragger?

I've not looked in detail at the Defrag API. Of course, once again it
points you to having an understanding of what your system is doing - my
40GB daily throughput consists of files only up to about 30MB. If you
were editing large AVI files you might choose different options.

>>> This is part of why I personally prefer to run defrag as a scheduled
>>> task or screen saver utility. You can still be locked out of the
>>> disk for an extended period of time whenever a huge file is being
>>> moved, but the problem is much easier to avoid.
>>
>> This is highly system dependant. In my systems, even when the
>> screen-saver is running the background processing of the 40GB/day
>> throughput continues, so "defrag only during screen save" would be a
>> poor choice. A number of us have tested MST Defrag under these high
>> throughput conditions, and found that there is no perceptible
>> degradation during interactive operation, nor is there any
>> interference with the highly time sensitive continuous throughput.
>
> That's at odds with the review I posted, and with how the technology
> works. There is no magic.(c) Perhaps you're just not seeing the
> impact of very large files, or your I/O is spread over multiple
> drives. The impact is nonetheless real for any version of Windows
> prior to Vista (and Vista has its own performance issues).

Yes, the system is set up with multiple drives, to minimise performance
issues. And I don't have large files, just thousands of small ones!

Cheers,
David

On Thu, 27 Dec 2007 16:48:03 GMT, "David J Taylor"
<david-taylor.RemoveThis@blueyonder.not-this-bit.nor-this-bit.co.uk> wrote in
<7HQcj.68727$c_1.56284@text.news.blueyonder.co.uk>:

>John Navas wrote:
>[]
>> I mean that background defragging is problematic,
>> as the reviewer noted, and as I explain in another post:
>
>OK, but I haven't seen these issues.

I would agree that background defragging works well much of the time,
particularly if you don't normally manipulate huge multi-GB files (e.g.,
DVD images) like I do.

>> In fact it can be a big issue for defraggers, many of which perform
>> poorly (or not at all) with a low percentage of free space.
>>
>> There should be no significant impact of system performance as long as
>> the system doesn't run out of free disk space, so perhaps I don't
>> understand what you're saying.
>
>It's good practice - keeping the disk 70% full can reduce the likelihood
>of fragmentation in the first place, although it's OS dependant.

I'd say it's more dependent on file creation and deletion patterns, and
on how well applications are written. Much fragmentation occurs when
applications do a poor job of initial file sizing, for which there is no
real solution other than defragging.

--
Best regards,
John Navas
Panasonic DMC-FZ8 (and several others)