# So you Start - Sentient?



## HN-Matt (Sep 30, 2015)

I've read some horror stories about So you Start's support. Blah blah long response times for hardware replacement and so on. On the other hand, I have some servers with OVH and have never had a problem with them, so I ended up giving SyS a try a few days ago. So far it seems to have been a mistake.

From the start there were problems from all angles. Potential hardware problems and possible problems with the custom OS they provide through their otherwise convenient automated OS re/installation platform (makes installing an OS super easy for beginners). It's still too early to draw conclusions, so I'll leave those issues aside for the time being and focus on a problematic 'failover IP' I was given (it would seem the term wins the day for ironic naming schemes).

I ordered a /30 at first and there were no connectivity problems (able to allocate the IPs and provision working VMs, etc.), so I bought another IP from a different location the next day and... well, here's a transcript from a ticket I submitted a couple days ago called "Extreme packet loss". Names and IP addresses have been removed to protect the innocent. My frustration is showing, having experienced problems with almost every aspect of the server so far.



Quote said:


> Me - 28/09/2015 20:49Is there a problem with your network at this time?
> 
> I was finally able to get my newest FO IP to work, but now there's extreme packet loss.
> 
> ...


So connectivity was globally atrocious with only 4 out of 36 hosts on 'Super-Ping' able to ping the IP at all, 86% packet loss from my home connection, some 'hilarious' results from ping.eu and more or less 100% packet loss from a few other test sites chosen at random. Seemingly this would suggest that any diagnosis of the problem will extend far beyond the results of a single traceroute from my home connection. The response?



Quote said:


> Support - 29/09/2015 01:40Good day,
> 
> If you think that your server is having hardware issues, you can put it in Rescue Mode and run the hardware check to see if your RAM or CPU or HDD is having any kind of fault. Here's how to launch the rescue session:
> 
> ...


100% packet loss from almost everywhere in the world? Hrm, sounds like a hardware problem, why not try booting the server into rescue mode?

