On Thu, 22 Jan 2009 18:44:32 GMT, n...@puntnl.niks (Nico Coesel)
wrote:

>D from BC <m...@comic.com> wrote:
>
>>On Wed, 21 Jan 2009 21:24:16 GMT, n...@puntnl.niks (Nico Coesel)
>>wrote:
>>
>>>D from BC <m...@comic.com> wrote:
>>>
>>>>
>>>>I wonder if the other SPICE program writers are massively pissed about
>>>>LTspice being free.
>>>>
>>>
>>>I don't think so. Ltspice is not very user friendly IMHO.
>>
>>Compared to what program?
>
>I like Orcad pspice. 

Capture sucks!

>The old microsim pspice also had a good
>schematics entry. 

I still use it.  Love it!

>If LTspice had a better user interface it would be a
>killer.

Yep!

                                        ...Jim Thompson
-- 
| James E.Thompson, P.E.                           |    mens     |
| Analog Innovations, Inc.                         |     et      |
| Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
| Phoenix, Arizona  85048    Skype: Contacts Only  |             |
| Voice:(480)460-2350  Fax: Available upon request |  Brass Rat  |
| E-mail Icon at http://www.analog-innovations.com |    1962     |
             
 I love to cook with wine     Sometimes I even put it in the food

Jim Thompson wrote:
> 
> On Wed, 21 Jan 2009 13:53:02 -0800, D from BC
> <m...@comic.com> wrote:
> 
> >On Wed, 21 Jan 2009 21:24:16 GMT, n...@puntnl.niks (Nico Coesel)
> >wrote:
> >
> >>D from BC <m...@comic.com> wrote:
> >>
> >>>
> >>>I wonder if the other SPICE program writers are massively pissed about
> >>>LTspice being free.
> >>>
> >>
> >>I don't think so. Ltspice is not very user friendly IMHO.
> >
> >Compared to what program?
> >
> >'Stupid LTSpice program doesn't have a 'Read Mind Make Circuit'
> >button.' :P
> >
> >
> >D from BC
> 
> That would be nice, particularly if there was a "Correct Wrong
> Connections" button ;-)


   Still wouldn't help Sloman.  It would still display "INSUFFICIENT
DATA, TRY GAIN".


-- 
http://improve-usenet.org/index.html

aioe.org, Goggle Groups, and Web TV users must request to be white
listed, or I will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm


There are two kinds of people on this earth:
The crazy, and the insane.
The first sign of insanity is denying that you're crazy.

Nico Coesel wrote:
> D from BC <m...@comic.com> wrote:
> 
>> On Wed, 21 Jan 2009 21:24:16 GMT, n...@puntnl.niks (Nico Coesel)
>> wrote:
>>
>>> D from BC <m...@comic.com> wrote:
>>>
>>>> I wonder if the other SPICE program writers are massively pissed about
>>>> LTspice being free.
>>>>
>>> I don't think so. Ltspice is not very user friendly IMHO.
>> Compared to what program?
> 
> I like Orcad pspice. The old microsim pspice also had a good
> schematics entry. If LTspice had a better user interface it would be a
> killer.
> 

LTspice schematics entry is just a little unusual, when you come
from MicroSim Pspice. Now that I'm used to it, I do indeed find it
better. Much better. It's all a matter of personal taste, I suppose.

Jeroen Belleman

On Tue, 20 Jan 2009 15:07:13 -0800, "Joel Koltner"
<z...@yahoo.com> wrote:

>"D from BC" <m...@comic.com> wrote in message 
>news:p...@4ax.com...
>> I did spot the max treads option under the LTspice control panel.
>> It's set to 2.
>> I haven't noticed a change in speed. :(
>
>That's because with hyperthreaded CPUs, "50% utilization" of "one CPU" is 
>still using (nearly) 100% of the total clock cycles available if nothing else 
>is running on the "second" CPU.
>
>In other words... you get 1 billion operations per second (or whatever). 
>Hyperthreaded CPUs just give the appearance of two CPUs so that if a 
>particular thread is waiting on, e.g., a memory read from DRAM (this can take 
>hundreds of cycles)

Memory access taking hundreds of cycles?  Hell not even a dozen.  

Task switches take hundreds of clocks assuming no cache misses.

>, another thread can run in those hundreds of cycles. 

What kills many applications is disk I/O, by taking many tens of
thousands to a few millions of clock cycles waiting to complete.

Hyperthreading uses this time in multitasking situations to get more
done.  There has to be something to be done in order to see any
improvement.

