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
^ Stupid me: I thought the internet was global. :-|
It is but piring is mater
@MasonR
Have just tried your script on Devuan Ascii i386, and there are errors such as:
The errors repeat and I need to stop the script manually.
Yes, of course, iperf3 is installed ( /usr/bin/iperf3 ), also the iperf3 dev package (but is this latter one also needed?).
I've also tried to run as root, but the same errors occur.
(Is the script only for amd64?)
This is simply a quick reaction -- I haven't looked into the matter further.
Why the double up on regions?
How many of your servers did you YABS'ed today?
I disagree. Speedtest is a single threaded connection (which almost never is capable of breaching > 1gbps). While on the otherhand, with iperf, you'll have many parallel connections providing a better representation of how your server will handle many high-bandwidth connections simultaneously.
Speedtest has the advantage of being simpler, but that's about it. If you're just trying to see how fast a single connection to some point in the world might be, then sure it's fine. But if you're trying to benchmark your servers total throughput, then iperf has it beat by a mile.
The iperf and ioping binaries are 64-bit only. I can probably compile a 32-bit version of ioping, but I'm not sure if a 32-bit static binary for iperf exists. I'll take a look around, though. I suppose I could also put in a check to see if iperf is installed first before downloading the portable binary.
Needs some refinement. Again, this is just the beta test for this script. I'll probably change the iperf locations over time if I can find suitable alternatives in other locations of the world. Issue is that there aren't many public iperf servers at all, so all the available public ones have already been added to the script. Luckily I received an offer to sponsor a few iperf locations, so I may host some sponsored locations myself for this.
IT'S OVER 9000!!!¡!!!¡!!!11!¡¡
Ah, so both ioping and iperf3 are downloaded from somewhere?
Perhaps it's a simple-minded question, but why not use local binaries instead? Why not make the script dependent on these binaries being locally available? (One doesn't need to be paranoid to prefer the use of local binaries.)
Anyway, the documentation should say that it's amd64 only (but perhaps I missed this).
I probably could be a bit more transparent, but the code is all there (even though it's a somewhat jumbled mess in its current state). But yes, ioping is downloaded from my repo (it's a pre-compiled static binary from a 64-bit machine, but I could probably make a 32-bit version as well and detect which one to snag). And iperf3 is downloaded from the iperf.fr site.
I decided against local binaries, because I wanted the script to not require any external dependecies to be installed prior to running the script. While not a high barrier of entry, it's obvious that much of bench.sh/nench.sh's success is that you can simply run the one-liner and not have to worry about anything being installed prior. Once you start adding in pre-reqs, more than half of the potential users of the script have already been turned off. If local binaries are preferred for security reasons or similar, I could potentially add a flag that won't grab any external binaries and only use what's local (if available). I'll have to think about that more.
And yes, the documentation needs updated for sure. You guys are my guinea pigs after all, so all feedback in this thread is going to help polish the script and docs as it evolves.
Okay, please take this for what it's worth: I really think that you need to say very clearly on the GitHub page that your script downloads two binaries.
Compare the GitHub page for nench ( https://github.com/n-st/nench ):
I agree. Will be added soon in the next round of updates.
So my wish-list would be:
Duly noted! The 32-bit version is likely to come first. The local binaries option will need quite a bit of testing, thus will take longer to make it in. I foresee some potential issues of old versions of iperf/ioping outputting results differently than I'm used to compared the pre-compiled binaries, which will throw off the script when the values are grep'd/awk'd/printf'd.
Using local binaries would also open the door to being able to run fio tests. I could easily check if fio is available locally and run some fio tests if so to satisfy @Falzo's hunger and thirst. Just a thought.
VM: Microsoft Azure, x64, Ubuntu 16 LTS
Could be interesting to make it work on BSD.
@coreflux can you run this
curl -LsO bench.monster/speedtest.sh; sh speedtest.sh -Global
We share the same code
I think libaio is the fio hurdle, but not 100% sure... afaik fio could be run without using libaio and therefore a precompiled binary still might work. not 100% sure though.
Silly me, it's seems I shouldn't bench Azure B1LS, it might be burstable but throttled ~10% even on single burstable vCore. Won't take a minute before got throttled immediately.
It takes more than 5minutes just to install bzip2 and yet installed till now,... #lol
And sometimes VM got freezed so I reboot it from VM dashboard.
upcloud San Jose on Ubuntu 18.04
https://pastebin.com/C4NMKwyR
great CPU
@MasonR, is Geekbench URL missing because of the unusual CPU name?
Also, a real-world CPU benchmark of sorts could prove useful (other than the synthetic ol' Geekbench). E.g. "openssl -evp aes-256-gcm" ([-bytes 16], or parsing results for the smallest block size) makes for a rough, not too biased estimate of what speeds to expect when AES-encrypting stuff (ssh, vpns, luks...)
No, it's likely because geekbench hit an error or didn't complete fully for some reason, thus didn't produce a url to grab the results. I realize now that there's no error handling for when these cases occur, so I've put on my to-do list to put that in. If you can run a Geekbench 4 test manually and let me know what happens, that would help me debug a bit.
Virmach 10G buffalo
above there is a 4 core vps test that has same bench scores like mine
is it because of aes-ni or cpu passthroug thing?
Please add (check https://bench.monster/speedtest.html)
Plenty of variables that could be at play. The biggest one being that the geekbench score you're comparing to has E3 cores (high clock speed) while your VM likely has E5 cores (low/mid clock speed). You'll likely always have E3's outperforming E5's core-for-core unless overselling becomes an issue.
Thanks, I'll consider it. However, I can't say I've ever seen anyone caring about, worried about, or even remotely interested in RAM speed.
RAM speed is almost never a bottleneck so I consider it unnecessary information in a bench.
Yes, it seems Geekbench is getting killed (because my VPS has only 512 MB RAM).
In a year or 2, SSD cache (optane or Xpoint) may be marketed as RAM...
I've run Geekbench successfully on a VPS with 512MB RAM, but my VPS has 1GB swap space:
https://browser.geekbench.com/v4/cpu/14823496
I see that your VPS doesn't have swap space.
Hi Mason,
Could you please add Singapore location?
Also, Indonesia location (Biznet) seems pretty difficult to get the result. Jakarta is better than Bogor afaik in term of internet infrastructure.