diff --git a/en/chap04.tex b/en/chap04.tex
index e0bcb50..6af867d 100644
--- a/en/chap04.tex
+++ b/en/chap04.tex
@@ -52,7 +52,8 @@ set the widths of edges according to their costs. Alternatively, by
 right-clicking any vertex, it is possible to highlight its shortest path DAG.
 If the user wants to find a specific route, showing the DAG also serves as
 selecting the start vertex. The context menus for vertices then allow finding
-the path to those vertices.
+the path to those vertices. Note that stub and external networks are sinks in
+the OSPF topology, so it is expected that the program draws an empty DAG for them.
 
 Finally, there is an option to reload the shown graph in the Topology menu. We
 decided that the graph should not change unexpectedly, because that could be
diff --git a/en/chap05.tex b/en/chap05.tex
index 9cfe538..57dfe88 100644
--- a/en/chap05.tex
+++ b/en/chap05.tex
@@ -1 +1,83 @@
 \chapter{Evaluation}\label{ch:evaluation}
+
+To show that Birdvisu is a usable project, we have tried to use it in several
+network systems, both synthetic and already deployed. Here we summarise our
+experience with using it.
+
+Because our project is mainly an interactive program, we do not present any
+performance or other measurements. Therefore, we rather focus on the subjective
+feeling of the project and evaluate the design decision from chapter~\ref{ch:design}.
+
+\section{Gennet}
+
+Naturally, Gennet, as described in section~\ref{s:gennet} is supported quite
+well. Since we had complete control of the whole network, we could test e.g.
+multi-area OSPF deployment, which is not common in real network systems, as far
+as we are aware.
+
+However, only small networks can be simulated in Gennet, because each router
+requires disk and memory, which may be quite scarce.
+
+\section{Our home network}
+
+At home, the author relies on a dynamic routing to switch between falling
+uplinks and to provide a simple way to address virtual machines across the
+network system. This was one of the reasons we decided to look for
+visualisations of OSPF topology state.
+
+Since it only spans a single room, this system is even smaller than Gennet,
+containing only three routers and less than 10 networks (the exact number
+depends on which devices are up at the time). We believe that major issues do
+not show up at this scale.
+
+Naturally, Gennet can be connected to the home network. At that point, our
+approach to laying out vertices starts feeling suboptimal, because edges cross
+unnecessarily often. The connections are clear, however, and this can be
+alleviated by using a fixed layout in a file. In the future, this could be
+addressed by using some force-based approach for the automatic layout.
+
+\section{Department of Applied Mathematics}
+
+The department which advised this thesis also uses OSPF in its infrastructure.
+Again, the main purpose is to address containers and virtual machines in the
+system. The topology consists of 5 routers and about 27 networks, most of which
+are stub.
+
+Again, the main issue is the automatic vertex layout. Also, since most of the
+networks are stub (and often only contain a single host), the graph could
+position these networks near each other, or even collapse them into one vertex.
+Birdvisu does not unfortunately support that at the moment.
+
+\section{Czela.net}
+
+Czela.net~\cite{czelanet} is a network system run by a community of network
+enthusiasts in Čelákovice and the surrounding area. This is the typical OSPF
+deployment, whose main task is to dynamically provide fallbacks in case of
+outages. It is also an example of a larger network, with 45 routers, 32 transit
+networks and 178 external routes\footnote{Most of these would be stub routes in
+other deployments, but there is little difference from the topology perspective.}.
+
+Unfortunately, their infrastructure does not use BIRD anywhere and we were not
+able to connect our instance to any of their transit networks. Therefore we
+only tested displaying the topology based on a dump from one of their MikroTik
+routers, which we manually converted to mimic BIRD's format. We believe this
+should not affect the performance much, because the retrieval of data from BIRD
+is only occasional and once BIRD dumps the topology, the procedure is the same
+as with loading the topology from file.
+
+This turned out to be helpful for both us and Czela.net. We discovered that our
+method of highlighting of costs does not work well with too big range of the
+costs, and on the other hand, we found several misconfigurations in their
+network, even without any other knowledge of their system.
+
+We did not notice any performance issues when dealing with the topology.
+
+\bigskip
+
+Unfortunately, we did not have the opportunity to test in a large network (the
+Czela.net's one is the largest we tested), so we do not really know the limits
+of capabilities. Those are even hard to guess, because while we are trying to
+use rather fast algorithms, they are implemented in Python, which can sometimes
+be quite slow, and more importantly, does not support threads well. The heavy
+use of hash tables and indirection can also impair performance.
+
diff --git a/en/epilog.tex b/en/epilog.tex
index 14393c5..0eae218 100644
--- a/en/epilog.tex
+++ b/en/epilog.tex
@@ -1,2 +1,10 @@
 \chapter*{Conclusion}
 \addcontentsline{toc}{chapter}{Conclusion}
+
+
+
+
+
+
+%Overall, we think that while not perfect, Birdvisu can still be a helpful tool
+%for network administrators.