It seems like they don't make a clear distinction between latency and bandwidth. From the little I know on SSDs(don't claim to be an expert here) the sequential reads are below or on-par with high spindle speed disks.
What seems to be a better take-away would be that sequencing of your reads isn't nearly as important as it used to be. Back in games we'd duplicate data across a DVD so that we could do "seekfree" loading where duplicating 5-10MB of data would mean just a single big call to read() and gain massive load time performance.
[1]: http://www.tomshardware.com/charts/enterprise-hdd-charts/-02...
[2]: http://www.computerworld.com/article/2900330/apple-mac/holy-...
No joke. Just got an new MBP for work. Before had a spinning disk (well hybrid). Was running some silly benchmarks that I ran before and clocked my disk throughput at about 100MB/s. On MBP got 800MB/s. I thought something broke (was hitting page cache or some trickery like that) or didn't compile things right. But no, tried other tools, looked online and it seemed correct. It really surprised me.
Not quite, but they're "only" a 2-5 times faster, not orders of magnitude faster, as with random accesses.
CentOS / RHEL as a rule is behind as far as package versions in order to be more stable. But they do bring in new drivers and back-port many fixes and packages.
Most of the stuff that applies to CentOS will apply to Fedora as well as a rule.
--- To put these numbers in context, acquiring a single uncontested lock on today's systems takes approximately 20ns, while a non-blocking cache invalidation can cost up to 100ns, only 25x less than an I/O operation. ---
It also depends if workload is throughput sensitive or latency sensitive. If it is latency, can do things like tie processes and interrupts to cores, isolate those cores, etc. For throughput can processes more than one packet at a time perhaps.
Then there is dpdk and even unikernels.
> CPU has responsibilities beyond simply servicing a device—at the very least, it must process a request and act as either a source or a sink for the data linked to it. In the case of data parallel frameworks such as Hadoop and Spark,7,17 the CPU
That's why you get more CPUs and explicitly isolate them if you can. But now depending on how they share data with other CPUs there will be invalidated cache lines so will pay that way as well.
In general if you run on RHEL / CentOS ( a lot banks, military and enterprise deployments do ), there is this helpful guide as an overview:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...