Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


jsg, the "Server Review King": can you trust him? Is YABS misleading you? - Page 7
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.

jsg, the "Server Review King": can you trust him? Is YABS misleading you?

15791011

Comments

  • @Arkas said: Ok, you dumbass Redneck :wink:

    Hey now, I just corrected your terminology. @TimboJones is right that I don't give a flying fuck about your opinion but I had enough class to keep that to myself. :wink:

    Actually I think redneck is more offensive as it has racial undertones to it.

    Sadly, this also is regionally dependent. In large swaths of the US there are people who proudly declare themselves rednecks and wouldn't find it offensive at all.

    Thanked by 1Arkas
  • DPDP Administrator, The Domain Guy

    Insults 101.

  • @jsg said: those calls (mostly) bypass the guest VMs caches but not the nodes caches

    If node caching really occurred in some significant manner we'd also see fio's scores increase by that much. Let's not try to ignore that point, you keep mentioning "caching", "sync/direct" as if that can explain it all away, when it just can't.

    Also, the point I made still remains true -- you can generally trust yabs/fio to provide a correct impression of the disk speeds that you can expect. With vpsbench you can get some values that might be "jsg's version of truth", but it doesn't mean anything as amply demonstrated here, and elsewhere in your "steal good", "Contabo best", and other threads of this kind.

  • jarjar Patron Provider, Top Host, Veteran

    @skorous said:
    Sadly, this also is regionally dependent. In large swaths of the US there are people who proudly declare themselves rednecks and wouldn't find it offensive at all.

    You called?

  • raindog308raindog308 Administrator, Veteran

    @Arkas said: Actually I think redneck is more offensive as it has racial undertones to it.

    Trust me, redneckism crosses many racial boundaries.

  • I am guessing this debate did not start from benchmark-ing the benchmarks of benchmark software, but simply because of a title. I wonder, if that title would have not been given, would this thread still exist?

  • Just set a new shiny badge to @stevewatson301 and forget about it.

    1.Direct China route director
    2.Captain of Mongolian submarine
    3.Unsuspected Taliban cowboy
    4. Violent TUN/TAP swapper
    5. Winnie Pooh in lace panties

    Vote for the right selection.

    Thanked by 1dahartigan
  • @jenkki said:
    Just set a new shiny badge to @stevewatson301 and forget about it.

    1.Direct China route director
    2.Captain of Mongolian submarine
    3.Unsuspected Taliban cowboy
    4. Violent TUN/TAP swapper
    5. Winnie Pooh in lace panties

    Vote for the right selection.

    I vote for:

    1. Premium fact checker
    1. "Public Enemy".
    Thanked by 1bulbasaur
  • jenkkijenkki Member
    edited September 2021
    1. Blazing slow survivor
  • @LTniger said:
    7. "Public Enemy".

    I suspect there is a typo. It should be:

    1. Public friend
    Thanked by 1lentro
  • defaultdefault Veteran
    edited September 2021

    I vote for:

    1. The Millenial

    [Oh wait, I'm a millenial too actually.]

    Just give him a title, any title. He's been with us for 4 successful years, he contributed to community, he wants it bad and he honestly deserves it.

    Sorry if I wrongfully assumed the gender by using the pronoun "he/him".

  • I like @yoursunny's suggestion the best:

    @yoursunny said:
    How to apply for a troll tag?

    Everyone that isn't a provider should get either a troll tag (for non-Chinese IP) or an MJJ tag (for Chinese IP).

    So, mods willing, I'd definitely like a "Troll" tag.

  • jsgjsg Member, Resident Benchmarker

    @stevewatson301

    Instead of wasting my time responding to your newest "I'm aggressive but clueless" declaration, disguised as a post, I chose to "waste" my time looking a bit at you and your arrogatedly authoritative assertions (e.g. "fio is the reference").

    Well noted, my point is not bashing fio. My point is to unmask you and your utter incompetence.

    For a start (yes, I saved that for now, for the case that you just wouldn't stop barking aggressively but cluelessly):

    @stevewatson301 said:
    As for reverse engineering, my reverse engineering skills are not that good and there are too many layers of indirection going on in their nim-written binary for me to figure out.

    and

    @stevewatson301 said:

    @jsg said: Can you even develop code (beyond some PHP or somesuch script)?

    Yes, I have developed programs outside of PHP, and yes, they've involved both compiled and interpreted languages. My code works and has generated value for those that use it

    At that time I chose to let that stand because my goal was the matter at hand, but now I'll respond:

    No, you are not a software developer, at least not at the level you try to make us believe. Maybe you occasionally wrote/write some code, PHP, Python, javascript, but you are definitely NOT a software engineer with any level of experience in programming in compiled languages worth mentioning.
    Proof? Simple: any software engineer even only halfway worth his salt wouldn't talk like you did, nor would he think that reverse engineering binaries created by Nim - or pretty much any compiled language - is somehow more difficult to reverse engineer than code written in another compiled languages. (s)he would know that modern compilers (both clang and gcc) generate very similar if not identical binaries, no matter the source language one feeds them.

    Proof 2: Any software engineer even only halfway worth his salt would look at trace outputs of both programs, fio and vpsbench. You clearly didn't, but then your goal never really was an objective review and comparison. Your goal was to bash me and vpsbench and so you (like some of your co-barkers) only looked a vpsbench trace.

    Proof 3: If you were even a mid-level real developer with more than a trivial experience you would at least understand what you look at and what you are talking about. You clearly do not. You just throw wild allegations without even really understanding what you are talking about. A clear example will follow below.

    Proof 4: I handed you an excellent opportunity by providing pseudo code for my disk testing. If you had any understanding and experience worth mentioning you would have recognized that and would have verified it against a trace.

    I could go on but I'll show some mercy - something you didn't - and instead focus on examining your and your co-barking pals oh so clear and strong and cut in stone "reference" assertion ...

    Unlike you I actually did look at traces of both (of course playing fair and using the same parameters for [l|s]trace and the same job size (2000 1 MB blocks/slices) and modes. All relevant parameters are exactly how yabs calls fio and vpsbench's analogon. Both were (of bloody course) run on the same (virtualbox) VM with the same basic load (stuff running other than the candidates)

          yabs                            |       vpsbench
    calls     errors  syscall         | calls     errors  syscall
    --------- ------  ----------------  --------- ------  -----------------
    2049              write      4007
    1921              wait4
       1                 fadvise64
    1026      1000    stat
     972         1    nanosleep
    3622              clock_gettime    **0**
       1                 shmdt
    1486              lstat
     284               close               11
     274               mmap            39
      11                clone                8
     395               getdents64
       1                 fallocate
      80                read             4009
                                     4000             fdatasync
                                     4003             lseek
     283               fstat             10
      43                munmap          1
       1                 fsync
      81                mprotect             16
       7                 brk                       3
       5                 rt_sigaction          8
       1                 rt_sigprocmask    1
                                           1         1   ioctl
       1         1    access                   1          1
       1               shmget
       1               shmat
       2         1    shmctl
       2               getpid
       1               execve                  1
       1               ftruncate
       1         1    unlink                   1
       2               sysinfo
       1               arch_prctl                  1
      29              futex
       2               sched_getaffinity
       1               set_tid_address     1
       1               restart_syscall
     353        69    openat                 11
       1               set_robust_list             1
       1               prlimit64                   1
    --------------------------------------------------------------
    Total: 
      1,763s, 12945 calls, 1073 errors    | 2,943s, 16135 calls, 2 errors
    

    So, my vpsbench is "spamming the kernel with clock_gettime syscalls" and I was absolutely wrong when I "lectured" you?
    I'll be nice and provide the number of my timing "syscalls" to you: 16001, which result from 4000 writes and 4000 reads, each with 2 timing calls, one before and one after the disk operation. But there is that other thing to mention: vpsbench does zero syscalls for timing, while fio does 3622 syscalls for timing (clock_gettime).
    So, actually fio is the spammer while mine do not end up syscalling into the kernel.

    Which leads us directly to the next point: the trace results (number of calls) varies, sometimes wildly, between runs. I've seen for example (absolutely identical) fio runs with 3799 clock_gettime calls as well as fewer syscalls.
    This may be related to fio showing very different number of some calls when the test file (from a former identical) run already exists - which is how yabs seems to do it when fio testing their 4 block sizes.

    Next point: Are LET users considering to buy a VPS really interested in number porn? Or are they - as I believe - interested in real performance as in "I want to know disk speed without loosing data"?
    Enter fdatasync(), which vpsbench calls but yabs/fio does not. What's the difference? fdatasync flushes data out to the drive while using only O_DIRECT only does pass the OS cache (goes directly to the disk) but does not guarantee that the data are really written when the the write call returns.

    Next point: yabs/fio does no lseek and hence does not do a real random read and write test. Of course one can do simulated random tests via mmapped test files but that creates just an illusion because it's not really accessing file sectors all over the place (as for example databases typically do). Or in other words, sorry, but yabs/fio doesn't show you real values, 'real' as in "both sequential and random reads/writes".

    There would be more to mention but I'll leave it that and close with a hint, the number of errors as reported by strace: yabs/fio: 1073 errors, vpsbench: 2 errors (with 'error' meaning that a call wasn't completed successfully). To be fair, both programs have a few error except for stat() where yabs/fio has ca. 99.9% of its errors; that may or may not be relevant for the result being reasonably true or (at least partially) false.

    Final point:

    @stevewatson301 said:
    As for reverse engineering, my reverse engineering skills are not that good and there are too many layers of indirection going on in their nim-written binary for me to figure out.

    You never even looked at fio's source code although it's available. Well, I did, and that's how I know that fio's source has way more indirections than mine.

    It was clear from the beginning that your knowledge of software engineering as well as benchmarks is very limited, but when you started this thread - with the obvious (and later admitted) goal of bashing and discrediting me and my work - I decided to look as if your attack worked at least to some degree ... and to give you some rope to hang yourself.

    You have delivered, thank you. It's clear and obvious now and has been properly demonstrated that you are but some clueless (in the relevant fields) guy whose "objective review" not only was everything but objective, but in fact evidently and verifiably extremely biased and utterly incompetent, which is why you again and again fell back to stubbornly throw allegations at me, that, at the very best, seemed (to a clueless person) to have some basis.

    Your fatal mistake was to talk about "objective" and having experience as a real software engineer, but to reliably fail to do the one thing that was the proper way: to objectively - as in 'cold data and proper analysis' - look at both programs.

    Again, I have no interest whatsoever to bash fio (or even yabs), but as you chose to not only present fio/yabs as "the reference" but also to try discrediting me and my work I had to take a closer look at both. Maybe fio could, with other parameters, do something similar to what vpsbench does, but the way it's used by yabs is not delivering proper and realistic results (I want to put it politely because, again, my point isn't about those benchmarks per se).

    Thanked by 2default AlwaysSkint
  • Ooo, the king has a point. Steve, what's your next move?

  • @jsg I understand you are defending yourself and that’s OK, but honestly the gate keeping about who is a real developer and who isn’t doesn’t do anyone any favours.

    We could start arguing that Nim isn’t a real language as it compiles to C, not machine code, etc. but what’s the point? A software developer is someone who develops software; that’s it. Whether they have a formal background in software engineering is neither here or there.

  • jsgjsg Member, Resident Benchmarker
    edited September 2021

    P.S.

    My test system was a debian based distro with kernel 4.9.235, the fio version was 3.12 installed via apt-get.

    And I apologize for the ridiculously poor formatting of the trace results above. It looked perfect in the console and editor but somehow the forum software has its own ways to go about formatting.

    Each line contains (in that order):
    yabs/fio calls, errors, syscall, vpsbench calls, errors, syscall

    Note: were 'errors' == 0 only one number for each yabs/fio and vpsbench is provided wchich is the number of calls.

    Note 2: There are a few lines with no info for yabs/fio and numbers only for vpsbench. Those are cases were a given syscall wasn't used by yabs/fio (example: 'fdatasync').
    Similarly there are cases with no numbers for vpsbench. Those are cases were a given syscall wasn't used by vpsbench (example: 'fstat').

  • @jsg said: So, actually fio is the spammer while mine do not end up syscalling into the kernel.

    thanks for the traces / comparison table, interesting indeed!
    mind me asking, how does vpsbench get its timings?

    could there be any chance that under certain race conditions the calculation gets it wrong due to rounding or whatever (thinking of edge cases for the granularity here... ns µs ms etc.)

  • jsgjsg Member, Resident Benchmarker

    @adly said:
    @jsg I understand you are defending yourself and that’s OK, but honestly the gate keeping about who is a real developer and who isn’t doesn’t do anyone any favours.

    We could start arguing that Nim isn’t a real language as it compiles to C, not machine code, etc. but what’s the point? A software developer is someone who develops software; that’s it. Whether they have a formal background in software engineering is neither here or there.

    I get your point, but sorry, actual knowledge and experience does play a major role in this matter. Someone who actually has over two decades of experience in the field and actually has written a benchmark knows and recognizes things that a say PHP developer with little experience doesn't know and recognize.
    Kindly note that I, unlike him, at least don't just willy nilly throw assertions about him.

    And sorry, but again no, a formal background and experience makes all the difference, as you will find confirmend when looking at how HR of top companies handle it.

    Btw, I have no interest whatsoever in doing harm to him or his reputation, but when push comes to shove that's the price one may have to pay when stubbornly and consistently trying to harm someone - he might hit back, even if he normally is a peaceful person.

  • jackbjackb Member, Host Rep
    edited September 2021

    @jsg said:
    Kindly note that I, unlike him, at least don't just willy nilly throw assertions about him.

    You kind of did though. Stating that "any developer worth their salt" or "at least mid level" would jump to strace is a willy nilly assertion.

    There's a lot of types of developer, and not all of them work in the same way as you.

    Labeling anyone who works differently to you "a PHP developer" is fairly rude and arrogant imo.

  • jsgjsg Member, Resident Benchmarker

    @LTniger said:
    Ooo, the king has a point. Steve, what's your next move?

    Oh, please stop referring as "king" to me. That wasn't my choice and that title wouldn't even have crossed my mind.

    @Falzo said:

    @jsg said: So, actually fio is the spammer while mine do not end up syscalling into the kernel.

    thanks for the traces / comparison table, interesting indeed!
    mind me asking, how does vpsbench get its timings?

    could there be any chance that under certain race conditions the calculation gets it wrong due to rounding or whatever (thinking of edge cases for the granularity here... ns µs ms etc.)

    I don't think so. My experience says that strace doesn't tend to be tricked, at least not when it's not expressly tried, which vpsbench does not and I trust yabs/fio doesn't either.

    The answer to the other question was already given "long" ago. The two use different parameters which leads to one (fio) actually doing a real syscall (albeit a quite lite one) while the other (vpsbench) basically just reads a variable maintained by the kernel but in user accessible space. I ltrace one can see the vpsbench call to the library (which however doesn't syscall into the kernel).

    From what I've seen in fio's source and remember fio can be compiled to act like vpsbench (in that regard) but for some reason debian and derivates (as well as other distros I presume) chose to compile it with another choice.

    Btw, funny side note: fio's manual is lying in that they say that they use (fewer or more) gettimeofday calls which is actually not true, at least with some linux distros (which also means that my negative remark (much earlier) about that call being used was actually wrong, but back then I relied on fio's manual).

  • jsgjsg Member, Resident Benchmarker
    edited September 2021

    @jackb said:

    @jsg said:
    Kindly note that I, unlike him, at least don't just willy nilly throw assertions about him.

    You kind of did though. Stating that "any developer worth their salt" or "at least mid level" would jump to strace is a willy nilly assertion.

    There's a lot of types of developer, and not all of them work in the same way as you.

    Labeling anyone who works differently to you "a PHP developer" is fairly rude and arrogant imo.

    Is it really? not according to my real world experience. But even if you were right, just assumed, kindly keep in mind that it was not me who introduced strace to the game ...
    nor was it my decision that some of those who did, did it in an unfair manner and some even without the capablity to understand it. Sorry, not my fault.

    As for PHP (and other scripting languages) my point wasn't arrogant. It's simply a fact that someone with say 20 years of experience with C under his belt will be in a much better position to judge something written in C (or another compiled language) than a PHP or Python developer is.

    Vice versa if this was about PHP code I (without extensive professional level experience in PHP) would be in a disadvantageous position.

  • jenkkijenkki Member
    edited September 2021

    @stevewatson301 said: I'd definitely like a "Troll" tag.

    That too short. Cutting edge trash can viewer - sounds better.

    Thanked by 1jsg
  • jackbjackb Member, Host Rep
    edited September 2021

    @jsg said:
    Is it really? not according to my real world experience. But even if you were right, just assumed, kindly keep in mind that it was not me who introduced strace to the game ...
    nor was it my decision that some of those who did did it in an unfair manner and some even without the capablity to understand it. Sorry, not my fault.

    I think your anecdotal real world experience might be pigeon holed to a particular type of work.

    For example, I largely work in .NET. Very few .NET developers will quickly think about strace or similar - usually that's once you've dived down a particular rabbit hole that hints the problem is in unmanaged code.

    NodeJS too - for example, I would say it is unlikely people would often need to trace syscalls. You certainly wouldn't lump joepie91 into the "PHP developer" category.

    These are just two examples.

    As for PHP (and other scripting languages) my point wasn't arrogant. It's simply a fact that someone with say 20 years of experience with C under his belt will be in a much better position to judge something written in C (or another compiled language) than a PHP or Python developer is.

    It is arrogant. There's a lot of shitty PHP code out there, but that doesn't mean anyone who uses PHP is automatically somewhat inferior. I'd suggest you choose a different label for when you want to sling mud.

  • PieHasBeenEatenPieHasBeenEaten Member, Host Rep

    So who is right? That is the ultimate question.

  • FalzoFalzo Member
    edited September 2021

    @jsg said: The two use different parameters which leads to one (fio) actually doing a real syscall (albeit a quite lite one) while the other (vpsbench) basically just reads a variable maintained by the kernel but in user accessible space. I ltrace one can see the vpsbench call to the library (which however doesn't syscall into the kernel).

    thanks for clarifying again and sorry if some questions seem repetitive or have been answered elsewhere and I just missed it. I am still genuinely curious about that and while I wouldn't call myself a developer I do look at source code quite often trying to 'debug' problems and therefore am used to question quite a lot 'outside the box'.

    other (dumb?) questions: that variable maintained by the kernel can be trusted in terms of being maintained/updated in the same speed as a direct call would deliver a result and it can't overflow or something (like a e.g. bean-counter)

    could you theoretically and for the sake of science replace your method of getting the time with 'spamming syscalls' instead and see how this affects the results? ;-)

    Thanked by 1chocolateshirt
  • jsgjsg Member, Resident Benchmarker

    @jackb said:

    @jsg said:
    Is it really? not according to my real world experience. But even if you were right, just assumed, kindly keep in mind that it was not me who introduced strace to the game ...
    nor was it my decision that some of those who did did it in an unfair manner and some even without the capablity to understand it. Sorry, not my fault.

    I think your real world experience might be pigeon holed to a particular type of work.

    For example, I largely work in .NET. Very few .NET developers will quickly think about strace or similar - usually that's once you've dived down a particular rabbit hole that hints the problem is in unmanaged code.

    NodeJS too - for example, I would say it is unlikely people would often need to trace syscalls. You certainly wouldn't lump joepie91 into the "PHP developer" category.

    These are just two examples.

    As for PHP (and other scripting languages) my point wasn't arrogant. It's simply a fact that someone with say 20 years of experience with C under his belt will be in a much better position to judge something written in C (or another compiled language) than a PHP or Python developer is.

    It is arrogant. There's a lot of shitty PHP code out there, but that doesn't mean anyone who uses PHP is automatically somewhat inferior. I'd suggest you choose a different label.

    I don't contest that - but this here isn't about .NET or NodeJS, this is about programs developed in a statically compiled language with (more or less) static types.

    You see, actually you confirm my point insofar as I would never tell an experienced say .NET developer that his work is sh_tty compared to some other work in .NET - because I don't see myself in a position to judge that (beyond "I like or dislike software A or B").

  • DPDP Administrator, The Domain Guy

    It's not often you see a thread stay on-topic for this long.

    This shit's real.

  • jsgjsg Member, Resident Benchmarker
    edited September 2021

    @Falzo said:

    @jsg said: The two use different parameters which leads to one (fio) actually doing a real syscall (albeit a quite lite one) while the other (vpsbench) basically just reads a variable maintained by the kernel but in user accessible space. I ltrace one can see the vpsbench call to the library (which however doesn't syscall into the kernel).

    thanks for clarifying again and sorry if some questions seem repetitive or have been answered elsewhere and I just missed it. I am still genuinely curious about that and while I wouldn't call myself a developer I do look at source code quite often trying to 'debug' problems and therefore am used to question quite a lot 'outside the box'.

    other (dumb?) questions: that variable maintained by the kernel can be trusted in terms of being maintained/updated in the same speed as a direct call would deliver a result and it can't overflow or something (like a e.g. bean-counter)

    I guess that enters "religious" territory. I personally trust that modern unix kernels don't badly f_ck up in that regard, others may have a different view.
    For cases like vpsbench and fio it's good enough anyway, as they both have a very high ratio of "disk IO" and "getting the time with usec precision", except one point (about which there are different opinions too): the way fio gets time info may be thrown off by kernel time corrections (e.g. ntp updating the time) but frankly, at least AFAIC that'l like quarrelling over the statement "my car has a length of 5 m" by bringing up "but actually that may differ by multiple micrometers!".

    As for high reliability systems and software the answer to the question is quite different. There one with very high likelyhood wouldn't trust any of the commonly used OSs but rather use high reliability RTOS with carefully crafted and verified code.

    Anyway, for vpsbench and fio the methods they use are good enough.

    could you theoretically and for the sake of science replace your method of getting the time with 'spamming syscalls' instead and see how this affects the results? ;-)

    Of course I could but trust me it doesn't make sense in terms of more trustworthy or precise results. Yes, my code is (half a bee's leg) better but fio's method is easily good enough, even if the result might be a couple of microseconds off occasionally.
    It just so happens that they are "spamming the kernel" while i do not, but frankly, that carries little weight other than, well, the guy thinking he's smart throwing that allegation at me was wrong (again). Even if fio's call would cost, let's go extreme, 1 ms, so what? That's not the question, as long as the call is used logic symetrical (losing the same at both start and end) and as long as it's properly placed (e.g. not including potentially expensive clean up code, file opening, fstat or whatnot).

  • @jsg said:
    Proof 4: I handed you an excellent opportunity by providing pseudo code for my disk testing. If you had any understanding and experience worth mentioning you would have recognized that and would have verified it against a trace.

    There's a really easy way to solve this: just release your source. It can't take any more time than rewriting pseudocode, and it'll allow third parties to definitively prove who is right.

Sign In or Register to comment.