Jihad needs scientists

In article <et3q4u$rad$8@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et39vo$8qk_001@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et1a4q$ki3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0qsp$8qk_002@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esurfc$ds3$6@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <esu74a$8qk_001@s861.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esrtcj$qj4$1@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
In other words, you wrote the TAPE.DIR after all the other files were
written. This means you had to write a file of that size and then the
data and then open TAPE.DIR for writing.

If this is what you did then my method of putting a correct checksum
still
works. If you wrote the TAPE.DIR before the other files and never
changed
it, my method still works.


[....]
Anybody who has done any grocery shopping would know the difference
between the two. Just because dog food is on your shopping list
never guarantees that dog food will be in your car when you get home.
The only listing that shows you were successful in putting
dog food in the shopping cart is the cash register receipt.

Does this mean you wrote TAPE.DIR after the other files were all
written?

Yes. TAPE.DIR was created after the files were written to the tape.
That is how you get a directory listing of the tape onto the tape.

The first cut of the tape had a zero block TAPE.DIR for a place holder
on the tape. Then a DIRECT DSK:TAPE.DIR=TAPE:/CHECKSUM was done.
Then another save was done; this time TAPE.DIR that was on the
tape contained a checksummed directory of the tape.

In other words, you "editted" the tape.

No.

How yes you did. You did exactly the action called editing when speaking
of a tape.

We don't call saving a saveset editing.

Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.

If the answer is yes, you edited the tape. In this case the method works.

If the answer is no then you can no longer argue that the TAPE.DIR is the
list of what is actually on the tape. It must be the list of what you
intend to put on the tape. You have claimed that this is not allowed, but
the method still works for this too.

The file was made by doing a directory of the tape.

No matter which you did, the checksums can be correct.

No, they cannot. The requirement was that TAPE.DIR be a directory
of the tape and not a made-up list.

You wrote one file and then wrote
something different in its place.

No. I wrote the whole save set. In magtape terms, the saveset
was the file on the tape.

Now what the heck are you claiming?

I'm still talking about the same thing.

You have changed what you have claimed. Suddenly, the TAPE.DIR is not a
file on the tape and is a part of the contents of a file on the tape,

TAPE.DIR is a file on the tape AND it is part of the contents
of the saveset (which is the physcial magtape file).

<snip.

I see that I can and have done exactly that in the past.

No, you have not done a similar thing.

I have explained
how to do it a few times. You seem unable to graps it. I've used it.
Remember I have written tapes too.

You may have copied files to tapes but you have not made a distribution
according to the spec we used.

[....]
Then that file was saved along with all the other files onto the tape.

Wait a minute! Suddenly TAPE.DIR is the list of what you intend to write
onto the tape. Your story has changed. You earlier asserted that it must
be made from what you actually wrote. Which is it?

It is both. That is why a CATCH-22 exists.

Not that it matter which it was because as I have already stated, I have
explained how you can get it right in either case.

Your method had each disk file copied to the tape. That is not
how our files were shipped. A saveset was the tape's file. There
were no EOFs between the files we distributed.

I'm getting technical here with reservations because I did not
want to have to explain tape formats to you.



/BAH

 

In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et3a41$8qk_002@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et15r5$h35$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0umt$8qk_018@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuppf$ds3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[.....]
In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world.
When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

Sure. If you have an sense of self-preservation, your router is
going to be seperated from your user machines. All homes
will have their own server which will not be on the same hardware
as their data.

I doubt this is where it will end up. The router software will just be
another task in the home machine. The code for doing rounting doesn't put
the user's data at risk. The firewall is the place where the danger is if
at all.

That would be a cheap and dangerous configuration.

There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns. The risk of a single system
house site configuration is the lack of redundancy. That is
what makes it dangerous. The danger is not just viral infections
but with users typing at a system which also controls vital
functions within the house.

/BAH

 

In article <5b9a2$45f55682$4fe7735$10616@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

jmfbahciv@aol.com wrote:

In article <et15r5$h35$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

In article <et0umt$8qk_018@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:

In article <esuppf$ds3$3@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:

[.....]

In my house there is a network that links two fast machines. These are
linked to the internet by a single high speed pathway. At some future
time, my house may have more than one path to the rest of the world.
When
the city puts in its 802.11 system, it will start to make sense for my
computer to start to choose between the two paths for my packets. This
puts routing inside my house.

Sure. If you have an sense of self-preservation, your router is
going to be seperated from your user machines. All homes
will have their own server which will not be on the same hardware
as their data.