>However, if the thread is never waiting on anything, it will consume all 1 
>billion cycles every second.
>
>A 1GHz hyperthreaded CPU can compute pi no faster than a non-hyperthreaded 
>CPU.  (Nor will it be any slow.)  But hyperthreaded is a win when you have 
>multiple *different* threads running around when one starts having to wait and 
>would otherwise just be wasting CPU cycles...
>

Your guesses were so far off as to be laughable.
  

On Tue, 20 Jan 2009 15:09:21 -0800, "Joel Koltner"
<z...@yahoo.com> wrote:

>"linnix" <m...@linnix.info-for.us> wrote in message 
>news:4...@x16g2000prn.googlegroups.com...
>>> I wonder if the other SPICE program writers are massively pissed about
>>> LTspice being free.
>> Not any more than than original free spice.  I just downloaded the
>> source, compiled and spiced.
>
>Oh, I think they're a little more ticked than before -- LTspice has many, many 
>improvements over Berkeley SPICE, plus it has a decent (if simplistic) 
>integrated graphing/probing environment, that had to be provided by various 
>(not as tightly-integrated) add-ons with the Berkeley SPICE.
>
You must be thinking of 20 years ago.

On Wed, 21 Jan 2009 19:20:34 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:

>On Wed, 21 Jan 2009 17:29:57 -0500, Spehro Pefhany
><s...@interlogDOTyou.knowwhat> wrote:
>
>>On Wed, 21 Jan 2009 13:46:09 -0800, "Joel Koltner"
>><z...@yahoo.com> wrote:
>>
>>>"Nico Coesel" <n...@puntnl.niks> wrote in message 
>>>news:4...@news.planet.nl...
>>>> I don't think so. Ltspice is not very user friendly IMHO.
>>>
>>>Compared to entering netlists by hand it's quite friendly. :-)
>>
>>In the old days we used an IBM 029 to enter the netlists. 
>>
>>http://en.wikipedia.org/wiki/File:IBM_card_punch_029.JPG
>
>I never had to use an 029, but I did have to wrap JCL around the
>netlist to run the sim jobs on the mainframe.  Text entry was via
>2741s (ruggedized communicating Selectric typewriters) and output via
>line/chain printers.
>

When you say line/chain printers are specifically limiting to chain
printers or are you including drum printers?  (or even other
technologies)
 

On Thu, 22 Jan 2009 20:23:27 +0100, "Helmut Sennewald"
<h...@t-online.de> wrote:

>
>"Nico Coesel" <n...@puntnl.niks> schrieb im Newsbeitrag 
>news:4...@news.planet.nl...
>>D from BC <m...@comic.com> wrote:
>>
>>>On Wed, 21 Jan 2009 21:24:16 GMT, n...@puntnl.niks (Nico Coesel)
>>>wrote:
>>>
>>>>D from BC <m...@comic.com> wrote:
>>>>
>>>>>
>>>>>I wonder if the other SPICE program writers are massively pissed about
>>>>>LTspice being free.
>>>>>
>>>>
>>>>I don't think so. Ltspice is not very user friendly IMHO.
>>>
>>>Compared to what program?
>>
>> I like Orcad pspice. The old microsim pspice also had a good
>> schematics entry. If LTspice had a better user interface it would be a
>> killer.
>>
>> -- 
>> Failure does not prove something is impossible, failure simply
>> indicates you are not using the right tools...
>>                     "If it doesn't fit, use a bigger hammer!"
>> --------------------------------------------------------------
>
>
>Hello Nico,
>
>I bet that I am faster drawing a schematic for simulation than you
>or I will do in PSPICE/ORCAD or any other SPICE program.
>LTspice schematic entry is optimized for SPICE schematics.
>PSPICE/ORCAD schematic entry is designed for PCB layout
>requirements which means extra burden if you only want enter
>a schematic for SPICE. I like the LTspice schematic entry,
>because it's fast and dedicated for (LT-)SPICE.
>
>Best regards,
>Helmut
>

I don't think anyone is really bitching about LTSpice schematic
capture much.  It could easily be better, like for instance add a
library editor / component creator.  Persuade several passive part
providers to create libraries (kind of dependent on component creator
function).  I think asking for hierarchical design would be a but much
though.
  

