@nick_ said:
I just noticed that the bandwidth used in both directions is around 90-100 GB every time you yabs. This is not only me and it's normal, right?
@nick_ said:
I just noticed that the bandwidth used in both directions is around 90-100 GB every time you yabs. This is not only me and it's normal, right?
normal for 10G network tests.
Thanks for the clarification! I got it now. I'll be more careful not to yabs randomly on VPSs with small bandwidth at a 10 Gbps port. Otherwise, they would get suspended after several yabs.
@nick_ said:
I just noticed that the bandwidth used in both directions is around 90-100 GB every time you yabs. This is not only me and it's normal, right?
normal for 10G network tests.
Thanks for the clarification! I got it now. I'll be more careful not to yabs randomly on VPSs with small bandwidth at a 10 Gbps port. Otherwise, they would get suspended after several yabs.
yes i almost got suspended within hours of getting new VPS with 750GB bandwidth lol
FABRIC Testbed default spec in WASH location, free for non-profit research purpose.
IPv4 is via experiment interface (ESnet peering); IPv6 is via management interface.
@Mason - is it somehow possible to make the iperf and fio tests less CPU intensive? This exhausts the CPU allocation on some VPSes which ends up giving a skewed GB5 result.
@stevewatson301 said: @Mason - is it somehow possible to make the iperf and fio tests less CPU intensive? This exhausts the CPU allocation on some VPSes which ends up giving a skewed GB5 result.
I can look into that, but I'm not aware of any possible settings that would resolve that. Tests are basically trying to push everything to the max, so any artificial limits would taint the results.
Im curious how the other tests would interfere with GB. Everything is run sequentially, so no tests should be stepping on the others' toes, unless you're saying that the tests are causing the CPU to be throttled by the time the GB test is run, to which, I'd simply suggest to run YABS with only GB first, then run a second time for the disk and network tests. But then I suppose you run into the issue of GB's high CPU usage negatively affecting the other tests afterwards.
@Mason said: unless you're saying that the tests are causing the CPU to be throttled by the time the GB test is run
This is correct. I only raised it in the interest of making the benches more accurate and to not give a skewed result to those relying on YABS.
Perhaps the default iperf3 mode could detect neighbouring servers through IP geolocation and run the test only on these servers, as a way to reduce the CPU usage due to the network bench. fio tests could use the same number of cores as the system, instead of relying on the static values of 4 threads (if I remember correctly, I last looked at this a year ago).
An easier idea could be to simply introduce a 2-3 second pause between each fio and iperf3 test, as a way to prevent skewing. Geekbench internally uses 1 second pauses between each test as a way to prevent thermal throttling, although none of this helps for environments that like to quickly throttle such as the T-family of EC2 instances.
@Mason said: unless you're saying that the tests are causing the CPU to be throttled by the time the GB test is run
This is correct. I only raised it in the interest of making the benches more accurate and to not give a skewed result to those relying on YABS.
Perhaps the default iperf3 mode could detect neighbouring servers through IP geolocation and run the test only on these servers, as a way to reduce the CPU usage due to the network bench. fio tests could use the same number of cores as the system, instead of relying on the static values of 4 threads (if I remember correctly, I last looked at this a year ago).
An easier idea could be to simply introduce a 2-3 second pause between each fio and iperf3 test, as a way to prevent skewing. Geekbench internally uses 1 second pauses between each test as a way to prevent thermal throttling, although none of this helps for environments that like to quickly throttle such as the T-family of EC2 instances.
Got it! I would like to revamp the way iperf servers are selected and move to a more random/dynamic selection trather than using a select few that are constantly used over and over. Maybe some geolocation can be done to smartly select some close by servers. For now, the only option to limit the servers used is the -r flag.
There already is a small wait between iperf tests (only 1 second), which could be increased if it'll be beneficial. No wait between fio tests yet, but can easily throw that in.
VirMach Ryzen Special 384 Tokyo ($17.76 biennially)
768 MB RAM 1 Ryzen 5900X CPU 10 GB NVMe 2 TB bandwidth
I got 2x RAM and bandwidth from a bug report.
AWS c6g.large (dedicated cores), us-west-2, $49/mo + $2.5 GP2 disk + egress fees. Similar to the a1.large I posted earlier, except for better GB scores.
I created the ticket and got it supported and it's back to normal. The reason given was that my vps had an incorrect CPU resource limit policy and they removed it.
Comments
Limewave Communications SEAV4GB $6/month after coupon (I got it for free for 3 months from their giveaway)
Almalinux 9 minimal doesn't have
tarso GB5 failed. After fixing that:I just noticed that the bandwidth used in both directions is around 90-100 GB every time you yabs. This is not only me and it's normal, right?
App DevTools | AppPDF | Convert.in.th | ConvertOnline | Imagez | ImgTools
normal for 10G network tests.
I bench YABS 24/7/365 unless it's a leap year.
Thanks for the clarification! I got it now. I'll be more careful not to yabs randomly on VPSs with small bandwidth at a 10 Gbps port. Otherwise, they would get suspended after several yabs.
App DevTools | AppPDF | Convert.in.th | ConvertOnline | Imagez | ImgTools
yes i almost got suspended within hours of getting new VPS with 750GB bandwidth lol
I bench YABS 24/7/365 unless it's a leap year.
FABRIC Testbed default spec in WASH location, free for non-profit research purpose.
IPv4 is via experiment interface (ESnet peering); IPv6 is via management interface.
HostBrr aff best VPS; VirmAche aff worst VPS.
Unable to push-up due to shoulder injury 😣
BuyVM LUX with Ryzen 5900X but GB5 only 190.
https://dttech.top - Personal Site.
Its GB8 not GB5 @dinhvanlocitvn
Vultr Tokyo 1 core, 1GB RAM, 25GB disk, 2TB transfer $6/month
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
20$? Gimme the link.
Amadex • Hosting Forums • Wie ist meine IP-Adresse? • AS215325
Forum for System Administrators: sysadminforum.com
@Amadex sold out rn
Team push-ups!
Which location? I like it.
Amadex • Hosting Forums • Wie ist meine IP-Adresse? • AS215325
Forum for System Administrators: sysadminforum.com
There's a PR in the repo to add latency/ping to the iperf tests. Is that something you guys would want?
Head Janitor @ LES • About • Rules • Support
That would be dope!
Team push-ups!
@Mason - is it somehow possible to make the iperf and fio tests less CPU intensive? This exhausts the CPU allocation on some VPSes which ends up giving a skewed GB5 result.
I can look into that, but I'm not aware of any possible settings that would resolve that. Tests are basically trying to push everything to the max, so any artificial limits would taint the results.
Im curious how the other tests would interfere with GB. Everything is run sequentially, so no tests should be stepping on the others' toes, unless you're saying that the tests are causing the CPU to be throttled by the time the GB test is run, to which, I'd simply suggest to run YABS with only GB first, then run a second time for the disk and network tests. But then I suppose you run into the issue of GB's high CPU usage negatively affecting the other tests afterwards.
Head Janitor @ LES • About • Rules • Support
This is correct. I only raised it in the interest of making the benches more accurate and to not give a skewed result to those relying on YABS.
Perhaps the default iperf3 mode could detect neighbouring servers through IP geolocation and run the test only on these servers, as a way to reduce the CPU usage due to the network bench. fio tests could use the same number of cores as the system, instead of relying on the static values of 4 threads (if I remember correctly, I last looked at this a year ago).
An easier idea could be to simply introduce a 2-3 second pause between each fio and iperf3 test, as a way to prevent skewing. Geekbench internally uses 1 second pauses between each test as a way to prevent thermal throttling, although none of this helps for environments that like to quickly throttle such as the T-family of EC2 instances.
Got it! I would like to revamp the way iperf servers are selected and move to a more random/dynamic selection trather than using a select few that are constantly used over and over. Maybe some geolocation can be done to smartly select some close by servers. For now, the only option to limit the servers used is the -r flag.
There already is a small wait between iperf tests (only 1 second), which could be increased if it'll be beneficial. No wait between fio tests yet, but can easily throw that in.
Head Janitor @ LES • About • Rules • Support
VirMach Ryzen Special 384 Tokyo ($17.76 biennially)
768 MB RAM 1 Ryzen 5900X CPU 10 GB NVMe 2 TB bandwidth
I got 2x RAM and bandwidth from a bug report.
App DevTools | AppPDF | Convert.in.th | ConvertOnline | Imagez | ImgTools
AWS c6g.large (dedicated cores), us-west-2, $49/mo + $2.5 GP2 disk + egress fees. Similar to the a1.large I posted earlier, except for better GB scores.
Maybe you just got unlucky with neighbour when you ran your test:
I created the ticket and got it supported and it's back to normal. The reason given was that my vps had an incorrect CPU resource limit policy and they removed it.
https://dttech.top - Personal Site.
Spaceberg.cc - Your favorite Seedbox provider!
Crunchbits Technical Support, Technical Writer, and Sales
Contact me at: +1 (509) 606-3569 or [email protected]
Clean server, without tuning.
Spaceberg.cc - Your favorite Seedbox provider!
Spaceberg.cc - Your favorite Seedbox provider!
Spaceberg.cc - Your favorite Seedbox provider!
The AMSD030X Virmach Amsterdam temp test server. It's been solid like a rock for me, two weeks at a time:
good heavens, new vps, it's hammeryabs time
webhorizon VZ512MB Japan $2 monthly
Fuck this 24/7 internet spew of trivia and celebrity bullshit.
I smell black Friday!
Crunchbits Technical Support, Technical Writer, and Sales
Contact me at: +1 (509) 606-3569 or [email protected]