I doubt this is where it will end up. The router software will just be
another task in the home machine. The code for doing rounting doesn't put
the user's data at risk. The firewall is the place where the danger is if
at all.


That would be a cheap and dangerous configuration.

Fine for a purely hobby machine. Folks are making serious use of
home machines these days, including doing their own finances on
a machine they connect to the internet. Some of them leave that
machine connected 24/7.

I keep a separate machine for such stuff.

There is that piece of usage. There will also be the usage of
house maintenance getting done by the "house computer". YOu
don't want kiddies access to that system. There is also
the redundancy issue. If a system has to be up 24x7 then
our crude implementation done in the late 70s will have
to be done again but hopefully, with more experience behind
it.

/BAH


/BAH

 

In article <2fef3$45f57c0a$4fe760d$11460@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

Dan Bloomquist wrote:

MassiveProng wrote:


Note that TTL was the requisite defining element.

Actually "the reason TTL was designed for 5 volts BCC"
was the requisite defining element. As usual, when
beaten to a logical pulp, one side attempted to shift
the goalposts.

That's another version of what amounts to the Godwin
alert, the discussion (as intended) is dead.

No, it's not. I'm still planning to do my homework so I can
answer one your questions.

<snip>

/BAH

 

[Ken Smith]

In article <et5vdg$8qk_002@s887.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Only in badly written software using languages without run time checking
does it happen. We now have more than enough CPU speed that buffer
overruns should be a thing of the past.

The risk of a single system
house site configuration is the lack of redundancy. That is
what makes it dangerous. The danger is not just viral infections
but with users typing at a system which also controls vital
functions within the house.

I would never network my PC to my pacemaker.

That said, you are assuming that the user runs as root/superuser. I very
rarely ever do on my home system. I do it a little more often on the work
system but that is because I need to directly fiddle a few hardware things
from time to time.




--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <QweJh.4664$B25.836@news01.roc.ny>,
Dan Bloomquist <public21@lakeweb.com> wrote:

MassiveProng wrote:

Note that TTL was the requisite defining element.

No, it is, 'Jihad needs scientists'

The thread has drifted. The Jihad isn't getting any scientists from
around here so we have gone onto more important issues like why the
republicans hate America so much, whether Dick Cheney is Satan or merely
his agent and whether GWB should be hung or given life in prison.


--
--
kensmith@rahul.net forging knowledge

 

[Eeyore]

Ken Smith wrote:

Dan Bloomquist wrote:
MassiveProng wrote:

Note that TTL was the requisite defining element.

No, it is, 'Jihad needs scientists'

The thread has drifted. The Jihad isn't getting any scientists from
around here so we have gone onto more important issues like why the
republicans hate America so much, whether Dick Cheney is Satan or merely
his agent and whether GWB should be hung or given life in prison.

You are correct but the thread title hasn't been changed hence any reference to
same must surely be 'on topic'.


Graham

 

[Ken Smith]

In article <c55a1$45f5eebb$49ecfae$14595@DIALUPUSA.NET>,
nonsense@unsettled.com <nonsense@unsettled.com> wrote:

MassiveProng wrote:

On Mon, 12 Mar 2007 14:34:47 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) Gave us:


In article <45F4CF7A.BD6428AD@hotmail.com>,
Eeyore <rabbitsfriendsandrelations@hotmail.com> wrote:
[....]

So Mr Expert. Why isn't TTL made on a 40 Volt process ?

Thats obvious. Its so there is a market for MOSFET drivers. I still want
a PIC made with Supertex's HV CMOS.
[....]
Here's a clue for you. High clock rates and complex
high density chips have a significant problem with
heat,

When you get up to large CMOS chips, heating is a major issue. I didn't
ask for a pentium. Supertex'es process makes for a low leakage current at
largish supply voltages. The PIC has PWM outputs. When making a power
supply you usually have alreeady put in a heat sink.

the main reason for the ever lowering voltages
in CPU's. Long leads, the essence of distributing
heat sources, slows things down significantly.

Actually, I think the heating from leakage current has become a bigger
issue. The static leakage current on a Blackfin is over 90mA when running
at 1.4V.


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <et5un4$8ss_002@s887.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:

In article <et3pbr$rad$7@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et39hp$8ss_003@s948.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <et1957$ki3$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
In article <et0oi0$8qk_003@s776.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
In article <esuqfn$ds3$5@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
[....]
No, you are making the same mistake over and over. As I stated before, if
you know what you are going to put into TAPE.DIR, you can make its
checksum correct. No editing of a magnetic tape was needed by the
method.

