Musket loader for your HDD

MyDefrag-v4.3.1

And be sure it's not an earlier version.

I've "differences" with this new MB. I'm not sure if it's a drive
conflict issue from MB resource loads (provided for Windows by the MB
manufacturer on CD).

This is a Windows install from a same MB, different model at an
earlier point;- I loaded the new MB's resource CD on top of the old
drivers.

Also, I was primarily using a PCI controller for two large mechanical
HDDs, and the MBs two SATA ports for a CD and bootable SSD.

Now that I've a lot more SATA ports on the new MB, (but only one PCI
slot), I'm getting unresponsiveness and slower utilization of speed.
Only during the defrag routine and not during direct file copy or move
operations through regular file maintenance utilities.

Symptoms are excessive times reported on particular files during
defragging, not affecting otherwise other program usages, as well a
reticence exhibited by defrag programs variously to release their
processes when asked to be terminated prematurely.

It works, to put it this way, although a USB docking station or simply
plugging a HDD another computer, one with another MB SATA controller,
will provide faster, proper performance for performing a defrag.

I've been through many of the options with several different Defragger
programs, which is why I mention MyDefrag. Does a nice job of
consolidating data, with finer levels (two settings) of granularity
than I suspect true with other defragmenters. Wiki doesn't mention
that;- its unique wrap-around technology is intended to surround files
Windows has tagged as unmovable.

I've no problem with that, except Windows is prone, due to some
page-file virtuosity crap, to flag unmovable a lot more files than it
reasonably ought to. Far more, and far more potential crap to
research for manually removing those restrictions incurred by the OS,
than, to say, using such as a commercial defragger, among
possibilities, which has its routine directly for bypassing that
restriction. Evidently not all defragmenters would concur with a
Windows methodology for haphazardly reporting file restrictions.
MyDefrag, however, does play along, which of course is a crying shame.

The good news, though, is that it's free, for what that's worth...
https://en.wikipedia.org/wiki/MyDefrag
which is most certainly worth a mention;- and it's also widely
well-regarded, if you've need for another.

It also uses Windows' API, which is indirectly tied to another
commercial defragmenter, no longer extant, Microsoft bought out. As
far as good getting better, I wouldn't care to bet on any assumption
Windows 8 to 10 is -- that is, better than or significantly superceded
a core NT technology still implemented since Windows XP.

Most defraggers do, the API, the good thing about that being -
somebody comes along swinging and slinging upside the circuit breaker
to the outside junction supply to your house - slams that baby down,
wham-bam leaving you in the dark, the Windows API and how it
supposedly works, in case you had a defrag routine going, will cover
your butt.

I know Disk Keeper advertised itself on that fine feature before it
fell behind, for me when HDDs first exceeded 512MBytes, first in line
to address that doom-scenario;...probably also who Microsoft also
bought out for the API. I get slam-dunked, all the time, by nasty
brown-outs;- momentary surges capable of resetting possibly one, if
not both computers always left on.

Flasherly wrote:
MyDefrag-v4.3.1

And be sure it's not an earlier version.

I've "differences" with this new MB. I'm not sure if it's a drive
conflict issue from MB resource loads (provided for Windows by the MB
manufacturer on CD).

This is a Windows install from a same MB, different model at an
earlier point;- I loaded the new MB's resource CD on top of the old
drivers.

Also, I was primarily using a PCI controller for two large mechanical
HDDs, and the MBs two SATA ports for a CD and bootable SSD.

Now that I've a lot more SATA ports on the new MB, (but only one PCI
slot), I'm getting unresponsiveness and slower utilization of speed.
Only during the defrag routine and not during direct file copy or move
operations through regular file maintenance utilities.

Symptoms are excessive times reported on particular files during
defragging, not affecting otherwise other program usages, as well a
reticence exhibited by defrag programs variously to release their
processes when asked to be terminated prematurely.

It works, to put it this way, although a USB docking station or simply
plugging a HDD another computer, one with another MB SATA controller,
will provide faster, proper performance for performing a defrag.

I've been through many of the options with several different Defragger
programs, which is why I mention MyDefrag. Does a nice job of
consolidating data, with finer levels (two settings) of granularity
than I suspect true with other defragmenters. Wiki doesn't mention
that;- its unique wrap-around technology is intended to surround files
Windows has tagged as unmovable.

I've no problem with that, except Windows is prone, due to some
page-file virtuosity crap, to flag unmovable a lot more files than it
reasonably ought to. Far more, and far more potential crap to
research for manually removing those restrictions incurred by the OS,
than, to say, using such as a commercial defragger, among
possibilities, which has its routine directly for bypassing that
restriction. Evidently not all defragmenters would concur with a
Windows methodology for haphazardly reporting file restrictions.
MyDefrag, however, does play along, which of course is a crying shame.

The good news, though, is that it's free, for what that's worth...
https://en.wikipedia.org/wiki/MyDefrag
which is most certainly worth a mention;- and it's also widely
well-regarded, if you've need for another.

It also uses Windows' API, which is indirectly tied to another
commercial defragmenter, no longer extant, Microsoft bought out. As
far as good getting better, I wouldn't care to bet on any assumption
Windows 8 to 10 is -- that is, better than or significantly superceded
a core NT technology still implemented since Windows XP.

Most defraggers do, the API, the good thing about that being -
somebody comes along swinging and slinging upside the circuit breaker
to the outside junction supply to your house - slams that baby down,
wham-bam leaving you in the dark, the Windows API and how it
supposedly works, in case you had a defrag routine going, will cover
your butt.

