Howdy, Stranger!

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


Review Data Packet Networks - zero tolerance
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.

Review Data Packet Networks - zero tolerance

Data Packet Networks - https://datapacket.net/ service offering is less than useful in that if the subscriber's VPS is doing anything more than sitting idle, they will login into the VPS and remove or disable services.

Receiving an email with the subject line 'ABUSE: Immediate action required' and the message: 'The following services have been removed. They were found to be causing high idle CPU on the host', is something no subscriber wants to receive.

Such a message is even more unwelcome when said server had been running for months, with no configuration changes other than Windows updates. Rather than working collaboratively to identify "why" services on a system are suddenly using more CPU resources, the support team logs in and removes the services.

In my case, the offending services were XLight FTPd, and a remote support application called SimpleHelp. These same services run on VPS' from other vendors (Virmach, Servarica, and Contabo) with no complaints, but for Data Packet networks, those two applications were a problem. Considering that my VPS were consuming less than 20% of the allocated disk space, virtually zero traffic, and rarely logged into, the systems were largely sitting idle.

It would seem that Data Packet Networks has a zero-tolerance-policy. I too have a zero-tolerance-policy, and after months of being an otherwise very happy client, I pulled the the plug and cancelled my services.

As for a hosting provider, Data Packet Networks is lacking more than a reasonable attitude. There is no way to reboot or restart a VPS. If a VPS needs a hard-reset, the only option is to contact support. Further, if privacy is important, look elsewhere; Data Paket Networks wants your administrator credentials. In my case, I shared the credentials, as the machines were essentially idle, but if I actually had been using the VPS for some business purpose, providing administrator access would have been a MAJOR concern.

In short, it is probably best to look for an alternative. Servarica has been excellent as has been Contabo. Virmach has been OK as well.

Data Packet Networks VPS was blazing fast, it was stable, and even though I had to share the admin credentials, I was happy with the service. However, once they became unreasonable, they became subject to my zero-tolerance-policy.

RG

