New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
The Sata pipe sits between the disk and the controller which again is connected by PCIe and DMA writing its data into RAM.
On the other side of that chain, far away, sits an application and requests the OS for data to be written or read.
You do not read or write to/from disk, the OS does, and memory can read/write many GB/s. That's the reason, btw. for RAM disks.
Your thinking would be correct only with a simple RTOS where the OS is merely abstracting away some hardware details.
Your vpsbench isn't reading data from the SSD into RAM at over 5000MB/s. Your app is nonsense.
If you're seeing similar performance between spinners, SSD and NVMe, you're probably measuring RAM to RAM copies and not testing the actual hardware.
I just can't grasp how you think over 5000MB/s is achievable let alone sustainable on an SSD. This is the point where everyone should just walk away.
Yes, buffered disk I/O (which is used by most applications) does indeed not test the hardware - and I said so and explained it multiple times.
Sync./direct I/O however does test the hardware (well, as far as that is possible).
Accordingly one can see very significant differences in performance.
Vpsbench doesn't make claims on sustainability of results. That's mainly a question of test set size. the 2 GB that vpsb uses as standard are almost certainly not large enough to break through some caching layers.
One can however configure a wide variety of parameters and one can break through almost all caching.
There are multiple reasons I chose 2 GB as standard test size, e.g. the fact that available disk space on VPSs (especially on low end ones) can be quite limited, or the fact that most use cases do not consistently read/write GB, and others.
But again, one can configure vpsbench over a wide range of all relevant parameters in order to benchmark for particular use cases.
The fact that I'm the only one calling shenanigans here is a really bad sign for LET.
Truly, truly disappointing. This can't be referred to as a "tech site" with this level of stupidity.
SMH
@TimboJones
I'm sorry but the only thing you really call is that you are saddeningly clueless and lack even basic understanding how modern OSs work.
Plus you fail to understand what vpsbench actually does. Wrt disk I/O it writes and reads - just like any application would do - x rounds of y size data. The difference to other applications is that vpsbench (a) collects precise timing, and (b) pauses in between rounds (unless disabled) so as to be a good neighbour on the node.
Btw, while you were busy taking dumps here and attacking me I
Yeah, right, we are all stupid and TimboJones is the only one who knows ...
Feel free to leave or to shut up to drive the level of intelligence here up quite considerably.
Who do you think carries more weight, a provider who has investment in his locations and asks for advice and the man behind LET who also invested a lot (not just money) and who wanted me to do benchmarking ... or TimboJones who doesn't even know what he's talking about? You just make lots of noise but your whining and complaining carries no weight at all, sorry.
If it's true that benchmark is flawed, but all the comparisons are use the same benchmark, does it matter?
For example, every VPS benched would be benched in the same "flawed" way so they can still be relative compared to each other just fine still?
WTF?
Prettiest pig ain't too bad 🤣
Well, actually @1606234's question isn't stupid (if I got it right). Example: assume I got a factor not right, say I multiplied some result number by 3000 instead of by 3600 to compute e.g some throughput per hour (rather than per seconds). In that case my results numbers would be wrong, of course, but if and as that error would appear in all tests (of diverse providers and locations) the relation between all the results would still be OK.
But, well noted, that's a theoretical issue anyway because I solidly checked and verified the algorithms used in vpsbench.
Yes, it matters. It would provide a loophole for providers who want to tweak their systems to get better benchmark numbers, without actually improving performance for customers.
e.g. CrudVPS starts ordering servers with enough cache that the writes seem to go very fast, but saves money buying slower disks.
As a consumer, who cares? I want my bits to get from source to destination the fastest. Provider wants to spend money on expensive RAM for cache and use slower disks? Great, probably a stupid move financially but transfers are fast my man!
Is the insinuation was that data is unprotected while in cache and not on disk? Does it matter if the data is in cache and not on disk?
I of course can't know and comment on @rcxb 's intentions but I can comment on the factual question:
Depends. Usually it doesn't really matter that much, because there are diverse places with some reserves. Most conforming PSU's e.g. store enough power for about 10 ms, better Raid controllers can keep disks alive for even some seconds. But what if the PSU or the Raid controller is the failing device?
So I'd say that in (very roughly) 95+% of trouble the caches can get written out but that's not guaranteed. So, if you want to be really on the safe side (5 nines and better), don't use buffered writing and disable all caching incl. on the Raid controller.
The problem of course is that there is a price to pay in terms of performance. And that's double and triple the case on shared systems (VPS of any kind) because there performance really goes down painfully.
It does if you care about data corruption. I certainly do.
Link or it didn't happen.
You know, I just typed out a response to you and then deleted it. You don't want any answers, you want to bitch.
I do have to give you credit though, people on other boards are even talking about you now. General consensus is that you're quite a cunt.
That's hilarious coming from you. I'd be surprised if there was a single helpful post made by you on LET, ever. I just recall your posts being from an asshole with absolutely no value.
How do I not want answers? I'm asking legit technical questions about obviously faulty data and assumptions. I'm telling him exactly what is wrong and how. Are you implying that you think jsg's replies are rational at all? Because then you're just jumping into the stupid pool with him. You've had multiple reading comprehension fails in the last few weeks, is this just another case?
I'm fine with people thinking I'm a cunt. It's no secret lots of people think you're a cunt, as well.
Hope that made you feel better, though.
You both are.
Glad I could join this conversation.
Nope, can't say it is really. But it seems to bug you more... Or, maybe it doesn't. Grown ass adults going by the name Timbo can't be all that self-aware.
Something about my ass and your dinner. I'd come up with some new insult but your existence is a big enough insult as it is...
This is the only reason I commented for. Satisfied enough with today's insult, no worries.
You two really need couples counseling.
The vpsb program is now available for download at https://yadi.sk/d/yfbjWW1Oudar6w
There are "packs" containing everything (manual, ...) for both linux-64 and FreeBSD-64.
There are also the binaries themselves only, also both for linux-64 and FreeBSD-64. Those are mainly for later if and when a new version is released (current is 2.0.3b) so one doesn't need to download the full pack anymore.
Also (with a friendly smile to @vimalware) there is a .sha256 checksum file for each file. In case you don't trust Yandex I'll also put their contents here:
Btw, please note that the binaries are quite small, less than 250 KB.
Get error on Debian 10 buster
If you include network testing (which is the default without command line options) then vpsb expects a file called 'ntargets' with a list of targets against which you want to test in the directory where it's started from. Have a look at 'manual.txt' (in the pack) in which you'll find explanations on how to use and run vpsb, incl. how a targets file looks like and how to specify your targets.
Here is a small extract of the 'ntargets' I use in my benchmarks:
I’m a bit late to the party but the “same flawed way” comment was way too funny to ignore.
If you're curious about the Source code : https://bit.ly/3k3A4AP
Feel free to build your own software but do not even dream of me giving in to your demands if only you push me enough! To that I only have one simple answer: FY!
do you have ARMv6 build for benching rpi or similar boards, or is it likely going to just destroy the sd card?
Nope, but I can look into building for Arm (64-bit only, sorry). If it's not too much trouble I'll build it and can test it with a not too different board.
As for your other question: No, it's not going to destroy your SD-card because you can set the parameters so as to go easy on the thingy. If I can produce an Arm version I'll provide the relevant hints to you. Just give me some days ...
P.S. Just glanced over my boards. The board I usually use to develop for is a Rock Pi A4 but I also have a rpi 4B and a Banana pi M2+. Would that work for you? (Sorry, I don't know, like, or care much about Arm versions, I merely sometimes build for them out of good will. Mips is another story and Risc-V certainly will have my attention and love).
4B should work fairly well in that class of chips
missing source code, units in test results and some formatting, export to html and bbcode/markdown would be nice future feature