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 » Windows 10 » Windows 10 Help Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Windows 1903 and Macrium Reflect



 
 
Thread Tools Rate Thread Display Modes
  #16  
Old May 25th 19, 06:22 PM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Windows 1903 and Macrium Reflect

John Doe wrote:


At least here, NVMe is not just for backups. Using NVMe for file
transfers is blazing fast, too. I copy 1 GB (minimum) media files
between NVMe drives without the Windows file copy window pop up even
appearing. Nonvolatile storage is the workhorse in a computer. NVMe
costs a lot per gigabyte and it's a boring upgrade, but it saves much
time every full day of use.


I suspect the OS design isn't good enough for modern hardware.

But that's just a theory of mine.

To give an example, on a test I carried out (using RAMDisks),
NTFS was only able to do certain operations at around 4K per
second. Whereas Linux TMPFS (a RAMDisk) was able to do the
same test at 186K per second.

NTFS may have been a good choice when it was invented around
the year 2000 or so, but it's perhaps a bit long in the tooth now.

One thing I haven't been able to determine, is whether the
"interrupt limiter" on Windows, has been changed radically
from the 10K to 15K per second range it used to be set at.
I expect that modern hardware can profitably go faster than
that. I haven't seen any notes on the issue in my travels.
I think Process Monitor has a counter, and perhaps perfmon.msc
has one too.

Paul
Ads
  #17  
Old May 25th 19, 07:00 PM posted to alt.comp.os.windows-10
Rene Lamontagne
external usenet poster
 
Posts: 2,549
Default Windows 1903 and Macrium Reflect

On 2019-05-25 12:22 p.m., Paul wrote:
John Doe wrote:


At least here, NVMe is not just for backups. Using NVMe for file
transfers is blazing fast, too. I copy 1 GB (minimum) media files
between NVMe drives without the Windows file copy window pop up even
appearing. Nonvolatile storage is the workhorse in a computer. NVMe
costs a lot per gigabyte and it's a boring upgrade, but it saves much
time every full day of use.


I suspect the OS design isn't good enough for modern hardware.

But that's just a theory of mine.

To give an example, on a test I carried out (using RAMDisks),
NTFS was only able to do certain operations at around 4K per
second. Whereas Linux TMPFS (a RAMDisk) was able to do the
same test at 186K per second.

NTFS may have been a good choice when it was invented around
the year 2000 or so, but it's perhaps a bit long in the tooth now.

One thing I haven't been able to determine, is whether the
"interrupt limiter" on Windows, has been changed radically
from the 10K to 15K per second range it used to be set at.
I expect that modern hardware can profitably go faster than
that. I haven't seen any notes on the issue in my travels.
I think Process Monitor has a counter, and perhaps perfmon.msc
has one too.

Â*Â* Paul


I could hardly believe my eyes!!!

I just did a backup and restore, with Macrium on medium compression.
NVMe to NVMe.

Windows Backup C: 29.3 GB, Mring file...13.8 GB. 1 minute 58 seconds
Restore to same drive *23 seconds*

I Did it again to make sure, backup 2 minutes 1 second.
Restore to same drive, *22 seconds*.
I sat and watched it to make sure I was fully Awake, Oh and I don't
drink or do drugs. :-)

Rene


:-)


  #18  
Old May 25th 19, 07:44 PM posted to alt.comp.os.windows-10
John Doe[_8_]
external usenet poster
 
Posts: 2,378
Default Windows 1903 and Macrium Reflect

Rene Lamontagne wrote:

Paul wrote:
John Doe wrote:


At least here, NVMe is not just for backups. Using NVMe for file
transfers is blazing fast, too. I copy 1 GB (minimum) media
files between NVMe drives without the Windows file copy window
pop up even appearing. Nonvolatile storage is the workhorse in a
computer. NVMe costs a lot per gigabyte and it's a boring
upgrade, but it saves much time every full day of use.


I suspect the OS design isn't good enough for modern hardware.

But that's just a theory of mine.

To give an example, on a test I carried out (using RAMDisks),
NTFS was only able to do certain operations at around 4K per
second. Whereas Linux TMPFS (a RAMDisk) was able to do the same
test at 186K per second.

