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
Did you even bother reading his posts? Check his recent posts on other threads as well, the guy is a first class moron. I can give as much as I get. I expected better from you... As well as from @adly ...
Regardless of whatever anyone else is doing, why try to out do them at their own game? If you think he’s an idiot scroll past and ignore it - you’ve only made yourself look worse with your responses.
Dicks dicks all around!
COCKANDBALLS
There's one thing I dont understand about jsg's OP.
He mentions that Steve "was intended to [...] discredit my vpsbench".
jsg wants to "do properly what he did on shaky grounds and sloppily as well as obviously biased".
Okay, do it properly. But then, you carefully hide this gem and expect people not to point out the hypocrisy:
"vpsbench is a new and enhanced version (2.4.0) with more realistic read results (learn more later)"
So you sloppily accepted that your previous way to benchmark disk reads was indeed wrong and corrected it. Then why cry bloody murder when steve's original post was exactly about this? His criticism was valid, yet you still started mudslinging that went on for 11 pages in his own thread.
I also have to mention your "vpsb RdRnd 1120,5" result being 4x the theoretical maximum as claimed by the manufacturer themselves. You cannot claim this with a straight face: "the still high but (now) in a reasonable region read numbers from vpsbench[...]"
How is this in a reasonable region? 4x the maximum claimed by the manufacturer? Reasonable? Region?
I hope you don't plan on calibrating speed cameras. "The speed limit is 65 here." - "You got fined because you went 260 in a 65. Measurement could be a bit inaccurate, but it is in a reasonable region."
This one line by @jsg … “Am I your servent”
and he lost all my respect
Propaganda is a tool of the Russian state, and its troll.
Carefully hiding? Uhm, I put it out there in the public and I also had a discussion in public with someone who criticized that point and I admitted that I wasn't happy with that myself. If that is "carefully hiding" we seem to live in different universes.
No, I already had publicly said to a critic that I wasn't happy about that issue and working on finding and implementing a solution.
People can repeat that Sata drives have a physical boundary in the range a bit above 500 MB/s but that doesn't change the fact that A VPS benchmark doesn't test the physical device but rather against the OS (usually of the VM) and that is not limited by Sata.
And even if I could measure the devices/hardware speed I would not because vpsbench is not designed and meant to specifically be a disk tester but to measure the speed users can expect on a given VPS, VDS, or dedi if and when doing reading and writing in the way that is most used by common software.
So, you're writing to the OS cache. Oh wait, in the OP you said you had disabled OS caching. So which is it really? Was caching disabled or enabled?
What was the entire PMS in that thread about, then?
That means these values are meaningless because no real representation of the hardware's capabilities or I/O limits are given by the "benchmark".
One of the major issues with testing the host cache & presenting it as disk read is that - as was the case with the contabo benchmark - a run on an empty node will have full use of the hosts memory cache. A run on a populated node likely will not be cached by the host; so ultimately to the end user it may well be meaningless. Plus, as people have noted; it looks very strange to have disk io listed as exceeding the maximum physical specifications of the hardware.
In my view if you want to present data that might be from the cache, which may well be a valid thing to show as you say (despite the caveats re: host load); I'd suggest labeling them appropriately.
E.g.
Cached read (MB/s)
Direct read (MB/s) / buffered read / etc etc whichever most accurately describes what it is you're testing.
hdparm -tThas a great example of this.As some seem to still not know that (or simply chose to ignore it): turning off disk caching is, especially on linux, not really disabling all caching.
Also: How many users actually want their VM to run with disabled caching? Extremely few, I guess.
But my benchmarking is about telling what performance they can expect, which means that measuring with disabled caching may be of value e.g. when comparing different benchmarks, but for the purpose of measuring what VM users can expect it's pretty much useless.
When benchmarking and reviewing a VPS my job is to find out what users can expect under the conditions they work in - which is without disabled caching.
fio seems to be a good benchmark program (even though it seems to have some weird spots) but it's a disk specific benchmark and designed to find answers to questions quite different from those vpsbench tries to find answers for and under usually different conditions.
If, for example, I were tasked to decide between different dedis (or dedi configs) and find the one that is best suited for some disk intense task, say a large database, I would highly likely use fio. But that is not my task as a low-end-VPS benchmarker/reviewer. For this task I prefer vpsbench (+ companion tools).
I am totally fine with that intention. however, if the bench is telling me I can expect 8GB/s read from my dedi running on not so special softraid-1 HDDs then I am afraid it will be a big surprise if I am starting to copy the first 1GB file from one folder to another.
don't get me wrong, it's not about the physical boundaries but obviously rather about that the file most likely won't be cached before this read for the copy - and therefore I simply never can expect these read speeds for it.
so if you would want to test more real experience you should not deploy a testfile beforehand (which then will be read from cache) as this does not match the regular use case, does it?
I get your point and don't disagree per se, but you see, how far shall one go, how much time and effort is the testing worth? Even now a single run can take over 30 min. on a poor VPS plus there's also the question of how much disk writing is needed until a read doesn't end up in a cache. Plus of course nodes are different, VM configs are different,etc so it would take quite some effort just to find out how much "preparation" writing is needed to make sure that I don't effectively read out my own data written before from the cache.
If vpsbench were a disk specific tool, I'd make that effort and that effort would be justified, but it's not. So I rather emphasize to do many runs and at different times all over the day (and night) because I think that's more relevant and valuable when looking at a VPS.
vpsbench is about providing a fair (in between all providers) impression of (mostly) VPS systems and if anyone needs a special focus on a particular use case (e.g. database or massive streaming) he'd better use tools with that specific focus, e.g. fio for very flexible disk testing. But vpsbench still can be useful in those cases as a "filter" to find a select a few candidates that look promising and are worth extended and specific benchmarking.
"When everything fails, change the rules".
Ok. What If I supply one of my VPSs for all tests to run on? We'll have the same VM, different tests, and then you can all analyze them in peace?
Thanks for your friendly and constructive offer, but no matter what the vile gang will find something, anything, or they pull something out of their ... to "criticize". This is like a court case where the verdict was decided and written before the session even starts.
No problem, @jbiloh, the admins, and mods seem to not care, so why should I? If that is how they like LET so be it.
awwwwwwwwww
he always knows best
even in advance
whole world is against him
evil people
they...
...want to make him "slavery"
...want to steal his genius benchmark
...want to steal his crown
he has to fight
always
THEY
EVIL
FIGHT
J
S
G
Wah, wah, crybaby. You've done ZERO validation and have no real world testing to validate your results yet drone on and on about its designed to reflect the experience one would have. This has been said to you years ago. You've got zero data to show your test results are valid. It's seriously bad QA.
What specific issue are we pulling out of our asses criticizing? Just answer that. Every fucking issue reported has ample evidence and explanation. You can't even respond to three basic, super obvious issues.
You keep crying as if we're making shit up with test results and screenshots and you've provided zero evidence that your benchmark is correct. Zero. All you keep doing is changing what you say the program does, but doesn't change the result that it's useless.
Once upon a time there was
a premium fact checker @stevewatson301
and a premium dethroned troll @jsg
They started throwing royal mud and their supporting Nationals joined them. The mud throwing went on and on and on. They all became dirty, but the broken benchmark was never fixed.
The sad end.
This is a direct question and test results are quantifiable.
Still no response …. that says it all
@jsg can you instead of using your usual distracting word diarrhea for once just answer this simple discretionary question with plain numbers and facts?
No. Actually that says that you are either ignoring what I wrote or lack reading comprehension. And it says that I don't play along with the gangs nasty witch hunt anymore.
And I'm confident that I serve the LET community (minus a few, albeit noisy users) better by working on and improving and extending my benchmark software than by trying to discuss with the few but noisy and nasty.
Should I see constructive criticism that I can use to correct flaws and/or to improve my software I'll of course take that and try to make something with it (Example: @Falzo).
What is this witch hunt you keep referring to? We're in one place talking about one topic. There's no searching going on.
But you won't release it anymore, so how does that make sense?
Which criticism, specifically, did @Falzo make that you used?
@stevewatson301 provided accurate test results in an almost scientific way. Which was pretty constructive IMHO.
You are ignoring a simple question which can close this discussion. The most likely reason is that you are just afraid of the answer.
Ask yourself who would want to use your benchmark if there are doubts like this.
Besides that, who would want to run a closed source binary with this background?
I guess you are silently going "to improve" your broken benchmark and fix this issue, but this isn't good enough. In the meantime you have lost the trust of more than a few people.
in before.....
witchhunt
From Cambridge:
From this, it doesn't seem like a witch hunt at all. It's not an "opinion" that your benchmark doesn't report correct values, your benchmark has always been shown to report incorrect values, especially read values.
This was shown on Amazon EC2, Oracle Cloud, Linux containers, dedis, and even you ended up proving that your benchmark reports incorrect values, double the drive's own specifications!
Now, sure, if you're of the "opinion" that the earth is flat, then fine, just don't expect that people would accept your view unchallenged. When people start asking questions, you claim that there's a witch hunt?
Bellend
Wow, long time not see..
Come on @Nekki, you're really gonna ignore the Emma Watson thread?