Then that TAPE.DIR was not made by taking a directory of the
tape. That was not the purpose of the file. If I had to do
it the way you suggested, I wouldn't put the file on the tape
since it would be a waste of tape space.

So now you are suddenly changing your story and saying that editing of the
tape was done.

There was no tape editing done.

In that case. The tape had to be written with the TAPE.DIR in place and
correct on the first pass.

This is the point. It will never be "correct" because the file
contains a checksummed listing of itself.

snip

Do the exercise. Then you will see what I'm talking about.

Bin thar, dun that, got t-shirt, wore out t-shirt.

I've done it. The idea wasn't new when I did. You just haven't
understood a very simple concept.


--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
<jmfbahciv@aol.com> wrote:
[....]

Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.

In other words, you created it based on what you intended to write to the
tape not what you actually wrote. This contradicts what you said earlier.

It doesn't matter because the suggested method still works. The checksum
could still have been correct.

If the answer is yes, you edited the tape. In this case the method works.

If the answer is no then you can no longer argue that the TAPE.DIR is the
list of what is actually on the tape. It must be the list of what you
intend to put on the tape. You have claimed that this is not allowed, but
the method still works for this too.

The file was made by doing a directory of the tape.

No matter which you did, the checksums can be correct.

No, they cannot. The requirement was that TAPE.DIR be a directory
of the tape and not a made-up list.

Yes they can, it can and once again you are contradicting what you said
above. Either the TAPE.DIR was made after the tape was written or it was
not. If it was not, then it was not a list of what was actually written.
In that case is must be a list of what you intend to write.

If the list existes before the write is done, then it is not a list of
what was written. It simply can't be unless you have a time machine.

It doesn't matter which order it was done in because, as I pointed out
earlier, I have explained how the TAPE.DIR can have the correct checksum
in all cases. You have just not understood the point.

You have changed what you have claimed. Suddenly, the TAPE.DIR is not a
file on the tape and is a part of the contents of a file on the tape,

TAPE.DIR is a file on the tape AND it is part of the contents
of the saveset (which is the physcial magtape file).

Are you saying there are two copies or are you saying that you wrote
everything in one big file?

It really doesn't matter because in either case, the checksum could be
correct but I am curious.

snip.

I see that I can and have done exactly that in the past.

No, you have not done a similar thing.

Actually yes I have.

I have explained
how to do it a few times. You seem unable to graps it. I've used it.
Remember I have written tapes too.

You may have copied files to tapes but you have not made a distribution
according to the spec we used.

Perhaps I have never made a tape based on the spec you used but I have
explained how you could have made one that followed that spec that had a
correct checksum.

Then that file was saved along with all the other files onto the tape.

Wait a minute! Suddenly TAPE.DIR is the list of what you intend to write
onto the tape. Your story has changed. You earlier asserted that it must
be made from what you actually wrote. Which is it?

It is both. That is why a CATCH-22 exists.

There is no CATCH-22. The checksum could have been right.

Not that it matter which it was because as I have already stated, I have
explained how you can get it right in either case.

Your method had each disk file copied to the tape. That is not
how our files were shipped. A saveset was the tape's file. There
were no EOFs between the files we distributed.

This doesn't change a thing. I was and still am trying to explain to you
how the checksum could have been correct on those tapes. In fact, you
composed the TAPE.DIR based on what you intended to write. when you made
this TAPE.DIR it could have had a correct checksum in it, for each file.

The checksum for TAPE.DIR can be correct as I have explained.


--
--
kensmith@rahul.net forging knowledge

 

[Phil Carmody]

jmfbahciv@aol.com writes:

In article <et3o1m$rad$2@blue.rahul.net>,
kensmith@green.rahul.net (Ken Smith) wrote:
There need not be any increase in the risk. Its all a matter of starting
with a reasonable OS and not adding buffer over runs.

There will always be buffer overruns.

Don't judge all programmers based on your own inadequacy as one.

Phil
--
"Home taping is killing big business profits. We left this side blank
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.

 

[Dan Bloomquist]

Eeyore wrote:

Dan Bloomquist wrote:


MassiveProng wrote:

kensmith@green.rahul.net (Ken Smith) Gave us:


Tell us, oh masterTARD, what would the maximum clock be on a 40 volt
logic swing.

