Howdy, Stranger!

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


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

Macedonia Launch (New Location) Double-Specs, VMs in UK, NL, AL, MK (VPS + VDS)

13

Comments

  • avsispavsisp Member, Patron Provider
    edited April 18

    @forest said:
    But you can't run a bridge relay on your VPS if your VPS blocks connections to all Tor relays, as the bridge itself needs to connect to Tor (and you can't use a bridge over a bridge). Likewise, you can't operate an onion service. If you really do have to block Tor, you should simply have an alert that fires if one of your IPs is detected on the Tor consensus and not block connections to the Tor network. After all, what if someone wants to run torsocks wget on your VPS?

    The entire point is for nobody to be a relay. They can still be a CLIENT on Tor by using a bridge in their configuration. Torsocks accesses the local Tor service - it would still work. We have already tested this. The only thing it can't be is a relay/without contacting others directly. Anything else, it can do over a bridge. Bridges basically act like socks proxies of their own in a way (oversimplified) and all traffic into the Tor network goes you -> bridge -> Tor ... Works just fine.

    Hmm, that's strange. I genuinely suspect something weird is happening because, with very few exceptions, I haven't seen a non-exit get flagged by any reputable (or even semi-reputable) IP reputation database, much less thousands of complaints. Is it possible that some people are either running exits (not middles), or are running middles while also abusing the service and trying to blame it on Tor? Because what you describe is out of the ordinary.

    Even a single node running will cause bgp.tools to flag is "Tor" as well as ip2location and others. Even browserleaks.com will classify it with a lovely "TOR" tag + a "VPN" tag.

    Do you have some examples of these 1000s of abuse complaints? I'm curious to figure out why that happens with your ASN so much more than others. I suspect there's more going on here than just excessive auto-reporting.

    We have had most removed - but I agree that it isn't fair. I don't think an entire ASN should be penalized for at max 4 users. I think it's a bit overkill and that those using these flags to handle blocks should rethink it. But there isn't much we can do. All we can do is let the databases with those flags know that those nodes no longer operate, ask them to remove the flags, etc.

    I only spent $10. I'm not a greedy person and I totally understand if this is a case of caveat emptor, but if you could instead donate it to the EFF or Tor Project, that would be better than refunding it to me.

    You spent 10 EUR (~12USD). As per your request, it has been donated directly to the Tor project. Screenshots follow. Thank you for supporting them. They're great projects - I just wish there was less bad actors on the Tor network specifically or that they didn't list all IPs publicly to get ASNs blocks like this.

  • I’d like to share a quick impression of this VPS service.

    Honestly, the VPS is very fast — even more than I expected. Performance has been consistently smooth and responsive, which was a pleasant surprise.

    What also stands out is the support team: they are polite, helpful, and genuinely willing to assist. It really feels like they care about providing good service and trying to meet each customer’s needs.

    Below is my fresh YABS test from the Micro VPS for reference:

    ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##

    Yet-Another-Bench-Script

    v2025-04-20

    https://github.com/masonr/yet-another-bench-script

    ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##

    Sat 18 Apr 2026 13:49:18 IST

    Basic System Information:

    Uptime : 0 days, 0 hours, 8 minutes
    Processor : AMD EPYC 7302 16-Core Processor
    CPU cores : 2 @ 2994.372 MHz
    AES-NI : ✔ Enabled
    VM-x/AMD-V : ✔ Enabled
    RAM : 1.9 GiB
    Swap : 2.0 GiB
    Disk : 38.2 GiB
    Distro : Debian GNU/Linux 13 (trixie)
    Kernel : 6.12.74+deb13+1-amd64
    VM Type : KVM
    IPv4/IPv6 : ✔ Online / ✔ Online

    IPv6 Network Information:

    ISP : Andrew Kristuli
    ASN : AS210464 AVS ISP
    Host : Andrew Kristuli
    Location : Tirana, Tirana (11)
    Country : Albania

    fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sda2):

    Block Size 4k (IOPS) 64k (IOPS)
    Read 129.21 MB/s (32.3k) 1.02 GB/s (16.0k)
    Write 129.56 MB/s (32.3k) 1.03 GB/s (16.1k)
    Total 258.77 MB/s (64.6k) 2.05 GB/s (32.1k)
    Block Size 512k (IOPS) 1m (IOPS)
    ------ --- ---- ---- ----
    Read 1.33 GB/s (2.6k) 1.39 GB/s (1.3k)
    Write 1.40 GB/s (2.7k) 1.49 GB/s (1.4k)
    Total 2.74 GB/s (5.3k) 2.89 GB/s (2.8k)

    iperf3 Network Speed Tests (IPv4):

    Provider Location (Link) Send Speed Recv Speed Ping
    Clouvider London, UK (10G) 1.91 Gbits/sec 2.22 Gbits/sec 46.4 ms
    Eranium Amsterdam, NL (100G) 2.54 Gbits/sec 2.39 Gbits/sec 37.9 ms
    Uztelecom Tashkent, UZ (10G) 2.30 Gbits/sec 1.88 Gbits/sec 112 ms
    Leaseweb Singapore, SG (10G) 1.11 Gbits/sec 1.36 Gbits/sec 269 ms
    Clouvider Los Angeles, CA, US (10G) 905 Mbits/sec 702 Mbits/sec 187 ms
    Leaseweb NYC, NY, US (10G) 2.21 Gbits/sec 1.92 Gbits/sec 116 ms
    Edgoo Sao Paulo, BR (1G) 1.66 Gbits/sec 1.70 Gbits/sec 224 ms

    iperf3 Network Speed Tests (IPv6):

    Provider Location (Link) Send Speed Recv Speed Ping
    Clouvider London, UK (10G) 1.91 Gbits/sec 2.26 Gbits/sec 46.5 ms
    Eranium Amsterdam, NL (100G) 2.54 Gbits/sec 2.36 Gbits/sec 37.9 ms
    Uztelecom Tashkent, UZ (10G) 2.28 Gbits/sec 2.06 Gbits/sec 112 ms
    Leaseweb Singapore, SG (10G) 1.27 Gbits/sec 1.66 Gbits/sec 269 ms
    Clouvider Los Angeles, CA, US (10G) 907 Mbits/sec 115 Mbits/sec 186 ms
    Leaseweb NYC, NY, US (10G) 2.20 Gbits/sec 2.16 Gbits/sec 116 ms
    Edgoo Sao Paulo, BR (1G) 1.62 Gbits/sec 1.60 Gbits/sec 224 ms

    Geekbench 6 Benchmark Test:

    Test | Value
    |
    Single Core | 1112
    Multi Core | 1951
    Full Test | https://browser.geekbench.com/v6/cpu/17691728

    YABS completed in 15 min 32 sec

    Thanked by 2oloke avsisp
  • forestforest Member
    edited April 18

    @avsisp said: The entire point is for nobody to be a relay. They can still be a CLIENT on Tor by using a bridge in their configuration. Torsocks accesses the local Tor service - it would still work. We have already tested this. The only thing it can't be is a relay/without contacting others directly.

    Why not just suspend users who appear on the Tor consensus? Because blocking connections prevents people from running a bridge, even if it doesn't stop them from using someone else's bridge. For example, imagine someone wants to support the Tor network with your service. They can't run a regular relay, so they want to run a bridge, as that won't put you on any blacklists. However, they quickly find that the bridge cannot connect to the network.

    Also, it interferes with other projects like I2P. Many people run both Tor and I2P, me included. Now people who want to run an I2P router on your servers will be unable to connect to my I2P routers simply because my routers run off the same IP that my Tor relay runs on. Same with my public Monero nodes (and many Monero nodes, actually). Likewise, if someone runs a Tor middle at home, they won't even be able to SSH into their VPS if they run it with you.

    Another example is Snowflake proxies. These act somewhat like bridges, being fully unlisted, and allow censored users in Iran, China, Russia, etc. to access Tor. But you're effectively banning people from running Snowflake proxies too, because Snowflake needs to be able to connect to Tor.

    I just think it would be better, if you really have to block Tor, not to block the network itself and instead just to suspend users who publish a relay descriptor. If you really, really, really have to block the whole network, then block the IP:ORPort combo of relays so that other services running on the same IP are not blocked.

    @avsisp said: You spent 10 EUR (~12USD). As per your request, it has been donated directly to the Tor project. Screenshots follow. Thank you for supporting them. They're great projects - I just wish there was less bad actors on the Tor network specifically or that they didn't list all IPs publicly to get ASNs blocks like this.

    Thank you!

    I am curious why your service in particular seems to be affected more by this than others, though. I guess if a lot of people use your IPs to try to watch Netflix, it might make sense as they'll detect it as a datacenter IP, but it won't affect the average person who just needs an IP that isn't on Spamhaus or AbuseIPDB and doesn't really care if BGP Tools says that the ASN has middles. Not arguing, but genuinely curious.

    I suppose if you ever supported BYOIP, people could run relays then?

    Thanked by 1concept
  • conceptconcept Member

    @forest said:

    I just think it would be better, if you really have to block Tor, not to block the network itself and instead just to suspend users who publish a relay descriptor. If you really, really, really have to block the whole network, then block the IP:ORPort combo of relays so that other services running on the same IP are not blocked.

    yup. It's sad to see a host go that far to block Tor as a relay operator myself.

    Thanked by 1gleepdorf
  • avsispavsisp Member, Patron Provider
    edited April 19

    @forest said:

    @avsisp said: The entire point is for nobody to be a relay. They can still be a CLIENT on Tor by using a bridge in their configuration. Torsocks accesses the local Tor service - it would still work. We have already tested this. The only thing it can't be is a relay/without contacting others directly.

    Why not just suspend users who appear on the Tor consensus? Because blocking connections prevents people from running a bridge, even if it doesn't stop them from using someone else's bridge. For example, imagine someone wants to support the Tor network with your service. They can't run a regular relay, so they want to run a bridge, as that won't put you on any blacklists. However, they quickly find that the bridge cannot connect to the network.

    Also, it interferes with other projects like I2P. Many people run both Tor and I2P, me included. Now people who want to run an I2P router on your servers will be unable to connect to my I2P routers simply because my routers run off the same IP that my Tor relay runs on. Same with my public Monero nodes (and many Monero nodes, actually). Likewise, if someone runs a Tor middle at home, they won't even be able to SSH into their VPS if they run it with you.

    Another example is Snowflake proxies. These act somewhat like bridges, being fully unlisted, and allow censored users in Iran, China, Russia, etc. to access Tor. But you're effectively banning people from running Snowflake proxies too, because Snowflake needs to be able to connect to Tor.

    I just think it would be better, if you really have to block Tor, not to block the network itself and instead just to suspend users who publish a relay descriptor. If you really, really, really have to block the whole network, then block the IP:ORPort combo of relays so that other services running on the same IP are not blocked.

    @avsisp said: You spent 10 EUR (~12USD). As per your request, it has been donated directly to the Tor project. Screenshots follow. Thank you for supporting them. They're great projects - I just wish there was less bad actors on the Tor network specifically or that they didn't list all IPs publicly to get ASNs blocks like this.

    Thank you!

    I am curious why your service in particular seems to be affected more by this than others, though. I guess if a lot of people use your IPs to try to watch Netflix, it might make sense as they'll detect it as a datacenter IP, but it won't affect the average person who just needs an IP that isn't on Spamhaus or AbuseIPDB and doesn't really care if BGP Tools says that the ASN has middles. Not arguing, but genuinely curious.

    I suppose if you ever supported BYOIP, people could run relays then?

    Somebody didn't read at all how it works. You mentioned IP blocks, which we don't do. We block IP + Port combo. It won't interfere with I2p. 2 services can't run on the same port. This is simply impossible.

    As for BYOIP, if it's on our ASN, it'd be blocked down. For BGP sessions, it isn't blocked. We block only from source IPs on our ASN -> IP:PORT combo of tor nodes. Nothing else.

  • avsispavsisp Member, Patron Provider

    @concept said:

    @forest said:

    I just think it would be better, if you really have to block Tor, not to block the network itself and instead just to suspend users who publish a relay descriptor. If you really, really, really have to block the whole network, then block the IP:ORPort combo of relays so that other services running on the same IP are not blocked.

    yup. It's sad to see a host go that far to block Tor as a relay operator myself.

    We literally do the minimum to block it. We only block src our IPs -> dest IP:PORT Orport as listed. We don't block whole IPs or even whole ports.

  • forestforest Member
    edited April 19

    @avsisp said: You mentioned IP blocks, which we don't do. We block IP + Port comb

    Oh, got it. Thanks for clarifying.

    Thanked by 1avsisp
  • forestforest Member
    edited April 19

    Hmm, I wonder if it would be possible to prevent people from running relays without blocking connections to the Tor network by simply blocking all but one of the directory authorities. That would prevent anyone from publishing a relay descriptor and getting on the consensus but wouldn't prevent people from running Snowflake.

    If only a single directory authority can be reached, it's enough to bootstrap as a client (e.g. for Snowflake, which you can't run behind a bridge because it is a bridge), but it's not enough to be added to the consensus as a relay.

    Thanked by 1concept
  • avsispavsisp Member, Patron Provider

    @forest said:
    Hmm, I wonder if it would be possible to prevent people from running relays without blocking connections to the Tor network by simply blocking all but one of the directory authorities. That would prevent anyone from publishing a relay descriptor and getting on the consensus but wouldn't prevent people from running Snowflake.

    If only a single directory authority can be reached, it's enough to bootstrap as a client (e.g. for Snowflake, which you can't run behind a bridge because it is a bridge), but it's not enough to be added to the consensus as a relay.

    I'm actually fully open to this idea if anyone has time to test it. Our goal is never to break Tor entirely, only to forbid relays so that the ASN doesn't get flagged and services block other clients from accessing legit services without hoops.

    I wouldn't even know how that works to be honest, since as far as I knew, Tor is supposed to be distributed with a consensus formed by Other Relays, not a single well-known directory IP.

    Thanked by 1JohnFilch123
  • thanks for the "double-spec plan" ordering process worked well - VPS work :)

    Thanked by 1avsisp
  • @avsisp said: anyone has time to test it

    Happy to test it. I have got your London VPS. Shall I open a ticket about it?

  • avsispavsisp Member, Patron Provider
    edited April 19

    @JohnFilch123 said:

    @avsisp said: anyone has time to test it

    Happy to test it. I have got your London VPS. Shall I open a ticket about it?

    I mean you can't test it behind the existing block. I meant for someone to test what he's saying (not sure if they're even listed anywhere publicly if they even work this way) about blocking certain nodes and it keeping a VM from joining the pool or being listed as a relay.

    But thanks mate, appreciate it.

    I think this test would need to be ran on home internet or another VM that doesn't block anything, wide open -> block the ones hes saying -> setup as relay -> wait 24 hours -> check relay list and see if it's listed.

    Thanked by 1JohnFilch123
  • @forest drop me a DM with instructions for dump people :lol: , happy to test.

    Thanked by 1avsisp
  • @forest : I don't quite understand, there's a nice and interesting offer here and you're just bothering us with your ideas - that's not so good - anyway, I've ordered the VPS and I'm happy about the doubling of capacity, the location and the good connection
    !

    Thanked by 1avsisp
  • forestforest Member

    @seoworld said:
    @forest : I don't quite understand, there's a nice and interesting offer here and you're just bothering us with your ideas - that's not so good - anyway, I've ordered the VPS and I'm happy about the doubling of capacity, the location and the good connection
    !

    I've got nothing against the offer, it looks quite good. I hope I'm not bothering anyone. The ideas should help reduce collateral damage.

    @avsisp said:

    @forest said:
    Hmm, I wonder if it would be possible to prevent people from running relays without blocking connections to the Tor network by simply blocking all but one of the directory authorities. That would prevent anyone from publishing a relay descriptor and getting on the consensus but wouldn't prevent people from running Snowflake.

    If only a single directory authority can be reached, it's enough to bootstrap as a client (e.g. for Snowflake, which you can't run behind a bridge because it is a bridge), but it's not enough to be added to the consensus as a relay.

    I'm actually fully open to this idea if anyone has time to test it. Our goal is never to break Tor entirely, only to forbid relays so that the ASN doesn't get flagged and services block other clients from accessing legit services without hoops.

    I wouldn't even know how that works to be honest, since as far as I knew, Tor is supposed to be distributed with a consensus formed by Other Relays, not a single well-known directory IP.

    When a client connects to the Tor network, it tries to contact one of a few directory authorities (their IPs are hardcoded in the Tor binary) that transfer the list of relays to the client, and then the client can make connections on its own. All it needs is one authority to be reachable. The reason it uses multiple authorities rather than a fully distributed consensus is so that it can kick malicious relays off the network.

    When a client wants to become a relay, it generates some keys and uploads those keys to the directory authorities. Then all the directory authorities will try to open up a connection to test the new relay, and if a sufficient number of authorities (3 or 4 I think?) can reach it, they will add it to the consensus that all clients get (and that BGP Tools uses to mark ASNs that have relays). If too few authorities can reach it, it won't get added as a relay, but can still be a client.

    It might also be enough just to block new incoming connections from the authorities, which would make them think the relay is unreachable while not preventing clients from bootstrapping. I'm going to set up a new relay on Loclix soon and I'll monitor the connections to the authorities when the relay is getting published to see exactly what they do. If you're still interested, I'll report back after the test.

    Thanked by 2avsisp hostal
  • NushairAlviNushairAlvi 🚩 Host Rep Tag Suspended

    it was funny ! :D

    Thanked by 2allthemtings avsisp
  • avsispavsisp Member, Patron Provider
    edited April 20

    @seoworld said:
    @forest : I don't quite understand, there's a nice and interesting offer here and you're just bothering us with your ideas - that's not so good - anyway, I've ordered the VPS and I'm happy about the doubling of capacity, the location and the good connection
    !

    Thank you for the kind words, we appreciate your feedback <3 Enjoy the VPS, and please let us know if you have any issues at all.

    @forest said:
    When a client connects to the Tor network, it tries to contact one of a few directory authorities (their IPs are hardcoded in the Tor binary) that transfer the list of relays to the client, and then the client can make connections on its own. All it needs is one authority to be reachable. The reason it uses multiple authorities rather than a fully distributed consensus is so that it can kick malicious relays off the network.

    When a client wants to become a relay, it generates some keys and uploads those keys to the directory authorities. Then all the directory authorities will try to open up a connection to test the new relay, and if a sufficient number of authorities (3 or 4 I think?) can reach it, they will add it to the consensus that all clients get (and that BGP Tools uses to mark ASNs that have relays). If too few authorities can reach it, it won't get added as a relay, but can still be a client.

    It might also be enough just to block new incoming connections from the authorities, which would make them think the relay is unreachable while not preventing clients from bootstrapping. I'm going to set up a new relay on Loclix soon and I'll monitor the connections to the authorities when the relay is getting published to see exactly what they do. If you're still interested, I'll report back after the test.

    Yeah mate, let me know how it goes. But tbh with you, I'm not quite sure it's that simple. Because if it was, anyone could just censor Tor entirely by blocking those known servers. And Tor is expected to be a distributed, redundant network, resistant to blocks and censorship. Have you read the great firewall code for Tor blocking? They do a LOT more than just block some directory servers. Networks wouldn't be doing DPI to block Tor (Russia, China, etc) if it was as simple as blocking a few IPs.

  • Is there a looking glass?

  • jsgjsg Member, Resident Benchmarker

    I'm a bit torn. One the one hand I really like my @avsisp VPS
    but one the other hand I very much dislike @forest again and again derailing this thread for his Tor spam. I'm not against Tor and certainly not against forest whose comments I often value - but in this thread he really unnerved (probably not only) me.

  • MurvMurv Member, Megathread Squad

    @jsg said: I'm a bit torn

    Try gooning

  • jimaekjimaek Member

    @zephyr32 said:
    Is there a looking glass?

    I think it's them? https://globalping.io/networks/rs-computers

    Thanked by 2oloke zephyr32
  • allthemtingsallthemtings Member, Megathread Squad
    edited April 21

    @zephyr32 said:
    Is there a looking glass?

    https://www.avsisp.com/lg/

    Edit- seems it needs updating @avsisp

    Thanked by 2skimply153 zephyr32
  • olokeoloke Member, Host Rep

    @jimaek said:

    @zephyr32 said:
    Is there a looking glass?

    I think it's them? https://globalping.io/networks/rs-computers

    It's their upstream

    Thanked by 1skimply153
  • allthemtingsallthemtings Member, Megathread Squad

    Macedonia

    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    #              Yet-Another-Bench-Script              #
    #                     v2025-04-20                    #
    # https://github.com/masonr/yet-another-bench-script #
    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    
    Tue 21 Apr 2026 08:51:32 IST
    
    Basic System Information:
    ---------------------------------
    Uptime     : 3 days, 11 hours, 25 minutes
    Processor  : AMD EPYC 7302 16-Core Processor
    CPU cores  : 2 @ 2994.372 MHz
    AES-NI     : ✔ Enabled
    VM-x/AMD-V : ✔ Enabled
    RAM        : 1.9 GiB
    Swap       : 1023.0 MiB
    Disk       : 38.2 GiB
    Distro     : Debian GNU/Linux 13 (trixie)
    Kernel     : 6.12.73+deb13-amd64
    VM Type    : KVM
    IPv4/IPv6  : ✔ Online / ✔ Online
    
    IPv6 Network Information:
    ---------------------------------
    ISP        : Andrew Kristuli
    ASN        : AS210464 AVS ISP
    Host       : Andrew Kristuli
    Location   : Tirana, Tirana (11)
    Country    : Albania
    
    fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sda2):
    ---------------------------------
    Block Size | 4k            (IOPS) | 64k           (IOPS)
      ------   | ---            ----  | ----           ----
    Read       | 103.26 MB/s  (25.8k) | 938.37 MB/s  (14.6k)
    Write      | 103.53 MB/s  (25.8k) | 943.31 MB/s  (14.7k)
    Total      | 206.79 MB/s  (51.6k) | 1.88 GB/s    (29.4k)
               |                      |
    Block Size | 512k          (IOPS) | 1m            (IOPS)
      ------   | ---            ----  | ----           ----
    Read       | 1.31 GB/s     (2.5k) | 1.34 GB/s     (1.3k)
    Write      | 1.38 GB/s     (2.7k) | 1.43 GB/s     (1.3k)
    Total      | 2.70 GB/s     (5.2k) | 2.77 GB/s     (2.7k)
    
    iperf3 Network Speed Tests (IPv4):
    ---------------------------------
    Provider        | Location (Link)           | Send Speed      | Recv Speed      | Ping
    -----           | -----                     | ----            | ----            | ----
    Clouvider       | London, UK (10G)          | 753 Mbits/sec   | 951 Mbits/sec   | 47.1 ms
    Eranium         | Amsterdam, NL (100G)      | 604 Mbits/sec   | 975 Mbits/sec   | 40.2 ms
    Uztelecom       | Tashkent, UZ (10G)        | 418 Mbits/sec   | 909 Mbits/sec   | 112 ms
    Leaseweb        | Singapore, SG (10G)       | 271 Mbits/sec   | 640 Mbits/sec   | 306 ms
    Clouvider       | Los Angeles, CA, US (10G) | 417 Mbits/sec   | 843 Mbits/sec   | 184 ms
    Leaseweb        | NYC, NY, US (10G)         | 445 Mbits/sec   | 833 Mbits/sec   | 114 ms
    Edgoo           | Sao Paulo, BR (1G)        | 278 Mbits/sec   | 695 Mbits/sec   | 224 ms
    
    iperf3 Network Speed Tests (IPv6):
    ---------------------------------
    Provider        | Location (Link)           | Send Speed      | Recv Speed      | Ping
    -----           | -----                     | ----            | ----            | ----
    Clouvider       | London, UK (10G)          | 805 Mbits/sec   | 947 Mbits/sec   | 47.1 ms
    Eranium         | Amsterdam, NL (100G)      | 710 Mbits/sec   | 961 Mbits/sec   | 40.1 ms
    Uztelecom       | Tashkent, UZ (10G)        | 372 Mbits/sec   | 899 Mbits/sec   | 112 ms
    Leaseweb        | Singapore, SG (10G)       | 302 Mbits/sec   | 738 Mbits/sec   | 261 ms
    Clouvider       | Los Angeles, CA, US (10G) | 331 Mbits/sec   | 808 Mbits/sec   | 184 ms
    Leaseweb        | NYC, NY, US (10G)         | 488 Mbits/sec   | 813 Mbits/sec   | 114 ms
    Edgoo           | Sao Paulo, BR (1G)        | 274 Mbits/sec   | 749 Mbits/sec   | 224 ms
    
    Geekbench 6 Benchmark Test:
    ---------------------------------
    Test            | Value
                    |
    Single Core     | 1049
    Multi Core      | 1847
    Full Test       | https://browser.geekbench.com/v6/cpu/17732987
    
    YABS completed in 16 min 5 sec
    
    Thanked by 2skimply153 oloke
  • @jsg said:
    I'm a bit torn. One the one hand I really like my @avsisp VPS
    but one the other hand I very much dislike @forest again and again derailing this thread for his Tor spam. I'm not against Tor and certainly not against forest whose comments I often value - but in this thread he really unnerved (probably not only) me.

    If you like servers then just buy them. Everything else is irrelevant really.

    Thanked by 2tentor forest
  • wish this was half monthly price instead of double specs :frowning:

  • @allthemtings said:
    Macedonia

    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
    # Yet-Another-Bench-Script #
    # v2025-04-20 #
    # https://github.com/masonr/yet-another-bench-script #
    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

    Tue 21 Apr 2026 08:51:32 IST

    Basic System Information:
    ---------------------------------
    Uptime : 3 days, 11 hours, 25 minutes
    Processor : AMD EPYC 7302 16-Core Processor
    CPU cores : 2 @ 2994.372 MHz
    AES-NI : ✔ Enabled
    VM-x/AMD-V : ✔ Enabled
    RAM : 1.9 GiB
    Swap : 1023.0 MiB
    Disk : 38.2 GiB
    Distro : Debian GNU/Linux 13 (trixie)
    Kernel : 6.12.73+deb13-amd64
    VM Type : KVM
    IPv4/IPv6 : ✔ Online / ✔ Online

    IPv6 Network Information:
    ---------------------------------
    ISP : Andrew Kristuli
    ASN : AS210464 AVS ISP
    Host : Andrew Kristuli
    Location : Tirana, Tirana (11)
    Country : Albania

    fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sda2):
    ---------------------------------
    Block Size | 4k (IOPS) | 64k (IOPS)
    ------ | --- ---- | ---- ----
    Read | 103.26 MB/s (25.8k) | 938.37 MB/s (14.6k)
    Write | 103.53 MB/s (25.8k) | 943.31 MB/s (14.7k)
    Total | 206.79 MB/s (51.6k) | 1.88 GB/s (29.4k)
    | |
    Block Size | 512k (IOPS) | 1m (IOPS)
    ------ | --- ---- | ---- ----
    Read | 1.31 GB/s (2.5k) | 1.34 GB/s (1.3k)
    Write | 1.38 GB/s (2.7k) | 1.43 GB/s (1.3k)
    Total | 2.70 GB/s (5.2k) | 2.77 GB/s (2.7k)

    iperf3 Network Speed Tests (IPv4):
    ---------------------------------
    Provider | Location (Link) | Send Speed | Recv Speed | Ping
    ----- | ----- | ---- | ---- | ----
    Clouvider | London, UK (10G) | 753 Mbits/sec | 951 Mbits/sec | 47.1 ms
    Eranium | Amsterdam, NL (100G) | 604 Mbits/sec | 975 Mbits/sec | 40.2 ms
    Uztelecom | Tashkent, UZ (10G) | 418 Mbits/sec | 909 Mbits/sec | 112 ms
    Leaseweb | Singapore, SG (10G) | 271 Mbits/sec | 640 Mbits/sec | 306 ms
    Clouvider | Los Angeles, CA, US (10G) | 417 Mbits/sec | 843 Mbits/sec | 184 ms
    Leaseweb | NYC, NY, US (10G) | 445 Mbits/sec | 833 Mbits/sec | 114 ms
    Edgoo | Sao Paulo, BR (1G) | 278 Mbits/sec | 695 Mbits/sec | 224 ms

    iperf3 Network Speed Tests (IPv6):
    ---------------------------------
    Provider | Location (Link) | Send Speed | Recv Speed | Ping
    ----- | ----- | ---- | ---- | ----
    Clouvider | London, UK (10G) | 805 Mbits/sec | 947 Mbits/sec | 47.1 ms
    Eranium | Amsterdam, NL (100G) | 710 Mbits/sec | 961 Mbits/sec | 40.1 ms
    Uztelecom | Tashkent, UZ (10G) | 372 Mbits/sec | 899 Mbits/sec | 112 ms
    Leaseweb | Singapore, SG (10G) | 302 Mbits/sec | 738 Mbits/sec | 261 ms
    Clouvider | Los Angeles, CA, US (10G) | 331 Mbits/sec | 808 Mbits/sec | 184 ms
    Leaseweb | NYC, NY, US (10G) | 488 Mbits/sec | 813 Mbits/sec | 114 ms
    Edgoo | Sao Paulo, BR (1G) | 274 Mbits/sec | 749 Mbits/sec | 224 ms

    Geekbench 6 Benchmark Test:
    ---------------------------------
    Test | Value
    |
    Single Core | 1049
    Multi Core | 1847
    Full Test | https://browser.geekbench.com/v6/cpu/17732987

    YABS completed in 16 min 5 sec

    is reddit guest blocked on their macedonia IP range? i have problems with a vps in albania with them

  • avsispavsisp Member, Patron Provider

    @allthemtings said:

    @zephyr32 said:
    Is there a looking glass?

    https://www.avsisp.com/lg/

    Edit- seems it needs updating @avsisp

    Yep. That one only runs on UK. Need to add other locations. But thanks mate <3

  • avsispavsisp Member, Patron Provider

    @Nekopara said:
    is reddit guest blocked on their macedonia IP range? i have problems with a vps in albania with them

    You've probably been a victim of the whole thread-derail part of the Tor flagging blocking our ASN on Reddit. As far as I know, that's no longer the case and Reddit works fine. At least we haven't had those kind of complaints in a while since the block was implemented.

    If you'd like, we (or another user) can run a "media test script" and see what it says?

    Thanked by 1skimply153
  • @jsg said:
    I'm a bit torn. One the one hand I really like my @avsisp VPS
    but one the other hand I very much dislike @forest again and again derailing this thread for his Tor spam. I'm not against Tor and certainly not against forest whose comments I often value - but in this thread he really unnerved (probably not only) me.

    Who the fuck cares? Buy the vps and move on.

Sign In or Register to comment.