Basic Performance

The performance of the network of Sites and Servers, or “infrastructure” is investigated first. This allows us to set the key network parameters of mean degree and shout radius for later experiments.

Degree Radius Shout Load Shout Load (ld 1.0) msgs/node (ld 1.0) msgs/node (ld 2.0)

2 2 7 12.4 (±2.98) 2.6 (±1.12) 5.7 (±2.33)

Table 5.2: The base network parameters investigated, and the measured message load on the sys-tem for load values of 1.0 and 2.0. The shout load is the mean number of Servers that process a broadcast/shouted message. Msgs/Node is the mean number of messages per server per second. Values in parentheses indicate the standard deviation for 100 runs.

Note that for a load value of 2.0 and higher network values, the mean number of mes-sages processed per node is near our set mean maximum of 20 mesmes-sages per second, indicating that the infrastructure system is near full capacity. Also note that our simple shout load reducing optimisation (see Section 4.4.1) does successfully reduce the shout cost on the system. The larger standard deviations for mean degree’s of two are due to the low network density at these levels, which means a Buyer must migrate more often, staying active in the system longer and increasing message load.

There is a trade-off between the network mean degree and shout radius, and the net-work performance overall. The more connections a site has, the more information it will have available, and the more traders on that node will be able to trade successfully.

However, the more connections a node has the more time it spends processing messages, which leads to increasing message delays, which can affect the performance of the allo-cation system.

Additionally, with the concept of a broadcast message with a shout radius, additional message processing load is added to the system polynomially. For example, a network with a mean degree of 4 and a shout radius of 3 can actually cause a theoretical maximum

Figure 5.1: The mean server utilisation for the system against load and by mean degree and shout radius. The overall utilisation clearly tends towards 1 as the load increases for higher degree/shout radius values.

of 4⁰+ 4¹+ 4²+ 4³ = 85 Sites to process that message (given a trader will send any broadcast message to its own node as well as its neighbours). The actual message load was less in most cases, because of the duplication avoidance mechanism described in Section 4.4.1

A further impact on the message load of the infrastructure are market supply and demand conditions. Market A prices will mean more chance of not finding a successful trading partner, which could mean more migrations and thus more load on the system, whereas market D prices would provide a much greater chance of finding a suitable trade.

As our goal in this instance is to investigate the infrastructure load, we use market A for these experiments.

We investigate our grid system under a variety of different load values, from 0.25 to 2.0. The key parameters that affect the grid’s infrastructure performance are mean degree, shout radius and the Server’s mean Server service time. We want to set these at levels that allow the grid infrastructure to cope with the messaging level for high load situations.

We set the mean service time as in table 4.1. This value allows for a mean throughput of 20 requests per second. This is very modest compared to many systems, but we wish to allow for a wide variety of Sites to be represented, and thus keep the mean performance relatively low.

We vary the mean degree and shout radius as shown in table 5.2. Given the desire to investigate the effects of topology, we do not experiment with a shout radius of 1 (i.e a single hop), as this effectively negates the effects of any network topology characteristics on the results. Shout radius values higher than two quickly overload the network, so we experiment with shout radius values of 1 and 2. A sample network size of 100 was used to provide statistically viable results without overly impacting execution times. Table 5.2 also shows some results for the actual message load on a system under load values of 1.0 and 2.0.

Figure 5.1 shows the basic grid performance for the mean degree/shout radius values specified above. More values were tested but a selected subset have been shown to im-prove the clarity of the graphs. The other values tested followed in the same patterns as the ones shown, that is, lower values were virtually identical to the lower values shown, and higher ones continued to degrade the system performance further. For now, we do not discuss the actual allocation performance, as we are looking at the infrastructure. See Section 5.2.3 for a discussion on the allocation.

The main factor emerging here is that our simulated Servers can get overloaded easily for high mean degree, shout radius and load values. Particularly, the large increase in wait time as the Servers get too busy to handle messages, which adversely affects the resource

utilisation. This is especially the case for higher load values.

While higher values do offer marginal improvements in resource utilisation for load values around 1.0, the severe degradation at higher load values is not worth the gain.

Based on these results, a standard mean degree of 4 and shout radius value of 2 seem the most appropriate to use for further exploration. These values essentially give the grid infrastructure the capacity to investigate what we are interested in (the resource allocation problem) rather than the performance of the infrastructure itself, which is not the aim of this work.

At a higher level, by setting relatively low mean degree/shout radius values, we con-tinue to direct our work in its pursuit of investigating how simple systems, with limited agent knowledge, can solve the resource allocation problem.

It should also be noted here that there are a variety of changes that could be made to the model to allow for higher mean degree/shout radius values. For one, currently there is only one Server processing all the messages for a Site, which is an implementation abstraction. In reality, every trader will probably be running on its own computing re-sources to some degree or other. However, the central server will still be the “gateway” to the traders at that node, and will have to route and store all broadcast messages, if not the point-to-point accept/reject messages. Additionally, the facility to dynamically adapt the number of connections or change the shout radius value depending on market conditions (i.e. current load) would be important for a real system. This is discussed further in Sec-tion 7.3.2, but is not investigated, as the study of dynamic networks is both complex and not the stated focus of this work.