Do you even know what slew rate is?

The reason it was 5 volts is because it was a reasonable voltage
that could be slewed to at a decent rate.

Wow. Sounds like ECL is a tremendous screw up.


ECL's use in commercial equipment is negligible.

You are changing the subject.

 

[nonsense@unsettled.com]

jmfbahciv@aol.com wrote:

In article <2fef3$45f57c0a$4fe760d$11460@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:

Dan Bloomquist wrote:


MassiveProng wrote:


Note that TTL was the requisite defining element.

Actually "the reason TTL was designed for 5 volts BCC"
was the requisite defining element. As usual, when
beaten to a logical pulp, one side attempted to shift
the goalposts.

That's another version of what amounts to the Godwin
alert, the discussion (as intended) is dead.

No, it's not.

Perhaps not to you, but they've shifted the goalposts
and the discussion to other issues, mostly arguing for
the sake of bloviating.

I'm still planning to do my homework so I can
answer one your questions.

As you wish. I don't have any outstanding unanswered
questions that I consider important, let alone cage
rattling.

 

[nonsense@unsettled.com]

Ken Smith wrote:

In article <et5v7k$8qk_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com> wrote:
[....]

Did you write a TAPE.DIR onto the tape after the tape had already been
written?

No. One of my requirements was that the file be the first in
the saveset.


In other words, you created it based on what you intended to write to the
tape not what you actually wrote. This contradicts what you said earlier.

It doesn't matter because the suggested method still works. The checksum
could still have been correct.

The operative word is "could." It can never be "what was read from
the tape." Your entire argument on this matter has been silly. It
is an elementary problem in recursion.

If the answer is yes, you edited the tape. In this case the method works.

If the answer is no then you can no longer argue that the TAPE.DIR is the
list of what is actually on the tape. It must be the list of what you
intend to put on the tape. You have claimed that this is not allowed, but
the method still works for this too.

The file was made by doing a directory of the tape.

No matter which you did, the checksums can be correct.

No, they cannot. The requirement was that TAPE.DIR be a directory
of the tape and not a made-up list.


Yes they can, it can and once again you are contradicting what you said
above. Either the TAPE.DIR was made after the tape was written or it was
not. If it was not, then it was not a list of what was actually written.
In that case is must be a list of what you intend to write.

If the list existes before the write is done, then it is not a list of
what was written. It simply can't be unless you have a time machine.

It doesn't matter which order it was done in because, as I pointed out
earlier, I have explained how the TAPE.DIR can have the correct checksum
in all cases. You have just not understood the point.



You have changed what you have claimed. Suddenly, the TAPE.DIR is not a
file on the tape and is a part of the contents of a file on the tape,

TAPE.DIR is a file on the tape AND it is part of the contents
of the saveset (which is the physcial magtape file).


Are you saying there are two copies or are you saying that you wrote
everything in one big file?

It really doesn't matter because in either case, the checksum could be
correct but I am curious.


snip.


I see that I can and have done exactly that in the past.

No, you have not done a similar thing.


Actually yes I have.



I have explained
how to do it a few times. You seem unable to graps it. I've used it.
Remember I have written tapes too.

You may have copied files to tapes but you have not made a distribution
according to the spec we used.


Perhaps I have never made a tape based on the spec you used but I have
explained how you could have made one that followed that spec that had a
correct checksum.


[....]

Then that file was saved along with all the other files onto the tape.

Wait a minute! Suddenly TAPE.DIR is the list of what you intend to write
onto the tape. Your story has changed. You earlier asserted that it must
be made from what you actually wrote. Which is it?

It is both. That is why a CATCH-22 exists.


There is no CATCH-22. The checksum could have been right.



Not that it matter which it was because as I have already stated, I have
explained how you can get it right in either case.

Your method had each disk file copied to the tape. That is not
how our files were shipped. A saveset was the tape's file. There
were no EOFs between the files we distributed.


This doesn't change a thing. I was and still am trying to explain to you
how the checksum could have been correct on those tapes. In fact, you
composed the TAPE.DIR based on what you intended to write. when you made
this TAPE.DIR it could have had a correct checksum in it, for each file.

The checksum for TAPE.DIR can be correct as I have explained.

 

[nonsense@unsettled.com]

Dan Bloomquist wrote:

Eeyore wrote:


Dan Bloomquist wrote:


MassiveProng wrote:

kensmith@green.rahul.net (Ken Smith) Gave us:


