How fast is NoiseMap?
We haven’t tried to answer this question previously because it is dependent on so many variables that it is very diffcult to give a meaningful answer.
NoiseMap implements the UK standard methodology natively. These methods were designed for manual calculation and they are very computationally efficient. Every effort has been made to maintain this efficiency in the NoiseMap implementation.
The most important factors in computation speed are the number of noise sources and the number of buildings, ground contours and noise barriers within the calculation area.
For a very complex model which requires each tile to be calculated with a wide surround, then 1.5 seconds per calculation point per processor would be typical.
On the Manual Example, which is a fairly simple example with 12 calculation tiles (each 500 metres square), using a mesh spacing of 10 m (2500 points per tile), a standard 4-core processor takes about 5 seconds per tile, which is about 2 milliseconds per calculation.
On top of the calculation time, you need to add for downloading the tiles, pre-processing and saving. This adds maybe another 2 seconds. This time could be longer if you are operating over a slow network.
The cloud server
NoiseMap’s cloud server is a dedicated machine housed in a commercial datacentre in central London. It has world-class security systems, including access to the datacentre, power supply, backups, etc. It uses a gigabit connection to the internet backbone.
Network speed and latency
In terms of network speed, it is misleading to rely on the number of bits per second. There is also the question of ‘latency’. Networks are usually set to prioritise certain traffic, for example to discourage casual web-browsing and to give priority to video streaming (and sometimes to certain company departments). In such cases, unless NoiseMap’s ports are set to receive priority, there can be a high degree of latency whilst it waits to receive attention from the network. Although NoiseMap generates very little network traffic, it does need priority when communicating, because it waits a ‘handshake’ from the remote server after sending each packet of information. If it has to wait, say, 5 seconds after sending a packet that took 0.05 seconds, this reduces the transmission speed to one-hundredth of the nominal value. This can cause problems.
On an ordinary broadband connection, loading 200 tiles from the Cloud server of a small part of a scheme containing 2,600 road segments, 17,250 ground contours, and 69,000 building outlines took 45 seconds.
Downloading and displaying the noise contours for these 200 tiles (500,000 results) took 15 seconds. It must be remembered that this includes the time for the server to find and prepare, encrypt and decrypt the information, as well as for it to be transmitted over the network.
It may be noted that this scheme contains over 13,000 populated tiles, and over 68,000 noise contour tiles, so the server is very efficient at extracting and transmitting just the required information.