YES a couple updates ago win10 DID fix it so that it does,

I don't use Win 10 at all, so I didn't know this, but...A COUPLE OF UPDATES AGO? Srsly? SSDs have been around for what, seven years now?

To restate what you said a bit more comprehensively, the seek time on a HDD for a piece of a file is about 15ms, while the seek time on an SSD is like 0.2ms. As a HDD becomes more fragmented, the performance degrades, so defragmenting the drive produces a useful benefit. Technically, this is also true with an SSD, but the effect is basically invisible for most situations. So defragmenting an SSD is basically a waste of time, and it gobbles up write cycles, which are limited on an SSD, so there's that to think about. Anti-write-cyclists will tell you that it is their SSD and their choice. I will let my good buddy Peter Huffer explain the virtues of wearing out your SSD before its time, hopefully with the same beautifully expressed logic that he employed in justifying dying needlessly.

To balance things out in the universe, an SSD has to clear out the state of a cell before it can write to it. An area of the SSD with random data will affect the performance of the SSD, while it doesn't really matter to a HDD. That's where the TRIM command comes in, which is now universally integrated into the firmware of the SSD.

SSDs have been around for what, seven years now?

The first 2.5" SSD was released in 1991.
It was probably around 2008 consumer 2.5" SATA SSDs became generally available, but their random performance was woeful, but by 2009 there were plenty of models available that left HDDs of the time well behind. (Anyone here remember the OCZ Vertex? Intel X-25M?)

the seek time on a HDD for a piece of a file is about 15ms, while the seek time on an SSD is like 0.2ms.

SSDs don't have a seek time. Seek time, by definition, it the time it takes from when the read command is issued to when the heads have moved to the correct track.
However you can compare the Latency of the two. For a HDD Latency is the time it takes the heads to move, and the disk to rotate in to position for the first bit of data to be transferred from the time the read command was issued. In the case of an SSD, the time it takes for the first bit of data to be transferred after the read command has been issued. HDDs are measured in milliseconds, SSDs in micoseconds.

an SSD has to clear out the state of a cell before it can write to it.

Actually, that only occurs if a drive has been heavily used, and no garbage collection has occurred. If there is no existing data in the block being written to, then nothing needs to be erased before the write can occur.

An area of the SSD with random data will affect the performance of the SSD, while it doesn't really matter to a HDD.

Actually random data kills HDD performance even more than it does on a SSD, due to the HDD heads having to be moved more often to more locations on the drive.

That's where the TRIM command comes in, which is now universally integrated into the firmware of the SSD.

