A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » General XP issues or comments
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Computer activity



 
 
Thread Tools Display Modes
  #1  
Old June 2nd 20, 03:55 PM posted to microsoft.public.windowsxp.general
KenK
external usenet poster
 
Posts: 444
Default Computer activity

Anyone have any idea what the computer is doing so actively when you aren't
using it? I often see the activity light flickering but have no idea what
it's doing. Sometimes no light activity.

TIA


--
I love a good meal! That's why I don't cook.






Ads
  #2  
Old June 2nd 20, 08:53 PM posted to microsoft.public.windowsxp.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Computer activity

KenK wrote:
Anyone have any idea what the computer is doing so actively when you aren't
using it? I often see the activity light flickering but have no idea what
it's doing. Sometimes no light activity.

TIA


That's the defragmenter running, and moving around prefetch
files or something. If you move the mouse, or attempt to investigate,
the defragmenter will frequently exit so you can't see what it's doing.
It doesn't exit immediately - that activity light can stay illuminated
for 30 seconds or so, after you try to get into the OS.

You might watch it with ProcMon (Process Monitor, Sysinternals), if
you want to see what it's doing. At the time, that's what I used
to verify what sector addresses it was using.

The prefetch movement thing can get into a loop. I could hear
a slight "singing" noise coming from my previous hard drive,
and the defragmenter doing the file moves, was moving the
same sectors to the same place, a "local minima" in the algorithm.
Just moving some files around a bit, affects the maths enough
that it stops pounding on that item. The program did not realize
that reading from sector 1234 and writing the stuff back to
sector 1234, was pointless. And done at high speed, it makes
the drive "sing". Moving a few files around, is sufficient
to have it read from 1234 and write to 5678, and that breaks
the loop and eventually it will stop when it's "satisfied".

The company who wrote the WinXP defragmenter is "President Software"
or such. There might be some Wiki info on it. The defragmenter was
not written by Microsoft. Whereas I suspect Microsoft wrote the
defragmenter on the Vista+ ones, as the defragmenter is much more
practical and not a "showoff". The Vista+ versions focus on "performance"
and are not a beauty contest like a commercial defragmenter is.
That's why the Microsoft defragmenter finishes before a commercial
one would. No shoeshine. But back in the WinXP era, Microsoft
contracted that part out, so the result has commercial quality
behavior, including a prefetch shoeshine without you knowing
what is running. And that makes the LED come on.

Paul
  #3  
Old June 3rd 20, 12:53 AM posted to microsoft.public.windowsxp.general
Apd
external usenet poster
 
Posts: 132
Default Computer activity

"KenK" wrote:
Anyone have any idea what the computer is doing so actively when you aren't
using it? I often see the activity light flickering but have no idea what
it's doing. Sometimes no light activity.


I will depend on what software is installed, what services are running
and what tasks (if any) are scheduled. Everyone's system is different.
Mine does nothing when I'm not using it.

What's this "activity light" - disk, network, something else?


  #4  
Old June 3rd 20, 10:51 AM posted to microsoft.public.windowsxp.general
Andy[_16_]
external usenet poster
 
Posts: 337
Default Computer activity

On Tuesday, June 2, 2020 at 2:54:00 PM UTC-5, Paul wrote:
KenK wrote:
Anyone have any idea what the computer is doing so actively when you aren't
using it? I often see the activity light flickering but have no idea what
it's doing. Sometimes no light activity.

TIA


That's the defragmenter running, and moving around prefetch
files or something. If you move the mouse, or attempt to investigate,
the defragmenter will frequently exit so you can't see what it's doing.
It doesn't exit immediately - that activity light can stay illuminated
for 30 seconds or so, after you try to get into the OS.

You might watch it with ProcMon (Process Monitor, Sysinternals), if
you want to see what it's doing. At the time, that's what I used
to verify what sector addresses it was using.

