Arduino Ethernet Shield under SIEGE

Today there are many single-board computers sufficient enough to create great projects for a low cost – an Arduino Electronic Pot for example. Although the Arduino Ethernet Shield is not meant to be a web server providing hosting services for many clients (more often to make automated requests), my curiosity about the capabilities was too strong…

The set-up

Preparing the tests was very simple, I already had the Arduino Leonardo main board and an Ethernet Shield attached to it. Hardware-wise – that’s it.

arduino ethernet shield

All tests were done by SIEGE benchmarking software (Joe Dog – creator; Man Pages). This application allowed me to make simultaneous GET requests to the root (/) of the web server. Additionally, for the created virtual clients, I could set the time between the requests.

For the Arduino I used the default example code of a web server. The only changes I made were configuration variables and the HTML section – instead of displaying the analog inputs, I created a sample website (using HTML-ipsum).

sample website


To get SIEGE:

sudo apt-get update
sudo apt-get install siege

If you want to know if you already have it:

siege --version

The structure of the command I used:

siege -v -c NUM -d TIME -r1 URL


  • NUM – number of server transactions (“virtual users”) – {5, 10, 15, 20, 25, 30, 35}
  • TIME – time delay between simulated users actions – {1, 2, 5}
  • URL – local IP address of the web server based on Arduino + Ethernet Shiled
  • -r1 – one repetition of transfer per virtual user


I run the test three times for every instance and calculated the average values. My main focus was the response time, I was curious where was the boundary after which the website was “unworkable”.

According to the Nielsen Norman Group, we can differentiate 3 main response time actions:

  • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

  • 1.0 second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

  • 10 seconds is about the limit for keeping the user’s attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

Based on the  above selections, none of my tests results would qualify to the first group. The lowest value was 0.78 of a second – for 5 virtual users with 5 seconds delayed actions.


For tested delay values, only the groups with 5 and 10 virtual users fit under the 10 seconds mark. It is also the only group, where the Availability of the web server was 100% for all tests:

Virtual Users 5 10 15 20 25 30 35
With 1 second delay 100% 100% 98% 82%
With 2 second delay 100% 100% 98% 82%
With 3 second delay 100% 100% 87% 88%
With 5 second delay 100% 100% 100% 100% 100% 93% 90%

The group with the 5 seconds delay achieved also 100% of web server availability for 25 virtual users. Making sure, that the delay between connections with our web server is enough to handle the responses could increase the possible availability of our server. Of course this is at the expense of cutting out users. In addition, this test was based on only request – in real life situations the user stays on the page and interacts with it, this scenario was not taken under consideration in this tests.



As assumed at the beginning, the Arduino + Ethernet Shield can’t be a robust and reliable web server for website hosting. Although it handled the requests for a small group of virtual users, the sample page was minimalistic and probably no one would host a website with this amount of content. The results were acceptable only for 5 virtual users, where the main average response time was about 1.5 seconds.

Electronic Pot [Arduino Nano + Ethernet Shield]

I always wanted a plant in my room, that would fill the space between unfinished projects. So I came up with the idea of an electronic pot – The Arduino Electronic Pot – that would measure the basic needs of the plant (humidity, temperature and the presence of light).

I also wanted to display the results in a neat way on a website, so I could see everywhere I was if the plant is doing OK.

arduino pot

I divided the whole process in three simple steps:

  1. Connecting the hardware
  2. Software for the Arduino (the .ino sketch)
  3. Software for the web-server (some .php files)

arduino pot

If you want to connect the Ethernet Shield with an Arduino Uno or Arduino Leonardo Board, you actually don’t need any wiring. The only thing you would have to connect with the set-up would be the sensors.


  • Arduino Nano Rev3 (Tested also on Leonardo and UNO)
  • Ethernet Shield
  • Photo-resistor
  • DHT11 Humidity Module
  • 1x 4,7kΩ
  • 1x 10kΩ
  • 1x Ceramic capacitor 100nF

You can of course use other sensors with other requirements, that’s why I don’t include any specific models or data sheets. Always make sure you use components recommended by the producers of the sensors.

I based the connection between the Nano and Ethernet Shield on this post Arduino Nano with Ethernet Shield by ntewinkel.

arduino pot


D13 on NANO – ~13 on Ethernet Shield [yellow]

D12 on NANO – ~12 on Ethernet Shield [blue]

D11 on NANO – ~11 on Ethernet Shield [red]

D10 on NANO – ~10 on Ethernet Shield [black]

D4 on NANO – ~4 on Ethernet Shield [green]

DATA on DHT11 – D2 on NANO [cyan]

GND on DHT11 – GND on NANO [brown]

VCC on DHT11 – 5V on NANO [purple]

1 on Photo-resistor – A0 on NANO [white]

2 on Photo-resistor – 5V on Ethernet Shield [gray]

As you can see on the graphic above, there are also additional pull-up resistors and a capacitor. Connect the 4,7kΩ resistor between the GND and DATA of the DHT11. The 100nF capacitor between the VCC and GND of the DHT11. The last part – a 10kΩ resistor – should be placed as a pull-up resistor for the photo-resistor from the data pin to GND (on Ethernet Shield in my case)

Software for the Arduino

The next step is to write the code for the Arduino. You can find my example code here:

I tried to comment everything where any problems could occur. If something isn’t clear or the code doesn’t work as it should, please contact me in any way.

