Howdy, Stranger!

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


[REVIEW] Aggressive Networks 128MB/NAT Trial VPS
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] Aggressive Networks 128MB/NAT Trial VPS

afterSt0rmafterSt0rm Member
edited February 2015 in Reviews

The Aggressive Netowrks ( @aggressivenetworks ) provider has invited some beta testers to review their new product. The specifications of the provided VPS are bellow:

RAM: 128MB
Swap: 128MB
HDD: 15 GB (Raid10)
Bandwidth: 200GB@ 1 Gbps
IPv4 network: NAT 19 Ports + 1 SSH
IPv6 network: /112 ipv6

The image used to build the container is outdated and doesn't include the last libc patch. We all know how to update our servers, I think, but should be a great idea to build new images with the latest updates:

root@trial:~# apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
The following packages will be upgraded:
  apt base-files debian-archive-keyring libapt-pkg4.12 libc-bin libc6 libssl1.0.0 locales multiarch-support tzdata
10 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 16.7 MB of archives.
After this operation, 778 kB of additional disk space will be used.
Do you want to continue [Y/n]?

The container, however, has very small set of running process out of box, cutting out services like xinetd and saslauthd from the startup:

root@trial:~# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.6   3140   840 ?        Ss   Feb01   0:00 init
root         2  0.0  0.0      0     0 ?        S    Feb01   0:00 [kthreadd/108]
root         3  0.0  0.0      0     0 ?        S    Feb01   0:00 [khelper/108]
root       112  0.0  0.2   2396   352 ?        S    Feb01   0:00 upstart-udev-bridge --daemon
root       120  0.0  0.4   2364   648 ?        Ss   Feb01   0:00 /sbin/udevd --daemon
root       167  0.0  0.3   2360   404 ?        S    Feb01   0:00 /sbin/udevd --daemon
root       168  0.0  0.3   2360   404 ?        S    Feb01   0:00 /sbin/udevd --daemon
root       336  0.0  0.1   2388   244 ?        S    Feb01   0:00 upstart-socket-bridge --daemon
root      1546  0.0  0.7  33852   980 ?        Sl   Feb01   0:00 /usr/sbin/rsyslogd -c5
root      1626  0.0  0.4   6340   584 ?        Ss   Feb01   0:00 /usr/sbin/sshd
root      1647  0.0  0.4   1976   616 tty1     Ss+  Feb01   0:00 /sbin/getty 38400 console
root      1649  0.0  0.4   1976   616 tty2     Ss+  Feb01   0:00 /sbin/getty 38400 tty2
root      2086  0.0  1.6   9280  2100 ?        Ss   06:28   0:00 sshd: root@pts/0 
root      2088  0.0  0.9   3044  1276 pts/0    Ss   06:28   0:00 -bash
root      3041  0.0  0.7   2692   976 pts/0    R+   06:39   0:00 ps aux

Memory and swap is just what should be:

root@trial:~# free -m
             total       used       free     shared    buffers     cached
Mem:           128          7        120          0          0          5
-/+ buffers/cache:          1        126
Swap:          128          4        123

You have 4 cores to use and this is very interesting. I don't know if we will keep with the 4 cores after trial but this is a good point to choose this server over the competitors:

root@trial:~# nproc
4

Each core comes from a Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz as you can see bellow:

root@trial:~# cat /proc/cpuinfo
processor   : 0
vendor_id   : Genu
cpu family  : 6
model       : 60
model name  : Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz
stepping    : 3
microcode   : 16
cpu MHz     : 3292.615
cache size  : 8192 KB
physical id : 0
siblings    : 8
core id     : 0
cpu cores   : 4
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
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 pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm
bogomips    : 6585.23
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

All the other 3 cores are the same as this one (obviouslly). The CPU has performed very well on some tests:

root@trial:~# wget dl.getipaddr.net/speedtest.sh 2>/dev/null -O- | bash
---------------CPU test--------------------
CPU: 4 x Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz
Time taken to generate PI to 5000 decimal places with a single thread: 0m21.527s

root@trial:~# openssl speed sha1
Doing sha1 for 3s on 16 size blocks: 8379526 sha1's in 2.99s
Doing sha1 for 3s on 64 size blocks: 6913999 sha1's in 3.00s
Doing sha1 for 3s on 256 size blocks: 4157273 sha1's in 3.00s
Doing sha1 for 3s on 1024 size blocks: 1652443 sha1's in 3.00s
Doing sha1 for 3s on 8192 size blocks: 262372 sha1's in 3.00s
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             44840.27k   147498.65k   354753.96k   564033.88k   716450.47k

root@trial:~# openssl speed sha256
Doing sha256 for 3s on 16 size blocks: 7529214 sha256's in 2.99s
Doing sha256 for 3s on 64 size blocks: 4584302 sha256's in 3.00s
Doing sha256 for 3s on 256 size blocks: 1991055 sha256's in 3.00s
Doing sha256 for 3s on 1024 size blocks: 614873 sha256's in 3.00s
Doing sha256 for 3s on 8192 size blocks: 82313 sha256's in 3.00s
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           40290.11k    97798.44k   169903.36k   209876.65k   224769.37k

