LowEndBox - Cheap VPS, Hosting and Dedicated Server Deals

CityNetHost – $3 128MB OpenVZ VPS

Tags: , , Date/Time: August 31, 2010 @ 1:43 pm, by LowEndAdmin

CityNetHost Mohamed from CityNetHost has sent me this offer. By using promo code LEB50 you can get 50% recurring discount on any VPS plans. So for $3/month you can get the following VPS in Egypt.

  • 128MB memory
  • 5GB storage
  • 200GB/month data transfer
  • OpenVZ/SolusVM

Not really an “exclusive offer” as a similar offer exists on their current promotion page. Nor is it cheaper than their previous special at $2.50/month for a 512MB OpenVZ VPS. Lots of comments with good discussions from previous two posts.

46 Comments

  1. So this means the previous offer from CityNetHost has expired, which is still a great VPS deal for me.

    August 31, 2010 @ 3:45 pm | Reply
  2. Gary:

    Nope, the previous offer is still available to buy by the looks of it.

    August 31, 2010 @ 4:30 pm | Reply
  3. Yes I think the previous offer is still available, although Mohamed did say that it is expiring soon (end of August?)

    August 31, 2010 @ 11:16 pm | Reply
  4. Irson:

    Seems like it’s still available.. I wonder for how long…

    Mohamed could you give us the info?

    September 1, 2010 @ 5:02 pm | Reply
  5. Yes the previous offer extended to 30/09/2010 :)

    September 2, 2010 @ 3:10 am | Reply
  6. Nicolas:

    Ok, sweet. And is it possible to take more than one VPS? If mine works well, i’d like to take another one to put mu backups :)

    September 2, 2010 @ 5:07 pm | Reply
  7. marikh:

    You should write some information about location in WHOIS, because server location is Unknown, when i’m visiting my pages hosted on your VPS.

    September 2, 2010 @ 9:01 pm | Reply
  8. @ Nicolas.

    Yes you can order more.

    September 2, 2010 @ 11:44 pm | Reply
  9. Gary:

    It just took 3 minutes to apt-get install whois (downloading the package was fast enough,the actual installing was the problem).

    18:47:12 up 23:18, 1 user, load average: 0.58, 0.29, 0.16

    That load was what awaited me when I logged in. Simply logging in via SSH had bumped the load so much.

    Perhaps I’m running something heavy? Think again. :)

    top – 18:56:52 up 23:27, 2 users, load average: 0.37, 0.81, 0.60
    Tasks: 10 total, 1 running, 9 sleeping, 0 stopped, 0 zombie
    Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
    Mem: 1048576k total, 13212k used, 1035364k free, 0k buffers
    Swap: 0k total, 0k used, 0k free, 0k cached

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    1 root 15 0 1980 688 588 S 0 0.1 0:01.35 init
    23762 root 18 0 8168 2720 2224 S 0 0.3 0:00.08 sshd
    23804 root 15 0 2788 1560 1224 S 0 0.1 0:00.01 bash
    23854 root 15 0 2256 1080 880 R 0 0.1 0:00.00 top
    24082 root 16 0 8016 2704 2224 S 0 0.3 0:00.07 sshd
    24094 root 15 0 2788 1572 1232 S 0 0.1 0:00.01 bash
    31846 root 15 0 1692 600 488 S 0 0.1 0:00.24 syslogd
    31895 root 18 0 1644 388 320 S 0 0.0 0:00.00 klogd
    32067 root 15 0 5272 1032 676 S 0 0.1 0:00.00 sshd
    32125 root 15 0 2036 868 696 S 0 0.1 0:00.04 cron

    It took a good 15 seconds to start top.

    And this is awful too…

    time dpkg -i rar_3.8b3-1_i386.deb
    Selecting previously deselected package rar.
    (Reading database … 11608 files and directories currently installed.)
    Unpacking rar (from rar_3.8b3-1_i386.deb) …
    Setting up rar (1:3.8b3-1) …
    Processing triggers for man-db …

    real 3m11.645s
    user 0m0.089s
    sys 0m0.150s

    I’m on one of their other packages where you get even more resources (4x as much guaranteed ram) so they can cram even more VMs on the hosts they’re using for this offer.

    It’s not a badly specced machine…

    processor : 0
    vendor_id : GenuineIntel
    cpu family : 15
    model : 4
    model name : Intel(R) Xeon(TM) CPU 2.80GHz
    stepping : 1
    cpu MHz : 700.031
    cache size : 1024 KB
    physical id : 0
    siblings : 2
    core id : 0
    cpu cores : 1
    apicid : 0
    fpu : yes
    fpu_exception : yes
    cpuid level : 5
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
    bogomips : 5600.25
    clflush size : 64
    cache_alignment : 128
    address sizes : 36 bits physical, 48 bits virtual
    power management:

    It just performs slower than any VPS I’ve ever used. I mean 3 minutes to dpkg -i rar? I don’t mind that the nic is artificially shaped to ~25mbit, I wouldn’t be using much BW. I would like it to respond to commands quickly though.

    Load hovers at about 0.5 when there’s nothing going on.

    To top it all off, I was about to open a ticket about this, but the link on their website to open a ticket just times out.

    September 7, 2010 @ 7:47 pm | Reply
  10. They will soon gone to deep… pools as well ;)

    September 7, 2010 @ 7:56 pm | Reply
  11. @Gary

    Actually your VM running on a very busy Node. We are taking necessary actions to move some of busy VMs to another node.

    Please open a ticket requesting to move your VM to a less busy node.

    Regards
    Mohamed Talaat

    September 7, 2010 @ 8:00 pm | Reply
  12. Gary:

    Like I said, I tried to open a ticket and the ticket page just doesn’t load. I wouldn’t normally complain in public before giving a host time to sort the problem, but I can’t even open a ticket.

    September 7, 2010 @ 8:12 pm | Reply
  13. Kamrul H.:

    Placing a order with them few moments ago. They setup my VPS instantly. If they will get so many customers they will never gone to dead pool.

    My IP : 41.223.52.102

    September 7, 2010 @ 8:39 pm | Reply
  14. NoName:

    @Mtalaat, Shouldn’t you be monitoring the nodes to ensure that the customers on it are getting what they pay for, I don’t see why a node become like this if the proper precautions were taken. i.e. the limitation of a certain amount of VMs per node along with cpu share technologies to ensure other users can’t effect the performance of another users VPS (cpu wise). And by the looks of it your simply overloading a “Rubbish” node, Out of intrest how many customers are you putting on each node?

    September 7, 2010 @ 8:39 pm | Reply
  15. Gary:

    It really seems like they have more problems than just an overloaded node. Unless their website is hosted on the same box as my VPS…

    September 7, 2010 @ 8:44 pm | Reply
  16. Gary:

    Ok, tickets are working now finally, I’ll submit one.

    September 7, 2010 @ 10:18 pm | Reply
  17. @Gary

    Our Ticket System always up, We are receiving tickets all the time.

    @NoName
    We are monitoring our nodes, some times a customer trying to abuse the server for few minutes. we take necessary action to isolate or terminate a VM with high load with evidence abusing the service.
    We are not using “Rubbish” Nodes!

    September 7, 2010 @ 10:38 pm | Reply
  18. @Mtalaat Although I love the service at the amazing price but I can also confirm that support ticket (WHMCS) is down at least 2 time in a week for about an hour. We discussed this in the support ticket yesterday remember?

    September 7, 2010 @ 10:47 pm | Reply
  19. Mike:

    I have one of their Xen VMs from a couple months ago, and have not had any problems with it. But that’s Xen, of course…

    September 7, 2010 @ 10:49 pm | Reply
  20. @Asim

    Yes we discovers that few customers from some countries not able to access parts of our network, we discussed the issue with our upstream provider and fixed it. it was an internet routing problem.

    We are very proud to say our network up time not less than 99.9% during the last 12 months.

    Please guys if you have any issue with your VPS or dedicated server do not hesitate to contact our live support or send email to support[@]citynethost.com or simply open a ticket.

    We consider every comment and every complain from you to make sure all of our customers are satisfied as much as we can.

    September 7, 2010 @ 11:07 pm | Reply
  21. Gary:

    Cheers for confirming it Asim. The ticket system was definitely not working. And it was more than someone abusing the system for a few minutes it was performing badly for hours, possibly longer.

    September 7, 2010 @ 11:13 pm | Reply
  22. @Gray,

    You have many options to contact us (email, Live Help, tickets) before you complain on public, Please open a ticket if you have an issue with your Server.

    September 7, 2010 @ 11:21 pm | Reply
  23. Gary:

    An update: I’ve now been put on a new node. They asked me if I minded getting a new IP, and that’s fine with me, so they moved me.

    I’m in an entirely different IP range. Network speeds are about the same I think, and actually doing things on the VPS is much faster. Thanks Mohamed.

    But…

    Here’s my new range:

    inetnum: 41.223.52.0 – 41.223.52.255
    netname: CITYNET-ADSL-Pool
    descr: CITYNET ADSL Pool
    country: EG
    admin-c: MT1-AFRINIC
    tech-c: MT1-AFRINIC
    status: ASSIGNED PA
    mnt-by: CITYNET-MNT
    source: AFRINIC # Filtered
    parent: 41.223.52.0 – 41.223.55.255

    person: Mohamed Talaat
    address: CityNet Telecom, S.A.E.
    34B Dohaa Mall
    Building (B)
    Tenth of Ramadan City
    Sharkia, Egypt.
    phone: +20 15 354448
    fax-no: +20 15 354449
    e-mail: admin@citynettelecom.net
    nic-hdl: MT1-AFRINIC
    source: AFRINIC # Filtered

    Ok… Out of date information maybe?

    Traceroute for the old IP address:

    traceroute 196.46.191.129
    traceroute to 196.46.191.129 (196.46.191.129), 30 hops max, 60 byte packets
    1 –.–.–.– (–.–.–.–) 0.029 ms 0.018 ms 0.017 ms
    2 ldn-1-6k.uk.eu (94.23.122.65) 174.066 ms * *
    3 gblx.as3549.uk.eu (213.251.130.54) 3.932 ms 3.980 ms 4.008 ms
    4 level3-2.ar2.LON3.gblx.net (208.50.13.194) 12.476 ms 12.621 ms 12.610 ms
    5 ae-33-51.ebr1.London1.Level3.net (4.69.139.65) 13.257 ms 13.244 ms 13.193 ms
    6 ae-48-48.ebr1.Paris1.Level3.net (4.69.143.114) 7.837 ms ae-45-45.ebr1.Paris1.Level3.net (4.69.143.102) 7.994 ms ae-48-48.ebr1.Paris1.Level3.net (4.69.143.114) 7.736 ms
    7 ae-1-51.edge1.Paris1.Level3.net (4.69.139.199) 8.178 ms 8.225 ms 8.209 ms
    8 LINKDOTNET.edge1.Paris1.Level3.net (212.73.206.18) 49.119 ms 49.120 ms 49.111 ms
    9 * * *
    10 * * *
    11 * * *
    12 host-196.46.189.26.citynet.com.eg (196.46.189.26) 76.024 ms 75.312 ms 78.133 ms
    13 host-196.46.189.14.citynet.com.eg (196.46.189.14) 54.506 ms 54.947 ms 54.936 ms
    14 host-196.46.189.13.citynet.com.eg (196.46.189.13) 62.048 ms 58.818 ms 61.783 ms
    15 host-196.46.189.14.citynet.com.eg (196.46.189.14) 54.631 ms 56.092 ms 55.469 ms
    16 host-196.46.189.13.citynet.com.eg (196.46.189.13) 58.251 ms 56.321 ms 55.793 ms
    17 host-196.46.189.14.citynet.com.eg (196.46.189.14) 55.755 ms 55.106 ms 54.439 ms
    18 host-196.46.189.13.citynet.com.eg (196.46.189.13) 55.030 ms 56.779 ms 61.411 ms
    19 host-196.46.189.14.citynet.com.eg (196.46.189.14) 55.063 ms 55.683 ms 58.092 ms
    20 host-196.46.189.13.citynet.com.eg (196.46.189.13) 56.992 ms 55.917 ms 56.068 ms
    21 host-196.46.189.14.citynet.com.eg (196.46.189.14) 57.533 ms 55.510 ms 55.716 ms
    22 host-196.46.189.13.citynet.com.eg (196.46.189.13) 58.377 ms 58.188 ms 58.898 ms
    23 host-196.46.189.14.citynet.com.eg (196.46.189.14) 57.004 ms 55.814 ms 55.593 ms
    24 host-196.46.189.13.citynet.com.eg (196.46.189.13) 55.704 ms 56.932 ms 56.629 ms
    25 host-196.46.189.14.citynet.com.eg (196.46.189.14) 56.105 ms 56.182 ms 56.863 ms
    26 host-196.46.189.13.citynet.com.eg (196.46.189.13) 59.534 ms 59.963 ms 57.583 ms
    27 host-196.46.189.14.citynet.com.eg (196.46.189.14) 57.186 ms 56.834 ms 55.846 ms
    28 host-196.46.189.13.citynet.com.eg (196.46.189.13) 60.774 ms 58.276 ms 56.321 ms
    29 host-196.46.189.14.citynet.com.eg (196.46.189.14) 56.277 ms 56.361 ms 58.983 ms
    30 host-196.46.189.13.citynet.com.eg (196.46.189.13) 56.491 ms 57.704 ms 57.796 ms

    Not sure what the hell is going on with hops 14-30.

    And here’s the new IP:

    traceroute to –.–.–.– (–.–.–.–), 30 hops max, 60 byte packets
    1 –.–.–.– (–.–.–.–) 0.048 ms 0.019 ms 0.016 ms
    2 ldn-1-6k.uk.eu (94.23.122.65) 3.856 ms * *
    3 gblx.as3549.uk.eu (213.251.130.54) 3.917 ms 3.912 ms 3.902 ms
    4 level3-2.ar2.LON3.gblx.net (208.50.13.194) 12.503 ms 12.494 ms 12.486 ms
    5 ae-33-51.ebr1.London1.Level3.net (4.69.139.65) 13.193 ms 13.185 ms 13.115 ms
    6 ae-47-47.ebr1.Paris1.Level3.net (4.69.143.110) 7.961 ms ae-48-48.ebr1.Paris1.Level3.net (4.69.143.114) 8.467 ms ae-45-45.ebr1.Paris1.Level3.net (4.69.143.102) 8.292 ms
    7 ae-1-51.edge1.Paris1.Level3.net (4.69.139.199) 8.066 ms 8.232 ms 8.214 ms
    8 LINKDOTNET.edge1.Paris1.Level3.net (212.73.206.18) 48.978 ms 48.967 ms 49.144 ms
    9 * * *
    10 * * *
    11 * * *
    12 host-196.46.189.254.citynet.com.eg (196.46.189.254) 58.983 ms 59.272 ms 56.709 ms
    13 host-196.46.189.86.citynet.com.eg (196.46.189.86) 71.913 ms 71.689 ms 70.531 ms
    14 –.–.–.– (–.–.–.–) 69.838 ms 70.799 ms 70.501 ms

    Incorrect whois info can cause real problems for spamlists etc, and it doesn’t look good if a customer/client whoises your website and it looks like it’s hosted on a home ADSL line. :/

    I’m getting 25mbit inbound and the same outbound, so it’s not on ADSL, but I’ll open a ticket and try to get them to sort the whois info.

    Performance problems are sorted though. :)

    September 8, 2010 @ 11:33 am | Reply
  24. Gary:

    Another update: Whois problem solved quickly. 10/10 for customer service. :)

    September 8, 2010 @ 12:09 pm | Reply
  25. @Gray
    Whois solved

    inetnum: 41.223.52.0 – 41.223.52.255
    netname: CITYNET
    descr: CityNet Host Dedicated Servers
    country: EG
    admin-c: MT1-AFRINIC
    tech-c: MT1-AFRINIC
    status: ASSIGNED PA
    notify: mtalaat@citynettelecom.net
    mnt-by: CITYNET-MNT
    changed: hostmaster@afrinic.net 20060831
    source: AFRINIC
    parent: 41.223.52.0 – 41.223.55.255

    September 8, 2010 @ 12:11 pm | Reply
  26. Whats

    13 host-196.46.189.14.citynet.com.eg (196.46.189.14) 54.506 ms 54.947 ms 54.936 ms
    14 host-196.46.189.13.citynet.com.eg (196.46.189.13) 62.048 ms 58.818 ms 61.783 ms
    15 host-196.46.189.14.citynet.com.eg (196.46.189.14) 54.631 ms 56.092 ms 55.469 ms
    16 host-196.46.189.13.citynet.com.eg (196.46.189.13) 58.251 ms 56.321 ms 55.793 ms
    17 host-196.46.189.14.citynet.com.eg (196.46.189.14) 55.755 ms 55.106 ms 54.439 ms
    18 host-196.46.189.13.citynet.com.eg (196.46.189.13) 55.030 ms 56.779 ms 61.411 ms
    19 host-196.46.189.14.citynet.com.eg (196.46.189.14) 55.063 ms 55.683 ms 58.092 ms
    20 host-196.46.189.13.citynet.com.eg (196.46.189.13) 56.992 ms 55.917 ms 56.068 ms
    21 host-196.46.189.14.citynet.com.eg (196.46.189.14) 57.533 ms 55.510 ms 55.716 ms
    22 host-196.46.189.13.citynet.com.eg (196.46.189.13) 58.377 ms 58.188 ms 58.898 ms
    23 host-196.46.189.14.citynet.com.eg (196.46.189.14) 57.004 ms 55.814 ms 55.593 ms
    24 host-196.46.189.13.citynet.com.eg (196.46.189.13) 55.704 ms 56.932 ms 56.629 ms
    25 host-196.46.189.14.citynet.com.eg (196.46.189.14) 56.105 ms 56.182 ms 56.863 ms
    26 host-196.46.189.13.citynet.com.eg (196.46.189.13) 59.534 ms 59.963 ms 57.583 ms
    27 host-196.46.189.14.citynet.com.eg (196.46.189.14) 57.186 ms 56.834 ms 55.846 ms
    28 host-196.46.189.13.citynet.com.eg (196.46.189.13) 60.774 ms 58.276 ms 56.321 ms
    29 host-196.46.189.14.citynet.com.eg (196.46.189.14) 56.277 ms 56.361 ms 58.983 ms
    30 host-196.46.189.13.citynet.com.eg (196.46.189.13) 56.491 ms 57.704 ms 57.796 ms
    

    all that about never seen this before.

    September 9, 2010 @ 5:50 pm | Reply
  27. Dirk:

    On another forum I saw something similar (with other IPs ofcourse) and the ISP then said this was due to the use of MPLS, not sure at all if this is correct or not.

    September 9, 2010 @ 6:18 pm | Reply
  28. Any VPS owner can cause traceroute loop by running a routing application on his machine to redirect ip traffic to the gateway, the gateway configured to route traffic to the VPS ip addreses, then the routing application will redirect traffic back to the gateway causing the loop.
    some times missconfigured openVPN cause these loops.

    Thanks Guys

    September 10, 2010 @ 11:29 am | Reply
  29. We accept PayPal now

    September 14, 2010 @ 11:12 am | Reply
  30. rm:

    @Mtalaat

    If you look closely at the cat /proc/cpuinfo output provided by Gary, you’ll notice:

    > model name : Intel(R) Xeon(TM) CPU 2.80GHz
    > stepping : 1
    > cpu MHz : 700.031

    This is very weird, it should say 2800 MHz there.
    And that reminds me of a glitch I personally seen on one Xeon-based physical server.
    Regardless of CPU load, it was locking itself down to the lowest-frequency power saving mode, and was operating slowly all the time. Maybe you run into the same bug and this is what causing slowness for some clients.

    September 16, 2010 @ 4:05 am | Reply
  31. @rm

    not the case. Some Control panels can limit the Mhz i know i can set it from 200Mhz to whatever the processor power.

    September 16, 2010 @ 6:20 am | Reply
  32. > Some Control panels can limit the Mhz
    On Xen – sure, but this is OpenVZ here.

    September 16, 2010 @ 6:26 am | Reply
  33. OpenVZ can do it aswell….

    September 16, 2010 @ 6:55 am | Reply
  34. Sorry if I am wrong but afaik in OpenVZ CPU limits work differently, i.e. they do not change MHz, and /proc/cpuinfo always shows real CPU data. At least this is how it is on my two OpenVZ VPSes from different providers.

    September 16, 2010 @ 7:06 am | Reply
  35. Check this out

    IP:109.169.24.47
    x0eVCwrgrS

    You will see what i meen.

    September 16, 2010 @ 7:15 am | Reply
  36. > IP:109.169.24.47
    Should I try connecting by ssh or http? It does not work on either. And does not even respond to ping.

    September 16, 2010 @ 7:54 am | Reply
  37. @rm

    VPS is a shared server, we can not assign every VPS 100% of total processor power.
    We assign every customer 25% of the Processor power to protect the node in case of a VPS high cpu load.

    September 16, 2010 @ 8:49 am | Reply
  38. With OpenVZ each virtual environment (VE) can have “cpuunits” and “cpulimit.

    AFAIK if “cpulimit” has been set on a VE, the CPU MHz figure under /proc/cpuinfo will be adjusted accordingly, although the CPU model is still showing the actual CPU on the host machine.

    September 16, 2010 @ 9:44 am | Reply
  39. @LEA thanks for the info.
    From what I read on that page, IMHO there should be no need to use cpulimits, because just setting cpuunits of each VPS to equal value would ensure no single VPS can unfairly consume CPU time at the expense of other VPSes.

    September 16, 2010 @ 9:52 am | Reply
  40. @rm — well not really. It allows the VE to burst to full CPU, but it does not give VE more “deterministic” performance characteristics.

    I guess for VPS there’s a choice that the provider has to make.

    – Use CPU throttling like cpulimit, so VE has slow non-burstable CPU, but more consistent.
    – Do not use CPU throttling, allow full burst to all cores, but someone is going to abuse it and you also get inconsistent performance.

    September 16, 2010 @ 10:05 am | Reply
  41. Mike:

    CPU throttling is probably the better approach in real-world use, to be honest. Especially at the low end of the VPS spectrum. My only suggestion is that two 300MHz “cores” might be better for most people than one 700MHz slice. (A lot of the older, more established OpenVZ hosts do something similar; I have one VPS in Germany with eight 100MHz CPU slices, for example, and it generally out-performs a lot of VMs with a single 2.4GHz or 2.8GHz core.)

    If nothing else, it’s encouraging to see a host who has set rational values for things like cpulimit, because it suggests they’ve actually RTFM, rather than just relying on some (completely ridiculous) UBC defaults like most other people foolishly do. (1M numproc comes immediately to mind…)

    September 16, 2010 @ 12:25 pm | Reply
  42. @Mike
    Not every job is parallelizable. Also it highly depends on your type of load.
    If you sustain a lot of http hits per second, then sure that can be farmed out to many cores.
    But if your website is visited, say, once per 20-30 seconds, but each visit incurs heavy PHP scripts or DB access, then having one faster core will benefit more.
    It’s exactly the same dilemma as currently with desktop CPUs. What to buy, higher-freq dualcore, or a lower-freq quad. :)

    September 16, 2010 @ 2:18 pm | Reply
  43. Core2 vs Core4 – do take a look at this (http://www.codinghorror.com/blog/2007/09/choosing-dual-or-quad-core.html). There are some codes that are specifically written to take advantage of multiple cores, however in virtual environment I believe it’s all about time slicing (not core slicing and not MHz slicing).

    Well, everyone can argue till the cows come home, ultimately I guess you’d have to test run your case in the environment and see how it performs.

    September 16, 2010 @ 3:23 pm | Reply
  44. Gary:

    Not sure a 3 year old article is the ideal way to make a point. Back then Quads were top-end only. These days they’re pretty much de facto, or even more than 4 cores, so a lot more progs are written with multi threading in mind, where possible. A lot of games require Quad at a minimum now.

    September 16, 2010 @ 4:22 pm | Reply
  45. Mike:

    @rm: It’s not so much whether a job is parallelizable, IMO, but more a question of whether one process can easily and by default gobble up 100% of the (CPU) resources allocated to you. Nice and renice are all fine and dandy, but having multiple cores is a much more foolproof way of trying to ensure certain minimum standards of performance.

    “…if your website is visited, say, once per 20-30 seconds, but each visit incurs heavy PHP scripts or DB access, then having one faster core will benefit more.” On an OpenVZ VPS, disk i/o is almost certainly going to be your bottleneck there, not the CPU. (And you’d see more benefit from more dedicated RAM to cache to than from having theoretical access to more MHz.)

    September 16, 2010 @ 6:23 pm | Reply
  46. Scrambleground:

    Avoid these scam artists, placed my order, they would never respond to your tickets, will close it without even care to respond, will set the order for pending forever and at the end mark it as fraud and never refund you, i dispute it on paypal, its a crappy service without even deliver, glad i didnt it buy it yearly.

    October 15, 2015 @ 12:36 am | Reply

Leave a Reply

Some notes on commenting on LowEndBox:

  • Do not use LowEndBox for support issues. Go to your hosting provider and issue a ticket there. Coming here saying "my VPS is down, what do I do?!" will only have your comments removed.
  • Akismet is used for spam detection. Some comments may be held temporarily for manual approval.
  • Use <pre>...</pre> to quote the output from your terminal/console, or consider using a pastebin service.

Your email address will not be published. Required fields are marked *