PC specification for Mascot Server

Introduction

Any recent, high specification PC containing either Intel or AMD Ryzen processor(s) should make a suitable platform for Mascot. Systems with more than two processor sockets usually carry a substantial price premium. If you plan to do high throughput work, and need to run Mascot on more than two processors, a cluster of single or dual processor boxes will usually offer the most cost effective solution.

If you don’t have time to read the whole of this document, then choose a system with one or two fast processor(s), at least 16GB of RAM (preferably 64GB), a 64-bit operating system, and the largest SATA hard disks available (at least 1TB). For a 2 CPU Mascot license, you will need a computer with at least 8 cores, preferably more. It is beneficial to put the operating system and Mascot program files on a solid state disk (SSD).

Our blog article How long should a search take? describes some issues relating to choosing how large a licence you need.

Hardware virtualisation is discussed in Running Mascot in a virtual machine.

Mascot Distiller hardware requirements are described in Choosing hardware for Mascot Distiller.

Processor (CPU)

The two main PC processor manufacturers are Intel and AMD. Matrix Science does not currently support Mascot on other PC processors such as Itanium.

We have observed excellent scalability under Microsoft Windows and Linux for systems with modest numbers of cores per processor. That is, throughput from a system with an 8 core processor can be very close to double that obtained from a processor with 4 cores and the same architecture and clock speed. However, power management for processors with large numbers of cores means that the clock frequency is progressively reduced as the workload increases, which causes scaling to become non-linear.

Processor Speed

The main factors affecting Mascot performance are processor clock speed and number of cores.

It is not possible to compare processor speeds directly for different architectures. However, for any given processor model, the search speed will be proportional to processor speed unless:

  • Disk access becomes a bottleneck, possibly because the FASTA sequence database has to be read into memory from disk (see section on RAM below) or
  • The processor cache is too small and causes a bottleneck between processor and memory.

The PassMark CPU benchmark is a pretty good guide as to the performance you can expect for Mascot Searches. The important benchmark for processor speed is single thread performance, because the cost of a Mascot Server licence depends on the number of cores used for searches.

Multiple Cores

Mascot supports up to 4 cores per licence. For example, to use all cores on a system with:

  • 1 x quad core processor requires a single processor Mascot licence
  • 1 x eight core processor requires a dual processor Mascot licence
  • 2 x dual core processors requires a single processor Mascot licence
  • 2 x 6-core processors requires a 3 processor Mascot licence

However, it is always wise to have at least one spare core for running reports, or downloading and preparing databases.

Versions of Mascot prior to Mascot 2.3 were licensed on a “per socket” basis. A system with 2 x dual core processors, for example, required a 2 cpu Mascot license to use all 4 cores.

Mascot 2.2 is configured so that it will not run on a system with more than 4 cores per physical cpu. So, six core processors, for example, are not supported with Mascot 2.2. For Nehalem quad core processors, version 2.2.06 or later (patch available here), is required. Support for processors with more than 4 cores was introduced in Mascot 2.3.

Mascot versions prior to 2.2 are unlikely to work on most modern hardware.

64-bit

All recent Intel and AMD processors are “64-bit” or, in Intel terms, have “Intel EM64T” technology. 32-bit applications can also run on these processors. All versions of Mascot will run on 64-bit Linux, but Mascot 2.2 or later is required for 64-bit Windows. For earlier versions of Mascot, you must install standard 32-bit Windows.

The main advantage in using a 64-bit system is that it is possible to install and access more memory. This is important when multiple searches are being run at the same time and it will also enable extremely large reports to be loaded without running out of memory. Mascot searches are split into ‘chunks’ and therefore all searches can be run on a 32-bit system without running out of address space.

To take advantage of 64-bit Windows in Mascot 2.5 and earlier, the 64-bit release of Active State Perl (provided on the Mascot CD) must be installed. Mascot 2.2 includes 64-bit Parser (for the reports) but only 32-bit binaries for the search engine. Mascot 2.3 and later include 32 and 64-bit binaries. Support for 32-bit Windows was dropped in Mascot 2.6.

Mascot 2.2, 2.3 and 2.4 for Linux includes both 32 and 64-bit binaries. Support for 32-bit Linux was dropped in Mascot 2.5.

Hyper-Threading or Simultaneous Multithreading technology

