I apologize as I simply restated what they had listed but I do get your point. Did they mean total utilization, perhaps a percentage of the utilization when a request to drive was made, and other possible scenarios? Another scenario I've seen with NVMe drives, gen3 and gen4, is that larger data transfers do trigger CPU spikes while they are happening. I've seen this with AMD and Intel setups. Does this help mitigate that? They, unfortunately, did not provide any data sets in the PR piece and I copied most of it into the article so what you see there is mostly are there is.Hmm. I love misleading headlines.
How much does a CPU spend on actual computation from data retrieval? 97% of a small number is ... still not a big number, but I guess 97% looks sexier.
If the drive itself is actually capable of performing basic database tasks - then I can see that, but I wonder what kind of driver it needs to do so, and what kind of support that would have. Would be less useful if it only works for one or two specific DBs on specific OSes. Also no mention of capacities, and being SSDs made for database oriented activities - overprovisioning and longevity in heavy write environments would be another thing that is missing from the article.
Wonder how many streamers are gonna see that and think it'll make Battlefield play 97% faster.
So, you're saying we need a hardware-accelerated DBMS to keep track of which drive(s) to query for a specific piece of data?In dealing with small fast data queries letting the storage handle things is like having a good hba card. It handles the computational side of the storage requests and streamlines data feeds.
Risks i see.
1. What happens with multiple nvme drives like this. Does 1 become the master device and others answer its queries, or does each drive answer independently.
2. Would the benefit of these drives extend to raid setups? Doe you need a special controller or logic go gain the benefit?