Comments

  • PHDanPHDan Member

    Can I ask who you have chosen as your legal representation in your actions against the provider?

  • Hi Robert,

    Thanks for your review, but let's clarify a few things.

    On March 13th your virtual machines were found using excessive amounts of persistent CPU on the host node and we worked with you to resolve the issue. You stated that we're welcome to login and take a look. You gave us the login credentials willingly of your own accord to investigate the issue. We reported the issue to you and the issue was resolved. A third party program you were running was found to be the culprit.

    Moving to the current situation we found your virtual machines using excessive persistent CPU on the host. Again we checked your virtual machines and found the same third party software had been reinstalled even though we had dealt with this a month prior. You elected to purposely ignore the previous abuse incident and warning.

    I don't follow your comment about zero tolerance, if we did your virtual machines would have been shut down and terminated on the first occurrence, but are still active today. We have displayed anything but zero tolerance. We are happy to work with you, but your recent responses have been filled with profanity and an unwillingness to work together.

    As explained to you already, high idle does not mean you can't use your VPS other than to idle. It means that while your VPS may show you as being idle, your virtual machine is actually causing the host node to experience high CPU usage. This generally occurs under Windows virtual machines utilizing third party software with timing issues or a KVM bug.

    Regards to the community.

    Kevin

  • jarjar Patron Provider, Top Host, Veteran
    edited April 2020

    Robert_G said: Rather than working collaboratively to identify "why" services on a system are suddenly using more CPU resources, the support team logs in and removes the services

    Sounds like a huge privacy violation.

    DataPacket said: You gave us the login credentials willingly of your own accord to investigate the issue

    And that means you (@Robert_G) intentionally left out the most defining detail. Seriously, you should feel really bad about that accusation if this is remotely true (and why wouldn't it be, sounds like Windows, I doubt they reset admin pass just to do this).

    Thanked by 2o_be_one marrco
  • Ban the OP. Ain't nobody got time for those affected by reality distortion. Excessive CPU is not the provider's responsibility to troubleshoot and the lack of appreciation or acknowledgement makes you a douche. They are in the right from everything you said or didn't say.

    Is this the kind of thing that goes into FraudRecord?

    Thanked by 2jar BrianHarrison
  • There are a lot of assumptions here, the biggest of which is that the offending services were using idle CPU. Windows' task manager doesn't reflect what Data Packet reported.

    The following three images show the same services on a similar KVM based VPS.

    https://www.adrive.com/public/DghXDr/1.jpg

    https://www.adrive.com/public/DNHtka/2.jpg

    https://www.adrive.com/public/GxEbEt/3.jpg

    Image 1 shows Xlight.exe using no CPU.

    Image 2 shows RemoteAccess.exe using no CPU.

    Image 3 shows the running processes sorted by use. The two offending services don't appear.

    When Data Packet contacted me the first time, I shared the credentials because I had nothing confidential on the server, because I wanted to cooperate fully, and because I did not want to negatively impact others using the service. I took their word on what they had found.

    Upon further investigation, I did find that Xlight had an available update. I installed the update and monitored the server for a few days. The only process that was consistently using idle time was chrome.exe. The service Remote.Access.exe sat idle waiting for a connection. I also monitored my other servers, and I could not reproduce the problem.

    When I was contacted a second time, I did not see any point in arguing. The two VPS I had with the service weren't running anything critical. There was an FTP daemon running, but it was never used. The servers were literally idle and I knew that I could not reproduce the problem. The quickest way to resolve the conflict was to cancel my services.

  • deankdeank Member, Troll

    I second the notion. Ban the OP.

  • imokimok Member

    Robert_G said: the same services on a similar KVM based VPS

    You must learn that, unless you have full control over the software you are using, each environment is not the same. Worse still when you talk about KVM VPS rented from different providers.

    That and probably you got hacked.

    Ban @deank also because @WSS is back.

    Thanked by 1TimboJones
  • @Robert_G said:
    There are a lot of assumptions here, the biggest of which is that the offending services were using idle CPU. Windows' task manager doesn't reflect what Data Packet reported.

    The following three images show the same services on a similar KVM based VPS.

    https://www.adrive.com/public/DghXDr/1.jpg

    https://www.adrive.com/public/DNHtka/2.jpg

    https://www.adrive.com/public/GxEbEt/3.jpg

    Image 1 shows Xlight.exe using no CPU.

    Image 2 shows RemoteAccess.exe using no CPU.

    Image 3 shows the running processes sorted by use. The two offending services don't appear.

    When Data Packet contacted me the first time, I shared the credentials because I had nothing confidential on the server, because I wanted to cooperate fully, and because I did not want to negatively impact others using the service. I took their word on what they had found.

    Upon further investigation, I did find that Xlight had an available update. I installed the update and monitored the server for a few days. The only process that was consistently using idle time was chrome.exe. The service Remote.Access.exe sat idle waiting for a connection. I also monitored my other servers, and I could not reproduce the problem.

    When I was contacted a second time, I did not see any point in arguing. The two VPS I had with the service weren't running anything critical. There was an FTP daemon running, but it was never used. The servers were literally idle and I knew that I could not reproduce the problem. The quickest way to resolve the conflict was to cancel my services.

    Windows is a weird OS in the hosting world. Mostly because that UI is really heavy. Even a regular update can easily increase cpu usage if you don't have the right amount of resources.

  • @Robert_G said:
    There are a lot of assumptions here, the biggest of which is that the offending services were using idle CPU. Windows' task manager doesn't reflect what Data Packet reported.

    The following three images show the same services on a similar KVM based VPS.

    https://www.adrive.com/public/DghXDr/1.jpg

    https://www.adrive.com/public/DNHtka/2.jpg

    https://www.adrive.com/public/GxEbEt/3.jpg

    Image 1 shows Xlight.exe using no CPU.

    Image 2 shows RemoteAccess.exe using no CPU.

    Image 3 shows the running processes sorted by use. The two offending services don't appear.

    When Data Packet contacted me the first time, I shared the credentials because I had nothing confidential on the server, because I wanted to cooperate fully, and because I did not want to negatively impact others using the service. I took their word on what they had found.

    Upon further investigation, I did find that Xlight had an available update. I installed the update and monitored the server for a few days. The only process that was consistently using idle time was chrome.exe. The service Remote.Access.exe sat idle waiting for a connection. I also monitored my other servers, and I could not reproduce the problem.

    When I was contacted a second time, I did not see any point in arguing. The two VPS I had with the service weren't running anything critical. There was an FTP daemon running, but it was never used. The servers were literally idle and I knew that I could not reproduce the problem. The quickest way to resolve the conflict was to cancel my services.

    CPU screenshots for other instances doesn't say much. You need data from your instance. Many VPS panels have monitoring available. It would have been good for Data Packet to show what they saw, but I'm sure it was more than what you've presented so far. System admins over the years will discover servers that can spike during certain times of the day or after certain events. Or find misconfigured applications, etc.

    For me, I find remote apps use 30-40% of CPU on low to mid hardware, so leaving SimpleHelp running all the time might be what is causing continuously high CPU usage?

Sign In or Register to comment.