NTFS may have been a good choice when it was invented around the
year 2000 or so, but it's perhaps a bit long in the tooth now.

One thing I haven't been able to determine, is whether the
"interrupt limiter" on Windows, has been changed radically from
the 10K to 15K per second range it used to be set at. I expect
that modern hardware can profitably go faster than that. I
haven't seen any notes on the issue in my travels. I think
Process Monitor has a counter, and perhaps perfmon.msc has one
too.


I could hardly believe my eyes!!!

I just did a backup and restore, with Macrium on medium
compression. NVMe to NVMe.

Windows Backup C: 29.3 GB, Mring file...13.8 GB. 1 minute 58
seconds Restore to same drive *23 seconds*

I Did it again to make sure, backup 2 minutes 1 second. Restore to
same drive, *22 seconds*. I sat and watched it to make sure I was
fully Awake, Oh and I don't drink or do drugs. :-)


You are doing the restore using a paid-for copy of Macrium Reflect?

Copying from NVMe to NVMe using the Macrium Reflect Free rescue
flash drive from the prompt takes at least 10 minutes (or whatever,
it's a long time). It's no big deal since the restore is done
rarely, I'm just curious.
  #19  
Old May 27th 19, 06:05 PM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Windows 1903 and Macrium Reflect

Rene Lamontagne wrote:
On 2019-05-25 12:22 p.m., Paul wrote:
John Doe wrote:


At least here, NVMe is not just for backups. Using NVMe for file
transfers is blazing fast, too. I copy 1 GB (minimum) media files
between NVMe drives without the Windows file copy window pop up even
appearing. Nonvolatile storage is the workhorse in a computer. NVMe
costs a lot per gigabyte and it's a boring upgrade, but it saves much
time every full day of use.


I suspect the OS design isn't good enough for modern hardware.

But that's just a theory of mine.

To give an example, on a test I carried out (using RAMDisks),
NTFS was only able to do certain operations at around 4K per
second. Whereas Linux TMPFS (a RAMDisk) was able to do the
same test at 186K per second.

NTFS may have been a good choice when it was invented around
the year 2000 or so, but it's perhaps a bit long in the tooth now.

One thing I haven't been able to determine, is whether the
"interrupt limiter" on Windows, has been changed radically
from the 10K to 15K per second range it used to be set at.
I expect that modern hardware can profitably go faster than
that. I haven't seen any notes on the issue in my travels.
I think Process Monitor has a counter, and perhaps perfmon.msc
has one too.

Paul


I could hardly believe my eyes!!!

I just did a backup and restore, with Macrium on medium compression.
NVMe to NVMe.

Windows Backup C: 29.3 GB, Mring file...13.8 GB. 1 minute 58 seconds
Restore to same drive *23 seconds*

I Did it again to make sure, backup 2 minutes 1 second.
Restore to same drive, *22 seconds*.
I sat and watched it to make sure I was fully Awake, Oh and I don't
drink or do drugs. :-)

Rene


:-)


13800 MB
----- = 627MB/sec
22 sec

https://forum.macrium.com/PrintTopic1229.aspx

"When an image is created each block of data (generally 64K
but may be larger depending on the partition size) has an
MD5 hash created after it is read from the disk and before
it is written to the image file. This hash value is saved
in the index of the image file. When the file is read back
the hash value is recalculated and compared with the original
hash in the index. Any discrepancy between the two values
indicates that the image file is corrupt or cannot be read
back reliably."

So it uses MD5, which is pretty well the lightest weight
popular hash (suitable for this purpose, has a decently
low collision probability, but is not suited to protecting
executables you download from random web sites).

MD5 is selected for its speed. It's slower than CRC32 by a
long shot, but it has much better properties than CRC32.

I compared an older version of Macrium and Windows, to the
newest one, and this is what I got by comparison.

280MB/sec verify (verify image while stored on RAMDisk)
233MB/sec restore (restore to RAMDisk)

243MB/sec verify with 7.3 Macrium and Win10 1903 x64
234MB/sec restore (restore to RAMDisk)

Your processor seems to be better at this than mine is,
that's a guess as to part of the difference. I don't know
if the NVMe is an enabler or not.

