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.
Related Posts:
- 5 Reasons Why You Want a Low End Box - May 26, 2021
- Dead Pool January 2012 - February 2, 2012
- exit(0); - January 19, 2012
So this means the previous offer from CityNetHost has expired, which is still a great VPS deal for me.
Nope, the previous offer is still available to buy by the looks of it.
Yes I think the previous offer is still available, although Mohamed did say that it is expiring soon (end of August?)
Seems like it’s still available.. I wonder for how long…
Mohamed could you give us the info?
Yes the previous offer extended to 30/09/2010 :)
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 :)
You should write some information about location in WHOIS, because server location is Unknown, when i’m visiting my pages hosted on your VPS.
@ Nicolas.
Yes you can order more.
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.
They will soon gone to deep… pools as well ;)
@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
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.
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
@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?
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…
Ok, tickets are working now finally, I’ll submit one.
@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!
@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?
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…
@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.
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.
@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.
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. :)
Another update: Whois problem solved quickly. 10/10 for customer service. :)
@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
Whats
all that about never seen this before.
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.
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
We accept PayPal now
@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.
@rm
not the case. Some Control panels can limit the Mhz i know i can set it from 200Mhz to whatever the processor power.
> Some Control panels can limit the Mhz
On Xen – sure, but this is OpenVZ here.
OpenVZ can do it aswell….
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.
Check this out
IP:109.169.24.47
x0eVCwrgrS
You will see what i meen.
> 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.
@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.
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.
@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.
@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.
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…)
@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. :)
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.
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.
@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.)
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.