Windows Remote VMs

From Stanford SSI Wiki
Revision as of 23:08, 17 October 2020 by Timv (talk | contribs) (Created page with "The Sasha compute cluster contains contains several Windows VMs, which SSI members can use to run resource-intensive software, without relying on their personal computers. Thi...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The Sasha compute cluster contains contains several Windows VMs, which SSI members can use to run resource-intensive software, without relying on their personal computers. This also allows members with Apple computers to run Windows software without having to Dual-Boot. This approach also enables computationally intense jobs to be run for extended periods, as the cluster maintains nearly 100% uptime.

Performance

Sasha is a Dell 2U rackmount server, with a 16 core Ryzen EPYC CPU, and 16 RAM slots for DDR4. It's quite powerful, and is configured to run multiple VMs (effectively independent operating systems within a single computer). The system is oversubscribed, meaning that each of the N systems can utilize far more than 1/N of the available resources. For non-interactive workloads (like Ansys) this means a remote VM will be significantly faster than a personal laptop.

For interactive workloads (CAD, Altium, etc.) the limiting factor for usability will be the users network connection to the cluster. Ever keyboard/mouse/screen interaction experience the latency added by your internet connection and Stanford's internet connection. For users on campus, this effect will likely be hard to notice, but for users around the world, there may be significant lag. You can test this latency by running the following command:

``` timv@timv-5510:~$ ping sasha.stanford.edu PING sasha.stanford.edu (171.64.160.16) 56(84) bytes of data. 64 bytes from sasha.stanford.edu (171.64.160.16): icmp_seq=1 ttl=48 time=29.7 ms 64 bytes from sasha.stanford.edu (171.64.160.16): icmp_seq=2 ttl=48 time=29.7 ms ``` From LA, I get 29.7ms round trip ping time to the cluster. This is quite respectable. Less than 100ms is quite good, and 15ms is about the limit of human perception.