Tell us, oh masterTARD, what would the maximum clock be on a 40 volt
logic swing.

Do you even know what slew rate is?

The reason it was 5 volts is because it was a reasonable voltage
that could be slewed to at a decent rate.


Wow. Sounds like ECL is a tremendous screw up.



ECL's use in commercial equipment is negligible.


You are changing the subject.

Of course, in usenet losers seem to do that a lot.

 

[krw]

In article <45F64100.9CD12C2C@hotmail.com>,
rabbitsfriendsandrelations@hotmail.com says...

Dan Bloomquist wrote:

MassiveProng wrote:
kensmith@green.rahul.net (Ken Smith) Gave us:


Tell us, oh masterTARD, what would the maximum clock be on a 40 volt
logic swing.

Do you even know what slew rate is?

The reason it was 5 volts is because it was a reasonable voltage
that could be slewed to at a decent rate.

Wow. Sounds like ECL is a tremendous screw up.

ECL's use in commercial equipment is negligible.

Wrong again, dumb donkey. Most IBM mainframes before CMOS
microprocessors took over (mid '90s) were ECL. That's a lot of ECL.

--
Keith

 

[krw]

In article <45F644B7.6A6487DD@hotmail.com>,
rabbitsfriendsandrelations@hotmail.com says...

"nonsense@unsettled.com" wrote:

MassiveProng wrote:
kensmith@green.rahul.net Gave us:

Tell us, oh masterTARD, what would the maximum clock be on a 40 volt
logic swing.

Do you even know what slew rate is?

The reason it was 5 volts is because it was a reasonable voltage
that could be slewed to at a decent rate.

NOW, we are at 3.3 volts and even 1.2V. The reason is slew rate,
and the fact that we can transition much faster at those swings than
we ever could at 5V.

Here's a clue for you. High clock rates and complex
high density chips have a significant problem with
heat, the main reason for the ever lowering voltages
in CPU's.

*One* of the reasons. Clearly slew rate is implicated equally.

Wrong again, dumb donkey. CMOS slews faster at higher voltages.
Power is squared (at least) as voltage increases. The reason voltage
is being forced down is precisely because of power. The reason power
supply voltages aren't falling faster is because speed is important
too.

--
Keith

 

[krw]

In article <45F6781B.B17EDA7@hotmail.com>,
rabbitsfriendsandrelations@hotmail.com says...

MassiveProng wrote:

Eeyore <rabbitsfriendsandrelations@hotmail.com> Gave us:
"nonsense@unsettled.com" wrote:
MassiveProng wrote:
kensmith@green.rahul.net Gave us:

Tell us, oh masterTARD, what would the maximum clock be on a 40 volt
logic swing.

Do you even know what slew rate is?

The reason it was 5 volts is because it was a reasonable voltage
that could be slewed to at a decent rate.

NOW, we are at 3.3 volts and even 1.2V. The reason is slew rate,
and the fact that we can transition much faster at those swings than
we ever could at 5V.

Here's a clue for you. High clock rates and complex
high density chips have a significant problem with
heat, the main reason for the ever lowering voltages
in CPU's.

*One* of the reasons. Clearly slew rate is implicated equally.


The transition time to an acceptable logic 1 without a false high at
5 volts is huge compared to modern logic designs. Sure power
consumption being lower is part of it, but the ability to go at 10GHz
is simply not possible at 5Volts, and certainly is at 1.2Volts.

The proof is in examining a signal. At 1.2 volts we see nice crisp,
nearly vertical slew transitions between levels. When an engineer
looks at a 5 Volt signature, he notes right away that the slew of the
pulse is so high that high frequency operation won't be possible.

I'd say reduced power consumption and heat generation was a benefit,
not the root reason for the transition.

Look at the cpu floating point wars between Intel and AMD for an
example. They are one of the main reasons that we saw this reduction
in logic level voltages (as consumers). Sure heat and power
consumption was a factor, but we would not be anywhere near where we
are if we were still at 3.3 volt logic levels on the FPUs.

So, nonsense and krw are currently on a false high for thinking that
they shot down my remarks. :-]

Many answers can be found in the overclocking community.

There, they'll happily up the volts to improve slew rate (hence CPU speed). At
the expense of higher dissipation and more expensive and exotic cooling.

Yes, dumb donkey. They're willing to trade off power/reliability for
speed. The REASON for lower voltages is lower power not faster slew
rates (which would occur with a higher voltage).

It's nothing but a trade off. It always has been.

