31–40 of 78 posts
One of my favourite parts of this article is how Elliot Thomas describes himself as a "Software Engineer". We may be writing software, but without a working knowledge of hardware it's not worth much!
I have barely any knowledge of hardware, but I have built plenty of pieces of software that have helped people.
> we run a fairly comprehensive set of block-level tests using fio, consisting of both sequential and random asynchronous reads and writes straight to the disk. Then we throw a few timed runs of the venerable dd program at it.
Running dd as a benchmark is a major red flag. It show that they didn't know what they were doing with fio, and didn't trust its results. They later started using IOzone and a custom-written tool to accomplish stuff they should have done with fio in their initial testing.
They also did not mention pre-conditioning the drives or ensuring that their tests run long enough to reach a steady state. This is one of the most important aspects of enterprise SSD testing and they would have known that if they'd consulted any outside resources on the subject instead of making up their own testing guidelines from a position of extreme ignorance about the fundamentals of the hardware they were using and the details of their own workload.
They really should stop calling any of their tests "comprehensive".
The biggest lesson to take away from this is probably that they thought they knew how to test a SSD, but were quite obviously clueless: > we run a fairly comprehensive set of block-level tests using fio, consisting of both sequential and random asynchronous reads and writes straight to the disk. Then we throw a few timed runs of the venerable dd program at it. Running dd as a benchmark is a major red flag. It show th…
The biggest lesson to take away from this is probably that they thought they knew how to test a SSD, but were quite obviously clueless: > we run a fairly comprehensive set of block-level tests using fio, consisting of both sequential and random asynchronous reads and writes straight to the disk. Then we throw a few timed runs of the venerable dd program at it. Running dd as a benchmark is a major red flag. It show th…
BBC published a technical (but really PR) article written by amateurs posing as pros, instead of consulting reputable experts?
Earlier quoted context omitted.
It's a shame this is so selectively applied. See, for example: - The constant mention of speaking to people 'over Skype' on the News - Publicization of Twitter hashtags on Questiontime and other programs - Hours worth of Top Gear footage (and the entire Arctic Special) that were effectively Toyota Hilux advertisements
The constant favourable coverage of Google and Apple, always talking about hipster-friendly Flickr when boring old Photobucket was doing 20x the volume... they apply their rules very selectively....
The biggest lesson to take away from this is probably that they thought they knew how to test a SSD, but were quite obviously clueless: > we run a fairly comprehensive set of block-level tests using fio, consisting of both sequential and random asynchronous reads and writes straight to the disk. Then we throw a few timed runs of the venerable dd program at it. Running dd as a benchmark is a major red flag. It show th…
BBC published a technical (but really PR) article written by amateurs posing as pros, instead of consulting reputable experts?
I built my home system early this year using the Samsung 960 Evo 1TB M2. Actual speeds were nowhere near advertised speeds until I enabled write-back cache on the drive, which gave me pause for concern about data persistence reliability. AFAIK the Samsung drivers (as opposed to the MS drivers I originally used) just turn this on without needing to be twiddled in settings. Just to confirm, I have seen the behaviour de…
I also have a Samsung 960 Evo. Its performance is what I consider a joke, fio and pg_test_fsync make it almost look as slow as spinning SAS drives. For example on a 4kb sync write with 16 threads test, the 960 Evo cannot do more than 1000 iops. In comparison the Intel P4800X (Optane) does friggin 500 000 iops on the same test. That is a 500X difference. https://forums.servethehome.com/index.php?threads/did-some-w...
Earlier quoted context omitted.
The BBC has a very strong product prominence policy[0] (i.e. avoid naming brands when possible), being government funded is a large driver of this policy. [0] http://www.bbc.co.uk/editorialguidelines/guidelines/editoria... EDIT: fixed policy name and added link
It's not Government funded. There's a mandatory TV tax (for TV viewers), the fee of which is set by Government.
One of my favourite parts of this article is how Elliot Thomas describes himself as a "Software Engineer". We may be writing software, but without a working knowledge of hardware it's not worth much!
I have barely any knowledge of hardware, but I have built plenty of pieces of software that have helped people.
This is the problem IMHO > We also looked up whether our HBA used TRIM in its current configuration. It turns out, in RAID mode, the HBA did not support TRIM. We did do some trim-enabled testing with a different machine, but these results are hard to compare fairly. In any case, we can't currently enable TRIM on our production systems. In our experience SSD write performance goes to sh*t if you don't regularly TRIM t…
Interesting, is that because of the load? It seemed "modern" SSDs have GCs good enough that trim isn't quite necessary anymore to ensure good performances in consumer loads.
> RAID cards not passing TRIM is a big problem for us too...
Are there NVMe RAID cards? I assume they'd necessarily pass the command along considering deallocate* is just one parameter/option of the DATA SET MANAGEMENT command, or do RAID cards just drop the entire command?