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. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 |
|
|