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
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.

horrible network on hostslim 14 eur let deal

124

Comments

  • today

    classic story: it slowly becomes worse and worse and will probably be unusable in a few months. the server will expire soon so unfortunately i won't be able to post updates!

  • Ralph should stick to selling books. He's always been rude and his services are thrash.

  • What are you using to monitor your servers? (in particular the first and last screenshots)

    I'd like to do the same.

  • sh97sh97 Member, Host Rep

    @proofofsteak said:

    What are you using to monitor your servers? (in particular the first and last screenshots)

    I'd like to do the same.

    Uptime kuma is first one, ping.pe is the second

    Thanked by 1proofofsteak
  • proofofsteakproofofsteak Member
    edited December 2025

    It appears HostSlim's entire 69.174.98.0/23 range is unreachable at the moment.

    Thanked by 1karjaj
  • host_chost_c Patron Provider, Top Host, Megathread Squad
    edited December 2025

    Probing 69.174.98.1 shows it belongs to RIPE NCC, AS3257 (GTT-BACKBONE), GTT – Estonia, Harjumaa, Tallinn [hosting]. ( hmm, I have seen this shit before, literally like 24 hours ago )

    The prefix 69.174.98.0/23 is clearly part of a larger aggregate, 69.174.0.0/17.

    Unless HostSlim has actually withdrawn the entire /23 — which I highly doubt — this smells like pure GTT fuckery.

    We’ve just gone through the exact same bullshit recently: a /24 we rented out suddenly started being announced again as part of the larger /19 it belonged to. After warning the broker for over two months that the subnet was being split incorrectly, I eventually dropped the entire subnet and told them to shove it up their ass.

    Their reply? “Yes, but the more specific announcement takes precedence.”
    Like I don’t know how BGP works.

    I may not know everything about BGP, but this is basic stuff: if you carve a larger block into smaller prefixes, you do it properly. You withdraw the aggregate and announce only the /24 ( the active subnet depending on the split ). You don’t leave the larger prefix active and hope the Internet magically behaves.

    Announce the /24 and be done with it. Anything else is sloppy at best and operationally broken at worst.

    The subnet in question of HostSlim looks like the shit we had:

    I personally doubt this is on them ( HostSlim ), I would say it is on the holder of the larger prefix ( this case GTT )

    EDIT:

    I’ve been seeing this more and more often lately. It genuinely feels like people are getting dumber at the NOC level.

    I understand aggregation. This is not an aggregation problem.

    We’re talking about larger prefixes being actively rented out as smaller blocks, while the parent aggregate is still being announced. That’s not a design choice, and it’s not a policy debate — it’s a lack of basic operational skill.

    If you lease out a /24 from a /19 or /17, you either withdraw the aggregate or you very clearly control how it’s announced. Leaving the larger prefix active and relying on “longest prefix wins” is lazy, error-prone, and eventually causes exactly these conflicts.

    This isn’t BGP being complex. This is people at the NOC not understanding — or not caring about — the consequences of what they announce.

    The Internet still works because of math — not because of people doing their jobs well.

  • i was wondering why smokeping turned green since yesterday, lol (my ip is in another subnet which works)

  • 0ka0ka Member

    im returning once again. the network is still shit. ssh drops every 5-15 minutes, udp is very strange: quic works, but not openvpn. it was very strange in the last few weeks: multiple times i noticed that when openvpn worked, later it would break and only small packets would go through the tunnel. idk if this is an anti-ddos filtering or what, there was no notification from hostslim, as always

  • rm_rm_ IPv6 Advocate, Veteran
    edited May 3

    @0ka said: the network is still shit. ssh drops every 5-15 minutes, udp is very strange: quic works, but not openvpn.

    Zero issues whatsoever with the Estonia location over the past months or right now, Amnezia WG works flawlessly and there is no packet loss or ssh drops.

    Maybe it's your ISP or your country's censorship?

  • 0ka0ka Member
    edited May 3

    @rm_ said: no packet loss or ssh drops

    connect to ssh directly and wait.

    a few days ago i was connected to it and to another server, both over a VPN (which is on another, third vps), hostslim kept dropping the connection. today i connected to hostslim directly and it was still dropping my ssh connection.

  • rm_rm_ IPv6 Advocate, Veteran

    @0ka said: connect to ssh directly and wait

    Sure, left it on for now.

    If you have NAT on your ISP, that may also affect things. Check out ServerAliveInterval in /etc/ssh/ssh_config (on the client).

  • rm_rm_ IPv6 Advocate, Veteran

    @0ka said: connect to ssh directly and wait.

    That's indeed correct, a long-running SSH connection (at least with nothing launched) hangs after a while. Typing no longer works, but there is no immediate disconnect either.

    ServerAliveInterval does not help, the connection will then end instead, with a "Timed out contacting server" error message.

    But then I SSHed into my server inside WG, using the in-WG IPs. And that one did not hang even after a long time. So it appears this is caused not by any dropouts in the network, not by any packet-loss or the like, but rather a misconfigured firewall on their side or their upstream.

    Thanked by 10ka
  • 0ka0ka Member
    edited May 3

    @rm_ said: at least with nothing launched

    it hangs even while typing and reconnect is required, also ssh port doesn't matter

  • 0ka0ka Member

    ssh stopped dropping and openvpn started working. im like 90% sure it will break again

  • TrikeLikeTrikeLike Member

    This network sounds awful in a beautiful way. Thank you for sharing this information with the world. I will be buying a server or two

  • 0ka0ka Member
    edited May 7

    @TrikeLike i saw your topic and you probably won't find it useful imo. last year it was like "netem random 10% loss", a few days ago it was like "iptables connbytes 1000 drop", currently it's fine and you will never know when something will happen.
    honestly i haven't seen a network worse than "netem random 50% loss reorder 10% delay 100ms 50ms" on LAN, if your program survives that then it will be like 90% fine anywhere. (the best thing that i could find for such conditions was "https://github.com/apernet/tcp-brutal" tcp congestion protocol (btw their quic implementation was much worse in case of packet reordering or jitter), for others you may look at my sysctl.conf https://pastebin.com/raw/nixHq56s)

    i mean, there are other cases such as "16kb block" and "blocking of multiple TLS sessions" in russia for example (you may read about it and some other cases at https://habr.com/ru/users/0ka/articles/), but i have no idea if you are affected by that

    Thanked by 1TrikeLike
  • edited May 7

    @0ka said:
    @TrikeLike i saw your topic and you probably won't find it useful imo. last year it was like "netem random 10% loss", a few days ago it was like "iptables connbytes 1000 drop", currently it's fine and you will never know when something will happen

    Sounds exciting. Do they charge extra for the experience would this be a little free thank you coming with every plan?

  • 0ka0ka Member
    edited May 16

    only icmp seems to work fine right now, any tcp and udp ports work for just 15 seconds every few minutes. also i forgot to add that my openvpn didn't work yesterday (idk since when)...

    upd: since icmp seemed unaffected, i disabled icmp echo on my vps, and when the network broke again, suddenly my ip address started responding to pings, that probably means someone hijacked my ip address

  • 0ka0ka Member

    someone is still jacking my ip address

    (empty - good, line - someone else is using my IP)

  • 0ka0ka Member

    whole /24 is down for 4 hours already

  • rm_rm_ IPv6 Advocate, Veteran
    edited June 1

    Unfortunately we need to be on lookout for this issue may have returned.

    2 days ago immediately after the introduction of new IPs the network started jittering all over the place, and there is now packet loss. I posted my thoughts in the thread, no response from the provider.

    Now the next hope is 5th June or whatever, when the old subnet IPs get removed. Maybe having 2x as much IPs on the node is overloading the system in some way.

    The graph above is from IPv6, since there's no easy way to plot a contiguous graph for IPv4, as those got switched over. But it's showing that IPv6 got affected too, even though it wasn't changed in this case.

  • 0ka0ka Member

    same for me, and now it's at 1% average packet loss in the last 24h, before it was at 0.2%

  • rm_rm_ IPv6 Advocate, Veteran

  • rm_rm_ IPv6 Advocate, Veteran

    And earlier today:

    [Sat Jun  6 12:47:19 2026] clocksource: Long readout interval, skipping watchdog check: cs_nsec: 4797784999 wd_nsec: 4797780024
    [Sat Jun  6 12:50:47 2026] clocksource: Long readout interval, skipping watchdog check: cs_nsec: 10423685136 wd_nsec: 10423682291
    [Sat Jun  6 12:51:12 2026] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
    [Sat Jun  6 12:51:28 2026] rcu:     (detected by 0, t=5508 jiffies, g=46661785, q=45 ncpus=1)
    [Sat Jun  6 12:51:28 2026] rcu: All QSes seen, last rcu_preempt kthread activity 5508 (4461906049-4461900541), jiffies_till_next_fqs=1, root ->qsmask 0x0
    [Sat Jun  6 12:51:28 2026] rcu: rcu_preempt kthread starved for 5508 jiffies! g46661785 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
    [Sat Jun  6 12:51:28 2026] rcu:     Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
    [Sat Jun  6 12:51:28 2026] rcu: RCU grace-period kthread stack dump:
    [Sat Jun  6 12:51:28 2026] task:rcu_preempt     state:R  running task     stack:0     pid:15    tgid:15    ppid:2      task_flags:0x208040 flags:0x00080000
    [Sat Jun  6 12:51:28 2026] Call Trace:
    [Sat Jun  6 12:51:28 2026]  
    [Sat Jun  6 12:51:28 2026]  __schedule+0x4fd/0xed0
    [Sat Jun  6 12:51:28 2026]  ? lock_timer_base+0x7c/0xb0
    [Sat Jun  6 12:51:28 2026]  schedule+0x27/0xd0
    [Sat Jun  6 12:51:28 2026]  schedule_timeout+0x86/0x110
    [Sat Jun  6 12:51:28 2026]  ? __pfx_process_timeout+0x10/0x10
    [Sat Jun  6 12:51:28 2026]  rcu_gp_fqs_loop+0x13f/0x530
    [Sat Jun  6 12:51:28 2026]  ? __pfx_rcu_gp_kthread+0x10/0x10
    [Sat Jun  6 12:51:28 2026]  rcu_gp_kthread+0xd3/0x190
    [Sat Jun  6 12:51:28 2026]  kthread+0xfe/0x240
    [Sat Jun  6 12:51:28 2026]  ? finish_task_switch.isra.0+0x88/0x2d0
    [Sat Jun  6 12:51:28 2026]  ? __pfx_kthread+0x10/0x10
    [Sat Jun  6 12:51:28 2026]  ret_from_fork+0x1e8/0x240
    [Sat Jun  6 12:51:28 2026]  ? __pfx_kthread+0x10/0x10
    [Sat Jun  6 12:51:28 2026]  ret_from_fork_asm+0x1a/0x30
    [Sat Jun  6 12:51:28 2026]  
    [Sat Jun  6 12:51:28 2026] rcu: Stack dump where RCU GP kthread last ran:
    [Sat Jun  6 12:51:28 2026] CPU: 0 UID: 107 PID: 1205 Comm: vnstatd Tainted: G           OE       6.18.33-rm1+ #517 PREEMPT(lazy) 
    [Sat Jun  6 12:51:28 2026] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
    [Sat Jun  6 12:51:28 2026] Hardware name: Red Hat KVM, BIOS 1.16.0-4.module_el8.9.0+3659+9c8643f3 04/01/2014
    [Sat Jun  6 12:51:28 2026] RIP: 0010:handle_softirqs+0x76/0x320
    [Sat Jun  6 12:51:28 2026] Code: 00 bd 0a 00 00 00 89 5c 24 18 45 89 f7 4c 89 24 24 89 6c 24 0c 40 88 7c 24 08 31 c0 65 66 89 05 88 17 13 02 fb 0f 1f 44 00 00  ff ff ff ff 48 c7 c5 c0 80 40 83 45 89 fc 41 0f bc df 83 c3 01
    [Sat Jun  6 12:51:28 2026] RSP: 0018:ffffce6500003f88 EFLAGS: 00000246
    [Sat Jun  6 12:51:28 2026] RAX: 0000000000000000 RBX: 0000000000400040 RCX: 00000000000006e0
    [Sat Jun  6 12:51:28 2026] RDX: 0000000000062810 RSI: ffff8b59c5458000 RDI: 0000000000000000
    [Sat Jun  6 12:51:28 2026] RBP: 000000000000000a R08: 00025f9437008200 R09: 7fffffffffffffff
    [Sat Jun  6 12:51:28 2026] R10: 00025f9436c37900 R11: 0000000000c23915 R12: 0000000109f339ed
    [Sat Jun  6 12:51:28 2026] R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000002
    [Sat Jun  6 12:51:28 2026] FS:  00007f39d932e740(0000) GS:ffff8b5a7abe6000(0000) knlGS:0000000000000000
    [Sat Jun  6 12:51:28 2026] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [Sat Jun  6 12:51:28 2026] CR2: 00007fbe1fb0d500 CR3: 000000000218a002 CR4: 0000000000372ef0
    [Sat Jun  6 12:51:28 2026] Call Trace:
    [Sat Jun  6 12:51:28 2026]  
    [Sat Jun  6 12:51:28 2026]  __irq_exit_rcu+0xc3/0xe0
    [Sat Jun  6 12:51:28 2026]  sysvec_apic_timer_interrupt+0x71/0x90
    [Sat Jun  6 12:51:28 2026]  
    [Sat Jun  6 12:51:28 2026]  
    [Sat Jun  6 12:51:28 2026]  asm_sysvec_apic_timer_interrupt+0x1a/0x20
    [Sat Jun  6 12:51:28 2026] RIP: 0010:finish_task_switch.isra.0+0x8e/0x2d0
    [Sat Jun  6 12:51:28 2026] Code: 44 24 34 00 00 00 00 0f 1f 44 00 00 4c 8b b3 d8 0b 00 00 4d 85 f6 0f 85 a7 00 00 00 48 89 df e8 a8 51 c4 00 fb 0f 1f 44 00 00 <66> 90 4d 85 ed 74 20 65 48 8b 05 3b b7 0e 02 4c 3b a8 50 09 00 00
    [Sat Jun  6 12:51:28 2026] RSP: 0018:ffffce65008bfcc8 EFLAGS: 00000282
    [Sat Jun  6 12:51:28 2026] RAX: 0000000080000002 RBX: ffff8b59fec31500 RCX: 0000000000000002
    [Sat Jun  6 12:51:28 2026] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b59fec31500
    [Sat Jun  6 12:51:28 2026] RBP: ffffce65008bfcf0 R08: 0000000000000001 R09: 0000000000000080
    [Sat Jun  6 12:51:28 2026] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8b59c1250000
    [Sat Jun  6 12:51:28 2026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
    [Sat Jun  6 12:51:28 2026]  ? finish_task_switch.isra.0+0x88/0x2d0
    [Sat Jun  6 12:51:28 2026]  __schedule+0x505/0xed0
    [Sat Jun  6 12:51:28 2026]  schedule+0x27/0xd0
    [Sat Jun  6 12:51:28 2026]  do_nanosleep+0x79/0x150
    [Sat Jun  6 12:51:28 2026]  hrtimer_nanosleep+0x89/0x100
    [Sat Jun  6 12:51:28 2026]  ? __pfx_hrtimer_wakeup+0x10/0x10
    [Sat Jun  6 12:51:28 2026]  common_nsleep+0x43/0x50
    [Sat Jun  6 12:51:28 2026]  __x64_sys_clock_nanosleep+0xf6/0x180
    [Sat Jun  6 12:51:28 2026]  do_syscall_64+0x86/0x7e0
    [Sat Jun  6 12:51:28 2026]  ? schedule+0x27/0xd0
    [Sat Jun  6 12:51:28 2026]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
    [Sat Jun  6 12:51:28 2026] RIP: 0033:0x7f39d9400503
    [Sat Jun  6 12:51:28 2026] Code: ff ff c3 0f 1f 40 00 83 ff 03 74 7b 83 ff 02 b8 fa ff ff ff 49 89 ca 0f 44 f8 80 3d de c0 10 00 00 74 14 b8 e6 00 00 00 0f 05  d8 c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec 28 48 89 54 24 10
    [Sat Jun  6 12:51:28 2026] RSP: 002b:00007fffc7e38338 EFLAGS: 00000202 ORIG_RAX: 00000000000000e6
    [Sat Jun  6 12:51:28 2026] RAX: ffffffffffffffda RBX: ffffffffffffff80 RCX: 00007f39d9400503
    [Sat Jun  6 12:51:28 2026] RDX: 00007fffc7e38350 RSI: 0000000000000000 RDI: 0000000000000000
    [Sat Jun  6 12:51:28 2026] RBP: 0000000000000009 R08: 0000000000000007 R09: 000000001c27ba10
    [Sat Jun  6 12:51:28 2026] R10: 00007fffc7e38350 R11: 0000000000000202 R12: 000000000000002d
    [Sat Jun  6 12:51:28 2026] R13: 0000000000000002 R14: 0000000000000004 R15: 00007fffc7e38998
    [Sat Jun  6 12:51:28 2026]  
    [Sat Jun  6 12:51:28 2026] clocksource: Long readout interval, skipping watchdog check: cs_nsec: 32173282073 wd_nsec: 32173284726
    
  • 0ka0ka Member

    it's completely unusable

  • NeoonNeoon Community Contributor, Veteran
    edited June 6

    @0ka said:

    it's completely unusable

  • I should learn to use probes, otherwise I might not know what's happening when I can't log into my VPS.

  • rm_rm_ IPv6 Advocate, Veteran

    30%+ packet loss by now pretty much all the time.

    Ticket #618683 unanswered for 2 days.

    @VPSSLIM is it maybe time to conclude that we have failed at hosting, and go do something else?

  • bustersgbustersg Member
    edited June 10

    i signed their cheap reseller hosting.. very happy at first then their Installatron cannot work anymore. opened ticket, reply was they working with Installatron ... almost a month and no updates. if i cant use softaculous or Installatron for ease of click-to-install, then why do i still want shared hosting, might as well go VPS setup myself.
    sorry for the rant - the owner Ralph was kind and quick in reply though.

Sign In or Register to comment.