Hyper-Threading is available on Intel processors. Recent AMD processors (Zen microarchitecture) have similar technology called Simultaneous Multithreading. Hyper-Threading works by duplicating certain sections of the processor – those that store the architectural state – but not duplicating the main execution resources. This allows a Hyper-Threading equipped processor to pretend to be two “logical” processors to the host operating system, allowing the operating system to schedule two threads or processes simultaneously.

When HT is enabled, 2 logical “processors” per core will be visible to Mascot. So, for example, a single physical Intel Xeon® Processor E5-2667 v3 with 8 cores and HT will appear to have 16 “cpus”.

Hyper-threading can give up to a 12% performance increase. It is not equivalent to a true multi-core processor.

Hyper-threading does not count towards the number of cores used for licensing purposes.

Intel or AMD Processors

We have found that performance for searches under identical conditions are roughly proportional to the results from these benchmarks. The performance ratios published here are similar but slightly harder to understand.

Random Access Memory (RAM)

RAM requirements are strongly dependent on the selection of databases you plan to search.

RAM usage during database compression

Mascot Monitor makes a compressed copy of each FASTA database, in which the title lines have been removed and the sequence strings have been packed in a byte efficient manner. The compressed copy of each database is mapped into RAM and, if there is sufficient room, can even be locked into memory.

RAM usage during database compression is negligible for most databases, because only small parts of the database are kept in memory at any given time. The exception is NCBIprot. This database uses a taxonomy file, prot.av2taxid, that lists the NCBI taxonomy ID for each accession in the FASTA file. During database compression, Mascot imports prot.av2taxid into an efficient disk-based data structure, which is memory mapped for fast access. If the PC has sufficient RAM, the operating system will automatically cache frequently accessed portions of prot.av2taxid in memory. If there is insufficient RAM, prot.av2taxid lookups become disk bound, which greatly increases NCBIprot compression time.

If you intend to use NCBIprot, we recommend at least twice the amount of RAM as the size of the prot.av2taxid file plus any operating system overhead. Current (November 2021) size is 14GB, so we recommend at least 32GB of RAM for NCBIprot. The size of the FASTA file is not important for RAM usage during database compression.

RAM usage during database search

When a search calls for a database that is not in memory, the search duration is increased by the time taken to read the database from disk. For a search that takes longer than a couple of minutes, this additional time will be negligible. For a short search, for example a PMF or an MS/MS search of a few spectra, reading from disk may take longer than the search itself.

Databases should always be memory mapped, even though a system might not have sufficient physical RAM to hold them all. Memory mapping only consumes virtual address space, and enables the file to be accessed more efficiently. However, it doesn’t guarantee that a particular database will be in memory when a search calls for it; some other process may have kicked it out. So, it may be advantageous to lock a small, frequently searched database into memory, guaranteeing that it is always resident in RAM.

Whether you have sufficient RAM to lock a database in memory can be estimated from the size of the FASTA file. For a protein database, the required RAM is roughly 80% of the FASTA file size, while for a nucleic acid database it is roughly 50%. Some examples are given in the following table, but the comprehensive sequence databases increase significantly in size every month.

Database FASTA RAM Compression
Swiss-Prot 265 MB 236 MB 1 : 0.9
NCBIprot 208 GB 166 GB 1 : 0.8
Plants_EST 18 GB 8.9 GB 1 : 0.5

You also need to allow approximately 60 MB for the operating system (Windows) and at least 200 MB per thread for each executing Mascot search. We do not currently recommend that NCBIprot or Uniref 100 be locked into memory.

In practice, it is rarely a sensible for a database as large as an EST database to be locked in memory. Being composed of short stretches of nucleic acid sequence, it is not suitable for peptide mass fingerprint searches, and tends to be used as a database of last resort for large searches, where the overhead of reading it from disk represents only a small part of the total search time.

Hard Disk Storage

The Mascot program files require very little disk space in comparison to the sequence databases and the accumulating result files.

For the sequence databases, you will need to maintain free disk space of the order of 3 times the largest database. This is because, during a database update, there may be the current FASTA file, reference file and its associated compressed files plus the equivalent for the incoming database. Mascot also keeps a copy of one previous database. Current (November 2021) disk requirements for the common databases are:

