Howdy, Stranger!

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


LEB/LET benchmarks - vps benchmark 2.x - Page 2
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.

LEB/LET benchmarks - vps benchmark 2.x

2

Comments

  • jsgjsg Member, Resident Benchmarker

    @TimboJones said:
    ???. Then you're not measuring the storage speed and you're doing it wrong.

    You can have a big ass water storage system (caching), but the amount of water that can transferred from it is limited by the hose connected to it. Sata 6 being the hose in this example. Having a storage system the size of a lake won't make the water transferred from the small ass hose 10X faster. coughignore water pressurecough

    In other words, if your 1Gbps NIC said it was doing 5Gbps, you'd flat out call shenanigans, no? This is the same fucking thing.

    To continue the network analogy, it's like you're doing that thing similar to iperf where the sender bursts a bunch of data at the start and use that number instead of the destination's stats of actually received data.

    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.

  • @jsg said:

    @TimboJones said:
    ???. Then you're not measuring the storage speed and you're doing it wrong.

    You can have a big ass water storage system (caching), but the amount of water that can transferred from it is limited by the hose connected to it. Sata 6 being the hose in this example. Having a storage system the size of a lake won't make the water transferred from the small ass hose 10X faster. coughignore water pressurecough

    In other words, if your 1Gbps NIC said it was doing 5Gbps, you'd flat out call shenanigans, no? This is the same fucking thing.

    To continue the network analogy, it's like you're doing that thing similar to iperf where the sender bursts a bunch of data at the start and use that number instead of the destination's stats of actually received data.

    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.

    Typical example: I've seen plenty SSDs, spindles, and even NVMEs with quite similiar performance in buffered mode because, as long as you don't go quite extreme the OS (especially linux) will try to make all of them seem fast.

    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.

    Thanked by 1doghouch
  • jsgjsg Member, Resident Benchmarker

    @TimboJones said:
    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.

    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.

    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.

    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

  • jsgjsg Member, Resident Benchmarker

    @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

    • improved vpsbench
    • created a driver that runs vpsbench at random times no less than x times a day and no more than y times a day. This allows for automatic gathering of performance data over the full day at unpredictable times but within a well defined time range.
    • had a well known provider asking me nicely to check some of his locations to spot potential problems and inconsistencies.

    This can't be referred to as a "tech site" with this level of stupidity.

    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?

  • LeeLee Veteran

    @1606234 said: 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?

    Thanked by 2TimboJones doghouch
  • @Lee said:

    @1606234 said: 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 🤣

    Thanked by 1Lee
  • jsgjsg Member, Resident Benchmarker
    edited August 2020

    @Lee said:

    @1606234 said: 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?

    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.

  • @1606234 said:
    If it's true that benchmark is flawed, but all the comparisons are use the same benchmark, does it matter?

    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.

    Thanked by 1jsg
  • @rcxb said: 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?

  • jsgjsg Member, Resident Benchmarker

    @PHDan said:
    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.

  • @PHDan said:
    Does it matter if the data is in cache and not on disk?

    It does if you care about data corruption. I certainly do.

  • @jsg said:
    Btw, while you were busy taking dumps here and attacking me I

    • improved vpsbench

    Link or it didn't happen.

  • PHDanPHDan Member
    edited September 2020

    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.

  • @PHDan said:

    You know, I just typed out a response to you and then deleted it. You don't want any answers, you want to bitch.

    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.

    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.

    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.

  • @TimboJones said: I'm fine with people thinking I'm a cunt. It's no secret lots of people think you're a cunt, as well.

    You both are.

    Glad I could join this conversation.

    Thanked by 2skorous TimboJones
  • @TimboJones said: It's no secret lots of people think you're a cunt, as well.

    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.

    @SCAM_DONT_BUY said: You both are.

    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...

  • @PHDan said:

    @SCAM_DONT_BUY said: You both are.

    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.

    Thanked by 1PHDan
  • You two really need couples counseling.

    Thanked by 2raindog308 vimalware
  • jsgjsg Member, Resident Benchmarker
    edited September 2020

    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:

    2ab5364937fcd9f2e1e15e470f1b3f499099b85712f9183195cd7267aeb09e3a  vpsb-lx64-203b
    3a1779f98dbdbe4a4ca14250ce5e5fe4bd40b7ff097c920ffd9339bdf4073801  vpsb-lx64-203b-pack.tar.gz
    addca93c27ffabda9b1aeb3870b62deb1a84e0c164906e0fe43afa9259a0e498  vpsb-fb64-203b
    1df60605fd492238cf72e8bf9522952409ab1f113c13f4a0b5ced1fcb1838e09  vpsb-fb64-203b-pack.tar.gz
    

    Btw, please note that the binaries are quite small, less than 250 KB.

  • xTomxTom Member, Patron Provider
    Version 2.0.3b, (c) 2018+ jsg (->lowendtalk.com)
    Machine: amd64, Arch.: x86_64, Model: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
    OS, version: Linux 4.19.0, Mem.: 1.971 GB
    CPU - Cores: 2, Family/Model/Stepping: 6/45/7
    Cache: 32K/32K L1d/L1i, 2M L2, 16M L3
    Std. Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
              pse36 cflsh mmx fxsr sse sse2 ss htt sse3 pclmulqdq ssse3 cx16 pcid
              sse4_1 sse4_2 x2apic popcnt tsc_deadline aes xsave osxsave avx
              hypervisor
    Ext. Flags: tsc_adjust syscall nx pdpe1gb rdtscp lm lahf_lm
    
    ----- Processor and Memory -----
    .................
    [PM-SC] 186.78 MB/s (testSize: 2.0 GB)
    .................
    [PM-MC] 401.12 MB/s (testSize: 8.0 GB)
    ----- Disk -----
    [D] Total size per test = 2048.00 MB, Mode: Sync
    ..... [D] Wr Seq:   6.07 s ~   337.61 MB/s
    ..... [D] Wr Rnd:   2.52 s ~   811.53 MB/s
    ..... [D] Rd Seq:   2.02 s ~  1012.82 MB/s
    ..... [D] Rd Rnd:   0.57 s ~  3598.54 MB/s
    ----- Network -----
    Error: Can't open file ntargets
    

    Get error on Debian 10 buster

  • jsgjsg Member, Resident Benchmarker

    @xTom said:

    ...> ----- Network -----
    Error: Can't open file ntargets
    

    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:

    http://nyc.download.datapacket.com/1000mb.bin           US NYC
    #http://speedtest.ny.buyvm.net/100MB.test US NYC
    speedtest.tokyo2.linode.com/100MB-tokyo2.bin JP TOK
    
  • @Lee said:

    @1606234 said: 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?

    I’m a bit late to the party but the “same flawed way” comment was way too funny to ignore.

  • vimalwarevimalware Member
    edited September 2020

    If you're curious about the Source code : https://bit.ly/3k3A4AP

    Thanked by 1TimboJones
  • jsgjsg Member, Resident Benchmarker
    edited September 2020
    • Due to a lot of noise about the oh soooo important need to check the source code for v.1 I gave in and published the source code. Result: Not even 3 people downloaded the source and highly likely no more than 1 or 2 (if that) actually looked at it.
    • I clearly and openly stated that I will not publish the source for v.2 for multiple reasons.
    • Since when is there a rule that investing dozens of hours to develop something and to make it freely available for the community isn't good enough? Since when is there an obligation to also publish the source?
    • On my side I have invested quite some time and effort (and research and knowledge and work) - on the other side what was on the table other than demands, mistrust, and even attacks?
    • @vimalware asked for checksums and I went the extra step and copied the sha256 from my SCM to the download and also published them here. And what do I get for it? A rude hint that evil me do not also provide the source ...

    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?

  • jsgjsg Member, Resident Benchmarker
    edited September 2020

    @hzr said:
    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

  • kalipuskalipus Member
    edited September 2020

    missing source code, units in test results and some formatting, export to html and bbcode/markdown would be nice future feature

Sign In or Register to comment.