EDS - Enhanced Dedicated Servers
A large part of our service has traditionally revolved around Dedicated Servers — parallelised instances of our applications running on multi-threaded platforms for a single license holder (in contrast our shared servers offer single-thread performance in a multi-tenant way to multiple license holders, a model that is suitable for only the least demanding use-cases). Our original dedicated server model developed at the beginning of our business, and it was entirely physical, running on Dell 1950 hardware offering a choice of four or eight cores (hardware threads). After we moved our production platform to a virtualised and replicated environment for improved resilience, we retained our four/eight thread offerings. After all, our next generation hypervisors (the physical machines that run the virtualised servers) typically had 32 threads, so even a handful of dedicated services didn't leave much CPU power to spare.
Things moved on after the launch of our Enterprise service in April 2020. Each Enterprise node offered 256 hardware threads, with each thread around twice as fast as those in our older hypervisors. Clearly this massively improved on what went before, but the hardware was very new and technical issues prevented us using those nodes to run multiple virtual servers. So our largest clients and projects could take advantage of an entire dedicated node, but our other services remained unchanged.
Having finally resolved the technical challenges around virtualisation on our new hardware, our imminent 2.8.4 release will launch support for EDS services — Enhanced Dedicated Servers offering 16, 32 and 64 threads. Not only is this a large increase in threading capacity, but each thread is faster than those available in previous hardware. In addition EDS hardware offers an accelerated maths library that permits a boost of up to 25% for certain operations. In Table 1 we measure a single thread run of 1000 in-force simulations for a dataset on our standard Dedicated Server (DS) hardware, and then compare with the same run on one of our new EDS servers with and without accelerated maths:
|Platform||Threads applied||Time taken
|EDS 2.8.4 (accelerated)||1||201||3.47x|
Bear in mind the above is only an example run against a modest demonstration dataset to show the reduction in runtime. But single-thread performance isn't really what this is all about. Where this really starts to help is with new more demanding model types, such as those using Hermite splines to model with mortality convergence. In a 4-thread Dedicated Server, the "Most" resource option applied 3-threads to a model. This is because "Most" resource always leaves something free for other work — the more powerful the server, the more threads will be applied, but also the more there will be left to satisfy concurrent tasks. For example, on a 4-thread server a single thread remains for other work, while on a 64 thread server, 23 threads remain while a "Most" resource operation runs. Table 2 shows a Hermite spline model for seasonal analysis run using "Most" resource on 4-thread Dedicated Server, on 16-, 32- and 64-thread Enhanced Dedicated Servers, plus full Enterprise. The EDS and Enterprise runs use accelerated maths, which is unavailable on standard Dedicated Servers.
|Platform||Threads applied||Time taken
Again, these runs are small for ease of benchmarking — typical models of this type can easily run for days on a large dataset, so these performance multiples make a huge difference to completing analysis within your deadlines. Note that we have only looked at Longevitas here. EDS and Enterprise can also be applied to the Projections Toolkit, and specifically to demanding value-at-risk VaR calculations. We'll take a look at that in a future post. Finally, details of the EDS and Enterprise services are available in our benchmarking documents — if you want to see those, just drop us a line.
Epidemics and pandemics are, by definition, fast-moving and difficult to track. These are the diseases that we couldn't keep a lid on, outbreaks that breached our initial efforts at control. It follows then, that ongoing reporting of such diseases won't be entirely accurate, subject to various limitations imposed by testing and recording protocols. This reality is misused by some who believe that reported impacts are exaggerated and societal responses unjustified, but such a belief runs counter to the evidence.