Disk I/O is pretty good too:

root@trial:~# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 0.711218 s, 1.5 GB/s

Network speed is OK, but UP/DOWN for/from some locations is really slow:

root@trial:~# wget dl.getipaddr.net/speedtest.sh 2>/dev/null -O- | bash
-------------Speed test--------------------
Testing North America locations
Speedtest from Portland, Oregon, USA [ generously donated by http://bonevm.com ] on a shared 100 Mbps port
    Download Speed: 9.90 MB/sec
    Upload speed: 5.18 MB/sec
Speedtest from Seattle, Washington, USA on a shared 100 Mbps port
    Download Speed: 9.39 MB/sec
    Upload speed: 3.67 MB/sec
Speedtest from Los Angeles, CA, USA [ generously donated by http://maximumvps.net ] on a shared 1 Gbps port
    Download Speed: 19.74 MB/sec
    Upload speed: 11.41 MB/sec
Speedtest from Los Angeles, CA, USA [ generously donated by TeraFire, LLC ] on a shared 1 Gbps port
    Download Speed: 13.70 MB/sec
    Upload speed: 8.00 MB/sec
Speedtest from Denver, CO, USA on a shared 100 Mbps port
    Download Speed: 5.48 MB/sec
    Upload speed: 15.34 MB/sec
Speedtest from Kansas City, MO, USA [ generously donated by http://megavz.com ] on a shared 1 Gbps port
    Download Speed: 5.09 MB/sec
    Upload speed: 8.98 MB/sec
Speedtest from Dallas, TX, USA [ generously donated by http://cloudshards.com ] on a shared 1 Gbps port
    Download Speed: 38.85 MB/sec
    Upload speed: 18.30 MB/sec
Speedtest from Chicago, IL, USA [ generously donated by http://vortexservers.com ] on a shared 1 Gbps port
    Download Speed: 34.68 MB/sec
    Upload speed: 25.18 MB/sec
Speedtest from Beauharnois, Quebec, Canada [ generously donated by http://mycustomhosting.net ] on a shared 1000 Mbps port in / 500 Mbps port out
    Download Speed: 10.40 MB/sec
    Upload speed: 3.14 MB/sec
Speedtest from Beauharnois, Quebec, Canada [ generously donated by http://hostnun.net/ ] on a shared 500 Mbps port
    Download Speed: 11.38 MB/sec
    Upload speed: 2.55 MB/sec
Speedtest from Buffalo, NY, USA on a shared 1 Gpbs port (location may be slow):
    Download Speed: 6.49 MB/sec
    Upload speed: 2.16 MB/sec
Speedtest from Atlanta, GA, USA [ generously donated by http://hostus.us ] on a shared 1 Gbps port
    Download Speed: 65.67 MB/sec
    Upload speed: 25.13 MB/sec
Speedtest from Lenoir, NC, USA [ generously donated by http://megavz.com ] on a shared 1 Gbps port
    Download Speed: 19.68 MB/sec
    Upload speed: 27.75 MB/sec
Speedtest from Jacksonville, FL, USA [ generously donated by http://maximumvps.net ] on a shared 1 Gbps port
    Download Speed: 61.73 MB/sec
    Upload speed: 16.82 MB/sec

Testing EU locations
Speedtest from Tallinn, Estonia on a shared 1 Gbps port
    Download Speed: 4.49 MB/sec
    Upload speed: 7.04 MB/sec
Speedtest from Paris, France on a shared 1 Gbps port
    Download Speed: 6.09 MB/sec
    Upload speed: 3.66 MB/sec
Speedtest from Milan, Italy [ generously donated by http://www.prometeus.net ] on a shared 1 Gbps port
    Download Speed: 15.31 MB/sec
    Upload speed: 6.62 MB/sec
Speedtest from Dusseldorf, Germany [ generously donated by http://megavz.com ] on a shared 1 Gbps port
    Download Speed: 8.30 MB/sec
    Upload speed: 7.37 MB/sec
Speedtest from Falkenstein, Germany [ generously donated by http://megavz.com ] on a shared 1 Gbps port
    Download Speed: 0 MB/sec
    Upload speed: 0 MB/sec
Speedtest from Bucharest, Romania [ generously donated by http://www.prometeus.net ] on a semi-dedicated 1 Gbps port
    Download Speed: 9.08 MB/sec
    Upload speed: 2.09 MB/sec

Testing Asian locations
Speedtest from Tokyo, Japan on a shared 1 Gbps port
    Download Speed: 2.65 MB/sec
    Upload speed: 3.01 MB/sec

Testing Australian locations
Speedtest from Sydney, Australia on a shared 1 Gbps port
    Download Speed: 2.29 MB/sec
    Upload speed: 1.08 MB/sec

I've stressed the container using:

root@trial:~# stress --cpu 4 --io 1 --vm 1 --vm-bytes 128M --hdd 1 --timeout 180s --verbose

This was the result:

stress-test

Without hangs, drops, locks or anything. But I think that a load limit should be imposed over the containers to stop abusers from running the node out of resources.

I've managed to compile and run a full web stack on the containeir (web server, php, sqlite) using monkeyServer.sh and it is running the Linfo script (that show details of the host running the script) and can be viewed from http://trial.alexteles.com:10602/, a set of PHP benchmark scripts that can be accessed from http://trial.alexteles.com:10602/bench.php and the phpinfo() output from http://trial.alexteles.com:10602/phpinfo.php.

I will release the ServerBear benchmark link when it get ready.

Comments

  • And there we go with the ServerBear results.

  • Thanks for the review! I will be updating the templates today when i get a chance. I/O is really due to ploop. Everyone will get the same access to equal share of the cores on the machine. Also I will make sure there is some kind of limit on load for a extend period of time. But i really appreciate point everything out. My to do list is growing. That is a point of a beta test so you can get the bugs worked out before going live!

  • @aggressivenetworks said:
    Thanks for the review! I will be updating the templates today when i get a chance. I/O is really due to ploop. Everyone will get the same access to equal share of the cores on the machine. Also I will make sure there is some kind of limit on load for a extend period of time. But i really appreciate point everything out. My to do list is growing. That is a point of a beta test so you can get the bugs worked out before going live!

    Please, make a Fedora 21 server image avaiable!

  • edited February 2015

    No problem ill make one up tonight!

  • @ekattylinux Well its going to be a little while for that Fedora 21 server image. Trying to get the networking to run is being a pain. Look like CentOS 7 which is crazy how things have changed so much.

  • @aggressivenetworks, did you tested the beta template avaiable at http://openvz.org/Download/template/precreated?

  • yes i did network is not working either. I will definitely get it working. Just going to take a little longer than I originally suspected.

  • @aggressivenetworks any ETA for the Fedora 21 server?

  • Hopefully in a couple days.

  • @ekaatylinux Ok I made the beta template networking work. They really dicked up by going to the systemd controls. Selinux was a big part of problem.

    Selinux config was missing from template Selinux had to be disable for even the network script in init.d directory to work half ass I will write a shell script to add the correct ip's via the ip addr add command

  • @ekaatylinux Fedora 21 beta template is up and working for now with ipv4 as of right now. Still trying to figure out why i can't get ipv6 working. But the scripts are in the template. I will look try to get ipv6 working on saturday night . If you want to upgrade to Fedora 21 beta template you need to let me know it will not work with ploop based only simfs. So i would have to delete your old vps and recreate one based on simfs.

  • @aggressivenetworks should I create a ticket for this? As far as I remember you are the first of my providers to make Fedora 21 Server avaiable to install. This is very good because I will be capable to test Cockpit on a VPS to the first time '-'

    And, of course, will make a review on this :D

    P.S.: It's sad that this is OpenVZ, I will not be capable to test the container deployment capabilities on Cockpit :'(

  • @ekaatylinux just open a ticket so I can have a way of tracking it.

  • @aggressivenetworks I started a new job this week which I hate and has taken up a lot of my energy, but tonight I'm going to try out Fedora 21 and set up a few things.

  • @im_jmz I totally understand. Just open a ticket so if you want to try out the template due to prior vps being ploop based and the template only work with simfs for some reason.

  • 200gb ba

  • @linuxthefish said:
    200gb ba

    What?

  • @linuxthefish It is 200 GB @ 1 Gbps

  • @aggressivenetworks I've opened the ticket. Just waiting for the change :D

  • SpiritSpirit Member
    edited February 2015

    EkaatyLinux said: @aggressivenetworks any ETA for the Fedora 21 server?

    You didn't mention in your review that they don't have support ticket system and you're forced to communicate with them over this forum.

    Offering free yearly vps to each of the beta testers to one day later publicly "review" them at some forum simply isn't right way to go. And now imagine more hosts to use this advertisemet strategy here. No go...

    Just set to sink for now.

  • edited February 2015

    First I never asked for a review from any of kind from the beta testers. Yes I do have a ticket system in place. I compensated people for taking their time out to help me out. Yes @spirit is right about the communication should of happened via tickets. That is why told them to open tickets due to this.But this was never my intention for even to make it look like some kind of advertisement in anyway shape or form. I do apologize for this getting out of line.

  • Just want to clarify: he never asked me to review it publicly, and I could have emailed him or used a support ticket, I just used the forum cause I was already on here and I'm a lazy fuck.

  • @aggressivenetworks if it is your desire, I will not post my other reviews here on LET to stop this problem. I'm sorry for causing you problems and will keep helping you the way I can.

    @spirit I can provide the evidences of the fact that they do have a support ticket and if someone should be punished here it's me. I will adjust my behavior to prevent any other future misunderstoods.

    I'm sorry.

  • adipurnamaadipurnama Member
    edited June 2015
  • They do all verifications and setup manually.

Sign In or Register to comment.