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
As for the first question of running a Tor relay - this isn't something we can allow at all - we're actually in the process of implementing technical measures that would break it anyways (relays are publicly listed with IP & Port combos, blocking them would stop Tor relays and nodes from functioning without breaking any other traffic). We've simply had way too much abuse to allow Tor - apologies. I do see you also run Freenet and I2P which we are 100% okay with and have absolutely no objections to at all. We aren't against anonymous networks themselves, we are only against the ridiculously large amount of abuse directly attributable to Tor - specially exit node traffic to clearweb (this is why I2P doesn't offer distributed exit nodes by default and only has outproxies hosted on very few publicly known servers or you'd have to host your own).
As for the second - I'm not sure what would prevent a person from turning off Tor.. even if you're using an OS that is directing all traffic through Tor, you'd have a phone I'd assume and our site is available in on mobile... This statement of "I can't turn off Tor" is impossible - even in highly secure Tor guarded OSes you can use a proxy on Firefox for example through Tor or make exceptions to firewall to allow your VPN / Proxy trough direct -> websites.
EDIT: Just saw you asked about UK Location - there, run Tor relays to your hearts content - no exit nodes though.
Both of those two use a similar amount of bandwidth, with Freenet also hammering I/O.
So what about Tor non-exit (middle) nodes? Those are identical in function to Freenet and I2P, i.e. they do not exit abusive traffic. I personally value diversity more than raw bandwidth, so if you could give me an acceptable bandwidth limit for your Albania location, I'd be happy to ensure that I never go over it. I'd much rather a slow Tor (non-exit) in Albania than a blazing fast Tor (non-exit) in UK/NL.
In our experience I2P does not. Never messed with Freenet - so not sure on Freenet - for I2P, it uses usually less than 10Mb/s on average from what I've seen - whereas Tor will eat up a 200Mb/s Pipe, a 1Gb/s pipe, whatever you feed it.
Tor non-exit eats traffic. See edit to last comment - on UK we don't care as much, as we have loads of traffic - Albania it will probably never be allowed - maybe with the exception of Colo / Dedicated Servers (which aren't available yet - coming soon).
Oof, I can barely get 200 Mbps even in NL! For small hosts, I usually try to stay around 10 to 20 Mbps using Tor's optional bandwidth throttling. In Brazil, for example, I don't think I'm even above 1 Mbps.
Is there any chance that I could run a Tor non-exit in AL if I throttle it so that it only uses a fixed amount of bandwidth, equivalent to Freenet or I2P?
That's very interesting. On our UK node, we've had clients pushing 2+Gb/s on Tor relays (not exit). I'm not sure how they do it - but it happens. I2P I've NEVER seen hit that high at all - I mean of course bursts here or there - but definitely nothing on the scale of Tor's non-stop traffic. I2P seems to go in ups and downs and averages out fine - Tor tends to saturate pipe as much as you let it. (Most people do not limit it, or maybe aren't even aware of how, like you mentioned doing yourself).
That's actually because the Tor network uses bandwidth measurement servers that are biased to Europe, so they send more traffic to servers in "popular" locations than others. I have a 500 Mbps pipe in Russia, but the Tor network barely routes 5 Mbps through it. Meanwhile I have a 200 Mbps server in NL that is constantly saturated because of its location.
I'm guessing (but not sure) that a totally unthrottled Tor relay in Albania would never exceed 20 Mbps. Of course, it's always possible to force it to stay that low, or lower, with
MaxAdvertisedBandwidth.I2P, on the other hand, doesn't seem to care about location and all nodes get roughly equal traffic.
Very strange - and seems counter-productive. Wouldn't you want to spread the traffic to multiple locations globally, especially through some obscure ones, to avoid chances of multiple governments or ISPs working together to do tracing?
For example, say you're American, is it not better for your connection to first go to a friendly country, lowerish-latency, say UK, and then hop to somewhere that doesn't cooperate with UK, say Russia, before hitting the exit node in one that is also less likely to work with both, say Brazil? Yeah, higher latency and lower pipe speeds - but also less chance that all 3 governments work together to connect all pieces of the "onion" together.
Oh absolutely, and that's a current limitation with the bandwidth authorities. The reason they even need authorities is because otherwise relays could maliciously self-report a higher bandwidth than they are really capable of, and siphon up too much traffic. So the bandwidth authorities anonymously test each relay, but their locations are not very diverse, so the network tends to be lopsided. There are ideas that the team has to fix it, such as using CDNs for bandwidth testing. Their current recommended workaround is just to run multiple relays on the same IP (up to 16), but of course with each process using 500 - 1000 MB of RSS, that's a bit impractical on small VPSes!
Anyway, it seems I was lucky with getting around the blocks earlier, but it's not working anymore. As I only sent 10 EUR, it's not a big deal and not really worth trying to get around for a UK location. Just consider it a donation, and do consider running a single node in Albania yourself in the future if you can.
Try max port speed full. Last relays that were on Albania used constantly their full allocation. They were legacy and had 300Mb's ports hitting 200-250Mb/s constantly. 1 VM with nothing but a Tor relay was using over 60TB/mo by itself, when average users are using 1-5TB/mo.
Possibly due to lower I2P adoption, it just doesn't see much traffic vs Tor tbh.
I think it's also a matter of all I2P users also being routers, so there are far more I2P routers than there are Tor relays. Combined with Tor seeing more usage, it results in each I2P router being relatively underutilized.
That's impressive! You must have really well-connected upstreams.
That actually depends. It may be, in theory, but what if your both your home ISP and the destination website's ISP are both on the same AS (or go through the same AS)? Then you're essentially looping around the world, just go reach the US again. That AS could see you send mystery traffic to the Tor network, then 100 ms later, see mystery traffic from some Brazilian exit relay reach a website they control, and they could correlate the traffic.
There is some research into AS-aware routing that is quite promising, however!
Send a PM if you don't mind - we'll work on getting the direct Tor onion site, i2p site, etc back up shortly and get you access to it - we can't just take your money - that's not fair or correct at all and just isn't the kind of people we are. We can either get you a refund somehow or get you access somehow - one of the 2. But thank you ❤️
Sent!
Super, thanks a lot. Please then double specs for VPS IDs 548981, 548982 and 548983
Doubling applied to all orders. Thank you for your support
well. in normal days it show no drops.
![](https://i.ibb.co/npY5PxF/ecbbcbec-5538-4dd7-9ed5-61feef60925a.png")
https://ibb.co/R8sVjRq
Even in that screenshot, there is "loss".
Quite a bit actually, showing. How many on ping.pe show loss depends on many things:
1) how much other stuff you have pinging at same time (monitors, etc)
2) how many of our other IPs those are also pinging at same time
We ratelimit them by source and by destination with different limits. 1 might show 100% loss if it's been blacklisted for flooding ICMP to several other VMs, whereas all might show 70,80, etc % if it's been hitting your own IP a lot and is being dest limited.
These tools are useful, but they aren't accurate when filtering is in place. Recommended way to check loss is yourself from inside VM. Just run "ping -c 20 1.1.1.1" and see what loss you get.
so that is the explanation for the frequent outage since i bought it last BF
hope you guys will have a rack there soon, although a little head-up about these outage could be useful
Yes - and we are working on it. We've spoken with another provider here that has given us some very good options that we're following up on for better options that may help to keep us online without these issues for Albania. That's one of the great things about Albania - another provider saw this post, had some contacts, and reached out to offer help - something that you won't find in a lot of other countries where everyone is trying to compete - and one of the things I love about Albania - everyone will try to help when they can. I won't name the provider - they know who they are - but they're very good people and I'm glad to know them - they've been a big help with this situation.
We don't want to announce anything immediately - but clients will be updated by email once we've decided on the appropriate solution. Mitigations are being implemented now in the meantime to avoid future downtime during the season. We've obtained servers in another location here and are in the process of syncing all VMs between both so that in the event of total failure, we can simply swap the BGP routes and activate live there before power fails entirely, avoiding large downtime with the tradeoff of a short reboot of VMs instead (when they shutdown on one location and come up on another location). This is a temporary solution of course, but also will allow us to move the servers once we've got logistics worked out for the new location that won't have these issues - without all VMs being offline during the move between locations.
As for the explanation about why you don't get notifications before an outage occurs and only after:
1) We wait a few hours and if no power, we send a warning "it might go down, we aren't sure" - might cause customers to panic or complaints, even though nothing goes down and everything is fine
or;
2) We wait until the systems are about to die, send a quick warning email to clients, wait until we hit "critically low" on batteries, and then perform a graceful shutdown to avoid data loss or damage.
So far, we've went with option 2 to avoid sending false notifications - that leaves customers with very little warning, but does avoid spamming emails when nothing is wrong (power gets restored, for example).
We also don't send notifications when internet lines go down because we have multiple backup lines and when one goes down, it normally falls-over to the next without more than a few seconds of downtime (checks for line life every 60 seconds by performing a few pings and if none return, calling it down). It's extremely rare that all lines go down at once - we've had it happen only once before.
We are always working to get better - we're all learning as we grow - making new connections - and solving issues as we go. We've made countless mistakes with Albania that we would have done differently if we could start over - but we can't so we learn and we fix. We do expect Albania will reach the level of stability the you have in NL and UK VERY VERY SOON - sooner than we expected to be possible. Thank you for sticking with us
@avsisp would you like to support globalping again with some small servers?
How i can deal with that?
By submitting a ticket, which you did - and us notifying our upstream where the packet loss is occurring at - not at us directly - which we have done. We are also in the process of re-routing traffic now.
Upon rerouting, checking from multiple methods, different IPs on different networks, we can confirm this is NOT an us issue. This is a T1 level issue effecting the networks of RETN and L3 specifically. In that image, click the "show" next to them - you'll see massive loss starting at RETN -> us.
We're reaching out to upstreams using RETN and to RETN themselves to address the issue.