| 1 |
On Tue, Dec 28, 2021 at 8:32 AM Jacques Montier <jmontier@×××××.com> wrote: |
| 2 |
> |
| 3 |
> Well, il cleaned my dusty mobo, unplugged and plugged again the sata cables. |
| 4 |
> Now, with or without NCQ, boot time is rather short (~28s). |
| 5 |
> So it seems it was a connection problem. |
| 6 |
|
| 7 |
Yeah, I've suspected my cables for some of these ATA errors. I do |
| 8 |
feel like SATA is probably a bit lacking in error management, but I |
| 9 |
haven't looked into the gory details. |
| 10 |
|
| 11 |
That said, without NCQ the drive should work completely normally but |
| 12 |
you may get degraded performance. The idea of NCQ is that the kernel |
| 13 |
can feed the drive multiple instructions at a time, and then the drive |
| 14 |
firmware can optimize order of execution to reduce seek time. The |
| 15 |
kernel doesn't know the physical layout of the disk and so if the |
| 16 |
commands are executed in strict order the drive may end up seeking in |
| 17 |
a non-optimal way, and of course with mechanical drives being what |
| 18 |
they are that is very costly. A bit of controller CPU spent solving |
| 19 |
the travelling salesman problem can save a LOT of time waiting for the |
| 20 |
disk and heads to move. |
| 21 |
|
| 22 |
One of the bigger changes in NVMe is making the queue vastly larger so |
| 23 |
that more operations can be done in parallel. Obviously there are no |
| 24 |
seek times in flash, but I'm not familiar with how the actual |
| 25 |
addressing works so there may still be cases where the order of access |
| 26 |
matters, or where dispatching instructions in parallel keeps the |
| 27 |
pipeline more full. |
| 28 |
|
| 29 |
-- |
| 30 |
Rich |
Archives