Is this Intel i7 machine good for LTSpice?

No. You're requirement sound more like a server motherboard than a "workstation". However, don't go shopping for a rack mount server package, which tends to have expensive features and options that you don't need.

Think about a dual processor Xeon server type motherboard:

How's this MB with 16 memory slots and 512GB maximum RAM?

Get a 250GB or 500GB SSD.

Picking a video card is tricky. I decided that I didn't want to listen to a fan, and ended dealing with a compromise between power consumption (as limited by the power supply), and performance. As Martin Riddle suggested, dig through the Passmark web pile for clues. For video, start here: Nvidia has a handy selection guide: Newegg also has a huge selection, that can be narrowed down with the "choices" on the left:

There's also quite a bit on the various FutureMark web piles: You download one of their (free) benchmarking programs, run it on your prospective hardware, and see where you stand compared to other systems. It's really designed for gamers, but if raw CPU/IO performance is what you want, methinks it would be useful if you just ignore the video benchmark results. Benchmark results:

Uh, I am the analog guy.

NGspice is easy to compile, at least under linux. I don't have a proper video card to test the cuda, but will make it a point to get one when I upgrade.

Under DOS (not to be confused with the windows "cmd"), you "own" the hardware. It is not a multi-user OS so there is no need to "abstract" the peripherals.

The classic DOS hacker program was to bit bang the parallel port. Since you could write directly to the port, it wasn't that hard. The second most popular DOS hack was to read the the level sensitive pins on the serial port (i.e. pins that don't go through the UART.)

If you are just running code to do calculations, DOSBOX is the way to go.

I was a big AMD fan, but Intel has trumped them. It isn't even a contest today.

I will say that the AMD CPUs have better memory management, so they do multitask a little better, but that can't save them on today's market.

I delayed building this Xeon PC hoping AMD would get their act together, but I gave up.

I can't speak for stuff they sell at box stores, but all my drives have cache. [64Mbytes in my case, newer drives use 128Mbytes.] There is zero reason to do a RAM disk. I'm running a software RAID, so besides the cache, much of the data is in RAM anyway prior to being written to disk. [The software RAID is one reason to use error detecting RAM.]

The advantage to building it yourself is you know the capabilities of each component. The disadvantage is is tends to cost more.

Looked at the list of i7 processor variants and all seemed to have a processor specific 256 KiB L2 cache and 4-20 MiB L3 cache. Depending on the program code and data access locality, most of the tight loop code and small data sets would be in the L2 and sometimes taken from the L3 cache with only few accesses to the DDR4 memory (which would actually be "L4 cache", while the disk storage would be the "main memory" in any virtual memory system).

Programs written in traditional languages had a quite good access locality, but unfortunately many programs written in C++ constantly make references all over the place both for code as well as data, reducing the cache hit ratio.

I haven't looked at the actual implement ion of those on-chip graphic controllers, but I would use a few megabyte cache for the actual refresh memory. That display cache controller needs the same kind of functionality as each CPU cache controller on a multiprosessor system that must detect write access to a specific area in the main memory by some foreign actor (other CPU, DMA etc.) and invalidate the local cache for that area.

So, when the application wants to change the display, it writes the new information into main memory, the display cache controller detects the write and invalidates that area in the display cache, which forces the display cache controller to reload the modified areas. Of course, if the application is so stupid that it writes to the main memory even if the contents has not changed, this will cause the display cache reload each time.

However, the display refresh loss is so small that it doesn't justify the use of megabytes of dedicated display cache, while that chip area would be better spent increasing the L3 cache size.

When using a lot of caching with disk writes, make sure that you have some kind of UPS, so that operations are actually written to the physical disk, before the UPS power is lost. Some file systems seem to corrupt the file system data, if the power is lost at a bad time.

Really? You should tell that to MickeySoft then. Here is their own MSKB entry on the topic - apart from a couple of well known commercial installers 16bit code is forbidden from running on x64 machines.

They tried breaking InstallShield at first and that went down *really* well! ISTR Adobe Photoshop would not install on x64 boxes at one point.

I don't doubt that hacking around in the registry with a flint axe will make it possible to run some 16 bit code.

They are not corner cases. I know a major multinational corporate that was stuck for ages using IE6 & XP because something in their huge MS intranet implementation would not work at all with anything later. IE11 was out by the time they were able to get the system upgraded.

People with such kit tend to buy in an entire spare PC or two to keep the thing running indefinitely. If it ain't broke don't fix it!