The prefetch movement thing can get into a loop. I could hear
a slight "singing" noise coming from my previous hard drive,
and the defragmenter doing the file moves, was moving the
same sectors to the same place, a "local minima" in the algorithm.
Just moving some files around a bit, affects the maths enough
that it stops pounding on that item. The program did not realize
that reading from sector 1234 and writing the stuff back to
sector 1234, was pointless. And done at high speed, it makes
the drive "sing". Moving a few files around, is sufficient
to have it read from 1234 and write to 5678, and that breaks
the loop and eventually it will stop when it's "satisfied".

The company who wrote the WinXP defragmenter is "President Software"
or such. There might be some Wiki info on it. The defragmenter was
not written by Microsoft. Whereas I suspect Microsoft wrote the
defragmenter on the Vista+ ones, as the defragmenter is much more
practical and not a "showoff". The Vista+ versions focus on "performance"
and are not a beauty contest like a commercial defragmenter is.
That's why the Microsoft defragmenter finishes before a commercial
one would. No shoeshine. But back in the WinXP era, Microsoft
contracted that part out, so the result has commercial quality
behavior, including a prefetch shoeshine without you knowing
what is running. And that makes the LED come on.

Paul


I am surprised Windows does not use a better file system like ext3 or ext4.

Neither require defragmenting.

Andy
  #5  
Old June 3rd 20, 11:40 AM posted to microsoft.public.windowsxp.general
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Computer activity

Andy wrote:
On Tuesday, June 2, 2020 at 2:54:00 PM UTC-5, Paul wrote:
KenK wrote:
Anyone have any idea what the computer is doing so actively when you aren't
using it? I often see the activity light flickering but have no idea what
it's doing. Sometimes no light activity.

TIA

That's the defragmenter running, and moving around prefetch
files or something. If you move the mouse, or attempt to investigate,
the defragmenter will frequently exit so you can't see what it's doing.
It doesn't exit immediately - that activity light can stay illuminated
for 30 seconds or so, after you try to get into the OS.

You might watch it with ProcMon (Process Monitor, Sysinternals), if
you want to see what it's doing. At the time, that's what I used
to verify what sector addresses it was using.

The prefetch movement thing can get into a loop. I could hear
a slight "singing" noise coming from my previous hard drive,
and the defragmenter doing the file moves, was moving the
same sectors to the same place, a "local minima" in the algorithm.
Just moving some files around a bit, affects the maths enough
that it stops pounding on that item. The program did not realize
that reading from sector 1234 and writing the stuff back to
sector 1234, was pointless. And done at high speed, it makes
the drive "sing". Moving a few files around, is sufficient
to have it read from 1234 and write to 5678, and that breaks
the loop and eventually it will stop when it's "satisfied".

The company who wrote the WinXP defragmenter is "President Software"
or such. There might be some Wiki info on it. The defragmenter was
not written by Microsoft. Whereas I suspect Microsoft wrote the
defragmenter on the Vista+ ones, as the defragmenter is much more
practical and not a "showoff". The Vista+ versions focus on "performance"
and are not a beauty contest like a commercial defragmenter is.
That's why the Microsoft defragmenter finishes before a commercial
one would. No shoeshine. But back in the WinXP era, Microsoft
contracted that part out, so the result has commercial quality
behavior, including a prefetch shoeshine without you knowing
what is running. And that makes the LED come on.

Paul


I am surprised Windows does not use a better file system like ext3 or ext4.

Neither require defragmenting.

Andy


This particular activity I'm referring to, is the pre-positioning of
files. Rather than defragmentation. The .pf files are used somehow,
to keep track of what needs doing.

The defragmenter is rather useless, because it does not defragment
white space, and there is a tendency for a freshly defragmented
volume, to fragment again.

Consequently, you "don't do it that way".

I remember one time, trying out the built-in defragmenter, and
it was still running the next morning (eight hours later). I said
to myself "I can do better than this", and I came up with a method
which could prepare a file system, in about half an hour, no matter
what state it was in. And that didn't use a defragmenter. It used
Robocopy instead.