*******

The Win10 1903 is still making mistakes in things like
HDTune, in the measurement of bandwidths. This changed
a couple of releases ago. Originally, Win10 seemed to give
the same results as running HDTune on other OSes. But
something changed a couple of releases ago, to give abnormally
low numbers by 10-15% maybe.

When I run my RAMDisk software on WinXP, I get a consistent
4GB/sec. On Windows 10, the performance is all over the place.
On Win10 10240, I was getting 1GB/sec (and on faster hardware
than the WinXP machine too). The 1903 performance is pretty
constant at 2GB/sec. Part of the behavior is probably due to
table walks when traversing large quantities of RAM. The
RAMDisk does work better with large pages (as seen on OSes where
the RAMDISk was able to use memory in the PAE region).

On Linux, the TMPFS gives 7GB/sec when tested in similar ways.
And it's possible that uses LargePages to reduce table walk
penalty. Table walk is necessary when the TLB doesn't have
a virtual to physical address translation in the TLB cache and
has to "look it up". The page table pointers are stored in RAM, and
you have to do a lookup, before being able to consult the
virtual addresses the OS uses for everything. The least
recently used TLB entry is evicted, and the page table
values load into a segment in the TLB. Scanning a RAMDisk, thrashes
the TLB (at least, if 4KB pages are used for everything,
which is the normal case). This would not be something that
affects an NVMe...

Paul
  #20  
Old May 27th 19, 07:15 PM posted to alt.comp.os.windows-10
Rene Lamontagne
external usenet poster
 
Posts: 2,549
Default Windows 1903 and Macrium Reflect

On 2019-05-27 12:05 p.m., Paul wrote:
Rene Lamontagne wrote:
On 2019-05-25 12:22 p.m., Paul wrote:
John Doe wrote:


At least here, NVMe is not just for backups. Using NVMe for file
transfers is blazing fast, too. I copy 1 GB (minimum) media files
between NVMe drives without the Windows file copy window pop up even
appearing. Nonvolatile storage is the workhorse in a computer. NVMe
costs a lot per gigabyte and it's a boring upgrade, but it saves
much time every full day of use.

I suspect the OS design isn't good enough for modern hardware.

But that's just a theory of mine.

To give an example, on a test I carried out (using RAMDisks),
NTFS was only able to do certain operations at around 4K per
second. Whereas Linux TMPFS (a RAMDisk) was able to do the
same test at 186K per second.

NTFS may have been a good choice when it was invented around
the year 2000 or so, but it's perhaps a bit long in the tooth now.

One thing I haven't been able to determine, is whether the
"interrupt limiter" on Windows, has been changed radically
from the 10K to 15K per second range it used to be set at.
I expect that modern hardware can profitably go faster than
that. I haven't seen any notes on the issue in my travels.
I think Process Monitor has a counter, and perhaps perfmon.msc
has one too.

Â*Â*Â* Paul


I could hardly believe my eyes!!!

I just did a backup and restore, with Macrium on medium compression.
NVMe to NVMe.

Windows Backup C:Â* 29.3 GB, Mring file...13.8 GB. 1 minute 58 seconds
Restore to same driveÂ*Â* *23 seconds*

I Did it again to make sure, backup 2 minutes 1 second.
Restore to same drive,Â* *22 seconds*.
I sat and watched it to make sure I was fully Awake, Oh and I don't
drink or do drugs.Â* :-)

Rene


:-)


13800 MB
-----Â*Â*Â*Â* = 627MB/sec
Â*22 sec

https://forum.macrium.com/PrintTopic1229.aspx

Â*Â* "When an image is created each block of data (generally 64K
Â*Â*Â* but may be larger depending on the partition size) has an
Â*Â*Â* MD5 hash created after it is read from the disk and before
Â*Â*Â* it is written to the image file. This hash value is saved
Â*Â*Â* in the index of the image file. When the file is read back
Â*Â*Â* the hash value is recalculated and compared with the original
Â*Â*Â* hash in the index. Any discrepancy between the two values
Â*Â*Â* indicates that the image file is corrupt or cannot be read
Â*Â*Â* back reliably."