They have a lost huge numbers due to launching products that were defective like Vista and now Win8 (which isn't actually defective in a technical sense so much as difficult to use as a desktop machine).

It doesn't alter the fact the the "official" MS position is that it doesn't work.

It might be easier to create a VM and run a legacy OS like XP or DOS

I didn't need to bother until Win7 since the same antique DOS .exe has been perfectly serviceable since the late 1980's when it was written.

Car makers have usually been smart enough not to put the windscreen in floor, swap round the brake and accelerator and hide the parking brake. Not so MS Win8 is an alien environment built on the same "productivity" idea that made Office2007 hilarious when it was rolled out. The Office

It was fun to watch people struggle with the "helpful" ribbon! Jokes about the paperclip aside at least he *was* trying to be helpful.

I know perfectly well about the memory contention issues of multicore machines. Hyperthreading is what gets in the way sometimes leaving the data caches in a state where pipeline stalls necessarily occur.

Each (virtual) CPU uses about 20% of memory bandwidth flat out on PC3-12800(800MHz) memory the 3-5% for the video makes no difference to when the turnover in performance occurs. And any decently written fast code will be properly cache aware so that the external memory bandwidth limitations are almost irrelevant since everything is already in cache apart from the very first access to a new cache line at each level.

It is quite unusual to be hitting things that hard for an extended period. Vector dot products and large FFTs will, but most ordinary computing tasks leave plenty of recovery gaps.

Because it doesn't have the performance hit that you imagine.

My i7-3770K at stock speed with the above memory 9-9-9-24 has a geekbench score of 12275 @ 3.5MHz the best are about 13000 so the performance hit for using the internal video is at most -5%. (broadly in agreement with the video bandwidth requirements)

In practice most applications do not hammer memory to quite the same extent as benchmarks or optimised dot product numeric code.

There is no point installing a fancy power hungry 3D graphics card unless you are actually going to use it via CUDA or similar.

The benchmarking game has been played to perfection in the i7.

My LTSpice RAW files are substantially larger than that. HD read-write times are a major slowdown.

That's ok. I just don't want this to turn into a time-consuming science project.

It is only worth doing that if you have vast amounts of memory unused.

You should also consider having an Intel SSD 32GB caching frequently used files. I have one and it works fairly well when compiling stuff. The files in use end up in the SSD after the first pass.

They call it Intel Rapid Storage techonology. It sits between your real hard disk and the application caching most recently used files.

It is much easier to buy something off the shelf unless you have time to burn. Although it does make sense to buy the SSDs separately. Just be sure to fit them on a SATA3 6GB interface. Way faster than magnetic.

If you want the fastest possible scratch disk a RAID0 array of the Samsung 840 256GB or 512GB is about as fast as you can get. Others may benchmark faster by using compression but for incompressible data the Samsungs or Crucial are still about as good as it gets.

And they don't whine horribly or run hot like the old 7200rpm SCSIs did.

With 32GB of RAM I'd have gobs of unused memory. Normally it would be very expensive to have that much memory, one reason why that Costco deal is enticing. AFAICT it only costs $20 in extra software to turn a large portion of RAM into a RAM disk.

Good idea, have to check that out. Never heard of it so far. Do you know an example, like a link to a product? When I search it all points to Intel but not computer stores.

Absolutamente.

Or RAM disk. Just have to make sure the power doesn't go out before shoveling a successful sim run to HD. Although mostly that isn't needed, I never store RAW files in LTSpice because they'd clog up a backup system in no time.

I've never liked SCSI.

Just be careful to make sure that you don't end up thrashing VM. Not sure the extra ram is that expensive going rate ~$100/8GB here and I would expect it to be down to about $60 over the pond.

Some motherboards have it built in. ASUS gaming ones for instance.

Be hard pressed to tell you which other ones without searching. It is handy if you regularly run the same code and data again and again.

It had its uses. I still have one PC that has classic SCSI on the back to use with my now ancient once state-of-the-art Nikon slide scanner.

That is surprisingly cheap. Not sure if it was Phil's dealer or another one but when going into the configuration menu upgrading to 32GB they showed many hundred Dollars extra.

Ah, now I understand. It's not a module to plug in but I'd need a whole different mobo then.

What I am doing is just what you described, running SPICE sims over an over again with minor circuit changes each time.

Very true. I have a Triplite true sine double conversion running.

The ram in a disk drive is used as a FIFO of sorts. [It is way more complicated that a FIFO in reality.] You are making the assumption that no writing on the drive is taking place, and that it is all going to the buffer. That is not the case. Thus the size of the cache on the drive doesn't need to equate to the size of the output file.

Your getting about 200MBytes/sec on a modern drive. That is 5 seconds a Gbyte. This shouldn't be an issue.

On a sunny day (Fri, 07 Nov 2014 01:53:24 -0800) it happened miso wrote in :

I have a laptop that will continue for several hours if power fails... :-)

More likely, the buffer capacity is used to reorganize write requests so that close by sectors and tracks are written first, i.e. minimize R/W head movement and do the writing during a single disk rotation.

Originally, this optimization was done by the OS, but the OS needed to know the physical structure of the disk. When the disk is accessed by logical block numbers (LBN) and when the disk drive itself performs e.g. bad block replacement, the OS doesn't know the physical structure of the disk and hence the disk itself has to perform access optimization.

Unfortunately, if the power is suddenly lost, some disk structures are out of date, and hopefully the next startup may be able to fix the disk.

Disk caches helps with multiple files on a badly fragmented disk. I do not understand what it would help with a single file access on a well defragmented disk.

I heard a salesman saying the AMDs are faster on floating point. Anyone heard that from a reliable source, like benchmarks maybe?