"JosephKK" <q...@yahoo.com> schrieb im Newsbeitrag 
news:p...@4ax.com...
> On Thu, 22 Jan 2009 20:23:27 +0100, "Helmut Sennewald"
> <h...@t-online.de> wrote:
>
>>
>>"Nico Coesel" <n...@puntnl.niks> schrieb im Newsbeitrag
>>news:4...@news.planet.nl...
>>>D from BC <m...@comic.com> wrote:
>>>
>>>>On Wed, 21 Jan 2009 21:24:16 GMT, n...@puntnl.niks (Nico Coesel)
>>>>wrote:
>>>>
>>>>>D from BC <m...@comic.com> wrote:
>>>>>
>>>>>>
>>>>>>I wonder if the other SPICE program writers are massively pissed about
>>>>>>LTspice being free.
>>>>>>
>>>>>
>>>>>I don't think so. Ltspice is not very user friendly IMHO.
>>>>
>>>>Compared to what program?
>>>
>>> I like Orcad pspice. The old microsim pspice also had a good
>>> schematics entry. If LTspice had a better user interface it would be a
>>> killer.
>>>
>>> -- 
>>> Failure does not prove something is impossible, failure simply
>>> indicates you are not using the right tools...
>>>                     "If it doesn't fit, use a bigger hammer!"
>>> --------------------------------------------------------------
>>
>>
>>Hello Nico,
>>
>>I bet that I am faster drawing a schematic for simulation than you
>>or I will do in PSPICE/ORCAD or any other SPICE program.
>>LTspice schematic entry is optimized for SPICE schematics.
>>PSPICE/ORCAD schematic entry is designed for PCB layout
>>requirements which means extra burden if you only want enter
>>a schematic for SPICE. I like the LTspice schematic entry,
>>because it's fast and dedicated for (LT-)SPICE.
>>
>>Best regards,
>>Helmut
>>
>
> I don't think anyone is really bitching about LTSpice schematic
> capture much.  It could easily be better, like for instance add a
> library editor / component creator.  Persuade several passive part
> providers to create libraries (kind of dependent on component creator
> function).  I think asking for hierarchical design would be a but much
> though.



Hello,

LTspice has the feature of hierarchical schematics and you
can probe in the lower level schematic of course.

Best regards,
Helmut

On Sat, 24 Jan 2009 02:49:37 -0800, JosephKK <q...@yahoo.com>
wrote:

>On Wed, 21 Jan 2009 19:20:34 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>
>>On Wed, 21 Jan 2009 17:29:57 -0500, Spehro Pefhany
>><s...@interlogDOTyou.knowwhat> wrote:
>>
>>>On Wed, 21 Jan 2009 13:46:09 -0800, "Joel Koltner"
>>><z...@yahoo.com> wrote:
>>>
>>>>"Nico Coesel" <n...@puntnl.niks> wrote in message 
>>>>news:4...@news.planet.nl...
>>>>> I don't think so. Ltspice is not very user friendly IMHO.
>>>>
>>>>Compared to entering netlists by hand it's quite friendly. :-)
>>>
>>>In the old days we used an IBM 029 to enter the netlists. 
>>>
>>>http://en.wikipedia.org/wiki/File:IBM_card_punch_029.JPG
>>
>>I never had to use an 029, but I did have to wrap JCL around the
>>netlist to run the sim jobs on the mainframe.  Text entry was via
>>2741s (ruggedized communicating Selectric typewriters) and output via
>>line/chain printers.
>>
>
>When you say line/chain printers are specifically limiting to chain
>printers or are you including drum printers?  (or even other
>technologies)

Chain printers (1403s).   They were soon replaced with laser printers
(3800s) though. 

On Sat, 24 Jan 2009 02:40:02 -0800, JosephKK wrote:

>>In other words... you get 1 billion operations per second (or whatever). 
>>Hyperthreaded CPUs just give the appearance of two CPUs so that if a 
>>particular thread is waiting on, e.g., a memory read from DRAM (this can take 
>>hundreds of cycles)
> 
> Memory access taking hundreds of cycles?  Hell not even a dozen.  

It depends how fast your RAM is. At one point (I guess around 5 years
ago), 350 CPU cycles for a code cache miss was not atypical, but RAM speed
has been consistently increasing faster than CPU speed for the last few
years.

> Task switches take hundreds of clocks assuming no cache misses.
> 
>>, another thread can run in those hundreds of cycles. 
> 
> What kills many applications is disk I/O, by taking many tens of
> thousands to a few millions of clock cycles waiting to complete.
> 
> Hyperthreading uses this time in multitasking situations to get more
> done.  There has to be something to be done in order to see any
> improvement.

For a virtual memory cache miss, where you're waiting on disc access,
hyperthreading doesn't help. The OS kernel will just do a full task
switch (assuming that there's another process/thread to switch to).