On Sat, 11 Mar 2017 17:11:18 -0000, "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> wrote:>"John Larkin" wrote in message >news:k2a8cc1jfblh5j3treis244mojipt6et25@4ax.com... > >On Fri, 10 Mar 2017 20:29:16 -0600, John S <Sophi.2@invalid.org> >wrote: > >>On 3/10/2017 12:42 PM, John Larkin wrote: >>> On Fri, 10 Mar 2017 19:06:04 +0100, Gerhard Hoffmann >>> <ghf@hoffmann-hochfrequenz.de> wrote: >>> >>>> Am 10.03.2017 um 17:20 schrieb John Larkin: >>>>> On Fri, 10 Mar 2017 04:51:03 +0100, Gerhard Hoffmann >>>>> <ghf@hoffmann-hochfrequenz.de> wrote: >>>> >>>>>> >>>>>> LTspice 4: Linux, virtual Win7 machine VMware Workstation 12: 42 sec >>>>>> same machine in a Linux window LTspice4 with wine under Linux: 22 sec >>>>>> >>>>>> Machine is a Dell Precision "portable Workstation" 3.5 years old. >>>>>> "portable" has to be taken with a grain of salt. 240W power supply. >>>> >>>>> >>>>> >>>>> On my Dell, that sim runs about 10% slower if I plot the waveform >>>>> during the run. I can imagine that PCs with slow graphics could take a >>>>> bigger hit. Do VMs add graphics overhead? >>>> >>>> I suppose they do. There must be a lot of exchanging graphics state >>>> when switching tasks and there must be a lot of task switches; when I >>>> move the cursor from a win7 window to the Linux table top: that looks >>>> harmless, but someone has to decide now which operating system has to >>>> react on the next click. And that click could trigger actions is a >>>> 3D game or 3D layout in Altium Designer. >>>> >>>> I also think that the 2nd 2560*144 pixel monitor attached to my laptop >>>> slows things down, somewhat. Waveform was ON in my test. >>>> >>>> >>>> >>>>> We once rented a compute farm from Amazon to run a slow sim. It wasn't >>>>> any faster than our 4-core Dells. >>>> >>>> Spice is well-known for being hard to parallelize. It has been tried >>>> over and over again. It is not even really floating-point limited. >>>> There has been H-spice on the Cray trying to vectorize it. Do you >>>> remember all those Weitek/NS32032 coprocessor boards that were sold >>>> as Spice accelerators? No one ever made a breakthrough. >>>> >>>> Gerhard >>>> >>> >>> I'd buy one of those Nvidia boards if it would speed up Spice by, say, >>> 100:1. >> >>In your example LTSpice listing, just change your maximum time step from >>10 ns to 10 us. That will give you great speed with no detectable loss >>of detail. >> >> > >>I deliberately set the time step short to slow down this simple >>simulation, so it could be timed in seconds. > >I have an option in SS to have variable wait states so that if you are using >the "change component values on the schematic in real time" feature, the >sim don't finish before you can do so :-)Just crank down the time step? I want a Spice with continuous waveform updates and component value sliders. And 1000x the compute power that I have now. It's impressive how fast one can converge two or three variables when it's trimpots and oscilloscopes, when it might never be possible with Spice.> >>But for LC oscillators, the default/automatic time step will create >>considerable frequency error, several per cent typically. What's awful >>is simulating high-Q circuits accurately in time domain, like crystal >>oscillators. > >Yes. A real pain. As noted in my other post though, I find most design work >can be done with a de-Qed xtal. >XOs are best analyzed in frequency/phase; startup delay seldom matters. But I design triggered oscillators that need to be analyzed in time domain. Spice is terrible, in transient mode, for displaying the frequency of a waveform to PPMs. Useless, actually.>However, for accurate, full Q phase noise, at my day job, its the $100k per >seat, per year Cadence Periodic Steady State Phase Noise. I usually use the >shooting method, rather than the harmonic balance. Often have to include >extra resistance in series with caps to get it to converge though. > >Phase noise results in Cadence are very impressive. Usually within the 1dB >or so error range. Its a complicated calculation. For every point in the >cycle, small signal noise is changing due to different instantaneous >currents. It handles it all in the wash. Does really well on up conversion >of the 1/f noise of devices and resistors. > >I don't know of any freebie PSS/PSSN. It requires a totally different >calculation engine than spiceI bet I can breadboard and test some oscillators faster than I could simulate them! And save most of that $100K. -- John Larkin Highland Technology, Inc lunatic fringe electronics
LTspice Loafing?
Started by ●March 9, 2017
Reply by ●March 11, 20172017-03-11
Reply by ●March 11, 20172017-03-11
"John Larkin" wrote in message news:0uc8cc5nn74l5s2c20jk535tc4redhcke2@4ax.com...>Just crank down the time step?My wait state is in time, so you have easier control over how fast the sim goes. Also it avoids generating huge files, which would happen by cranking down the time step. I never use this feature myself. Just never, ever. Added it for completeness. Adding Monte Carlo gave me the ability to stuff the matrix directly, so it was a minor detail to add real time change of the values.>I want a Spice with continuous waveform updates and component value >sliders. And 1000x the compute power that I have now.>It's impressive how fast one can converge two or three variables when >it's trimpots and oscilloscopes, when it might never be possible with >Spice.Yep.> >>But for LC oscillators, the default/automatic time step will create >>considerable frequency error, several per cent typically. What's awful >>is simulating high-Q circuits accurately in time domain, like crystal >>oscillators. > >Yes. A real pain. As noted in my other post though, I find most design work >can be done with a de-Qed xtal. >>XOs are best analyzed in frequency/phase; startup delay seldom >matters. But I design triggered oscillators that need to be analyzed >in time domain. Spice is terrible, in transient mode, for displaying >the frequency of a waveform to PPMs. Useless, actually.Sure, but running De-qued and dividing by the de-qued facter does give you a really good estimate of what it does at full Q. I have checked this extensively over the years by running PSS and TRAN. Sort of strange really. Don't matter if the series c1 of the xtal is 0.1ff or 10p, the loop gain peak stays the same value. When your dealing with board level stuff, the idea of still getting a net low impedance through a 0.1ff cap is notable.>However, for accurate, full Q phase noise, at my day job, its the $100k >per >seat, per year Cadence Periodic Steady State Phase Noise. I usually use the >shooting method, rather than the harmonic balance. Often have to include >extra resistance in series with caps to get it to converge though. > >Phase noise results in Cadence are very impressive. Usually within the 1dB >or so error range. Its a complicated calculation. For every point in the >cycle, small signal noise is changing due to different instantaneous >currents. It handles it all in the wash. Does really well on up conversion >of the 1/f noise of devices and resistors. > >>I don't know of any freebie PSS/PSSN. It requires a totally different >>calculation engine than spice>I bet I can breadboard and test some oscillators faster than I could >simulate them! And save most of that $100K.Sure, for just the oscillator, but the whole chip I design uses 10,000s of transistors, so the cost has to be for paid anyway. An oscillator chip, is quite a bunch of stuff. A TCXO has chebychev function generators to compensate the frequency v temperature response. An OCXO has heater control feedback loops. Several regulators, output rf buffers, which are non trivial to get -165 dBc noise. VCXO linearizing circuits. Its a bit of a meal to get 50ppb on a TCXO and 1ppb on a TCOCXO. Every chip individually compensated. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
Reply by ●March 11, 20172017-03-11
On Sat, 11 Mar 2017 18:16:13 -0000, "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> wrote:>"John Larkin" wrote in message >news:0uc8cc5nn74l5s2c20jk535tc4redhcke2@4ax.com... > > >>Just crank down the time step? > >My wait state is in time, so you have easier control over how fast the sim >goes. Also it avoids generating huge files, which would happen by cranking >down the time step. > >I never use this feature myself. Just never, ever. Added it for >completeness. Adding Monte Carlo gave me the ability to stuff the matrix >directly, so it was a minor detail to add real time change of the values. > > >>I want a Spice with continuous waveform updates and component value >>sliders. And 1000x the compute power that I have now. > >>It's impressive how fast one can converge two or three variables when >>it's trimpots and oscilloscopes, when it might never be possible with >>Spice. > >Yep. > >> >>>But for LC oscillators, the default/automatic time step will create >>>considerable frequency error, several per cent typically. What's awful >>>is simulating high-Q circuits accurately in time domain, like crystal >>>oscillators. >> >>Yes. A real pain. As noted in my other post though, I find most design work >>can be done with a de-Qed xtal. >> > >>XOs are best analyzed in frequency/phase; startup delay seldom >>matters. But I design triggered oscillators that need to be analyzed >>in time domain. Spice is terrible, in transient mode, for displaying >>the frequency of a waveform to PPMs. Useless, actually. > >Sure, but running De-qued and dividing by the de-qued facter does give you a >really good estimate of what it does at full Q. I have checked this >extensively over the years by running PSS and TRAN. > >Sort of strange really. Don't matter if the series c1 of the xtal is 0.1ff >or 10p, the loop gain peak stays the same value. > >When your dealing with board level stuff, the idea of still getting a net >low impedance through a 0.1ff cap is notable. > >>However, for accurate, full Q phase noise, at my day job, its the $100k >>per >>seat, per year Cadence Periodic Steady State Phase Noise. I usually use the >>shooting method, rather than the harmonic balance. Often have to include >>extra resistance in series with caps to get it to converge though. >> >>Phase noise results in Cadence are very impressive. Usually within the 1dB >>or so error range. Its a complicated calculation. For every point in the >>cycle, small signal noise is changing due to different instantaneous >>currents. It handles it all in the wash. Does really well on up conversion >>of the 1/f noise of devices and resistors. >> >>>I don't know of any freebie PSS/PSSN. It requires a totally different >>>calculation engine than spice > >>I bet I can breadboard and test some oscillators faster than I could >>simulate them! And save most of that $100K. > >Sure, for just the oscillator, but the whole chip I design uses 10,000s of >transistors, so the cost has to be for paid anyway. > >An oscillator chip, is quite a bunch of stuff. A TCXO has chebychev function >generators to compensate the frequency v temperature response. An OCXO has >heater control feedback loops. Several regulators, output rf buffers, which >are non trivial to get -165 dBc noise. VCXO linearizing circuits. Its a bit >of a meal to get 50ppb on a TCXO and 1ppb on a TCOCXO. Every chip >individually compensated.Frequency-domain analysis is faster than transient, but it ignores nonlinearities, and nonlinearities are what ultimately matters. Which is one reason that I buy XOs nowadays and don't design them. You can do that for me. There are some stunning 1x1" OCXOs around lately, incredible phase noise specs for ca $80. Maybe people have figured out how to slice SC-cut crystals cheap. Just a good bare SC-cut rock used to cost $250. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●March 13, 20172017-03-13
On 03/09/2017 06:49 PM, John Larkin wrote:> On Thu, 9 Mar 2017 18:01:20 -0500, bitrex > <bitrex@de.lete.earthlink.net> wrote: > >> On 03/09/2017 02:33 PM, John Larkin wrote: >>> On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs >>> <pcdhSpamMeSenseless@electrooptical.net> wrote: >>> >>>> On 03/09/2017 05:37 AM, Johann Klammer wrote: >>>>> On 03/09/2017 09:29 AM, rickman wrote: >>>>>> I was running some simulations on LTspice and it is not even using >>>>>> 5% of my CPU. Nothing else is topping it and the entire computer >>>>>> is pretty much at idle. What could be limiting the speed? >>>>>> >>>>>> One of the main reasons I bought a laptop with an i7 processor was >>>>>> to speed simulations. Is this wasted on LTspice or am I doing >>>>>> something wrong? >>>>>> >>>>> I think it saves the waveforms to a file as it goes along >>>>> simulating. Where you the one who complained about your hdd being >>>>> slow in an earlier thread? maybe try running the sim from an ext usb >>>>> stick. if that helps it's definitely the hdd. >>>>> >>>> >>>> I'd start with a ramdisk and see then. USB sticks are glacial compared >>>> with real flash drives. >>>> >>>> Cheers >>>> >>>> Phil Hobbs >>> >>> Try this one. 32 seconds on my new Dell. Runs about 25% CPU. >> >> I get a simulation speed average of about 150uS/sec on my i7-5500U 2.4 >> Ghz laptop/SSD drive combo with the "normal" solver, running on >> Wine/Xubuntu. > > I'm seeing 720 us/s, Win7, newish Dell desktop with 8G ram.Whoops, I made an error. Turns out my laptop was throttling the CPU while charging when the battery was at very low charge when I ran the test... With a fully-charged battery I'm getting about 700uS/sec simulation speed. 150uS/sec did seem sluggish for an i7...
Reply by ●March 13, 20172017-03-13
Am 10.03.2017 um 23:56 schrieb Kevin Aylward:> Not sure where you get your information from. Spice can, and has been > paralysed quite effectively. The core function of parallel processingFreud at work?> all the elements in a matrix has been around for a long time in physics > applications e.g. solving nuclear bomb equations. Those systems you read > about that have Petraflop performance at er..ahmm, 10 MWs of power > basically do the same sort of calculations that spice does. > > Gaussian elimination of a matrix is a classic software problem that can > be parallelised pretty easily. All elements in a row, and all rows, can > all be multiplied at once. Each reduction of the matrix size does not > depend on any other calculation. Many other software algorithms can be > very difficult to parallelise like this.Yeah, unless you get pipeline stalls from pivot checks or dealing with sparse matrix methods because your huge matrix contains mostly zeroes. The existence of hand-optimized packets for that is proof enough that there _are_ performance problems. In our first CAD course, we had to write that stuff all ourselves before we were given the Spice 2G4 sources: constructing the matrix, finding the o/p, linearization around the o(p, plugging transistors into the matrix, time discretization of Caps/ companion models, inversion, pivoting, integration and all that. And I have also ported the 3F version to Interactive Unix on the 286. That was not so funny with the small segments. regards, Gerhard
Reply by ●April 17, 20172017-04-17
On Friday, March 10, 2017 at 6:03:40 AM UTC+1, mixed nuts wrote:> On 3/9/2017 2:33 PM, John Larkin wrote: > > On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs > > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > > >> On 03/09/2017 05:37 AM, Johann Klammer wrote: > >>> On 03/09/2017 09:29 AM, rickman wrote: > >>>> I was running some simulations on LTspice and it is not even using > >>>> 5% of my CPU. Nothing else is topping it and the entire computer > >>>> is pretty much at idle. What could be limiting the speed? > >>>> > >>>> One of the main reasons I bought a laptop with an i7 processor was > >>>> to speed simulations. Is this wasted on LTspice or am I doing > >>>> something wrong? > >>>> > >>> I think it saves the waveforms to a file as it goes along > >>> simulating. Where you the one who complained about your hdd being > >>> slow in an earlier thread? maybe try running the sim from an ext usb > >>> stick. if that helps it's definitely the hdd. > >>> > >> I'd start with a ramdisk and see then. USB sticks are glacial compared > >> with real flash drives. > >> > >> Cheers > >> > >> Phil Hobbs > > > > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > > Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. > Slower and busier with a plot updating. > > -- > Grizzly H.That is really good! * LTspice Alternate Solver 33.129 seconds * LTspice normal solver 22.392 seconds * LTspice normal solver with .save 13.306 seconds * NGSPICE 9.660 seconds * NGSPICE with .save 9.002 seconds OS: Windows 7 Service Pack 1 CPU: Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz Logical processors: 12 Total DRAM available = 32702.8 MB. DRAM currently available = 25883.0 MB. The big speedup caused by .save is the most remarkable for me. My PC has an SSD and ReadyBoost turns itself off (its says: no gain possible). -marcel
Reply by ●April 17, 20172017-04-17
wrote in message news:779882df-64e0-4433-8b58-fcdce25392ac@googlegroups.com... On Friday, March 10, 2017 at 6:03:40 AM UTC+1, mixed nuts wrote:> On 3/9/2017 2:33 PM, John Larkin wrote: > > On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs > > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > > >> On 03/09/2017 05:37 AM, Johann Klammer wrote: > >>> On 03/09/2017 09:29 AM, rickman wrote: > >>>> I was running some simulations on LTspice and it is not even using > >>>> 5% of my CPU. Nothing else is topping it and the entire computer > >>>> is pretty much at idle. What could be limiting the speed? > >>>> > >>>> One of the main reasons I bought a laptop with an i7 processor was > >>>> to speed simulations. Is this wasted on LTspice or am I doing > >>>> something wrong? > >>>> > >>> I think it saves the waveforms to a file as it goes along > >>> simulating. Where you the one who complained about your hdd being > >>> slow in an earlier thread? maybe try running the sim from an ext usb > >>> stick. if that helps it's definitely the hdd. > >>> > >> I'd start with a ramdisk and see then. USB sticks are glacial compared > >> with real flash drives. > >> > >> Cheers > >> >> >> Phil Hobbs > > >> > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > >> Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. >> Slower and busier with a plot updating. > > -- >> Grizzly H.>That is really good!>* LTspice Alternate Solver 33.129 seconds >* LTspice normal solver 22.392 seconds >* LTspice normal solver with .save 13.306 seconds >* NGSPICE 9.660 seconds >* NGSPICE with .save 9.002 secondsThis don't make any sense to me. LTSpice should be running several times faster than NGSpice. Are you running default settings in LTSpice, or say, setting a minimum step time? It is possible to override stuff in LTSpice, such that it aint running anything like as fast as it should. Its also possible to speed it up a bit by changing some settings for some circuits. I would be interested in what settings you have for reltol, trtol and min step size The spice default Spice3 value of trtol is 7. I think LTSpice might use 1, I use 1 in SS. The 1 setting can slow it down by a factor of 3, but for some switching circuits, a value of 7 generates way too large errors. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
Reply by ●April 17, 20172017-04-17
On Thursday, 9 March 2017 15:03:49 UTC, mako...@yahoo.com wrote:> > >> I was running some simulations on LTspice and it is not even using > > >> 5% of my CPU. Nothing else is topping it and the entire computer > > >> is pretty much at idle. What could be limiting the speed? > > Make sure the hard drives are running in DMA mode not PIO mode. > > They automatically and permanently fall back to PIO mode if there are hardware errors. > > markWin98 was the last OS AFAIK to default to PIO. So yes it's possible but not very likely. NT
Reply by ●April 17, 20172017-04-17
>"Kevin Aylward" wrote in message >news:pbmdnWA37PxVRmnFnZ2dnUU7-afNnZ2d@giganews.com...>wrote in message >news:779882df-64e0-4433-8b58-fcdce25392ac@googlegroups.com...On Friday, March 10, 2017 at 6:03:40 AM UTC+1, mixed nuts wrote:> On 3/9/2017 2:33 PM, John Larkin wrote: > > On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs > > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > > >> On 03/09/2017 05:37 AM, Johann Klammer wrote: > >>> On 03/09/2017 09:29 AM, rickman wrote: > >>>> I was running some simulations on LTspice and it is not even using > >>>> 5% of my CPU. Nothing else is topping it and the entire computer > >>>> is pretty much at idle. What could be limiting the speed? > >>>> > >>>> One of the main reasons I bought a laptop with an i7 processor was > >>>> to speed simulations. Is this wasted on LTspice or am I doing > >>>> something wrong? > >>>> > >>> I think it saves the waveforms to a file as it goes along > >>> simulating. Where you the one who complained about your hdd being > >>> slow in an earlier thread? maybe try running the sim from an ext usb > >>> stick. if that helps it's definitely the hdd. > >>> > >> I'd start with a ramdisk and see then. USB sticks are glacial compared > >> with real flash drives. > >> > >> Cheers > >> >> >> Phil Hobbs > > >> > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > >> Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. >> Slower and busier with a plot updating. > > -- >> Grizzly H.>That is really good!>* LTspice Alternate Solver 33.129 seconds >* LTspice normal solver 22.392 seconds >* LTspice normal solver with .save 13.306 seconds >* NGSPICE 9.660 seconds >* NGSPICE with .save 9.002 secondsOK, I have now ran the example posted by John at the top of this thread. Is this the one that has been run here? If so, the speed problem is trivial. The tran statement is .tran 0 20m 10n uic This runs in about 15 secs on my laptop in LTSpice. However..... If you right click on the tran line in LTSpice and remove the max time step entry, to let LT does what it does, it runs in < 1/2 sec, probably even 100 ms. Its just zooms through, so difficult to tell. As I keep mentioning, those that use Spice, should take the trouble to at least learn the most trivial, elementary basics of it. You all need to understand that the max time step, if used, must be set with some modicum of rationality. Dah... Like, 10ns in 20us is 2,000 points per cycle. Typically, you only need 20 or so, depending on how jaggered you want the waveform. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
Reply by ●April 17, 20172017-04-17
On Mon, 17 Apr 2017 17:38:01 +0100, "Kevin Aylward" <kevinRemoveandReplaceATkevinaylward.co.uk> wrote: [snip]> >As I keep mentioning, those that use Spice, should take the trouble to at >least learn the most trivial, elementary basics of it. > >You all need to understand that the max time step, if used, must be set with >some modicum of rationality. Dah... > >Like, 10ns in 20us is 2,000 points per cycle. Typically, you only need 20 or >so, depending on how jaggered you want the waveform. > > > >-- Kevin Aylward >http://www.anasoft.co.uk - SuperSpice >http://www.kevinaylward.co.uk/ee/index.html >Yep. Virtually ALL of the questions about LTspice are from those too lazy to RTFM. (On the other side of the tolerances are those who set such a loose timestep that their circuit converges... and they swear by it, even when I demonstrate in PSpice that it sings... I think the tune is "All Hail Larkin" >:-} ...Jim Thompson -- | James E.Thompson | mens | | Analog Innovations | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | STV, Queen Creek, AZ 85142 Skype: skypeanalog | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at http://www.analog-innovations.com | 1962 | Thinking outside the box... producing elegant solutions.