Now, if we fast forward a bit, and look at Windows 10, for the
most part, that does not need user attention. It uses a lightweight
defragmenter, which can be scheduled by the OS, so that you hardly
ever see it. It leaves gaps between files. It doesn't pack
the files shoulder to shoulder. It does *not* defragment any
file larger than 50MB or so (those don't need to be defragmented).

If you were using a Windows 10 machine today, the topic would hardly
come up.

There are ways you can chew the **** out of a file system, in
Windows 10, but you have to put your mind to it. Just the
other day, I managed to make a 17% fragmented volume, and rather
than defragmenting it the long way, I just repaved the volume
using Macrium. Macrium will do some amount of defrag, during
a Restore operation, if you modify the partition size a tiny bit.
The Restoration mode changes to a kind of file by file operation,
and the image restored has close to zero fragmentation.
The result is not guaranteed in any way, and no documentation
refers to this behavior.

That's one reason you don't keep your movie collection on C:
with the OS. By separating your data collection from the OS,
it allows the occasional backup or cleanup to take place,
without involving gobs of unrelated data. You can do a backup
in less than ten minutes, do a restore in less than ten minutes.

EXT4 is good on hard drives. But, it represents extra wear on
flash based storage, due to the additional journal writes.
You can see this when Macrium backs up an EXT4 partition, and
the backup file is larger than the file set - the extra space is
overhead in the file system. I use nothing but EXT4 for Linux
on hard drives, because rotating disks don't care about stuff like that.

Most of the SSDs here, are for Windows, where the extra speed
is needed to make up for the bad hygiene (Windows Defender scanning,
indexing and so on). WinXP is still on hard drives. Linux is on
hard drives.

Paul
  #6  
Old June 3rd 20, 11:53 AM posted to microsoft.public.windowsxp.general
J. P. Gilliver (John)[_7_]
external usenet poster
 
Posts: 603
Default Computer activity

On Wed, 3 Jun 2020 at 02:51:28, Andy wrote:
[]
I am surprised Windows does not use a better file system like ext3 or ext4.

Neither require defragmenting.

Andy


I occasionally see such claims (can't comment on which FS).

I fail to understand how _any_ file system can not _require_
defragmenting - unless it does not allow fragmenting in the first place
(like the BBC "DFS"), which then needs "compacting" from time to time.
(I also cannot see how such a FS can _handle_ a situation where two or
more files are being written at once, e. g. a logging and a recording.)

I'm willing to have it explained to me, though.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)[email protected]+H+Sh0!:`)DNAf

Quantum particles: the dreams that stuff is made of - David Moser
  #7  
Old June 3rd 20, 02:48 PM posted to microsoft.public.windowsxp.general
Andy[_16_]
external usenet poster
 
Posts: 337
Default Computer activity

On Wednesday, June 3, 2020 at 5:40:34 AM UTC-5, Paul wrote:
Andy wrote:
On Tuesday, June 2, 2020 at 2:54:00 PM UTC-5, Paul wrote:
KenK wrote:
Anyone have any idea what the computer is doing so actively when you aren't
using it? I often see the activity light flickering but have no idea what
it's doing. Sometimes no light activity.

TIA
That's the defragmenter running, and moving around prefetch
files or something. If you move the mouse, or attempt to investigate,
the defragmenter will frequently exit so you can't see what it's doing.
It doesn't exit immediately - that activity light can stay illuminated
for 30 seconds or so, after you try to get into the OS.

You might watch it with ProcMon (Process Monitor, Sysinternals), if
you want to see what it's doing. At the time, that's what I used
to verify what sector addresses it was using.

The prefetch movement thing can get into a loop. I could hear
a slight "singing" noise coming from my previous hard drive,
and the defragmenter doing the file moves, was moving the
same sectors to the same place, a "local minima" in the algorithm.
Just moving some files around a bit, affects the maths enough
that it stops pounding on that item. The program did not realize
that reading from sector 1234 and writing the stuff back to
sector 1234, was pointless. And done at high speed, it makes
the drive "sing". Moving a few files around, is sufficient
to have it read from 1234 and write to 5678, and that breaks
the loop and eventually it will stop when it's "satisfied".

The company who wrote the WinXP defragmenter is "President Software"
or such. There might be some Wiki info on it. The defragmenter was
not written by Microsoft. Whereas I suspect Microsoft wrote the
defragmenter on the Vista+ ones, as the defragmenter is much more
practical and not a "showoff". The Vista+ versions focus on "performance"
and are not a beauty contest like a commercial defragmenter is.
That's why the Microsoft defragmenter finishes before a commercial
one would. No shoeshine. But back in the WinXP era, Microsoft
contracted that part out, so the result has commercial quality
behavior, including a prefetch shoeshine without you knowing
what is running. And that makes the LED come on.

Paul


I am surprised Windows does not use a better file system like ext3 or ext4.

Neither require defragmenting.

Andy


This particular activity I'm referring to, is the pre-positioning of
files. Rather than defragmentation. The .pf files are used somehow,
to keep track of what needs doing.

The defragmenter is rather useless, because it does not defragment
white space, and there is a tendency for a freshly defragmented
volume, to fragment again.

Consequently, you "don't do it that way".

I remember one time, trying out the built-in defragmenter, and
it was still running the next morning (eight hours later). I said
to myself "I can do better than this", and I came up with a method
which could prepare a file system, in about half an hour, no matter
what state it was in. And that didn't use a defragmenter. It used
Robocopy instead.

Now, if we fast forward a bit, and look at Windows 10, for the
most part, that does not need user attention. It uses a lightweight
defragmenter, which can be scheduled by the OS, so that you hardly
ever see it. It leaves gaps between files. It doesn't pack
the files shoulder to shoulder. It does *not* defragment any
file larger than 50MB or so (those don't need to be defragmented).

If you were using a Windows 10 machine today, the topic would hardly
come up.

There are ways you can chew the **** out of a file system, in
Windows 10, but you have to put your mind to it. Just the
other day, I managed to make a 17% fragmented volume, and rather
than defragmenting it the long way, I just repaved the volume
using Macrium. Macrium will do some amount of defrag, during
a Restore operation, if you modify the partition size a tiny bit.
The Restoration mode changes to a kind of file by file operation,
and the image restored has close to zero fragmentation.
The result is not guaranteed in any way, and no documentation
refers to this behavior.

That's one reason you don't keep your movie collection on C:
with the OS. By separating your data collection from the OS,
it allows the occasional backup or cleanup to take place,
without involving gobs of unrelated data. You can do a backup
in less than ten minutes, do a restore in less than ten minutes.

EXT4 is good on hard drives. But, it represents extra wear on
flash based storage, due to the additional journal writes.
You can see this when Macrium backs up an EXT4 partition, and
the backup file is larger than the file set - the extra space is
overhead in the file system. I use nothing but EXT4 for Linux
on hard drives, because rotating disks don't care about stuff like that.

Most of the SSDs here, are for Windows, where the extra speed
is needed to make up for the bad hygiene (Windows Defender scanning,
indexing and so on). WinXP is still on hard drives. Linux is on
hard drives.

Paul


Thanks for all the useful info.

I found this too.

https://docs.microsoft.com/en-us/arc...r-windows-refs

Andy
  #8  
Old June 3rd 20, 02:50 PM posted to microsoft.public.windowsxp.general
Andy[_16_]
external usenet poster
 
Posts: 337
Default Computer activity

On Wednesday, June 3, 2020 at 5:54:31 AM UTC-5, J. P. Gilliver (John) wrote:
On Wed, 3 Jun 2020 at 02:51:28, Andy wrote:
[]
I am surprised Windows does not use a better file system like ext3 or ext4.

Neither require defragmenting.

Andy


I occasionally see such claims (can't comment on which FS).

I fail to understand how _any_ file system can not _require_
defragmenting - unless it does not allow fragmenting in the first place
(like the BBC "DFS"), which then needs "compacting" from time to time.
(I also cannot see how such a FS can _handle_ a situation where two or
more files are being written at once, e. g. a logging and a recording.)

I'm willing to have it explained to me, though.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)[email protected]+H+Sh0!:`)DNAf

Quantum particles: the dreams that stuff is made of - David Moser


File systems are rather complex.

Way beyond my understanding.

Andy
  #9  
Old June 3rd 20, 06:56 PM posted to microsoft.public.windowsxp.general
JJ[_11_]
external usenet poster
 
Posts: 744
Default Computer activity

On Wed, 3 Jun 2020 11:53:58 +0100, J. P. Gilliver (John) wrote:
On Wed, 3 Jun 2020 at 02:51:28, Andy wrote:
[]
I am surprised Windows does not use a better file system like ext3 or ext4.

Neither require defragmenting.

Andy


I occasionally see such claims (can't comment on which FS).

I fail to understand how _any_ file system can not _require_
defragmenting - unless it does not allow fragmenting in the first place
(like the BBC "DFS"), which then needs "compacting" from time to time.
(I also cannot see how such a FS can _handle_ a situation where two or
more files are being written at once, e. g. a logging and a recording.)

I'm willing to have it explained to me, though.


It's an exaggeration of Ext#, IMO.

Ext# file systems can actually be fragmented. What makes them seem to never
need a defragmenter is mainly because of how Ext# driver/handler manages the
file systems. Mainly it's because of these two things.

1. Ext# driver/handler always try to allocate non fragmented clusters for a
newly created file.

2. Ext# driver/handler has an automatic file relocator feature (not to be
confused with file defragmenter). If file appending process would end up
fragmenting the file (i.e. because the following cluster is already used),
the file will be relocated to somewhere else where the following clusters is
large enough to fit the appended data, then the appended data is written.
So, the file never get into a fragmented state.

In #1, when there's enough disk free space but not enough free space
fragments, e.g. new file size is 80MB, disk free space is 100MB in two free
space fragments: 60MB and 40MB; #2 will kick in to extend a free space
fragment to large enough size to hold the new file. In this case, #2 does
not defragment files, but relocate files. However, it _does_ defragment the
free space. However, linux users seem to consider the term "defragment" is
only applicable for files.

That being said, _all_ (built in) Windows file system drivers are still
worse than Ext# in terms of fragmentation - where sometimes (if not, in most
cases), _deliberately_ fragment newly created files even though there is
enough free space fragment to hold the new files without fragmentation, and
even though no other process (not even the system) is using the disk to
write something.
  #10  
Old June 3rd 20, 10:39 PM posted to microsoft.public.windowsxp.general
J. P. Gilliver (John)[_7_]
external usenet poster
 
Posts: 603
Default Computer activity

On Thu, 4 Jun 2020 at 00:56:59, JJ wrote:
On Wed, 3 Jun 2020 11:53:58 +0100, J. P. Gilliver (John) wrote:
On Wed, 3 Jun 2020 at 02:51:28, Andy wrote:
[]
I am surprised Windows does not use a better file system like ext3 or ext4.

Neither require defragmenting.

Andy


I occasionally see such claims (can't comment on which FS).

I fail to understand how _any_ file system can not _require_
defragmenting - unless it does not allow fragmenting in the first place
(like the BBC "DFS"), which then needs "compacting" from time to time.
(I also cannot see how such a FS can _handle_ a situation where two or
more files are being written at once, e. g. a logging and a recording.)

I'm willing to have it explained to me, though.


It's an exaggeration of Ext#, IMO.


Thanks for the explanations. Yes, I agree the claims are exaggerated.

Ext# file systems can actually be fragmented. What makes them seem to never
need a defragmenter is mainly because of how Ext# driver/handler manages the
file systems. Mainly it's because of these two things.

1. Ext# driver/handler always try to allocate non fragmented clusters for a
newly created file.


Fine if you know how big the file is going to be when you open it.

2. Ext# driver/handler has an automatic file relocator feature (not to be
confused with file defragmenter). If file appending process would end up
fragmenting the file (i.e. because the following cluster is already used),
the file will be relocated to somewhere else where the following clusters is
large enough to fit the appended data, then the appended data is written.
So, the file never get into a fragmented state.


So there'll be a sudden pause while the file-so-far is suddenly moved.

In #1, when there's enough disk free space but not enough free space
fragments, e.g. new file size is 80MB, disk free space is 100MB in two free
space fragments: 60MB and 40MB; #2 will kick in to extend a free space
fragment to large enough size to hold the new file. In this case, #2 does
not defragment files, but relocate files. However, it _does_ defragment the
free space. However, linux users seem to consider the term "defragment" is
only applicable for files.


So it moves the file(s) that are between the two free space blocks.
Again, sudden pause while it does so.

That being said, _all_ (built in) Windows file system drivers are still
worse than Ext# in terms of fragmentation - where sometimes (if not, in most
cases), _deliberately_ fragment newly created files even though there is
enough free space fragment to hold the new files without fragmentation, and
even though no other process (not even the system) is using the disk to
write something.


If I understand you rightly, "deliberately" is overstating the case a
teeny bit: not deliberately fragmenting, just not moving to the first
huge gap when writing starts. Again, not practical for
continuously-growing files, like a recording. Or log, though those _are_
usually smaller.

I _can_ see the advantages for certain kinds of use.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)[email protected]+H+Sh0!:`)DNAf

If you think privacy is unimportant for you because you have nothing to hide,
you might as well say free speech is unimportant for you because you have
nothing useful to say - Garas Paras @GarasParas on Twitter, 2020-5-5
  #11  
Old June 5th 20, 06:47 AM posted to microsoft.public.windowsxp.general
JJ[_11_]
external usenet poster
 
Posts: 744
Default Computer activity

On Wed, 3 Jun 2020 22:39:25 +0100, J. P. Gilliver (John) wrote:

If I understand you rightly, "deliberately" is overstating the case a
teeny bit: not deliberately fragmenting, just not moving to the first
huge gap when writing starts. Again, not practical for
continuously-growing files, like a recording. Or log, though those _are_
usually smaller.

I _can_ see the advantages for certain kinds of use.


No, I meant deliberately fragmenting the file. I could understand when the
driver might choose a non optimized starting cluster for a new file, because
it doesn't know how big the file can be. What I meant is that when a file is
growing and the next cluster is still free, the next appended data is not
written into that next free cluster. Thus, fragmenting the file.

The only reason I could think of as for why it behaves like that, is for
performance - by minimizing the HDD actuator movement.

As for the starting cluster of a new file, IME, in most cases, it chooses
the next cluster of the previously written cluster - no matter which file
owns that cluster. Instead of choosing the largest free fragment. And only
if the next cluster is already occupied, it would either choose the first
free cluster - even though it's not in the largest free fragment.
  #12  
Old June 5th 20, 01:53 PM posted to microsoft.public.windowsxp.general
J. P. Gilliver (John)[_7_]
external usenet poster
 
Posts: 603
Default Computer activity

On Fri, 5 Jun 2020 at 12:47:33, JJ wrote:
[]
No, I meant deliberately fragmenting the file. I could understand when the
driver might choose a non optimized starting cluster for a new file, because
it doesn't know how big the file can be. What I meant is that when a file is
growing and the next cluster is still free, the next appended data is not
written into that next free cluster. Thus, fragmenting the file.


You mean when writing into clear space, it deliberately suddenly changes
before getting to the end of the gap? I didn't know that.

The only reason I could think of as for why it behaves like that, is for
performance - by minimizing the HDD actuator movement.


I wouldn't even have thought of that! Would only work, though, surely,
if the new gap it moved to was in the same "cylinder"?

As for the starting cluster of a new file, IME, in most cases, it chooses
the next cluster of the previously written cluster - no matter which file


I'll yield to your E there.

owns that cluster. Instead of choosing the largest free fragment. And only
if the next cluster is already occupied, it would either choose the first
free cluster - even though it's not in the largest free fragment.


I could see that always using the largest free fragment - especially if
the file size isn't known - would under certain circumstances result in
the size of available fragments reducing faster.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)[email protected]+H+Sh0!:`)DNAf

Imagine a world with no hypothetical situations...
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 12:40 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.
Copyright 2004-2023 PCbanter.
The comments are property of their posters.