Week 3

Lab 2 (continu'd)

Good evening everyone,

                This blog is mostly a continuation of the second lab. This time i will be displaying my result and the specs of the machine I was attempting to baseline php from. So this blog is separated into the specs analysis part and the result of the base lining.

Machine Specifications               

                The machine I was working on was the red machine, aka the machine with the ARM processor. After installing hp I ran the following commands to outline its specs. The information I gotten from it is displayed below.

                First I ran lshw which listed all the hardware on the machine. The output was enormous with 7 CPU and 4 network card. but only one of the CPU was not disabled, the rest of the output that was up is as follow:

 description: Computer

    product: APM X-Gene Mustang board

    width: 64 bits

  *-core

       description: Motherboard

       physical id: 0

       capabilities: apm_mustang apm_xgene-storm

     *-cpu:0

          description: CPU

          product: cpu

          physical id: 0

          bus info: cpu@0

  *-network:1

       description: Ethernet interface

       physical id: 2

       logical name: eth0

       serial: 00:01:73:02:07:eb

       size: 1Gbit/s

       capacity: 1Gbit/s

       capabilities: ethernet physical tp aui bnc mii fibre 10bt-fd 100bt-fd 1000bt-fd autonegotiation

       configuration: autonegotiation=on broadcast=yes driver=xgene_enet driverversion=v1.0 duplex=full firmware=N/A ip=172.16.172.215 link=yes multicast=yes port=MII speed=1Gbit/s

  *-network:2

       description: Ethernet interface

       physical id: 3

       logical name: eth1

       serial: 7a:10:a1:99:e0:5e

       size: 1Gbit/s

       capacity: 1Gbit/s

       capabilities: ethernet physical mii 1000bt-fd autonegotiation

       configuration: autonegotiation=on broadcast=yes driver=xgene_enet driverversion=v1.0 duplex=full firmware=N/A link=no multicast=yes port=MII speed=1Gbit/s

  *-network:3

       description: Ethernet interface

       physical id: 4

       logical name: bond0

       serial: 52:0b:1f:d6:c5:4d

       capabilities: ethernet physical

       configuration: autonegotiation=off broadcast=yes driver=bonding driverversion=3.7.1 firmware=2 link=no master=yes multicast=yes

  *-network:4

       description: Ethernet interface

       physical id: 5

       logical name: eth2

       serial: 1a:be:06:73:ff:ee

       size: 10Gbit/s

       capabilities: ethernet physical fibre

       configuration: autonegotiation=off broadcast=yes driver=xgene_enet driverversion=v1.0 duplex=full firmware=N/A link=no multicast=yes port=fibre speed=10Gbit/s

Then I ran the command free to figure of the memory usage, the output was a follow:

                           total             used              free        shared    buff/cache     available

Mem:       16713728     1176192     2205248       37440       13332288    15276096

Swap:             0           0           0

Finally for my final specs check I went to see the file describing the CPU info and the operating release version, the output was as followed respectively:

                The CPU information list had 7 identical entry of the following with the processor number been the only distinguishing number.

processor       : 0

Features        : fp asimd evtstrm

CPU implementer : 0x50

CPU architecture: 8

CPU variant     : 0x0

CPU part        : 0x000

CPU revision    : 0

Then the release version the machine is running on:

NAME=Fedora

VERSION="21 (Twenty One)"

ID=fedora

VERSION_ID=21

PRETTY_NAME="Fedora 21 (Twenty One)"

ANSI_COLOR="0;34"

CPE_NAME="cpe:/o:fedoraproject:fedora:21"

HOME_URL="https://fedoraproject.org/"

BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Fedora"

REDHAT_BUGZILLA_PRODUCT_VERSION=21

REDHAT_SUPPORT_PRODUCT="Fedora"

REDHAT_SUPPORT_PRODUCT_VERSION=21

Fedora release 21 (Twenty One)

Fedora release 21 (Twenty One)

cpe:/o:fedoraproject:fedora:21

Baselining Results

For the baselining, I decided to test the amount of time php takes to echo a certain word a thousand times. I used the following command which I mentioned about in my previous blog:

time php -r 'for($i = 0; $i < 1000; $i++){echo "hello";}'

                This tested how long it took for the machine to run the echo "hello" 1000 times. The result I gotten were pretty close to each other with only a small degree of difference between runs. The results that kept on reappearing after 30 tries were the following times:

real 0.035s

user 0.030s

sys  0.000s

real 0.036s

user 0.010s

sys  0.020

real 0.035s

user 0.020s

sys  0.010s

                These times show that the php can reliably echo "hello" a thousand time under 0.036 second in real time. And the use-mode and kernel time always add up to 0.030s, mostly only sharing the time between the kernel and user-mode if there is simultaneous runs of the php code.

                This is the result I have gotten from my understanding of how to do baselining. Hopefully this is enough, if there anything wrong with it, or if you feel I need to add more to complete this report please feel free to comment below. Next time I will be finish blogging about my profiling lab which I am currently working on.

Week 1 & 2

Good Evening everyone,

                It has been an hectic first week so my the blog for the first lab has been delay all the way to today. So this blog will contain both Lab 1 material about submissions to open source communities, as well as Lab 2 about my benchmarking Lab.

Lab 1 - Open Source Community Submission

                For this Submission I have to chosen to look at Mozilla Firefox Bug Fixing Submission method and the proper way to submit patches to the Linux kernel. This Lab submission is separate into those two part respectively.

Mozilla Firefox

                To submit a bug fix  to Firefox anybody can just needs to follow the instruction listed on their website at : http://codefirefox.com/. For the purpose of this write up however I will summarize the content so it can be contrasted to submission to the Linux Kernel.

                To submit a bug fix to Firefox, one can access their  database of bug needed to be fixed simply by signing up on the website with a free Bugzilla. A default account will allow access to all the bugs Firefox is currently having as well as the ability to post comments on the forums. It does not give access to the source code for working on the bug.

                In order to be able to access those configuration file, one can just post on the forum in the specific  bug page the interest in working on the bug. Then someone who has permission to access those file will assign you as the current assignee to the bug therefore allowing you access to the configuration. According to the website this process would not take more than 24 hours. Once you have finish working on the bug you just upload your code to the forum where it will be process by the main staff and other contributors before been implemented into Firefox.

                Now if you are a regular on Firefox, you can take it to the next step to be able to edit permissions and email: bmo-perms@mozilla.org. In the email that you would send to them it should contain two bugs you have already worked on and fixes, or three bugs you wish to be working on but could not because of the lack of permissions. Once those permission are unlock, you should be able to assign yourself and other as assignee for bug fixes.

Linux Kernel

                To submit patches for the Linux kernel, just like for Firefox, one can just follow all the instruction listed on their website at: https://www.kernel.org/doc/Documentation/SubmittingPatches. I will be however summarizing the process underneath for purpose of completing this lab submission.

                After creating your patch in linux,(using the proper command) load it into a tar file using the proper commands. Then you must write up a report with the list of changes you have made. Be specific about it and make sure to include all details such as will only work with certain driver, or previous patches, etc. Then make sure to style check the changes, make sure the email or description is plain text. Then send an email to one of the maintainers, you should receive back and email. If not feel free to send the patch to the Linux kernel developer's at : linux-kernel@vger.kernel.org. Then once the community has your patches in hand it will get review by other developers. In any case of patches the final decision on including your patch will be made by Linus Torvalds.

Lab 2 - Baseline Builds and Benchmarking

                For lab 2, our pod did not manage to properly finish the entire lab in time. We did manage to start  doing a baseline for PHP compiling time on the x86 architecture machine.  What we did manage to do was download PHP, install all the library necessary to compile PHP and then load up a test code for it on the x86 machine. We did not manage to get enough data to have a proper baseline, not did we have the time to benchmark it to the ARM machine.

                The commands we have used are all listed below, and are the result of our pod collaboration:

# wget -O php-5.6.6.tar.bz2 http://ca1.php.net/get/php-5.6.5.tar.bz2/from/this/mirror

#./configure \

--prefix=/usr/local/php \

--enable-mbstring \

--with-curl \

--with-openssl \

--with-xmlrpc \

--enable-soap \

--enable-zip \

--with-gd \

--with-jpeg-dir \

--with-png-dir \

--with-mysql \

--with-pgsql \

--enable-embedded-mysqli \

--enable-intl \

#make

#make install

Then the code we ran to attempt to baseline the compiling time was the following:

#time php -r 'for($i = 0; $i < 1000; $i++){echo "hello";}'

In which we tried to time the amount of time it takes for php to run the command a 1000 times.

                Hopefully this can be a good point where  our pod can continue working from in the future to do baseline builds and benchmarking.

                If there is anything you feel can be improved, please feel free to comment and I will try my best to fix it next time I blog. Hopefully this will be different by the end of this course, I look forward to your responses.

First Time Blog

Good day,

This is my first blog, hopefully everything this semester goes well. I will start the assignment posting on Sunday .