Database Total size of files (GB) Max disk space (GB)
Swiss-Prot 3.9 11
NCBIprot 436 1200
Human_EST 8.3 25
Mus_EST 4.5 13
Plants_EST 28 85

This illustrates how storage requirements are strongly dependent on which databases are required.

The space needed for result files depends on the overall search profile and on how long results are to remain on-line. Individual result file sizes range from 20 kB for a peptide mass fingerprint search through to several GB for a large LC-MS/MS dataset.

Disk drives are very inexpensive, and most PC’s support up to four SATA devices. It is difficult to have too much disk space, especially if you plan to search databases similar in size to NCBIprot.

If any databases are not memory mapped, short searches may be disk I/O bound, and a fast disk (e.g. Serial Attached SCSI, SAS) or a disk array (e.g. RAID), or solid state disk (SSD) can then become an important factor in maximising throughput.

Operating System

Microsoft Windows

The following versions of Windows are supported:

Operating System Max CPU Max RAM
Vista Home Premium – 64 bit 1 16 GB
Vista Business – 64 bit 2 128 GB
Vista Enterprise – 64 bit 2 128 GB
Vista Ultimate – 64 bit 2 128 GB
2008 R2 Server Web Edition – 64 bit 4 32 GB
2008 R2 Server Standard Edition – 64 bit 4 32 GB
2008 R2 Server Enterprise Edition – 64 bit 8 2 TB
2008 R2 Server Datacenter Edition – 64 bit 64 2 TB
Windows 7, Home Premium – 64 bit 1 16 GB
Windows 7, Ultimate, Enterprise and Professional – 64 bit 2 192 GB
Windows 8.1 (Core) – 64 bit 1 128 GB
Windows 8.1 (Pro) – 64 bit 2 512 GB
2012 Server Foundation – 64 bit 1 32 GB
2012 R2 Server Essentials – 64 bit 2 64 GB
2012 R2 Server Standard – 64 bit 64 4 TB
2012 R2 Server Datacenter – 64 bit 64 4 TB
Windows 10 Home – 64 bit 2 128 GB
Windows 10 Pro – 64 bit 2 2 TB
Windows 10 Enterprise – 64 bit 2 6 TB
2016 Server Essentials – 64 bit 2 64 GB
2016 Server Standard – 64 bit 64 24 TB
2016 Server Datacenter – 64 bit 64 24 TB
2019 Server Essentials – 64 bit 2 64 GB
2019 Server Standard – 64 bit 64 24 TB
2019 Server Datacenter – 64 bit 64 24 TB
2022 Server Standard – 64 bit 64 48 TB
2022 Server Datacenter – 64 bit 64 48 TB
Windows 11 Home – 64 bit 2 128 GB
Windows 11 Pro – 64 bit 2 2 TB
Windows 11 Enterprise – 64 bit 2 6 TB

  • Windows Server Core editions are not supported
  • Windows Home Basic and Starter editions are not supported
  • Windows Vista and Windows 2008 Server and later require Mascot 2.2.03 or later

Linux

Mascot has very few system dependencies on Linux. The main requirement is glibc 2.5 or later, which is satisfied by most Linux distributions released since 2010.

Mascot is tested in-house on:

  • Debian 9
  • Debian 8
  • CentOS 7
  • CentOS 5

Web Server Software

Mascot requires a web server for administration and interactive use. In the case of Windows, Microsoft Internet Information Server (IIS) is the obvious choice unless you are committed to some other package. IIS is bundled with all supported Windows Versions.

The Mascot installation program automatically configures IIS versions 7 and later.

Apache is a good choice for Linux. Apache can also be used under Windows.

Running a web browser on the same PC as the web server can take a surprising amount of processor time, so search times may suffer. If the same PC is also used for instrument control and data acquisition, you may need to adjust job priorities using Windows Task Manager to ensure that the instrument gets adequate priority.

Mascot Cluster Mode

A Mascot licence for 4 or more processors (i.e. 16 cores) automatically supports operation on a cluster of systems connected by a dedicated LAN. A cluster offers several advantages over a single, multi-processor system:

  • Mass market, reliable, low cost PC hardware can be used.
  • The cluster can be incrementally expanded as workload increases.
  • Cluster nodes can use processors with modest number of cores, circumventing the clock frequency throttling in processors with high core count.
  • The limited bandwidth of the PC bus is effectively multiplied by the number of systems in the cluster.

Further information here.