I know Disk Keeper advertised itself on that fine feature before it
fell behind, for me when HDDs first exceeded 512MBytes, first in line
to address that doom-scenario;...probably also who Microsoft also
bought out for the API. I get slam-dunked, all the time, by nasty
brown-outs;- momentary surges capable of resetting possibly one, if
not both computers always left on.

If your power quality is really bad, use a double-conversion UPS.

The power will stay up, so you can do a controlled shutdown.

Defragmenter performance can depend to some extent, on the
disk drive cache operation. Newer drives can keep more commands
in flight, and achieve minor improvements in MB/sec while
defragging.

If you really are using a PCI slot for a disk controller,
it cannot go faster than about 110MB/sec. If there is
other activity on the PCI bus, the number will be
less than that.

If you are on a VIA chipset motherboard, VIA made some
mistakes in their PCI stuff. And the "fix", I think it
involves reducing the burst size on the bus or something.
If the BIOS on the VIA chipset machine enables that fix,
performance drops to around 20-30MB/sec (and that's with the
WinTV capture card doing nothing). On my machine
here, the behavior was triggered by a BT878 WinTV capture
card. As soon as that card is installed, the BIOS "adjusts"
the bus to deal with the hardware issue, and performance
goes into the toilet. I replaced the motherboard in
that situation, with one having an Intel chipset.
Intel tends to fix any mistakes they make, whereas
VIA used to "copy" broken designs, from one chipset
to the next. I think the Southbridge on that one was
8237-S, which has the SATA fix (i.e. it works with SATA II
drives).

Paul

On Fri, 25 Aug 2017 15:32:23 -0400, Paul
wrote:

Power supply is new. Used to have one, but I don't do UPS these days
-- too much and too many boxes to add another. That's a big plus on
the Windows API being a safeguard, that last sector being transferred,
before slammed with a brownout, isn't consequently scrambled in FAT32.

If your power quality is really bad, use a double-conversion UPS.

The power will stay up, so you can do a controlled shutdown.

Defragmenter performance can depend to some extent, on the
disk drive cache operation. Newer drives can keep more commands
in flight, and achieve minor improvements in MB/sec while
defragging.

If you really are using a PCI slot for a disk controller,
it cannot go faster than about 110MB/sec. If there is
other activity on the PCI bus, the number will be
less than that.

--

If you are on a VIA chipset motherboard, VIA made some
mistakes in their PCI stuff. And the "fix", I think it
involves reducing the burst size on the bus or something.
If the BIOS on the VIA chipset machine enables that fix,
performance drops to around 20-30MB/sec (and that's with the
WinTV capture card doing nothing). On my machine
here, the behavior was triggered by a BT878 WinTV capture
card. As soon as that card is installed, the BIOS "adjusts"
the bus to deal with the hardware issue, and performance
goes into the toilet. I replaced the motherboard in
that situation, with one having an Intel chipset.
Intel tends to fix any mistakes they make, whereas
VIA used to "copy" broken designs, from one chipset
to the next. I think the Southbridge on that one was
8237-S, which has the SATA fix (i.e. it works with SATA II
drives).

Nope - no PCI extra controllers, although this is where it does get
interesting. If there's as you say recurrent VIA issues (since and in
the interim) introduced with this _new_ MB, albeit a 5-year-old
(probably plus) designed MB, for an AMD3 socket;- the AMD3 (octal
core) has functionally replaced a retired socket AMD2, (though it does
work perfectly for a quadcore), and both are Gigabytes.

Yes, and wouldn't you know it -- the other MB I mentioned, where
defragmentation is very robust, so happens to be an Intel socket 775
board. Which I'm using and on for my "online" box.

I can't believe it, that Gigabyte and VIA would sludge together
something so glaringly mismanaged. If so - and I really do not want
to throw money into either a PCI-E slotted HDD controller, nor as well
the "short-slotted" PCI variety, both unoccupied. Not when I already
have a perfectly working and, at some effort I expended to find it, a
good and stable, regular PCI controller -- just no longer the extra
luxury of a regular PCI to populate it within. This new MB has six or
eight SATA port headers, besides, which is like rubbing my face in it.

Although I suppose I can take solace in the fact that nothing else
other than defragmentation efforts, (so far), is negatively so
affected. Small wonders...at what point that might be, to push it a
little farther, is very much significant to my thinking, rendering
performance useless and ready enough, to step in with a class action
lawsuit, for delivering _known_ negligent and flagrant product
deficiencies.

On Fri, 25 Aug 2017 22:03:18 -0400, Flasherly
wrote:

Reading where ACHI driver installs, (requires and OS reinstall viz
first selecting BIOS ACHI mode enabled), IOW walking away from the
driver CD disk provision is solving (more general storage
transfer-rate) problems ... these aren't, for sure, VIA, but the "new
generation" of AMD's *"inferior, budget-minded stuff" -- (sic) from
the crowd of some of an opinion, "if you can't afford an Intel".

*North Bridge AMD 760G & South Bridge SB710 is what I have.

Can't recall owning an AMD chipset MB before, so this is a heads-up,
specially from AMD to me. Microsoft ACHI will apparently be detected
and provided for during an OS install, presumably with AMD's MB driver
CD not overwriting it for what's otherwise needed, (later and
selectively, eg- USB3 drivers for one), all and aside from degradative
SATA transfer rates ensuing during the defragmentation process.

Be nice -- what I'm getting is comparatively sick -- to see a defrag
run along and closer to normal file copy speeds, as was the case with
either a PCI HDD or the MB controller and my prior AMD socket AMD2
MB...ie- GeForce 6100 and nForce 430 north / south bridge.
(Or most any not AMD, stricken with sickness, among a universe of
normally operating MBs).