At this point you should log into your database and create the needed table. This step depends on the type of your database, in my case (MySQL) I just went to the ‘SQL’ tab in the control panel and created the table with this query:

 CREATE TABLE `tempLog` (
`ahum1` INT(11) NOT NULL,
`temp1` INT(11) NOT NULL,
`light` INT(11) NOT NULL

Now the main part – the first two files are needed to handle the communication between:

  • Arduino Ethernet Shield – Web server (add.php)
  • Web server – Database (connect.php)

Example files also available on

After this steps, you should see data in your database in the table ‘tempLog’.

The next steps are related only with web development. We create the main file which always open when we have a visitor on our server (index.php) and a second file that contains the code responsible for the menu at the top – header.php. The third file is optional – I just wanted to show some photos of my project that’s why I included a gallery.php file.

These three files are included above on github also. You need to make couple of changes (substitute the domain names with your domains), but it shouldn’t cause any problems.

However if you get stuck at any point, just let me know and I will be happy to help you.

You can find these instructions also on instructable.

Good luck with your E-Pot 🙂

Assembly – Hello World

Trying to learn some basic assembly code, I often couldn’t find good content that shows in a fast way the main idea behind the code. This segment is created to hopefully fill the hole.

Keep in mind I don’t write code in assembly language professionally, these are only code snippets that worked for me & are written only for educational purposes. This example worked on a x86 architecture, was build using the default assembler (as) and linker (ld) that comes with Linux [GAS Syntax].

First of all, try run the code below and check the output:

    .ascii "Hello World\n" 
.global _start 
    mov $4, %eax 
    mov $1, %ebx 
    mov $message, %ecx 
    mov $12, %edx 
int $0x80
    mov $1, %eax 
    mov $0, %ebx 
int $0x80

file: hello.s

  1. Write the above code using a text editor and save it – in my example hello.s
  2. Start your terminal and go to the place where the file was created
  3. Assembly the code: user$ as hello.s -o hello.s
  4. Link the code: user$ ld hello.o -o hello
  5. Run the code & check the output: user$ ./hello

As a result, you should see the glorious output Hello World. Let’s now explain as simple as possible all the new things that we saw here.

About the code Structure

You will often see the structure:

.global .......

These lines of code (which start with a dot) describe mostly places of the current code. Every program that we execute is given some part of the memory. We divide this main section in more sub-sections, making it easier for our OS and the user itself, by placing code with similar purpose nearby. You can see our example in the image compared to the typical computer data memory arrangement:


Sections in code

There purpose is to define different contents of the program and so for our example: .data is the starting point of the section with data used later in the program. As you can see, it’s not so different from other languages. For example in C you would write something like:

int speed = 40;

[type] [name] = [value]; In assembly it looks only slightly different:

.ascii "Hello World\n"

.[type] [value]

Constants in as assembler

.text is the part where the “real” program starts. It’s the place where the executable executes. The last one is .global. It is a specific directive, which makes a label of a place global. It means, that this place in the program is available from the outside. You will almost always see this directive once written in a program. To give you a better feeling of this directive: Let’s say I will have a program written in C (a calculator for example) and want to use a sub-program written in assembly (just the addition of two values). I can do that, by linking the object files, but only if the function of adding – the label in assembly code – is flagged as global.


The fun part

We have now our code and a basic idea about the structure. We know that we already have our message in the .data section and we need somehow to output it for the user. In the code you can clearly see that the main part of the magic happens under the global label _start. The label _start is again only a pointer to a place in the code. In an image above, you could see that the _start code is divided – not only optically – into two sections. These sections are responsible for calling two system calls.

The first one is WRITE and the second one – EXIT. Of course you don’t see any of the names above in the code. System calls are called in a more specific way. We have to give (in assembly language) which of the system calls should be called and with what parameters. For example when we give the information that we will run the WRITE function, we need also give the information where we want to write, how much and what exactly. All these information are given in the highlighted code above.

We have mostly one command, that repeats often – mov. As you can expect it is an abbreviation for move – it takes one thing and places it in another. In our example, we assign numbers (remember everything is binary), and place them in our 32-bit registers. You can read more about registers and the assembly syntax here.

The function calls

The WRITE function call takes us 5 lines of code:

  • mov $4, %eax
    In this part we are indicating which system call we want to call. A number 4 in the 32-bit register eax does that. In example, if we would insert the number 3 in this register, the system would prepare to execute the READ function. Finally we will call another function at the end – the EXIT function, which takes the number 1 in the register eax. The whole list of system calls on a Linux kernel using 32-bit registers can be found here.
  • mov $1, %ebx
    The first parameter we give to this function is the target for the output. We want to see it in our console after execution. ($1 for terminal output)
  • mov $message, %ecx
    In this line we give already the exact point, where our message for output is placed in memory. The ecx register expects us to give an address to the point, the ‘$’ sign before ‘message’ does exactly that.
  • mov $12, %edx
    In this part we give the system the information, how many characters we want to display.
  • int $0x80
    What do we need else? After giving the needed information for the function WRITE, we need only to signal the system that the registers are ready to go.

The EXIT function is executed in a similar way, we give the $1 to the eax register (indicating EXIT) and zero-out the ebx register. In more difficult examples and software it is important to keep in mind what we leave in the registers. It is only a very simple explanation of the basics, and I can assure you that many things are oversimplified, but I hope it will help just for the start 😉