So it uses MD5, which is pretty well the lightest weight
popular hash (suitable for this purpose, has a decently
low collision probability, but is not suited to protecting
executables you download from random web sites).

MD5 is selected for its speed. It's slower than CRC32 by a
long shot, but it has much better properties than CRC32.

I compared an older version of Macrium and Windows, to the
newest one, and this is what I got by comparison.

Â*Â* 280MB/sec verifyÂ* (verify image while stored on RAMDisk)
Â*Â* 233MB/sec restore (restore to RAMDisk)

Â*Â* 243MB/sec verify with 7.3 Macrium and Win10 1903 x64
Â*Â* 234MB/sec restore (restore to RAMDisk)

Your processor seems to be better at this than mine is,
that's a guess as to part of the difference. I don't know
if the NVMe is an enabler or not.

*******

The Win10 1903 is still making mistakes in things like
HDTune, in the measurement of bandwidths. This changed
a couple of releases ago. Originally, Win10 seemed to give
the same results as running HDTune on other OSes. But
something changed a couple of releases ago, to give abnormally
low numbers by 10-15% maybe.

When I run my RAMDisk software on WinXP, I get a consistent
4GB/sec. On Windows 10, the performance is all over the place.
On Win10 10240, I was getting 1GB/sec (and on faster hardware
than the WinXP machine too). The 1903 performance is pretty
constant at 2GB/sec. Part of the behavior is probably due to
table walks when traversing large quantities of RAM. The
RAMDisk does work better with large pages (as seen on OSes where
the RAMDISk was able to use memory in the PAE region).

On Linux, the TMPFS gives 7GB/sec when tested in similar ways.
And it's possible that uses LargePages to reduce table walk
penalty. Table walk is necessary when the TLB doesn't have
a virtual to physical address translation in the TLB cache and
has to "look it up". The page table pointers are stored in RAM, and
you have to do a lookup, before being able to consult the
virtual addresses the OS uses for everything. The least
recently used TLB entry is evicted, and the page table
values load into a segment in the TLB. Scanning a RAMDisk, thrashes
the TLB (at least, if 4KB pages are used for everything,
which is the normal case). This would not be something that
affects an NVMe...

Â*Â* Paul



I did an HD tune 2.55 test on my Samsung 850 EVO, Transfer Rate average
362 MB/s
and on my NVMe 1284 MB/s. both on 64K block size.

Gotta love the access time on the NVMe 0.0 :-)

Rene

  #21  
Old May 27th 19, 11:50 PM posted to alt.comp.os.windows-10
nospam
external usenet poster
 
Posts: 4,718
Default Windows 1903 and Macrium Reflect

In article , Rene Lamontagne
wrote:


I did an HD tune 2.55 test on my Samsung 850 EVO, Transfer Rate average
362 MB/s and on my NVMe 1284 MB/s. both on 64K block size.


that's typical for an 850, but the nvme could be a lot faster.

https://static.techspot.com/articles-info/1281/bench/AS_01.png
https://pcper.com/wp-content/uploads...k-sn750-cdm-se
q.png
  #22  
Old May 28th 19, 12:33 AM posted to alt.comp.os.windows-10
Rene Lamontagne
external usenet poster
 
Posts: 2,549
Default Windows 1903 and Macrium Reflect

On 2019-05-27 5:50 p.m., nospam wrote:
In article , Rene Lamontagne
wrote:


I did an HD tune 2.55 test on my Samsung 850 EVO, Transfer Rate average
362 MB/s and on my NVMe 1284 MB/s. both on 64K block size.


that's typical for an 850, but the nvme could be a lot faster.

https://static.techspot.com/articles-info/1281/bench/AS_01.png
https://pcper.com/wp-content/uploads...k-sn750-cdm-se
q.png



Hey, Lets use the same program if you want to compare!
I was quoting HD Tune, you are showing results from AS-SSD!! Apples to
oranges.

Now we will do Apples to Apples

AS-SSD sequential reads,

My Samsung 850 reads 516.36
My ATA SX8200 reads 2863.97
A big difference when you use the same benchmark, Eh.

Rene

 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

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 On
HTML code is Off






All times are GMT +1. The time now is 03:26 PM.


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