Trim has been in the firmware of SSDs for a very long time now. The issues were with the operating systems not supporting the command (and those that provided support for SATA drives didn't necessarily support PCI or NVMe drives), and some disk interface hardware (eg hardware RAID) not passing the command to the SSD.
SSDs actually do their garbage collection in the background, generally during periods of no or low activity. However what constitutes low activity varies by manufacturer & drive model. Also if a drive is under continuous I/O activity it may not get to to do the garbage collection, resulting in a massive drop in performance (because of the earlier mentioned need to erase data before writing new data- but even so, even with the cheapest of SSDs these days at their worst, they will still outperform the best available HDDs) hence the Trim command to force the drive to do it when the command is issued.

---

Grant
Darwin NT

Looks like another batch of dodgy Tasks.

norn_struct_profile_layered_design_TMWFYIV_ has about a 50% failure rate at present. It runs to complettion, then errors out when trying to return the result.

<core_client_version>7.16.11</core_client_version>
<![CDATA[
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.20_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol norn_pssm_layered_nocart_design.xml -parser:script_vars pssm=4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25.pssm aacompfile=TMWFYIV_0.05_0.02_0.03_0.04_0.05_0.06_0.10.comp wts=beta_nov16.wts @beta_nov16.flags -in:file:boinc_wu_zip 4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25.zip -in:file:s 4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25.pdb -silent_gz -mute all -out:file:silent default.out -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 1199775
Using database: database_357d5d93529_n_methylminirosetta_database
WARNING! attempt to create gzipped file ../../projects/boinc.bakerlab.org_rosetta/norn_struct_profile_layered_design_TMWFYIV_0.05_0.02_0.03_0.04_0.05_0.06_0.10_beta_nocart_4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25_SAVE_ALL_OUT_1391598_1_0_r496735313_0 failed.
======================================================
DONE ::    98 starting structures  28765.3 cpu seconds
This process generated     98 decoys from      98 attempts
======================================================
BOINC :: WS_max 6.35744e+08
17:39:41 (3732): called boinc_finish(0)

</stderr_txt>
<message>
upload failure: <file_xfer_error>
  <file_name>norn_struct_profile_layered_design_TMWFYIV_0.05_0.02_0.03_0.04_0.05_0.06_0.10_beta_nocart_4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25_SAVE_ALL_OUT_1391598_1_0_r496735313_0</file_name>
  <error_code>-240 (stat() failed)</error_code>
</file_xfer_error>
</message>
]]>

---

Grant
Darwin NT

Looks like another batch of dodgy Tasks.

norn_struct_profile_layered_design_TMWFYIV_ has about a 50% failure rate at present. It runs to complettion, then errors out when trying to return the result.

<core_client_version>7.16.11</core_client_version>
<![CDATA[
<stderr_txt>
command: projects/boinc.bakerlab.org_rosetta/rosetta_4.20_windows_x86_64.exe -run:protocol jd2_scripting -parser:protocol norn_pssm_layered_nocart_design.xml -parser:script_vars pssm=4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25.pssm aacompfile=TMWFYIV_0.05_0.02_0.03_0.04_0.05_0.06_0.10.comp wts=beta_nov16.wts @beta_nov16.flags -in:file:boinc_wu_zip 4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25.zip -in:file:s 4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25.pdb -silent_gz -mute all -out:file:silent default.out -nstruct 10000 -cpu_run_time 28800 -boinc:max_nstruct 20000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -boinc::cpu_run_timeout 36000 -run::rng mt19937 -constant_seed -jran 1199775
Using database: database_357d5d93529_n_methylminirosetta_database
WARNING! attempt to create gzipped file ../../projects/boinc.bakerlab.org_rosetta/norn_struct_profile_layered_design_TMWFYIV_0.05_0.02_0.03_0.04_0.05_0.06_0.10_beta_nocart_4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25_SAVE_ALL_OUT_1391598_1_0_r496735313_0 failed.
======================================================
DONE ::    98 starting structures  28765.3 cpu seconds
This process generated     98 decoys from      98 attempts
======================================================
BOINC :: WS_max 6.35744e+08
17:39:41 (3732): called boinc_finish(0)

</stderr_txt>
<message>
upload failure: <file_xfer_error>
  <file_name>norn_struct_profile_layered_design_TMWFYIV_0.05_0.02_0.03_0.04_0.05_0.06_0.10_beta_nocart_4716650f04d7b54da760d38cfe51965a_1kq1A_L7L7L7L7L5L2_63_TrR_FOLD_1_0_0.25_SAVE_ALL_OUT_1391598_1_0_r496735313_0</file_name>
  <error_code>-240 (stat() failed)</error_code>
</file_xfer_error>
</message>
]]>

Confirmed here too - upload failure: <file_xfer_error>

But I've had successes with this task-type as well, so intermittent for some reason

Since my oc tweaks, my errors are reduced from 180+ to just 9. 6 from pre-tweak days and 3 of this type. Generally, things much better for all reasons

---

Actually random data kills HDD performance even more than it does on a SSD, due to the HDD heads having to be moved more often to more locations on the drive.

Maybe poorly expressed. I meant that a HDD doesn't care about the data in an area in which it intends to write, whereas it does matter to an SSD. There lies the performance issue.

As for the rest, a little pedantic about the "seek time" thingy but otherwise Interesting detail. Thanks.

a little pedantic about the "seek time" thingy

Maybe so, but when the correct terms aren't used, or correct terms are used incorrectly, confusion results. And then that can often lead to never ending heated arguments...

---

Grant
Darwin NT

Looks like another batch of dodgy Tasks.

norn_struct_profile_layered_design_TMWFYIV_ has about a 50% failure rate at present. It runs to complettion, then errors out when trying to return the result....

Confirmed here too - upload failure: <file_xfer_error>

But I've had successes with this task-type as well, so intermittent for some reason

In my case it's gone from around a 50% success rate to around about 25% or less.
Almost 75% of those Tasks are failing with that particular error.

---

Grant
Darwin NT

Maybe so, but when the correct terms aren't used, or correct terms are used incorrectly, confusion results. And then that can often lead to never ending heated arguments...

How's life treating you there in Trumpworld, fam?

YES a couple updates ago win10 DID fix it so that it does,

I don't use Win 10 at all, so I didn't know this, but...A COUPLE OF UPDATES AGO? Srsly? SSDs have been around for what, seven years now?

To restate what you said a bit more comprehensively, the seek time on a HDD for a piece of a file is about 15ms, while the seek time on an SSD is like 0.2ms. As a HDD becomes more fragmented, the performance degrades, so defragmenting the drive produces a useful benefit. Technically, this is also true with an SSD, but the effect is basically invisible for most situations. So defragmenting an SSD is basically a waste of time, and it gobbles up write cycles, which are limited on an SSD, so there's that to think about. Anti-write-cyclists will tell you that it is their SSD and their choice. I will let my good buddy Peter Huffer explain the virtues of wearing out your SSD before its time, hopefully with the same beautifully expressed logic that he employed in justifying dying needlessly.

To balance things out in the universe, an SSD has to clear out the state of a cell before it can write to it. An area of the SSD with random data will affect the performance of the SSD, while it doesn't really matter to a HDD. That's where the TRIM command comes in, which is now universally integrated into the firmware of the SSD.

As long as the OS recognizes it and lets it happen, I don't believe Win7 ever has and that's why I just turn it off in the Registry and don't worry about it EXCEPT on my fully updated Win10 machines.

Maybe so, but when the correct terms aren't used, or correct terms are used incorrectly, confusion results. And then that can often lead to never ending heated arguments...

How's life treating you there in Trumpworld, fam?

I don't believe we need to degrade into the politics of one another, we have already degraded into the size of ones dick!!!

This is about crunching for Rosetta and other Projects no matter WHAT the politics of the cruncher may be!!

Maybe so, but when the correct terms aren't used, or correct terms are used incorrectly, confusion results. And then that can often lead to never ending heated arguments...

How's life treating you there in Trumpworld, fam?

?

---

Grant
Darwin NT

As long as the OS recognizes it and lets it happen, I don't believe Win7 ever has and that's why I just turn it off in the Registry and don't worry about it EXCEPT on my fully updated Win10 machines.

Windows 7 initially supported TRIM only for drives in the AT Attachment family including Parallel ATA and Serial ATA, and did not support this command for any other devices including Storport PCI-Express SSDs even if the device itself would accept the command.[41] It is confirmed that with native Microsoft drivers the TRIM command works on Windows 7 in AHCI and legacy IDE / ATA Mode.[42] Windows 8 and later Windows operating systems support trim for PCI Express SSDs based on NVMe, and the unmap command which is a full analog of the TRIM command from Serial ATA for devices that use the SCSI driver stack, including USB Attached SCSI Protocol (UASP). Microsoft has released an update for Windows 7 that adds NVM Express support including TRIM for PCIe SSDs.[43][44]

OS support for Trim
So as long as your OS is Win7 or later & reasonably up to date, and the SSD isn't ancient, Trim will be supported and the OS will recognise the drive is a SSD and not a HDD.

---

Grant
Darwin NT

I am an anti vaxxer.

I'm deeply shocked.

And I stated a very clear explanation of a good way SSDs could work.

Wear leveling, which was referenced in the post you replied to [pssst...peter....he's trying to tell you that what you suggested is already the way that it works] Add reading comprehension to your wish list, Huffer.

No reason wear levelling can't work when the drive is nearly full. You automatically move the stuff that never gets changed onto the half worn out part.

Actually the average British IQ is 2 higher than the USA.

Was I talking about IQ, Mr. Nonsequiter? Hint: no, I was not.

Hint, what does the I in IQ stand for?

trimming or something

This is really interesting. Please tell us more about how trimming is defragmentation for SSDs.

Trimming is what a defrag program does when presented with an SSD, and it speeds it up just like defragging does.

YES a couple updates ago win10 DID fix it so that it does, before that though, and for those that are not being updated it does not and it did actual defragging instead of trimming. Defragging an SSD wastes time and resources as it's faster than any defragging can help, at least until you get into the 1 and 2TB range anyway. It's like pre-fetching should also be turned off as the SSD is fast enough to overcome any advantage it could make and it just wastes drive space.

I read that Windows 7 introduced proper SSD support. Why would they take it away in early 10 editions?

And I am an anti vaxxer. It's my body and my choice.

Simply.....no.
Vaccine is not ONLY a personal choice, but also a community choice.
Protect you and OTHER people.

You want to be protected, then you take precautions, don't expect me to do it for you. You can wear a mask and get a vaccine and be a pansy if you desire, I don't have to do it for you.

Actually the average British IQ is 2 higher than the USA.

Actualy the average Italian IQ is 2 higher than British (and 4 than USA).
So can i say that you are not smart? No.
IQ is, for me, almost crap.

You can say the average Italian is a little smarter than the average Brit. We're let down by Glasgow and Manchester. Japan is 4 higher than you.

SSDs have been around for what, seven years now?

The first 2.5" SSD was released in 1991.
It was probably around 2008 consumer 2.5" SATA SSDs became generally available, but their random performance was woeful, but by 2009 there were plenty of models available that left HDDs of the time well behind. (Anyone here remember the OCZ Vertex?

Yes, 5 of the 10 I bought failed catastrophically in a few months. 3 of the free replacements for those 5 also failed. Hence I believe that company is now bust.

You want to be protected, then you take precautions, don't expect me to do it for you. You can wear a mask and get a vaccine and be a pansy if you desire, I don't have to do it for you.

Weren't you the one complaining that the U.S. was not exporting vaccines, or was that somebody else?
I would not want to be complicit in your pansyism.

---

Actually random data kills HDD performance even more than it does on a SSD, due to the HDD heads having to be moved more often to more locations on the drive.

Maybe poorly expressed. I meant that a HDD doesn't care about the data in an area in which it intends to write, whereas it does matter to an SSD.

Which I guess means it's less likely for someone to recover the naughty data from your disk that you forgot to securely erase.