The reason for low voltages is not high speed, rather lower power.

What I'm surpised no-one has mentioned is load capacitance.

That's a constant defined by geometry.

--
Keith

 

[krw]

In article <t5khc4-tr.ln1@sirius.tg00suus7038.net>,
ewill@sirius.tg00suus7038.net says...

In sci.physics, MassiveProng
MassiveProng@thebarattheendoftheuniverse.org
wrote
on Mon, 12 Mar 2007 16:52:21 -0700
3mpbv2h1ts0jed1imfmdt5h52ukk3bcskj@4ax.com>:
On Mon, 12 Mar 2007 14:34:47 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) Gave us:

In article <45F4CF7A.BD6428AD@hotmail.com>,
Eeyore <rabbitsfriendsandrelations@hotmail.com> wrote:
[....]
So Mr Expert. Why isn't TTL made on a 40 Volt process ?

Thats obvious. Its so there is a market for MOSFET drivers. I still want
a PIC made with Supertex's HV CMOS.



Tell us, oh masterTARD, what would the maximum clock be on a 40 volt
logic swing.

Do you even know what slew rate is?

The reason it was 5 volts is because it was a reasonable voltage
that could be slewed to at a decent rate.

NOW, we are at 3.3 volts and even 1.2V. The reason is slew rate,
and the fact that we can transition much faster at those swings than
we ever could at 5V.

There would be no GHz+ Pentiums if we were still at 5 Volt logic
levels.

Getteth thyself a clue.

Well, I for one was under the opinion that the reason E
= 1.2V is because P = E^2/R and also proportional to the
switching frequency of the transistors (since each switch
requires a small pulse of current; the more pulses, the
higher the power required to switch), and also proportional
to the total transistor area, which AFAIK has been largely
constant even as we pack more transistors per die.

Dynamic power is proportional to CFV^2 (R doesn't figure into the
equation given that the circuit switches). You're missing static
power though. Static power (leakage) gets significant with smaller
geometries.

Assuming one can run a chip at both 1.2V and 5V at the
same clock rate, the 5V running will run far hotter --
about 17.4 x more power, in fact.

At the same clock, yes (5^2/1.2^2).

Then again, there's a fair number of factors here, not the
least of which is process control. A chip, like an
airplane, is a bunch of compromises, one of them being
clock speed versus power dissipation.

Logic delay vs. power dissipation, really. Clock speed gets into
microarchitectural issues as well. For example, a P4 will run at a
higher clock speed than a P3 in the same technology. The P3 will
likely outperform it at the same power though.

The x86 series
is an excellent example of a total bodge-up because
it compromised so many things (for example, it's still
source-code compatible with the 8080A and probably with
the Z80 as well!).

Source code compatibility means nothing here.

But it still works.

Now, assuming anyone wants an HV CMOS 40V logic swing, I
for one would think that the best method of achieving such
is through a 1.2V-to-40V swing converter, which presumably
would be a carefully-adjusted standard CMOS transistor-pair
inverter which flips at about 0.6 volts to ground. The rest
of the circuitry can run at 1.2 V without trouble.

Not sure why you'd want 40V, but you're not going to get it on the
same hunk of silicon.

If necessary the level shifter can feed another, more standard inverter.

There might be better solutions; it's been a long time since I've been
anywhere near semiconductor designs, and I only really worked with
slow-speed digital stuff at most.

--
Keith

 

[krw]

In article <et5uie$8ss_001@s887.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv@aol.com says...

In article <3f1c7$45f554cb$4fe7735$10594@DIALUPUSA.NET>,
"nonsense@unsettled.com" <nonsense@unsettled.com> wrote:
jmfbahciv@aol.com wrote:
snip

You have noted that he stripped my post to make it appear that
I was agreeing with his factoid. I was talking about something
completely different.

Happens all the time.

These are the people who when asked "What is pi" will argue to
death that it is 3.14.

# the ratio of the circumference to the diameter of a circle;
approximately equal to 3.14159265358979323846...
# private detective: someone who can be employed as a detective to
collect information
# principal investigator: the scientist in charge of an experiment or
research project
# the 16th letter of the Greek alphabet
# protease inhibitor: an antiviral drug used against HIV; interrupts HIV
replication by binding and blocking HIV protease; often used in
combination with other drugs

wordnet.princeton.edu/perl/webwn

In my corner of the biz, it would have been read as priority interrupt.

"Primary Input". ;-)

--
Keith