Howdy, Stranger!

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


HAZI.ro | 25% LIFETIME VPS/VDS Servers | Extra IPs 0.75€/mo - 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.

HAZI.ro | 25% LIFETIME VPS/VDS Servers | Extra IPs 0.75€/mo

2

Comments

  • spiritysdxspiritysdx Barred
    edited July 2022

    @NoComment said:
    You are indeed right but at this point it is questionable if @FlorinMarian is happy with traffic exchange customers. It probably isn't a problem with "dedicated cpu" and "unmetered bandwidth" but some providers don't like traffic exchange.

    just run a traceroute to less than 10 IP
    and they suspend my server
    It's even not triggered by my speedtest-cli behavior

    https://github.com/zhanghanyun/backtrace/blob/9bcda4140335d7c419f400232512d0803831a373/asn.go#L16-L19

  • @NoComment said:

    @spiritysdx said:
    https://github.com/zhanghanyun/backtrace
    The collection script I used, the script used for backhaul routing, and the address you mentioned in the screenshot.

    You are indeed right but at this point it is questionable if @FlorinMarian is happy with traffic exchange customers. It probably isn't a problem with "dedicated cpu" and "unmetered bandwidth" but some providers don't like traffic exchange.

    To add, out of all the merchants I've seen that I've purchased from, none of them have blocked my machine for the reason you mentioned.

  • sotssots Member

    @yoursunny said:
    A single YABS triggers "permanent mitigation" that your network speed would decrease to less than 20 Mbps.
    A single "abuse", including zero day attack that is not your fault, causes service deletion with 30-minute notice and no second chances.

    Also, IPv6 and push-up payment method are missing.

    That's terrible. Why didn't this scamming provider get banned from LET? Seems that there are already some victims in LET.

  • @spiritysdx said:

    @NoComment said:
    You are indeed right but at this point it is questionable if @FlorinMarian is happy with traffic exchange customers. It probably isn't a problem with "dedicated cpu" and "unmetered bandwidth" but some providers don't like traffic exchange.

    just run a traceroute to less than 10 IP
    and they suspend my server
    It's even not triggered by my speedtest-cli behavior

    https://github.com/zhanghanyun/backtrace/blob/9bcda4140335d7c419f400232512d0803831a373/asn.go#L16-L19

    I think this owner just for fun for banning customers

  • FlorinMarianFlorinMarian Member, Host Rep

    @sots said:

    @yoursunny said:
    A single YABS triggers "permanent mitigation" that your network speed would decrease to less than 20 Mbps.
    A single "abuse", including zero day attack that is not your fault, causes service deletion with 30-minute notice and no second chances.

    Also, IPv6 and push-up payment method are missing.

    That's terrible. Why didn't this scamming provider get banned from LET? Seems that there are already some victims in LET.

    To be banned for what?
    The YABS thing is simple. When you download at full capacity from multiple sources in a short period of time, Voxility limits INBOUND traffic and the customer only has to open a ticket informing us that it has entered permanent mitigation and we make a request to Datacenter to remove limitation.
    Oh, that you like drama, it's something else entirely :)

  • NoCommentNoComment Member
    edited July 2022

    @spiritysdx said:

    @NoComment said:

    @spiritysdx said:
    https://github.com/zhanghanyun/backtrace
    The collection script I used, the script used for backhaul routing, and the address you mentioned in the screenshot.

    You are indeed right but at this point it is questionable if @FlorinMarian is happy with traffic exchange customers. It probably isn't a problem with "dedicated cpu" and "unmetered bandwidth" but some providers don't like traffic exchange.

    To add, out of all the merchants I've seen that I've purchased from, none of them have blocked my machine for the reason you mentioned.

    Don't pretend you are unaware that traffic exchange is fraud. Not only is traffic exchange fraud, it usually is a resource hog for something pointless and fraudulent. Every provider could technically kick you out with some fraud/illegal activity clause. Some outright mention that traffic exchange isn't allowed.

    Just because you didn't get caught doesn't make traffic exchange a legit usecase. But I don't care what hazi.ro thinks of traffic exchange. Just setting the record straight that traffic exchange is usually frowned upon.

  • @NoComment said:

    @spiritysdx said:

    @NoComment said:

    @spiritysdx said:
    https://github.com/zhanghanyun/backtrace
    The collection script I used, the script used for backhaul routing, and the address you mentioned in the screenshot.

    You are indeed right but at this point it is questionable if @FlorinMarian is happy with traffic exchange customers. It probably isn't a problem with "dedicated cpu" and "unmetered bandwidth" but some providers don't like traffic exchange.

    To add, out of all the merchants I've seen that I've purchased from, none of them have blocked my machine for the reason you mentioned.

    Don't pretend you are unaware that traffic exchange is fraud. Not only is traffic exchange fraud, it usually is a resource hog for something pointless and fraudulent. Every provider could technically kick you out with some fraud/illegal activity clause. Some outright mention that traffic exchange isn't allowed.

    Just because you didn't get caught doesn't make traffic exchange a legit usecase. But I don't care what hazi.ro thinks of traffic exchange. Just setting the record straight that traffic exchange is usually frowned upon.

    I won't be deploying something similar on another platform next time I buy it, I know.

  • @spiritysdx said:
    I won't be deploying something similar on another platform next time I buy it, I know.

    "I'm sorry because I got caught"

    Thanked by 3bulbasaur Liso foitin
  • yoursunnyyoursunny Member, IPv6 Advocate

    @FlorinMarian said:

    @sots said:

    @yoursunny said:
    A single YABS triggers "permanent mitigation" that your network speed would decrease to less than 20 Mbps.
    A single "abuse", including zero day attack that is not your fault, causes service deletion with 30-minute notice and no second chances.

    Also, IPv6 and push-up payment method are missing.

    That's terrible. Why didn't this scamming provider get banned from LET? Seems that there are already some victims in LET.

    To be banned for what?
    The YABS thing is simple. When you download at full capacity from multiple sources in a short period of time, Voxility limits INBOUND traffic and the customer only has to open a ticket informing us that it has entered permanent mitigation and we make a request to Datacenter to remove limitation.
    Oh, that you like drama, it's something else entirely :)

    What we ask for is disabling this "limit inbound traffic after YABS" feature or automatically making the request whenever such limit has been applied without needing a ticket from customer, because YABS is a totally legitimate use case.

  • NoCommentNoComment Member
    edited July 2022

    @jmgcaguicla said:

    @spiritysdx said:
    I won't be deploying something similar on another platform next time I buy it, I know.

    "I'm sorry because I got caught"

    What's funny is he didn't even get caught for traffic exchange and now maybe there is just cause to terminate his service.

    @yoursunny said: What we ask for is disabling this "limit inbound traffic after YABS" feature or automatically making the request whenever such limit has been applied without needing a ticket from customer, because YABS is a totally legitimate use case.

    I'm guessing he can't disable this limit and I haven't heard of this kinda thing from voxility antiddos. It's probably some sort of cost-saving measure by his datacenter when providing him an antiddos addon for 1U colocation (at a dirt cheap price).

    Thanked by 1FlorinMarian
  • FlorinMarianFlorinMarian Member, Host Rep

    @yoursunny said:

    @FlorinMarian said:

    @sots said:

    @yoursunny said:
    A single YABS triggers "permanent mitigation" that your network speed would decrease to less than 20 Mbps.
    A single "abuse", including zero day attack that is not your fault, causes service deletion with 30-minute notice and no second chances.

    Also, IPv6 and push-up payment method are missing.

    That's terrible. Why didn't this scamming provider get banned from LET? Seems that there are already some victims in LET.

    To be banned for what?
    The YABS thing is simple. When you download at full capacity from multiple sources in a short period of time, Voxility limits INBOUND traffic and the customer only has to open a ticket informing us that it has entered permanent mitigation and we make a request to Datacenter to remove limitation.
    Oh, that you like drama, it's something else entirely :)

    What we ask for is disabling this "limit inbound traffic after YABS" feature or automatically making the request whenever such limit has been applied without needing a ticket from customer, because YABS is a totally legitimate use case.

    I tried this, but the response from the datacenter was prompt. "We rule out exposing your entire IP class to disrupting the entire datacenter in the event of an attack." (then 256 IP addresses, now 768).

  • yoursunnyyoursunny Member, IPv6 Advocate

    @FlorinMarian said:

    @yoursunny said:
    What we ask for is disabling this "limit inbound traffic after YABS" feature or automatically making the request whenever such limit has been applied without needing a ticket from customer, because YABS is a totally legitimate use case.

    I tried this, but the response from the datacenter was prompt. "We rule out exposing your entire IP class to disrupting the entire datacenter in the event of an attack." (then 256 IP addresses, now 768).

    Since you are able to send a request to remove the restriction, you can automate sending the request without waiting for customer to open the ticket.

  • FlorinMarianFlorinMarian Member, Host Rep

    @yoursunny said:

    @FlorinMarian said:

    @yoursunny said:
    What we ask for is disabling this "limit inbound traffic after YABS" feature or automatically making the request whenever such limit has been applied without needing a ticket from customer, because YABS is a totally legitimate use case.

    I tried this, but the response from the datacenter was prompt. "We rule out exposing your entire IP class to disrupting the entire datacenter in the event of an attack." (then 256 IP addresses, now 768).

    Since you are able to send a request to remove the restriction, you can automate sending the request without waiting for customer to open the ticket.

    I have no idea when someone has issues with download speed.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @FlorinMarian said:

    @yoursunny said:

    @FlorinMarian said:

    @yoursunny said:
    What we ask for is disabling this "limit inbound traffic after YABS" feature or automatically making the request whenever such limit has been applied without needing a ticket from customer, because YABS is a totally legitimate use case.

    I tried this, but the response from the datacenter was prompt. "We rule out exposing your entire IP class to disrupting the entire datacenter in the event of an attack." (then 256 IP addresses, now 768).

    Since you are able to send a request to remove the restriction, you can automate sending the request without waiting for customer to open the ticket.

    I have no idea when someone has issues with download speed.

    You should be receiving a notice if one of the IP is getting "attacked".
    Upon receiving the notice, automatically send a request to the data center to remove inbound restriction.
    However, send only one request every 24 hours, so that real attacks are still blocked.

    Every DDoS protection system should have a notification feature.
    If they don't, stop using this DDoS protection system and just offer unprotected IP.

  • RapToNRapToN Member, Host Rep

    @FlorinMarian Are you sure this is a Voxility limitation?
    I am using there DDoS Protection for years now and never had such a Problem on one of my IPs.

  • FlorinMarianFlorinMarian Member, Host Rep

    @yoursunny said:

    @FlorinMarian said:

    @yoursunny said:

    @FlorinMarian said:

    @yoursunny said:
    What we ask for is disabling this "limit inbound traffic after YABS" feature or automatically making the request whenever such limit has been applied without needing a ticket from customer, because YABS is a totally legitimate use case.

    I tried this, but the response from the datacenter was prompt. "We rule out exposing your entire IP class to disrupting the entire datacenter in the event of an attack." (then 256 IP addresses, now 768).

    Since you are able to send a request to remove the restriction, you can automate sending the request without waiting for customer to open the ticket.

    I have no idea when someone has issues with download speed.

    You should be receiving a notice if one of the IP is getting "attacked".
    Upon receiving the notice, automatically send a request to the data center to remove inbound restriction.
    However, send only one request every 24 hours, so that real attacks are still blocked.

    Every DDoS protection system should have a notification feature.
    If they don't, stop using this DDoS protection system and just offer unprotected IP.

    I'll ask for such notification but probably they're notified by Voxility at DC level.> @RapToN said:

    @FlorinMarian Are you sure this is a Voxility limitation?
    I am using there DDoS Protection for years now and never had such a Problem on one of my IPs.

    My DC isn't direct customer to Voxility, probably there are other filters between my end servers and Voxility.

  • sotssots Member

    @FlorinMarian said:

    @sots said:

    @yoursunny said:
    A single YABS triggers "permanent mitigation" that your network speed would decrease to less than 20 Mbps.
    A single "abuse", including zero day attack that is not your fault, causes service deletion with 30-minute notice and no second chances.

    Also, IPv6 and push-up payment method are missing.

    That's terrible. Why didn't this scamming provider get banned from LET? Seems that there are already some victims in LET.

    To be banned for what?
    The YABS thing is simple. When you download at full capacity from multiple sources in a short period of time, Voxility limits INBOUND traffic and the customer only has to open a ticket informing us that it has entered permanent mitigation and we make a request to Datacenter to remove limitation.
    Oh, that you like drama, it's something else entirely :)

    Racknerd also uses Voxility for DDoS protection, but we've never heard a customer got banned because of too much inbound or outbound traffic or YABS.

    Thanked by 3Hishiro yoursunny adly
  • zedzed Member

    is it a requirement that romanian providers always bring such entertainment?

  • @zed said:
    is it a requirement that romanian providers always bring such entertainment?

    I've got my popcorn ready. xD

  • FlorinMarianFlorinMarian Member, Host Rep

    I requested during the day to receive notification when an IP enters the permanent mitigation (approved) and after taking the 3rd physical server we gain more courage and directly request an API in which we remove any IP from the permanent mitigation.
    When the 3rd server appears, I would also like to take my own AS number in order to have more control over the rented resources.
    Thank you all for your advice, suggestions and criticism.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @FlorinMarian said:
    I requested during the day to receive notification when an IP enters the permanent mitigation (approved) and after taking the 3rd physical server we gain more courage and directly request an API in which we remove any IP from the permanent mitigation.
    When the 3rd server appears, I would also like to take my own AS number in order to have more control over the rented resources.

    That's how you do it, way to go!
    HAZI to the moon!

    Thank you all for your advice, suggestions and criticism.

    Bros help bros build a better network.

  • @yoursunny said:

    @FlorinMarian said:
    Thank you all for your advice, suggestions and criticism.

    Bros help bros build a better network.

    What a wholesome ending

    image

  • FlorinMarianFlorinMarian Member, Host Rep

    Today we sent a new request to add an exception on our subnets to that rule that triggers permanent mitigation when running YABS.
    They said that on Monday they will talk to the network administrator to see if he can do such a thing.
    Wish us good luck, we need it.

    Thanked by 2JayEs Zyra
  • stefemanstefeman Member
    edited July 2022

    @FlorinMarian said:
    Today we sent a new request to add an exception on our subnets to that rule that triggers permanent mitigation when running YABS.
    They said that on Monday they will talk to the network administrator to see if he can do such a thing.
    Wish us good luck, we need it.

    If they do it, please tell us here so I'll know if I need to move my DayZ SA server to another provider from Voxility.

    Theres 2 ways they can do it.

    1. Whitelist the YABS script's IPs. If they go this route, they likely want to fix it at once for all customers, so it will be applied globally and not just into your subnet, cause others will then ask about same fix too later on.
    2. Whitelist iperf3-like traffic. Which is even more retarded.

    They will likely go for 1. since its faster to implement, and they are lazy as fuck since their prices are low.

    In case of 1. you can just modify and recompile an attack script, to spoof specifically into YABS listed IPs and send whatever you want and it will go through. Amplification wont go through, but usually the attackers have more than one dedicated server and plenty of bandwidth anyway.

    In case of 2. you just construct a packet that is iperf3 and spam that. You can even do it on zmap which can be installed with normal apt-get.. no need for any external scripts or files or compiling.

    Whichever way they choose to implement it, it will be abused for sure.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @stefeman said:
    Whitelist the YABS script's IPs. If they go this route, they likely want to fix it at once for all customers, so it will be applied globally and not just into your subnet, cause others will then ask about same fix too later on.

    The next month, YABS adds new destination, and the drama returns.

    Whitelist iperf3-like traffic. Which is even more retarded.
    you just construct a packet that is iperf3 and spam that.

    iperf3 requires a TCP control connection.
    The firewall/IDS can detect the presence (and even content) of this control connection before allowing UDP traffic.

    A typical iperf3 session is short in duration.
    In YABS, only one iperf3 session is active at any given time.
    If a local IP is creating more than 120 iperf3 flows within 60 seconds or if each flow has lasted more than 120 seconds, this is likely an attack and the firewall/IDS can block further iperf3 traffic for 12 hours.

    Thanked by 1Xrmaddness
  • @yoursunny said:

    @stefeman said:
    Whitelist the YABS script's IPs. If they go this route, they likely want to fix it at once for all customers, so it will be applied globally and not just into your subnet, cause others will then ask about same fix too later on.

    The next month, YABS adds new destination, and the drama returns.

    Whitelist iperf3-like traffic. Which is even more retarded.
    you just construct a packet that is iperf3 and spam that.

    iperf3 requires a TCP control connection.
    The firewall/IDS can detect the presence (and even content) of this control connection before allowing UDP traffic.

    A typical iperf3 session is short in duration.
    In YABS, only one iperf3 session is active at any given time.
    If a local IP is creating more than 120 iperf3 flows within 60 seconds or if each flow has lasted more than 120 seconds, this is likely an attack and the firewall/IDS can block further iperf3 traffic for 12 hours.

    They'll just go with 1. then or allow all tcp/udp on iperf3 default port lol

  • VoidVoid Member

    @yoursunny said:

    @FlorinMarian said:
    I requested during the day to receive notification when an IP enters the permanent mitigation (approved) and after taking the 3rd physical server we gain more courage and directly request an API in which we remove any IP from the permanent mitigation.
    When the 3rd server appears, I would also like to take my own AS number in order to have more control over the rented resources.

    That's how you do it, way to go!
    HAZI to the moon!

    Thank you all for your advice, suggestions and criticism.

    Bros help bros build a better network.

    Bros before yabs

    Thanked by 1yoursunny
  • FlorinMarianFlorinMarian Member, Host Rep

    Today we filled last two empty cadies in our 1st hosted server.
    We had chance to optimize our BIOS settings and now CPU benchmark looks better than before :smile:

    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    #              Yet-Another-Bench-Script              #
    #                     v2022-06-11                    #
    # https://github.com/masonr/yet-another-bench-script #
    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    
    Fri Jul  8 13:18:33 EEST 2022
    
    Basic System Information:
    ---------------------------------
    Uptime     : 0 days, 0 hours, 17 minutes
    Processor  : Intel(R) Xeon(R) CPU E5-2698 v3 @ 2.30GHz
    CPU cores  : 64 @ 3600.000 MHz
    AES-NI     : ✔ Enabled
    VM-x/AMD-V : ✔ Enabled
    RAM        : 251.8 GiB
    Swap       : 0.0 KiB
    Disk       : 
    Distro     : Debian GNU/Linux 11 (bullseye)
    Kernel     : 5.15.39-1-pve
    
    fio Disk Speed Tests (Mixed R/W 50/50):
    ---------------------------------
    Block Size | 4k            (IOPS) | 64k           (IOPS)
      ------   | ---            ----  | ----           ---- 
    Read       | 375.13 MB/s  (93.7k) | 3.21 GB/s    (50.2k)
    Write      | 376.12 MB/s  (94.0k) | 3.22 GB/s    (50.4k)
    Total      | 751.26 MB/s (187.8k) | 6.44 GB/s   (100.6k)
               |                      |                     
    Block Size | 512k          (IOPS) | 1m            (IOPS)
      ------   | ---            ----  | ----           ---- 
    Read       | 3.50 GB/s     (6.8k) | 580.87 MB/s    (567)
    Write      | 3.69 GB/s     (7.2k) | 619.55 MB/s    (605)
    Total      | 7.19 GB/s    (14.0k) | 1.20 GB/s     (1.1k)
    
    iperf3 Network Speed Tests (IPv4):
    ---------------------------------
    Provider        | Location (Link)           | Send Speed      | Recv Speed     
                    |                           |                 |                
    Clouvider       | London, UK (10G)          | 2.70 Gbits/sec  | 639 Mbits/sec  
    Online.net      | Paris, FR (10G)           | 2.94 Gbits/sec  | 482 Mbits/sec  
    Hybula          | The Netherlands (40G)     | 2.68 Gbits/sec  | 995 Mbits/sec  
    Uztelecom       | Tashkent, UZ (10G)        | 1.81 Gbits/sec  | 840 Mbits/sec  
    Clouvider       | NYC, NY, US (10G)         | 1.41 Gbits/sec  | 537 Mbits/sec  
    Clouvider       | Dallas, TX, US (10G)      | 537 Mbits/sec   | 308 Mbits/sec  
    Clouvider       | Los Angeles, CA, US (10G) | 933 Mbits/sec   | 512 Mbits/sec  
    
    iperf3 Network Speed Tests (IPv6):
    ---------------------------------
    Provider        | Location (Link)           | Send Speed      | Recv Speed     
                    |                           |                 |                
    Clouvider       | London, UK (10G)          | 429 Mbits/sec   | 471 Mbits/sec  
    Online.net      | Paris, FR (10G)           | 472 Mbits/sec   | 356 Mbits/sec  
    Hybula          | The Netherlands (40G)     | 364 Mbits/sec   | 312 Mbits/sec  
    Uztelecom       | Tashkent, UZ (10G)        | 353 Mbits/sec   | 344 Mbits/sec  
    Clouvider       | NYC, NY, US (10G)         | 415 Mbits/sec   | 329 Mbits/sec  
    Clouvider       | Dallas, TX, US (10G)      | 419 Mbits/sec   | 467 Mbits/sec  
    Clouvider       | Los Angeles, CA, US (10G) | 360 Mbits/sec   | 470 Mbits/sec  
    
    Geekbench 5 Benchmark Test:
    ---------------------------------
    Test            | Value                         
                    |                               
    Single Core     | 867                           
    Multi Core      | 16315                         
    Full Test       | https://browser.geekbench.com/v5/cpu/15891977
    
  • @FlorinMarian said:
    Today we filled last two empty cadies in our 1st hosted server.
    We had chance to optimize our BIOS settings and now CPU benchmark looks better than before :smile:

    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    #              Yet-Another-Bench-Script              #
    #                     v2022-06-11                    #
    # https://github.com/masonr/yet-another-bench-script #
    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    
    Fri Jul  8 13:18:33 EEST 2022
    
    Basic System Information:
    ---------------------------------
    Uptime     : 0 days, 0 hours, 17 minutes
    Processor  : Intel(R) Xeon(R) CPU E5-2698 v3 @ 2.30GHz
    CPU cores  : 64 @ 3600.000 MHz
    AES-NI     : ✔ Enabled
    VM-x/AMD-V : ✔ Enabled
    RAM        : 251.8 GiB
    Swap       : 0.0 KiB
    Disk       : 
    Distro     : Debian GNU/Linux 11 (bullseye)
    Kernel     : 5.15.39-1-pve
    
    fio Disk Speed Tests (Mixed R/W 50/50):
    ---------------------------------
    Block Size | 4k            (IOPS) | 64k           (IOPS)
      ------   | ---            ----  | ----           ---- 
    Read       | 375.13 MB/s  (93.7k) | 3.21 GB/s    (50.2k)
    Write      | 376.12 MB/s  (94.0k) | 3.22 GB/s    (50.4k)
    Total      | 751.26 MB/s (187.8k) | 6.44 GB/s   (100.6k)
               |                      |                     
    Block Size | 512k          (IOPS) | 1m            (IOPS)
      ------   | ---            ----  | ----           ---- 
    Read       | 3.50 GB/s     (6.8k) | 580.87 MB/s    (567)
    Write      | 3.69 GB/s     (7.2k) | 619.55 MB/s    (605)
    Total      | 7.19 GB/s    (14.0k) | 1.20 GB/s     (1.1k)
    
    iperf3 Network Speed Tests (IPv4):
    ---------------------------------
    Provider        | Location (Link)           | Send Speed      | Recv Speed     
                    |                           |                 |                
    Clouvider       | London, UK (10G)          | 2.70 Gbits/sec  | 639 Mbits/sec  
    Online.net      | Paris, FR (10G)           | 2.94 Gbits/sec  | 482 Mbits/sec  
    Hybula          | The Netherlands (40G)     | 2.68 Gbits/sec  | 995 Mbits/sec  
    Uztelecom       | Tashkent, UZ (10G)        | 1.81 Gbits/sec  | 840 Mbits/sec  
    Clouvider       | NYC, NY, US (10G)         | 1.41 Gbits/sec  | 537 Mbits/sec  
    Clouvider       | Dallas, TX, US (10G)      | 537 Mbits/sec   | 308 Mbits/sec  
    Clouvider       | Los Angeles, CA, US (10G) | 933 Mbits/sec   | 512 Mbits/sec  
    
    iperf3 Network Speed Tests (IPv6):
    ---------------------------------
    Provider        | Location (Link)           | Send Speed      | Recv Speed     
                    |                           |                 |                
    Clouvider       | London, UK (10G)          | 429 Mbits/sec   | 471 Mbits/sec  
    Online.net      | Paris, FR (10G)           | 472 Mbits/sec   | 356 Mbits/sec  
    Hybula          | The Netherlands (40G)     | 364 Mbits/sec   | 312 Mbits/sec  
    Uztelecom       | Tashkent, UZ (10G)        | 353 Mbits/sec   | 344 Mbits/sec  
    Clouvider       | NYC, NY, US (10G)         | 415 Mbits/sec   | 329 Mbits/sec  
    Clouvider       | Dallas, TX, US (10G)      | 419 Mbits/sec   | 467 Mbits/sec  
    Clouvider       | Los Angeles, CA, US (10G) | 360 Mbits/sec   | 470 Mbits/sec  
    
    Geekbench 5 Benchmark Test:
    ---------------------------------
    Test            | Value                         
                    |                               
    Single Core     | 867                           
    Multi Core      | 16315                         
    Full Test       | https://browser.geekbench.com/v5/cpu/15891977
    

    Oh no, someone run a YABS, the whole server will be gone forever. What a disaster.

  • FlorinMarianFlorinMarian Member, Host Rep

    @riofredinand said:

    @FlorinMarian said:
    Today we filled last two empty cadies in our 1st hosted server.
    We had chance to optimize our BIOS settings and now CPU benchmark looks better than before :smile:

    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    #              Yet-Another-Bench-Script              #
    #                     v2022-06-11                    #
    # https://github.com/masonr/yet-another-bench-script #
    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    
    Fri Jul  8 13:18:33 EEST 2022
    
    Basic System Information:
    ---------------------------------
    Uptime     : 0 days, 0 hours, 17 minutes
    Processor  : Intel(R) Xeon(R) CPU E5-2698 v3 @ 2.30GHz
    CPU cores  : 64 @ 3600.000 MHz
    AES-NI     : ✔ Enabled
    VM-x/AMD-V : ✔ Enabled
    RAM        : 251.8 GiB
    Swap       : 0.0 KiB
    Disk       : 
    Distro     : Debian GNU/Linux 11 (bullseye)
    Kernel     : 5.15.39-1-pve
    
    fio Disk Speed Tests (Mixed R/W 50/50):
    ---------------------------------
    Block Size | 4k            (IOPS) | 64k           (IOPS)
      ------   | ---            ----  | ----           ---- 
    Read       | 375.13 MB/s  (93.7k) | 3.21 GB/s    (50.2k)
    Write      | 376.12 MB/s  (94.0k) | 3.22 GB/s    (50.4k)
    Total      | 751.26 MB/s (187.8k) | 6.44 GB/s   (100.6k)
               |                      |                     
    Block Size | 512k          (IOPS) | 1m            (IOPS)
      ------   | ---            ----  | ----           ---- 
    Read       | 3.50 GB/s     (6.8k) | 580.87 MB/s    (567)
    Write      | 3.69 GB/s     (7.2k) | 619.55 MB/s    (605)
    Total      | 7.19 GB/s    (14.0k) | 1.20 GB/s     (1.1k)
    
    iperf3 Network Speed Tests (IPv4):
    ---------------------------------
    Provider        | Location (Link)           | Send Speed      | Recv Speed     
                    |                           |                 |                
    Clouvider       | London, UK (10G)          | 2.70 Gbits/sec  | 639 Mbits/sec  
    Online.net      | Paris, FR (10G)           | 2.94 Gbits/sec  | 482 Mbits/sec  
    Hybula          | The Netherlands (40G)     | 2.68 Gbits/sec  | 995 Mbits/sec  
    Uztelecom       | Tashkent, UZ (10G)        | 1.81 Gbits/sec  | 840 Mbits/sec  
    Clouvider       | NYC, NY, US (10G)         | 1.41 Gbits/sec  | 537 Mbits/sec  
    Clouvider       | Dallas, TX, US (10G)      | 537 Mbits/sec   | 308 Mbits/sec  
    Clouvider       | Los Angeles, CA, US (10G) | 933 Mbits/sec   | 512 Mbits/sec  
    
    iperf3 Network Speed Tests (IPv6):
    ---------------------------------
    Provider        | Location (Link)           | Send Speed      | Recv Speed     
                    |                           |                 |                
    Clouvider       | London, UK (10G)          | 429 Mbits/sec   | 471 Mbits/sec  
    Online.net      | Paris, FR (10G)           | 472 Mbits/sec   | 356 Mbits/sec  
    Hybula          | The Netherlands (40G)     | 364 Mbits/sec   | 312 Mbits/sec  
    Uztelecom       | Tashkent, UZ (10G)        | 353 Mbits/sec   | 344 Mbits/sec  
    Clouvider       | NYC, NY, US (10G)         | 415 Mbits/sec   | 329 Mbits/sec  
    Clouvider       | Dallas, TX, US (10G)      | 419 Mbits/sec   | 467 Mbits/sec  
    Clouvider       | Los Angeles, CA, US (10G) | 360 Mbits/sec   | 470 Mbits/sec  
    
    Geekbench 5 Benchmark Test:
    ---------------------------------
    Test            | Value                         
                    |                               
    Single Core     | 867                           
    Multi Core      | 16315                         
    Full Test       | https://browser.geekbench.com/v5/cpu/15891977
    

    Oh no, someone run a YABS, the whole server will be gone forever. What a disaster.

    I have received clarifications on this subject.
    The protection that limits inbound traffic is actually a local one, created at the datacenter level in the idea that they had situations in which Voxility entered so late that the entire datacenter had lost its internet connection.
    I think it is important to specify that this datacenter does not focus on colocation services / servers but on game servers, having many attacks daily.

Sign In or Register to comment.