I responded emphasizing the insane packet loss again (as I probably hadn't done so enough) and asked them to forward the ticket to someone who actually reads the content of messages instead of just copy/pasting canned responses that have nothing to do with the issue at hand. The reply:



Quote said:


> Support - 29/09/2015 21:51Good day,
> 
> Just to make this thing clear, do you have network or hardware issues with your server because all your tickets are not saying the same.
> 
> ...


I... I have other open tickets... and yes... it's true that each ticket contains different subject matter...

Alas, the concept of multiple tickets for different problems is too much and we have reached an either/or juncture. Is it a _network_ or a _hardware_ issue? Apparently you can only have one and it's up to me to find out!

Well, I've sent about 3 million ping tests from multiple locations around the globe so far and have a different ticket open regarding potential hardware problems (to which they replied with the same canned response as above). The situation is absurd, but I try to respond calmly.



Quote said:


> Me - 29/09/2015 23:20I'm not entirely certain re: hardware issues yet, but it's certainly a network problem in this ticket.


To which I received this response about an hour and a half ago...



Quote said:


> Support - 29/09/2015 23:33Good day,
> 
> I've seen the information you provided and the ping test is not enough to qualify this issue as packet loss. As already mentioned in my first message, we will also need a traceroute and Ipfer test:
> 
> ...


 

Right now I'm sincerely wondering if SyS's tech support is comprised of 'sentient beings'. Does anyone know? I would probably feel a bit better if it turned out I had been communicating with a primitive AI attempting to parse/interpret 'human input'.

Other than that, to their credit, I was given a 'better' server than the one I ordered. Bought something from their lowest priced range and was given an E3-1245v2 instead! How can I complain, right!?


----------



## HN-Matt (Sep 30, 2015)

Another problem is there's no IPMI and they charge $30 per day for a KVM console. I didn't foresee this as IPMI is free with OVH's dedicated server line.







In other words, it seems I can't use any third party OS and am stuck with their custom OS templates?

Makes diagnosing certain problems a bit difficult to say the least.

I mean, come on, even SolusVM offers a console to every single VPS as a standard feature. It's not like it's some $30-per-day luxury to instantiate. I understand their prices are low, but I already paid the setup fee which was more than the monthly price of the server. There's no way I'm gonna pay an extra $30 just for the one-day 'privilege' of being able to install a third party OS!

EDIT: So you Start has now merged all of my tickets into one, lol. Usually I'll see tech support complain when different problems are all jumbled into the same ticket. 'One ticket per issue' etc. Not with SyS, I guess.


----------



## HN-Matt (Sep 30, 2015)

More obliviousness and misdirection...



Quote said:


> Support - 30/09/2015 07:10Hello,
> 
> In order to help you with your issue, we will need to see your network interface configuration of each IP failover:
> 
> ...


I'm not sure what copious packet loss from _52 different test sites around the world_ has to do with the "network interface configuration of each IP failover" at the level of config files in /etc/x.

The IPs are configured correctly (in fact, I eventually got them working by NOT following the generic guide at docs.ovh.ca). I can create VMs and connect to them. The VMs are able to communicate with the internet. The problem was staying connected because of _copious packet loss_, not misconfigured values in the OS...

On the verge of a chargeback now as I've wasted multiple days going nowhere with their support. I have a hard time believing the techs are that oblivious, it seems they are wilfully ignoring where the problem lies.


----------



## GIANT_CRAB (Sep 30, 2015)

So you Suck


----------



## HN-Matt (Sep 30, 2015)

very rude @GIANT_CRAB


----------



## IndoVirtue (Sep 30, 2015)

HN-Matt said:


> very rude @GIANT_CRAB



Instead of taking 'you' literally, it might be more like a word play of SYS (So You Start). If anything, he agrees with you. I might be wrong though, need @GIANT_CRAB to answer


----------



## wlanboy (Sep 30, 2015)

SyS is Bad - Shit bYond compare. 

Can'tbelieve their "support" responses...


----------



## TheLinuxBug (Sep 30, 2015)

I will mention this, if the additional IP you ordered has a different subnet mask and/or gateway you may not have the routing setup correctly on your server.  If this was the case you would see large amounts of packet loss.   Of course I have never used SYS so I am just guessing here.  If all the ips are in the same c-class, subnet and use the same gateway, then your right, this would have to be an issue to resolve from their side.  The first thing I would do is remove the additional IP and see if the issue goes away.  If it does, instead of telling them there is a problem, ask them for the correct network configuration to use when assigning the IP to the server, it could be that you are not correctly defining the route that data to and from that IP should take.

If you remove the IP and the issue continues, then I would say they have configured something incorrectly at the router and again I would mention that this issue has occurred since they assigned you that IP and ask them if there is possibly a configuration problem on their side.

my 2 cents.

Cheers!


----------



## KuJoe (Sep 30, 2015)

Why not follow their directions in their original reply to help them? Fighting with them and refusing to help them doesn't help anybody. MTR results go a long way when troubleshooting network issues.


----------



## HN-Matt (Oct 1, 2015)

@IndoVirtue lol I know / was only playing, but thanks for spelling it out. Beep boop double entendre 0 or 1. First fuzzy logic, then the world.

@TheLinuxBug there was only packet loss with a single failover IP. It was indeed in a different 'c-class'. Although I think you may have misunderstood the problem as adding/removing it had no effect on the other IPs (host node and other FO IP) which were not experiencing any packet loss. Smooth sailing except for a single IP.

@Kujoe you're joking, right? Any remotely competent support would have been able to at least begin troubleshooting this without requesting 'MTR' results, e.g. they could have quickly set up a test server and attempted to reproduce the problem by allocating a similar IP with a slightly different fourth octet. I doubt they bothered to check for themselves at all. Instead they told me that the issue didn't even 'qualify' as packet loss! If a client sends you _fifty fucking two_ different locations experiencing 86 - 100% packet loss and you literally respond with "thats not enough to qualify the issue as packet loss" you're either a complete asshole or beyond oblivious.

Either way, I've had enough. The absurdity of their support responses alone are enough to make me never look back.


----------



## HN-Matt (Oct 1, 2015)

To add some more perspective, I've bought hundreds of FO IP from OVH within the past year and am more or less satisfied with the quality and service. I've never had connectivity problems with any of them, not a single one, until now via SyS.


----------



## KuJoe (Oct 1, 2015)

HN-Matt said:


> @Kujoe you're joking, right? Any remotely competent support would have been able to at least begin troubleshooting this without requesting 'MTR' results, e.g. they could have quickly set up a test server and attempted to reproduce the problem by allocating a similar IP with a slightly different fourth octet. I doubt they bothered to check for themselves at all. Instead they told me that the issue didn't even 'qualify' as packet loss! If a client sends you _fifty fucking two_ different locations experiencing 86 - 100% packet loss and you literally respond with "thats not enough to qualify the issue as packet loss" you're either a complete asshole or beyond oblivious.
> 
> Either way, I've had enough. The absurdity of their support responses alone are enough to make me never look back.



An MTR will show them where the packet loss is. You opened the ticket yet you're not willing to put any effort in resolving it? The ticket could have gone a lot differently if you just followed their request. Anybody who's ever called their ISP for tech support knows that step number one is rebooting the modem/router even though it's not going to fix most issues but we humor the script readers and do it so that we can get on to step two of troubleshooting or perhaps escalation. If their script says "do not escalate without an MTR from both directions" then you're only hurting yourself at this point. Sure, the tech could do this themselves but why should they? If nobody else is having a problem and you're the only one then why should they build a new server in hopes of reproducing a problem that is obviously not widespread? They're probably making less than $20/hour juggling dozens or even hundreds of tickets at a time so of course they'll be more helpful towards clients who don't fight them on something simple as an MTR showing where the packet loss is. Imagine how you'd feel if somebody opened a ticket with you, fought with you for hours, only to receive an MTR output showing the packet loss was occurring on their server and not their network? With tech support you need to pick and choose your battles and this was one battle not worth fighting and as a result you've wasted more time than you needed to (they're getting paid either way so the only loss is your own, then again it's your call if it's a loss or not but I personally see the dollar signs leaving my wallet if I had to make that many replies to a ticket with a data center like you did).


----------



## HN-Matt (Oct 1, 2015)

"the script readers"

I see what you're saying @Kujoe but if their 'support' (if you can even call it that without cringing) can't respond beyond the cynicism of your speculations, then it's even more reason for me to cancel. If they're only functionaries who can't improvise beyond a script, why would I want to work with them to begin with?

Not all hosts are reduced to highly constrained script-reading contexts like the outsourced tech support for large ISPs (I used to do that exact job for Comcast in my early twenties... hated it).

Really, you can argue about 'MTR' or any other small detail re: 'what I should have done' until you're blue in the face, but in the end there's a minimum definition of 'support' that I'm willing to work with and they failed to meet it.


----------



## HN-Matt (Oct 1, 2015)

KuJoe said:


> With tech support you need to pick and choose your battles and this was one battle not worth fighting and as a result you've wasted more time than you needed to (they're getting paid either way so the only loss is your own, then again it's your call if it's a loss or not but I personally see the dollar signs leaving my wallet if I had to make that many replies to a ticket with a data center like you did).



By the way, this too. You don't 'pick and choose your battles' with any support team that is actually there to help. That's absolute nonsense. If you've reached the point where you're battling with _those who you're paying for support_, it's only another reason to get your money back and move on if anything.

That's what's so insulting about it. I'm paying them hundreds of dollars and for what? So they can waste my time while proving they're incapable of doing anything beyond the tunnel vision of scripted responses? No thanks.


----------



## DomainBop (Oct 2, 2015)

HN-Matt said:


> KuJoe said:
> 
> 
> > I'm paying them hundreds of dollars and for what? So they can waste my time while proving they're incapable of doing anything beyond the tunnel vision of scripted responses? No thanks.


OVH's budget used equipment brands SoYouStart and Kimsufi only include a bare minimal amount of non-managed support for hardware problems and billing problems only.  Nothing else besides hardware and billing assistance is included (and their support page says to ask all other questions on their forum).  "Scripted responses" help keep the costs down and the bare minimal support levels they provide for those budget brands are the only reason they're able to offer their servers at those prices.  

If you want something non-scripted with better support you need to get a full priced server at OVH instead of SYS, and if you want something with great support buy their VIP support package for €49.00 monthly (payable in annual payments only, so €588.00 each year).  If you're running a business on OVH it's a good idea to get their VIP support package as an insurance policy in case something goes wrong (and it should go without saying you shouldn't try to run a business on SYS).



Quote said:


> They're probably making less than $20/hour juggling dozens or even hundreds of tickets at a time so of course they'll be more helpful towards clients who don't fight them on something simple as an MTR showing where the packet loss is.


Their job posting for Level1/2 techs doesn't include a salary but if anyone needs a job they're hiring 20 more L1/L2 techs...4 week training period: https://www.ovh.com/fr/careers/sc_st_rbx1015-technicien-support-it

 (list of all job openings: https://www.ovh.com/fr/careers/offres/?country=fr )


----------



## willie (Oct 2, 2015)

Mtr in both directions is a standard request.... I had packet loss with a ramnode vps the other day and they asked for that.  By the time I sent it the problem had cleared up, but at least it showed the issue was at their end.  Matt your expectations are unrealistic.  Just send the mtr's next time.


----------



## HN-Matt (Oct 2, 2015)

@DomainBop I didn't realize SyS = 100% used hardware. Are you sure? As I wrote earlier, I have some full priced servers with OVH for business use and no problems there. Didn't imagine SyS would be so [email protected] obviously it was possible for them to do their own MTR or traceroutes. Super-Ping has a traceroute feature (http://www.super-ping.com/?traceroute=xxx.xxx.xxx.xxx&node=x) so they would have had the opportunity to do 36 different traceroutes from that site alone if they'd bothered to confirm what I sent. Ellipsis Node is even a sponsor so they could have done a traceroute from one of my nodes without having to ask me. Running traceroutes or MTR from multiple directions (why only 'both'?) would have been much more helpful than a single MTR from me. Especially with such insane worldwide packet loss which clearly suggests that any diagnosis shouldn't be isolated to a single location... and yet refusing to budge until that happened?



willie said:


> Mtr in both directions is a standard request....


It is? Then why didn't they bother to do it?

Seriously, if a client is citing ridiculous packet loss from 52 different locations, how is it not 'standard' to imagine that support would first and foremost attempt to confirm it on their end? There is no 'sane' reason to isolate responsibility to the client in such circumstances. Refusing to help beyond forcing an MTR from one particular location in the face of worldwide packet loss without doing any tests of your own is not standard, it's stupid. I have no problem typing those three magic letters either, it was their scripted inflexibility to do so themselves that lost me. If that's all SyS's support is, then my mistake for renting from there to begin with.


----------



## KuJoe (Oct 2, 2015)

HN-Matt said:


> willie said:
> 
> 
> > Mtr in both directions is a standard request....
> ...


I understand why you think this, it's probably a foreign concept to most, but in reality it is more beneficial to the client and the provider if the client does the legwork before opening a ticket. We've had a lot of  ticket where client go "OMG packet loss!" when the rest of the network is running fine and we make them do the traceroutes and MTRs so they can see where the packet loss is on their VPS or their home ISP (one of those "if you teach a man to fish" things). Sure, I could easily run the MTR myself but if I had to do that for every ticket then I'd just close up shop because for a $7/month VPS doesn't cover the cost of hand holding (even at my very reduced rate of $25/hour that I charge our clients if they insist on hand holding). If there's a definite problem with our network then yes, I'll be happy to invest hours of my time to resolve it but if one person is affected out of hundreds then they must show me that the problem is with our network and not their VPS before I can assist them. I even wrote a document for our clients to follow if they experience a network issue that I request they do before I even login to any servers, routers, or switches (link). SoYouStart is budget servers, if the techs there were to hold everybody's hand every ticket they would be operating at a loss since human support is easily the most expensive factor of operating a budget brand.

To clarify the "pick your battles" thing I mentioned above, it has to do with expectations also:


If I call up my home ISP for packet loss I immediately expect the person on the phone to read me a script and make me waste half an hour of our lives to go through the motions even if I tell them exactly what/where the problem is.
If I call up my work ISP for packet loss I don't ping a damn thing if I get an alert, I simply say "circuit is down" or "circuit is experience packet loss" and within 5 minutes I'm off the phone and they're working on it (for $10k+ a month they'll send a tech out to the site and do the traceroutes themselves)
If I open a ticket for a $2/month VPS I already provide them the traceroutes and MTRs in my first message along with telling them where the packet loss is (which hop) so when they make their first response (hopefully within 48 hours) they'll have all of the information I have available to me.
If I open a ticket for a $75/month VPS I have, I'm happy to just open a ticket on my phone with simply "Got an alert, please investigate" while I'm out and about without doing any general troubleshooting myself.


----------



## HN-Matt (Oct 2, 2015)

KuJoe said:


> I understand why you think this, it's probably a foreign concept to most, but in reality it is more beneficial to the client and the provider if the client does the legwork before opening a ticket.


I don't disagree, but 'in reality' it's also more beneficial to both parties if the host does the legwork goes beyond the scriptwork should the client not follow their script to a T, rather than stubbornly refusing to do anything at all until then (i.e. the definition of being unhelpful, inflexible and incapable of spontaneously adapting to different situations).



Quote said:


> We've had a lot of  ticket where client go "OMG packet loss!" when the rest of the network is running fine...


Sure, but your 'rest of the network' and OVH's are completely different. The latter is much larger and has service in Portugal, Ireland, Lithuania, Finland, United Kingdom, Germany, Poland, Belgium, France, Netherlands, Spain, Czech Republic, Italy and more. I had FO IP in multiple locations. It would be silly for their support to simply assume the rest of the network 'is probably running fine' if IP addresses on the same host node are experiencing extreme packet loss in one part of the world and not another.



KuJoe said:


> and we make them do the traceroutes and MTRs so they can see where the packet loss is on their VPS or their home ISP (one of those "if you teach a man to fish" things).



Then what's the problem with asking them to do it after you? MTR isn't stupid, but needlessly forcing it into a script's anachronistic 'order of operations' and being 'unable to help' (i.e. being negligent and/or bullshitting your way through excuses) outside of that sure is!



Quote said:


> Sure, I could easily run the MTR myself but if I had to do that for every ticket then I'd just close up shop because for a $7/month VPS doesn't cover the cost of hand holding (even at my very reduced rate of $25/hour that I charge our clients if they insist on hand holding).


Being competent enough to look into your own network's connectivity prior to _forcing_ the client to do it first is not 'hand holding'. You're obviously lying, or at least I hope you are because lol if you get enough packet loss related tickets to end your business should you dare attempt an MTR for each one. You could have done like 1000 MTR tests in the time it's taken you to respond here.

Rather than bending over backwards to defend SyS's Eternal Right to never have to do any of their own MTR 'legwork' (lmao) prior to bizarrely isolating the responsibility to the client and awkwardly refusing to help otherwise, why not suggest they update their dumb scripts?


----------



## KuJoe (Oct 2, 2015)

Quote said:


> I don't disagree, but 'in reality' it's also more beneficial to both parties if the host does the legwork goes beyond the scriptwork should the client not follow their script to a T, rather than stubbornly refusing to do anything at all until then (i.e. the definition of being unhelpful, inflexible and incapable of spontaneously adapting to different situations).


It's not beneficial to anybody as you've clearly seen already. Offering tech support on a budget is what you've experienced with SYS already, the best way to make it work is to do the legwork yourself to avoid these kinds of tickets.



Quote said:


> Sure, but your 'rest of the network' and OVH's are completely different. The latter is much larger and has service in Portugal, Ireland, Lithuania, Finland, United Kingdom, Germany, Poland, Belgium, France, Netherlands, Spain, Czech Republic, Italy and more. I had FO IP in multiple locations. It would be silly for their support to simply assume the rest of the network 'is probably running fine' if IP addresses allocated to the same host node are experiencing extreme packet loss in one part of the world and not another.


For every 1 ticket I get they probably get 100 and that's exactly why making the client do the legwork is where it becomes better for all parties. A simple MTR output could have prevented this thread and probably resolved your issue much quicker.



Quote said:


> Then what's the problem with asking them to do it after you? It's not the MTR test that's stupid, but needlessly forcing it into a scripted 'order of operations' routine and being 'unable' to help (i.e. being negligent and/or bullshitting your way through excuses) outside of that sure is!


In this instance they probably do not have access to your server so their MTRs would not be apples to apples.



Quote said:


> Being competent enough to look into your own network's connectivity prior to forcing the client to do it first is not 'hand holding'. You're obviously lying, or at least I hope you are because lol if you get enough packet loss related tickets to end your business should you dare attempt an MTR for each one. You could have done like 1000 MTR tests in the time it's taken you to respond here.Rather than bending over backwards to defend a support team's Eternal Right to never have to do any of their own MTR 'legwork' (lmao) prior to bizarrely isolating the responsibility to the client and awkwardly refusing to help otherwise, why not suggest they update their dumb scripts?


We have monitoring that tells us when our own network is having issues as I'm sure OVH has the same types of monitoring in place. If the issue was affecting more than a few people I would hope that the "script readers" would have simply told you so but since they didn't it's probably safe to assume the issue was exclusive to your service.

I'm not lying about the hand holding and not all tickets we receive are due to packet loss (A LOT of clients get blocked by firewalls on a daily basis) but if I had to login to a computer every time I wanted to answer a support ticket I would be losing a lot of money and closing up shop would be much more profitable for me. When a client opens a ticket about not being able to connect to their VPS, 99.999999999999% of the time it's because they either blocked themselves with their own firewall, our firewall blocked them for whatever reason, or their ISP blocked their access to their server. A simple traceroute/MTR would tell us exactly where they were blocked and I could get the whole thing resolved from my cell phone (where I answer the majority of my support tickets).

I'm just trying to show you another point of view on this situation so hopefully it makes more sense why they do the things they do.


----------



## HN-Matt (Oct 2, 2015)

Okay, this could go on forever.

re: "a simple traceroute/MTR would tell us exactly where they were blocked", again, the excessive packet loss was worldwide... simply doing a traceroute/MTR from a single location wouldn't have accounted for everywhere else. This is obvious, so why ask for only one MTR? Refusing to do your own tests in the face of such excessive packet loss is, at best, intellectually insulting in that it suggests to the client you either don't believe or don't understand the severity of the problem. (Not quite the way to build trust).

tl;dr I am against the usage of MTR as _dei ex machina_.


----------



## HN-Matt (Oct 12, 2015)

If you're an MTR fan you can always try this subsequent packet loss drama on LET: http://www.lowendtalk.com/discussion/65489/seflow-stay-far-away-scammers-and-liars/p2#Comment_1323299

50% packet loss from more than one location and yet MTR didn't help to address anything about the deeper, underlying problem at all, as it wouldn't have here. The obfuscating focus on its 'correct usage' as a miracle cure is amusing, at least.

FOR IMMEDIATE RELEASE, reducing all aspects of the problem into a Trivial Pursuit game on how to use the command line might be completely misguided!

(P.S. I ended up cancelling the server and was given a full refund for the troubles in this thread, so thanks to SyS for not trying to scam me out of the money, at least).


----------



## Tyler (Oct 12, 2015)

I just want to pop in and say that their use of MTR is a bit silly. OVH & SYS both want MTR's for everything. It's unnecessary and a lot of distros don't even have mtr installed by default.


----------



## matteob (Oct 13, 2015)

HN-Matt said:


> If you're an MTR fan you can always try this subsequent packet loss drama on LET: http://www.lowendtalk.com/discussion/65489/seflow-stay-far-away-scammers-and-liars/p2#Comment_1323299
> 
> 50% packet loss from more than one location and yet MTR didn't help to address anything about the deeper, underlying problem at all, as it wouldn't have here. The obfuscating focus on its 'correct usage' as a miracle cure is amusing, at least.
> 
> ...



This thread, as example is not correct, because we was forced to do that reply to the customer due to police investigation. (we can now share the details). We had for 48 hours the police in DCs to sniff customer traffic due to international compliants from german IT police.


----------



## HN-Matt (Oct 13, 2015)

@matteob I wasn't calling you a scammer and I didn't mean the problems in both threads were similar. I've never had an account with seflow and have no opinion of your service.

I was juxtaposing the threads to show how in each instance MTR tunnel-vision was a diversionary focus that didn't really address any of the underlying problems.

Beyond that, I have no idea what's going on between you and the client on LET. That's messed re: police intervention, though, sorry to hear that.


----------



## matteob (Oct 13, 2015)

hi,

 nono i not want accuse you. Just want say that mtr shown on that thread was altered due to sniffing operations.


----------



## DomainBop (Oct 13, 2015)

KuJoe said:


> Quote said:
> 
> 
> > HN-Matt said:
> ...


I've had servers with them for 2+ years and they're one of the European dedicated providers I always recommend.  The network in Milan is very good (since they started using Noction and added Level3 and NTT in 2013 and dumped Cogent), their servers are reliable and priced similarly to OVH/Hetzner,  very fast response times to support tickets (I think all of my technical support tickets have been answered in under 15 minutes), and they're staffed by real people (as opposed to OVH which is staffed by robots...) 

TL;DR I tend to ignore reviews that call providers "scams" when the reviews are started by people who in the past have started threads asking _"Any providers that allows spoofed UDP?"_  



Tyler said:


> I just want to pop in and say that their use of MTR is a bit silly. OVH & SYS both want MTR's for everything. It's unnecessary and a lot of distros don't even have mtr installed by default.



I don't think any distros install mtr or mtr-tiny by default but it is available for all distros and *BSDs and Solaris.  It's one of the things I install on every server (and desktop) because it is a useful tool for diagnosing problems but there are many cases where it won't be much help (like police sniffing operations...)


----------



## HN-Matt (Oct 14, 2015)

Fun text re: the myth of echo & narcissus: http://criticalinformationsva.com/wp-content/uploads/2011/11/Gee_Erin_echo-narcissus.pdf



> [...]
> 
> *Echo and Ping –connectivity in networked landscapes*
> 
> ...


----------

