The biggest knock against NLTSS during its production lifetime was performance. The one performance issue that affected users most was file access latency. This generally wasn't a significant problem for disk I/O, but the systems that NLTSS ran on also supported a significant complement of very low latency solid state disks with access times under 10 microseconds. The initial latencies for file operations under NLTSS were comparable to the latency for solid state disk access and significantly higher than the LTSS latency for such access. To improve file access latency under NLTSS the implementation was changed significantly to put the most latency sensitive processes (in particular the file server) "in the kernel". This effort wasn't as significant as it might at first sound as all NLTSS servers worked on a multithreading model. What this change really amounted to was to move the threads responsible for file server services from a separate file server process into the kernel "process". Communication to users was unchanged (still through buffer tables, LINCS tokens, etc.), but file operations avoided some significant context changes that were the primary cause of the higher latencies over what the older LTSS and the competing Cray Time Sharing System provided. This change did significantly (~3x) improve the latency of file I/O operations, but it also meant that the file server became a trusted part of the kernel (by implementation, not by design).