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.
RackNerd refused refund for VPS with 12% endpoint packet loss — full timeline
Hi all, sharing my experience with RackNerd in case it helps others decide. Keeping it factual with a full timeline.
The service: VPS 23.94.208.129 (Los Angeles). Ticket #SQ98186 with their Billing department.
The problem (all documented):
- From my home connection: ~12% packet loss at the endpoint itself, avg 159ms (WinMTR)
- Inside the US, Twelve99 backbone: 8%–23% packet loss on intermediate hops
- China Telecom path: ~95% packet loss
- Return path detours via Europe: 214–267ms
- RackNerd's own test from the VPS averaged ~290ms
- Full test report: https://Report.Check.Place/net/1WYHF63AA.svg
Timeline:
- Opened ticket #SQ98186 asking for a refund — full, or pro-rated, to the original payment method.
- Support (Dejana P., Dillon S.) asked for MTR results a couple of times; I pointed to the report and findings already in the thread each time.
- Sep 28 ~09:18 PDT: Anthony Fye (Customer Success Manager) gave a final written decision — refused both full and pro-rated refunds to the original payment method, called it final. Offered $18.30 account credit or a migration to a different location/IP instead. I declined the credit (original payment method only, no account credit).
- Sep 28 11:16: I posted a detailed 7-point rebuttal (the endpoint's own 12% loss, Twelve99 backbone loss, their own 290ms test result, and contradictions in their reasoning).
- Sep 28 ~13:57 PDT: Anthony replied again — redefined the credit/migration as pure "courtesy", attributed the issue to Chinese carriers / GFW / congestion, restated the refusal.
My take: a VPS with 12% packet loss at its own endpoint is not a usable service, no matter where the loss is attributed. "Online" is not the same as "usable". I'll let the community judge whether the refund refusal was reasonable.
Has anyone else had a similar refund experience with RackNerd?
Thanked by 1WyvernCo
Comments
@dustinc
Foreign (non-Chinese) networks cannot guarantee 0% packet loss to mainland China past the GFW. Your best option is to test companies network by using the test IP during peak times of the day to check loss before ordering.
@MikeA Fair point on testing first — lesson learned, point taken.
One clarification: I never asked for 0% loss. 12% loss at the endpoint itself, 8–23% inside the US on Twelve99, ~95% on the telecom path — that's not imperfect cross-border routing, that's an unusable box. This thread is about the refund side of it: refusing even a pro-rated refund to the original payment method for a service in that state.
To be honest, I don't see any loss to the IP provided right now.
https://s.ping.pe/J/W/snap_JWbuLLqA.html
Too early in China. Test in 5 hours.
I always ask for at least 20% loss
So, it just dropped the packet when busy / overloaded ? Noted.
Yea good ol international China connectivity. At least with Russia there is no packet loss, just straight network blocks!
Edit - 10 AM to 3 PM I think is where I've seen most packet loss at in the past, and that comes with latency increase due to the congestion.
@oloke Appreciate you testing it. A single snapshot at 7am Beijing time is off-peak though — MikeA's right that timing matters here. The 12% wasn't from one ping; it was sustained WinMTR from my home connection, plus 8–23% loss inside the US on Twelve99 (nothing to do with China peak hours), and RackNerd's own test averaging ~290ms. If you re-run during 8–11pm Beijing time I'd be curious how it compares.
@tenji That's exactly it — and that's my whole point. Usability that depends on the hour, sold with no such caveat, and then no refund (not even pro-rated) when it's unusable during the hours you actually need it.
@MikeA Thanks — 10am–3pm lines up with what I've observed as well. Useful reference.