Sign in with
Sign up | Sign in
Your question

Is Pseudo-Sync the same as "asynchronous mode"?

Last response: in CPUs
Share
September 12, 2004 1:20:13 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

I believe that pseudo-sync is synchronized thus not asynchronized.

However, is pseudo-sync also called 'asynchronous mode'?

i've put some evidence that it is called 'asynchronous mode' at the
end of the post in 2 chunks each marked <extract>...</extract>

The evidence that led me to my belief that pseudo-sync is synchronized
and not asynchronized is below, all the way down, up to the 2
<extract>s.

a disclaimer is at the end

Based on the references below i've concluded that async really means
separate clock, not derived. However, since the introduction of
pseudo-sync / pseudo-synchronous memory, some manufacturers have
called
pseudo-sync 'async' (without the quotes) which is wrong(even with
quotes is wrong), as you can't suddenly change and completely
contradict the traditional meaning of the word. And there is
absolutely
no way for that meaning of async to change, since it's de facto (been
in common usage for years) and de jure (set in law, coined many moons
ago no doubt).

I will follow with further proof that pseudo-sync is sync (and thus
can't be async because async means not sync - so it's either one or
the
other)
I went to my BIOS and set the clock for my memory bus to 100MHz,
(note,
my RAM is 266 DDR-SDRAM i.e. 133*2 MHz.
I ran Si Sandra and it told me that my RAM was at 266MHz = (2*133MHz)
multiplier of 4/3 x
So that means that my RAM which is DDR-SDRAM (the S standing for
synchronous) was operating at (4/3) times my FSB, that is a
pseudo-synchronous rate.
Pseudo-synchronous (keith and frank agree) is when the said clock's
speed is derived by a non-integer multiplier or a divider(divisor?)
that is 1/[insert non-integer here] like 1/2.5 (often stated as 2/5)
So my multiplier of 4/3 (note it's top heavy, thus a multiplier not a
divider) of 1.33x is pseudo-sychronous, and my RAM is DDR-SDRAM
SD= ***synchronous*** dynamic.
And my DDR-SDRAM was taking my FSB=100 as input, multiplying that by
4/3 to get 133MHz and then the RAM was writing/reading data onto the
memory bus at DDR thus 133*2=266MHz So it took the 100, multiplied
it, then DDR'd it.

note: yeah, i know with FSB=100MHz and RAM at 133MHz, i'm not making
use of the extra speed that i'm running my RAM at. But my processor is
1.3GHz and since i've got an AMD Athlon, I guess my multiplier is
locked at 13. Thus If I increase my FSB to 133(for max RAM
efficiency),
it would overclock my processor. I will probably unlock the
processor's multiplier (big hassle and risky) then set my FSB to
133MHz
and my multiplier to 10x, I will be overclocking my processor by
30GHz(no big deal!). My AGP @ 1/2x and PCI @ 1/4x should be ok.

References - these threads explain async, sync, and pseudo-sync
[1]
Re: Asus SP97-V question (9th december 2000)
http://tinyurl.com/4n3mx
note: pseudo-sync is explained here but all the way to the end, keith
and frank use different definitions.

(please see disclaimer, this is my understanding - which think is
correct - of what keith and frank said. I don't intend to put words
into their mouths)


Keith says pseudo-sync is a case of sync
Frank says it's a case of async

Keith's definition from years of experience and based on the
traditional definition of async which i tyhink he would argue has not
changed and can't refer to a derived clock. asynchrous clocks are 2
separate clocks, not derived from each orther,

no multipliers or dividers
"Asynchronous clocks need not have
any frequency relationship and therefor have no phase
relationship"
"They are *ASYNCHRONOUS*. There is no phase alignment."

(so that is why keith says pseudo-synchronous / pseuso-sync is not
async -
he says it is sync as it uses a derived clock like x1 or x 2/5 or 4/3

(i'm not sure if he used the term derived clock)

Frank's definition is from manuals and glossaries, he defines
pseudo-sync as a case of async.
in the 37th post of this thread "Subject: Re: Recommendations on
cheap
AT motherboard" frank gives a lot of evidence from his
manuals.

[2]
Re: Cyric MII 333 problems (from message 12 in thread) 21st Jan 1999
http://tinyurl.com/5v4nl
note: pseudo-sync explained brilliantly by keith.

[3]
Re: Recommendations on cheap AT motherboard (12 October 2001)
http://tinyurl.com/4qpxt
note : keith and frank still disagree on whether pseudo-sync is
async.
Frank gives lots of evidence from manuals in the 37th post of the
thread.


Extracts giving evidence that pseudo-sync = 'async mode'
extract from an overclockers website article
www.overclockers.com/tips1039/index02.asp
<extract>
"You should now have noted that a FSB of 133 MHz and one of 166 MHz
both produce the same memory speed of 333 MHz for DDR memory as a
result of the multiplier change in value at 166 MHz. The difference
between the two cases being the first is in an asynchronous mode of
operation while the second is in a synchronous mode. "

My thinking, is that he's saying
a)FSB 133 RAM (333=166*2) Mult=1.25
b)FSB 166 RAM (333=166*2) Mult=1

he calls 'a' async (from the threads mentioned below, I know that b
is
sync and a is pseudo-sync as pseudo-sync is mult by an non-integer or
by 1/[non-integer] )
Thus, since b is pseudo-sync and this guy called it 'asynchronous
mode'
I guess that pseudo-sync is the same as asynchronous mode.
</extract>

and more evidence that pseudo-sync is 'asynchronous mode'
http://forums.amd.com/index.php?s=76b91b820399d27c78b4c...
topic=18694&st=0&#entry191509
or http://tinyurl.com/4mq2u
<extract from="AMD forum">
"On the other hand, if you want to keep the RAM frequency in 266Mhz
(by
SPD) or change to 333Mhz, you'll be forced to run in asynchronous mode
(FSB:D RAM ratio= 4:6 or 4:5), "
</extract>
notice also, that he's talking about DDR RAM (the guy mentions it
elsewhere. Also, I think 266MHz in our times smacks of DDR 133*2).


DISCLAIMER
disclaimer: my references make mention of keith and frank's
discussion.
Since their discussion was very long, I summarised my understanding of
their statements. I do not mean to speak for them, I have done my
best
to state their points and where they differ as accurately as possible,
to the best of my understanding. Just take my comments on their
comments as a general guide at best, and if you want to know their
exact comments, I included references to the threads they spoke in,
and
I included many quotes which I hope I haven't taken out of context.
I am not an engineer nor do I have any practical experience with PCBs
or chips. I just started reading about this stuff last week. So please
don't consider my words authoritative!! Anything i've stated that has
been derived largely from my brain , i've been careful to precede with
'i guess' or 'i think'(note the small i), unless i've backed it up
with strong
evidence. Since i've been composing in the wee hours and am posting
it at 5am, there may be the odd silly mistake, but since i've repeated
myself so much in this post so as to make my points as strongly as
possible, the rest of the post will show the silly mistake to be a
slip up and not a misunderstanding. hopefully, any misunderstandings
will glare out from the post (along with the eccentricity). I'm being
careful 'cos i'm stating other peoples' statements a lot on a subject
i started reading last week as a hobby, and at 5am i'm dizzy and more
prone to slip ups.
September 14, 2004 2:43:42 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:

> I believe that pseudo-sync is synchronized thus not asynchronized.

You would be correct.

> However, is pseudo-sync also called 'asynchronous mode'?

No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
pseudo-sync, which meant a non-integral, but synchronous multiplier
between the processor bus and the PCI bus.

<snip>

> Based on the references below i've concluded that async really means
> separate clock, not derived.

Yes.

<snip much>

You are correct.

--
Keith
Anonymous
a b à CPUs
September 14, 2004 10:36:11 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On 11 Sep 2004 21:20:13 -0700, q_q_anonymous@yahoo.co.uk (Anon) put
finger to keyboard and composed:

>I believe that pseudo-sync is synchronized thus not asynchronized.
>
>However, is pseudo-sync also called 'asynchronous mode'?

I hate to revisit that old pile of bile, but my take on the issue is
as follows.

Synchronous mode is when two clocks are in phase alignment in such a
way that each edge of the slower clock coincides with an edge of the
faster clock. This occurs, for example, when a single oscillator is
used to generate two frequencies which are integer multiples of each
other.

Asynchronous mode is when there is no phase alignment between the two
clocks. This would be the case if the two clocks, even at the same
frequency, were generated from two different free-running oscillators.

Some vendors such as Asus (a motherboard manufacturer) define a
pseudo-synchronous mode where two clocks are derived from the same
oscillator but where not every edge of the slower clock aligns with an
edge of the faster clock. This occurs when the frequencies are not
integer multiples, but integer ratios, eg 2:5. The two clocks in such
an example would still be synchronised because the pattern repeats at
every 5 cycles of the faster clock.

The confusion arises when other vendors (including manufacturers of
clock generator ICs) choose to define async as anything which is not
sync. Hence, as far as they are concerned, pseudo-sync is async.

The scenario which was the basis of the old thread involved a single
14MHz crystal oscillator and a single clock generator IC. This would
have made the chip's FSB/PCI clock outputs pseudo-synchronous, as
defined by Asus. However, the IC manufacturer's datasheet made no such
distinction and referred to it simply as async.

IIRC, Keith claimed that he was in possession of two versions of the
same Asus motherboard which used both clocking schemes, but when I
challenged him to identify the respective clock chip(s) he was
strangely silent. So the matter was never conclusively resolved.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
Related resources
September 14, 2004 10:36:12 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Tue, 14 Sep 2004 06:36:11 +1000, Franc Zabkar wrote:

> On 11 Sep 2004 21:20:13 -0700, q_q_anonymous@yahoo.co.uk (Anon) put
> finger to keyboard and composed:
>
>>I believe that pseudo-sync is synchronized thus not asynchronized.
>>
>>However, is pseudo-sync also called 'asynchronous mode'?
>
> I hate to revisit that old pile of bile, but my take on the issue is
> as follows.
>
> Synchronous mode is when two clocks are in phase alignment in such a
> way that each edge of the slower clock coincides with an edge of the
> faster clock. This occurs, for example, when a single oscillator is
> used to generate two frequencies which are integer multiples of each
> other.
>
> Asynchronous mode is when there is no phase alignment between the two
> clocks. This would be the case if the two clocks, even at the same
> frequency, were generated from two different free-running oscillators.
>
> Some vendors such as Asus (a motherboard manufacturer) define a
> pseudo-synchronous mode where two clocks are derived from the same
> oscillator but where not every edge of the slower clock aligns with an
> edge of the faster clock. This occurs when the frequencies are not
> integer multiples, but integer ratios, eg 2:5. The two clocks in such
> an example would still be synchronised because the pattern repeats at
> every 5 cycles of the faster clock.
>
> The confusion arises when other vendors (including manufacturers of
> clock generator ICs) choose to define async as anything which is not
> sync. Hence, as far as they are concerned, pseudo-sync is async.
>
> The scenario which was the basis of the old thread involved a single
> 14MHz crystal oscillator and a single clock generator IC. This would
> have made the chip's FSB/PCI clock outputs pseudo-synchronous, as
> defined by Asus. However, the IC manufacturer's datasheet made no such
> distinction and referred to it simply as async.
>
> IIRC, Keith claimed that he was in possession of two versions of the
> same Asus motherboard which used both clocking schemes, but when I
> challenged him to identify the respective clock chip(s) he was
> strangely silent. So the matter was never conclusively resolved.

Yes, I found the evidence, and there were indeed different versions of
the SP97(?). I simply found it uninteresting to argue with someone who
was *so* wrong. BTW, the board I had in my drawer indeed did have only
one oscillator. ...so you were right there. OTOH, I had the records from
*hundreds* of boards (from every manufacturer - including the SP97) that
said there were both. The SiS chipsets could do either. Via was indeed
pseudo-sync (non-integral synchronous) only.
September 15, 2004 2:17:23 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
> On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>
> > I believe that pseudo-sync is synchronized thus not asynchronized.
>
> You would be correct.
>
> > However, is pseudo-sync also called 'asynchronous mode'?
>
> No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
> pseudo-sync, which meant a non-integral, but synchronous multiplier
> between the processor bus and the PCI bus.

there are a number of sites that seem to refer to 1 clock chipsets as
being able to run in 'asynchronous mode'

http://www.hardwarepage.nl/viaapollomvp4.html
and http://www6.tomshardware.com/motherboard/19980731/socke...
"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
mode for your memory"


If async means 2 clocks, - and given the quote above - then maybe
'asynchronous mode' is different from 'real' async. If that were the
case, then maybe 'async mode' is a pseudonym for pseudo-sync
September 15, 2004 2:18:03 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
> On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>
> > I believe that pseudo-sync is synchronized thus not asynchronized.
>
> You would be correct.
>
> > However, is pseudo-sync also called 'asynchronous mode'?
>
> No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
> pseudo-sync, which meant a non-integral, but synchronous multiplier
> between the processor bus and the PCI bus.

there are a number of sites that seem to refer to 1 clock chipsets as
being able to run in 'asynchronous mode'

http://www.hardwarepage.nl/viaapollomvp4.html
and http://www6.tomshardware.com/motherboard/19980731/socke...
"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
mode for your memory"


If async means 2 clocks, - and given the quote above - then maybe
'asynchronous mode' is different from 'real' async. If that were the
case, then maybe 'async mode' is a pseudonym for pseudo-sync
Anonymous
a b à CPUs
September 15, 2004 7:41:02 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

Anon wrote:

> keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>
>>On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>
>>
>>>I believe that pseudo-sync is synchronized thus not asynchronized.
>>
>>You would be correct.
>>
>>
>>>However, is pseudo-sync also called 'asynchronous mode'?
>>
>>No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>>pseudo-sync, which meant a non-integral, but synchronous multiplier
>>between the processor bus and the PCI bus.
>
>
> there are a number of sites that seem to refer to 1 clock chipsets as
> being able to run in 'asynchronous mode'
>
> http://www.hardwarepage.nl/viaapollomvp4.html
> and http://www6.tomshardware.com/motherboard/19980731/socke...
> "VIA's MVP3 chipset allows you to use a synchronous or asynchronous
> mode for your memory"
>
>
> If async means 2 clocks, - and given the quote above - then maybe
> 'asynchronous mode' is different from 'real' async. If that were the
> case, then maybe 'async mode' is a pseudonym for pseudo-sync

There's nothing about asynchronous that requires ANY clock. It simply means
the events are not 'synchronous' with each other. I.E. They are not
necessarily occurring in a fixed time relationship with each other; they
happen when they happen.
September 15, 2004 12:03:28 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

David Maynard <dNOTmayn@ev1.net> wrote in message news:<10kg03rsctkdgaa@corp.supernews.com>...
> Anon wrote:
>
> > keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
> >
> >>On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
> >>
> >>
> >>>I believe that pseudo-sync is synchronized thus not asynchronized.
> >>
> >>You would be correct.
> >>
> >>
> >>>However, is pseudo-sync also called 'asynchronous mode'?
> >>
> >>No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
> >>pseudo-sync, which meant a non-integral, but synchronous multiplier
> >>between the processor bus and the PCI bus.
> >
> >
> > there are a number of sites that seem to refer to 1 clock chipsets as
> > being able to run in 'asynchronous mode'
> >
> > http://www.hardwarepage.nl/viaapollomvp4.html
> > and http://www6.tomshardware.com/motherboard/19980731/socke...
> > "VIA's MVP3 chipset allows you to use a synchronous or asynchronous
> > mode for your memory"
> >
> >
> > If async means 2 clocks, - and given the quote above - then maybe
> > 'asynchronous mode' is different from 'real' async. If that were the
> > case, then maybe 'async mode' is a pseudonym for pseudo-sync
>
> There's nothing about asynchronous that requires ANY clock. It simply means
> the events are not 'synchronous' with each other. I.E. They are not
> necessarily occurring in a fixed time relationship with each other; they
> happen when they happen.

ok, i'll just correct something i said. when i said "async means 2
clocks" I meant 2 oscillators. But I take what you say, so even with
2 oscillators it can be synced if 1 oscillator happens to be aet the
same beat as another, or a multiple.
The thing is though, that I think the VIA MVP3 chipset's clocks use 1
oscillator with multipliers and dividors, thus there is a fixed time
relationship.

Coming to think of it. Every rational number can be put in the form
A/B where A and B are integers. Thus, given 2 clocks each with its
own oscillator, then whatever speeds the 2 clocks are, there will
always be a fixed timing relationship between them. So I don't see
how your definition of sync can be right. There's always a
non-integeral timing relationship i.e. an A/B relationship and thus
by that definition of sync, there is no async!
Anonymous
a b à CPUs
September 15, 2004 12:14:07 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Mon, 13 Sep 2004 22:51:21 -0400, keith <krw@att.bizzzz> put finger
to keyboard and composed:

>On Tue, 14 Sep 2004 06:36:11 +1000, Franc Zabkar wrote:

>> The scenario which was the basis of the old thread involved a single
>> 14MHz crystal oscillator and a single clock generator IC. This would
>> have made the chip's FSB/PCI clock outputs pseudo-synchronous, as
>> defined by Asus. However, the IC manufacturer's datasheet made no such
>> distinction and referred to it simply as async.
>>
>> IIRC, Keith claimed that he was in possession of two versions of the
>> same Asus motherboard which used both clocking schemes, but when I
>> challenged him to identify the respective clock chip(s) he was
>> strangely silent. So the matter was never conclusively resolved.
>
>Yes, I found the evidence, and there were indeed different versions of
>the SP97(?). I simply found it uninteresting to argue with someone who
>was *so* wrong.

You avoided several opportunities to present the "evidence" which you
claimed was at your fingertips. Instead you chose to fabricate a
preposterous lie because you were not man enough to admit that you
were wrong.

> BTW, the board I had in my drawer indeed did have only
>one oscillator. ...so you were right there.

Of course I was. The photographs on Asus's website were evidence
enough.

> OTOH, I had the records from
>*hundreds* of boards (from every manufacturer - including the SP97) that
>said there were both.

BS. IIRC, there were only two versions of the SP97, one with both
SIMMs and DIMMs, the other with SIMMs only. Both used a single
oscillator and clock generator.

>The SiS chipsets could do either.

At that time many users discovered that a combination of AMD K6 CPU
and SiS5597/5598 chipset was unstable when using a pseudo-synchronous
PCI/FSB clock in the ratio of 2:5. This problem was well documented in
various forums.

> Via was indeed
>pseudo-sync (non-integral synchronous) only.

I doubt it. Show me the evidence.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
Anonymous
a b à CPUs
September 15, 2004 9:25:12 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

Anon wrote:
> David Maynard <dNOTmayn@ev1.net> wrote in message news:<10kg03rsctkdgaa@corp.supernews.com>...
>
>>Anon wrote:
>>
>>
>>>keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>>>
>>>
>>>>On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>>>
>>>>
>>>>
>>>>>I believe that pseudo-sync is synchronized thus not asynchronized.
>>>>
>>>>You would be correct.
>>>>
>>>>
>>>>
>>>>>However, is pseudo-sync also called 'asynchronous mode'?
>>>>
>>>>No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>>>>pseudo-sync, which meant a non-integral, but synchronous multiplier
>>>>between the processor bus and the PCI bus.
>>>
>>>
>>>there are a number of sites that seem to refer to 1 clock chipsets as
>>>being able to run in 'asynchronous mode'
>>>
>>>http://www.hardwarepage.nl/viaapollomvp4.html
>>>and http://www6.tomshardware.com/motherboard/19980731/socke...
>>>"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
>>>mode for your memory"
>>>
>>>
>>>If async means 2 clocks, - and given the quote above - then maybe
>>>'asynchronous mode' is different from 'real' async. If that were the
>>>case, then maybe 'async mode' is a pseudonym for pseudo-sync
>>
>>There's nothing about asynchronous that requires ANY clock. It simply means
>>the events are not 'synchronous' with each other. I.E. They are not
>>necessarily occurring in a fixed time relationship with each other; they
>>happen when they happen.
>
>
> ok, i'll just correct something i said. when i said "async means 2
> clocks" I meant 2 oscillators.

Same thing in this context.

> But I take what you say, so even with
> 2 oscillators it can be synced if 1 oscillator happens to be aet the
> same beat as another, or a multiple.

No, if they are sync'd to each other then they're synchronous.

You're confusing the analog world with the digital world and there's no
such thing as two clocks that 'just happen' to be at the same frequency (an
analog measurement), or multiple, of each other. There is always some
deviation, unless they are synchronized.

> The thing is though, that I think the VIA MVP3 chipset's clocks use 1
> oscillator with multipliers and dividors, thus there is a fixed time
> relationship.

There is a fixed relationship between the derived clocks, of course, but
you're confusing the memory types. The asynchronous memory they're talking
about does not operated by any of those clocks. It is asynchronous.

A data request is made and 'some time' later the data is ready. The only
thing you know about when the data will be ready is that it should be less
than the specified read delay; typically 60ns for good FPM SIMMS. But it is
not ready in 'sync' with any clock. It's ready when it's ready: asynchronously

> Coming to think of it. Every rational number can be put in the form
> A/B where A and B are integers. Thus, given 2 clocks each with its
> own oscillator, then whatever speeds the 2 clocks are, there will
> always be a fixed timing relationship between them. So I don't see
> how your definition of sync can be right. There's always a
> non-integeral timing relationship i.e. an A/B relationship and thus
> by that definition of sync, there is no async!

In the first place, I said asynchronous doesn't require ANY clocks but you
keep insisting on defining it with clocks.

Second, you're confusing idealized math with the real world. By idealized I
mean you're ignoring all the other things that comprise the real world
(analog) signals; the first of which I already mentioned: that there's no
such thing as two clocks that 'just happen' to be at the same frequency.
The next is there's no such thing as a 'pure' and constant time domain.
Clocks do not run at 'X' frequency, nor at it forever. They run at X -+
some error with Y jitter and Z drift over time. So, if you want two clocks
to maintain a particular relationship over time then you have to do
something to cause them to stay in that relationship. That is precisely
what synchronization means: the relationship remains constant over time.

Your 'intuitive' extrapolation from rational numbers is true in that there
is a ratio between them at point 'A' in time. But there's another one at
point 'B', and another one at point 'C', and so on and so on, because the
clocks are not perfect, error free, things that remain constant. And, to
make matters worse, the error adds up over time.

Put another way, your math presumes things that are not true unless
intentionally caused to be so... e.g. by synchronizing the clocks.
Anonymous
a b à CPUs
September 15, 2004 11:42:31 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Wed, 15 Sep 2004 08:14:07 +1000, Franc Zabkar <fzabkar@optussnet.com.au>
wrote:

>On Mon, 13 Sep 2004 22:51:21 -0400, keith <krw@att.bizzzz> put finger
>to keyboard and composed:

>>The SiS chipsets could do either.
>
>At that time many users discovered that a combination of AMD K6 CPU
>and SiS5597/5598 chipset was unstable when using a pseudo-synchronous
>PCI/FSB clock in the ratio of 2:5. This problem was well documented in
>various forums.
>
>> Via was indeed
>>pseudo-sync (non-integral synchronous) only.
>
>I doubt it. Show me the evidence.

Anybody as interested as you should have the VIA data sheets. Look up the
MVP3 chipset (598.pdf), specifically the VT82C598 North Bridge. It
supported FSB:p CI clock ratios of 2, 2.5 and 3 and that's err, all folks.
FWIW there were many mbrds which were scripted for 2.5 jumpering but I
never heard of one which actually implemented it - even when there was a
jumper, instead of a couple of spare pads, it did not actually force a 2.5
ratio. AIR a look at the clock chips used showed that it was just not
supported - mbrd mfr cheaped out or possibly the the VIA 598 didn't
actually work right that way.

If you don't have the .pdf and are umm, nice (for a change :-}) I'll e-mail
it to you.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 15, 2004 11:42:31 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On 14 Sep 2004 22:17:23 -0700, q_q_anonymous@yahoo.co.uk (Anon) wrote:

>keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>> On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>
>> > I believe that pseudo-sync is synchronized thus not asynchronized.
>>
>> You would be correct.
>>
>> > However, is pseudo-sync also called 'asynchronous mode'?
>>
>> No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>> pseudo-sync, which meant a non-integral, but synchronous multiplier
>> between the processor bus and the PCI bus.
>
>there are a number of sites that seem to refer to 1 clock chipsets as
>being able to run in 'asynchronous mode'
>
>http://www.hardwarepage.nl/viaapollomvp4.html
>and http://www6.tomshardware.com/motherboard/19980731/socke...
>"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
>mode for your memory"

Amazing the fiction you can find on WWW, presented as fact. The MVP3 did
*NOT* support "asynchronous" (not a good term anyway since it means
something different in other apps) clocking of any kind. The memory was
clocked the same as the FSB; the AGP was clocked at 2x PCI and the FSB:p CI
allowed ratios of 2, 2.5 and 3.

>If async means 2 clocks, - and given the quote above - then maybe
>'asynchronous mode' is different from 'real' async. If that were the
>case, then maybe 'async mode' is a pseudonym for pseudo-sync

Nope. Just read the data sheets - it's in there.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 16, 2004 3:05:41 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:

> On 14 Sep 2004 22:17:23 -0700, q_q_anonymous@yahoo.co.uk (Anon) wrote:
>
>
>>keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>>
>>>On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>>
>>>
>>>>I believe that pseudo-sync is synchronized thus not asynchronized.
>>>
>>>You would be correct.
>>>
>>>
>>>>However, is pseudo-sync also called 'asynchronous mode'?
>>>
>>>No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>>>pseudo-sync, which meant a non-integral, but synchronous multiplier
>>>between the processor bus and the PCI bus.
>>
>>there are a number of sites that seem to refer to 1 clock chipsets as
>>being able to run in 'asynchronous mode'
>>
>>http://www.hardwarepage.nl/viaapollomvp4.html
>>and http://www6.tomshardware.com/motherboard/19980731/socke...
>>"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
>>mode for your memory"
>
>
> Amazing the fiction you can find on WWW, presented as fact. The MVP3 did
> *NOT* support "asynchronous" (not a good term anyway since it means
> something different in other apps) clocking of any kind. The memory was
> clocked the same as the FSB; the AGP was clocked at 2x PCI and the FSB:p CI
> allowed ratios of 2, 2.5 and 3.

And what makes you think tomshardware is wrong?

http://www.mtiusa.com/sy-5eh.htm

That board uses the MPV3 chipset and supports FPM and EDO; both of which
are asynchronous memory.

>
>
>>If async means 2 clocks, - and given the quote above - then maybe
>>'asynchronous mode' is different from 'real' async. If that were the
>>case, then maybe 'async mode' is a pseudonym for pseudo-sync
>
>
> Nope. Just read the data sheets - it's in there.
>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 16, 2004 12:06:47 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On 15 Sep 2004 08:03:28 -0700, q_q_anonymous@yahoo.co.uk (Anon) put
finger to keyboard and composed:

>ok, i'll just correct something i said. when i said "async means 2
>clocks" I meant 2 oscillators. But I take what you say, so even with
>2 oscillators it can be synced if 1 oscillator happens to be aet the
>same beat as another, or a multiple.
>The thing is though, that I think the VIA MVP3 chipset's clocks use 1
>oscillator with multipliers and dividors, thus there is a fixed time
>relationship.
>
>Coming to think of it. Every rational number can be put in the form
>A/B where A and B are integers. Thus, given 2 clocks each with its
>own oscillator, then whatever speeds the 2 clocks are, there will
>always be a fixed timing relationship between them. So I don't see
>how your definition of sync can be right. There's always a
>non-integeral timing relationship i.e. an A/B relationship and thus
>by that definition of sync, there is no async!

Oscillators are not perfect. Frequencies drift with temperature, for
example.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
Anonymous
a b à CPUs
September 16, 2004 8:41:11 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Wed, 15 Sep 2004 23:05:41 -0500, David Maynard <dNOTmayn@ev1.net> wrote:

>George Macdonald wrote:
>
>> On 14 Sep 2004 22:17:23 -0700, q_q_anonymous@yahoo.co.uk (Anon) wrote:
>>
>>
>>>keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>>>
>>>>On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>>>
>>>>
>>>>>I believe that pseudo-sync is synchronized thus not asynchronized.
>>>>
>>>>You would be correct.
>>>>
>>>>
>>>>>However, is pseudo-sync also called 'asynchronous mode'?
>>>>
>>>>No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>>>>pseudo-sync, which meant a non-integral, but synchronous multiplier
>>>>between the processor bus and the PCI bus.
>>>
>>>there are a number of sites that seem to refer to 1 clock chipsets as
>>>being able to run in 'asynchronous mode'
>>>
>>>http://www.hardwarepage.nl/viaapollomvp4.html
>>>and http://www6.tomshardware.com/motherboard/19980731/socke...
>>>"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
>>>mode for your memory"
>>
>>
>> Amazing the fiction you can find on WWW, presented as fact. The MVP3 did
>> *NOT* support "asynchronous" (not a good term anyway since it means
>> something different in other apps) clocking of any kind. The memory was
>> clocked the same as the FSB; the AGP was clocked at 2x PCI and the FSB:p CI
>> allowed ratios of 2, 2.5 and 3.
>
>And what makes you think tomshardware is wrong?

<titter> Well err, it usually is.:-)

>http://www.mtiusa.com/sy-5eh.htm
>
>That board uses the MPV3 chipset and supports FPM and EDO; both of which
>are asynchronous memory.

I forgot about the Soyo 5EHM (were there others - don't think so) and we
have a couple in the office. Never used FPM/EDO with them though and it
was a glaring waste of mbrd real estate... given the relative prices in
hmm, 1998(?). Did any company make FPM/EDO PC memory SIMMs which would
respond to a 100MHz FSB pass-through rate?... 40ns?

Of course that was not the "asynchronous" being discussed here anyway..
which was to do with the FSB:p CI ratio. I guess I fell into the trap the
previous poster set for himself.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 16, 2004 11:37:45 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:

> On Wed, 15 Sep 2004 23:05:41 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>George Macdonald wrote:
>>
>>
>>>On 14 Sep 2004 22:17:23 -0700, q_q_anonymous@yahoo.co.uk (Anon) wrote:
>>>
>>>
>>>
>>>>keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>>>>
>>>>
>>>>>On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>>>>
>>>>>
>>>>>
>>>>>>I believe that pseudo-sync is synchronized thus not asynchronized.
>>>>>
>>>>>You would be correct.
>>>>>
>>>>>
>>>>>
>>>>>>However, is pseudo-sync also called 'asynchronous mode'?
>>>>>
>>>>>No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>>>>>pseudo-sync, which meant a non-integral, but synchronous multiplier
>>>>>between the processor bus and the PCI bus.
>>>>
>>>>there are a number of sites that seem to refer to 1 clock chipsets as
>>>>being able to run in 'asynchronous mode'
>>>>
>>>>http://www.hardwarepage.nl/viaapollomvp4.html
>>>>and http://www6.tomshardware.com/motherboard/19980731/socke...
>>>>"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
>>>>mode for your memory"
>>>
>>>
>>>Amazing the fiction you can find on WWW, presented as fact. The MVP3 did
>>>*NOT* support "asynchronous" (not a good term anyway since it means
>>>something different in other apps) clocking of any kind. The memory was
>>>clocked the same as the FSB; the AGP was clocked at 2x PCI and the FSB:p CI
>>>allowed ratios of 2, 2.5 and 3.
>>
>>And what makes you think tomshardware is wrong?
>
>
> <titter> Well err, it usually is.:-)

That's a useless accusation, especially since they were right and you were
wrong on the support of asynchronous memory.

>>http://www.mtiusa.com/sy-5eh.htm
>>
>>That board uses the MPV3 chipset and supports FPM and EDO; both of which
>>are asynchronous memory.
>
>
> I forgot about the Soyo 5EHM (were there others - don't think so) and we
> have a couple in the office. Never used FPM/EDO with them though and it
> was a glaring waste of mbrd real estate... given the relative prices in
> hmm, 1998(?).

All of which, even if true, means nothing as it only takes one to prove the
chipset supports it whether you think it was a 'good idea' or not.

> Did any company make FPM/EDO PC memory SIMMs which would
> respond to a 100MHz FSB pass-through rate?... 40ns?

The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.

To illustrate the point, how did you come up with 40ns in order to "respond
to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
*synchronous* memory would need a 10ns access rate to keep up. Asynchronous
can be anything because it's, ahem, asynchronous.

And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
either. The effective data rate for 60ns memory would be, at best (ignoring
all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.


> Of course that was not the "asynchronous" being discussed here anyway..
> which was to do with the FSB:p CI ratio. I guess I fell into the trap the
> previous poster set for himself.

The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
is there 'the one here'. Asynchronous is asynchronous.

>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 17, 2004 5:18:31 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:
> George Macdonald wrote:

> The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.

> To illustrate the point, how did you come up with 40ns in order to "respond
> to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
> *synchronous* memory would need a 10ns access rate to keep up. Asynchronous
> can be anything because it's, ahem, asynchronous.

Nothing is truly "asynchronous" in this context. The DRAM is considered
"asynchronous" because it did not explicitly move from one state to
another state in response to s clock input, rather, it changed states
relative to the timing of some control signals, but those control
signals were generated by a DRAM controller, which is itself
"synchronous" and operated on a base clock frequency.

"Asynchronous" PB EDO could have a 10ns "cycle rate" in the sense that
it could burst out the data at the 10ns (100MHz) rate, if you so pushed
the margins and picked the right parts, but I agree, it would have been
tough.

> And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
> either. The effective data rate for 60ns memory would be, at best (ignoring
> all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.

"60ns" memory is 60ns tRAC**, and that has nothing to do with the effective
datarate, since the DRAM manufacturers were actually pipelining and
spitting out data on xEDO parts just as they were on SDRAM parts.

> > Of course that was not the "asynchronous" being discussed here anyway..
> > which was to do with the FSB:p CI ratio. I guess I fell into the trap the
> > previous poster set for himself.

> The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
> is there 'the one here'. Asynchronous is asynchronous.

Asynchronous is asynchronous, except when it's not really asynchrnous.
Even when it's "synchronous", it's not really "synchronous". What does
"clock" mean when the strobe signals arrive the device interfaces at
different times? It's all relative... To something... Usually an
explicit clock or strobe, but could be implicitly relative to the clock.

** tRAC is Randomc access latency. Which is basically tRCD + tCAS.
Micron's data sheet on obsolete FPM and EDO parts are still available
online at www.micron.com.

--
davewang202(at)yahoo(dot)com
Anonymous
a b à CPUs
September 17, 2004 11:03:26 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Wed, 15 Sep 2004 19:42:31 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> put finger to keyboard and
composed:

>On Wed, 15 Sep 2004 08:14:07 +1000, Franc Zabkar <fzabkar@optussnet.com.au>
>wrote:
>
>>On Mon, 13 Sep 2004 22:51:21 -0400, keith <krw@att.bizzzz> put finger
>>to keyboard and composed:
>
>>>The SiS chipsets could do either.
>>
>>At that time many users discovered that a combination of AMD K6 CPU
>>and SiS5597/5598 chipset was unstable when using a pseudo-synchronous
>>PCI/FSB clock in the ratio of 2:5. This problem was well documented in
>>various forums.
>>
>>> Via was indeed
>>>pseudo-sync (non-integral synchronous) only.
>>
>>I doubt it. Show me the evidence.
>
>Anybody as interested as you should have the VIA data sheets.

Unfortunately such internal documents are available only to a select
few. Mere mortals don't qualify.

> Look up the
>MVP3 chipset (598.pdf), specifically the VT82C598 North Bridge. It
>supported FSB:p CI clock ratios of 2, 2.5 and 3 and that's err, all folks.
>FWIW there were many mbrds which were scripted for 2.5 jumpering but I
>never heard of one which actually implemented it - even when there was a
>jumper, instead of a couple of spare pads, it did not actually force a 2.5
>ratio. AIR a look at the clock chips used showed that it was just not
>supported - mbrd mfr cheaped out or possibly the the VIA 598 didn't
>actually work right that way.
>
>If you don't have the .pdf and are umm, nice (for a change :-}) I'll e-mail
>it to you.

I'm always nice ... to nice people. But I detest liars and pompous
blowhards.

Thanks for your offer of the .pdf file. I suspect the OP would
appreciate a copy, too. I don't really need it myself, though, as I
don't doubt your integrity, nor your knowledge. OTOH, I have proven
Keith to be wrong on so many occasions, on even basic issues, that I'm
loathe to accept anything he says without independent confirmation.

May I suggest you upload the VIA datasheet to your own webspace and
post a link to same.

>Rgds, George Macdonald
>
>"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
Anonymous
a b à CPUs
September 17, 2004 11:36:55 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

Franc Zabkar <fzabkar@optussnet.com.au> wrote:

>I don't doubt your integrity

Guffaw.
Anonymous
a b à CPUs
September 18, 2004 2:18:35 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Fri, 17 Sep 2004 07:03:26 +1000, Franc Zabkar <fzabkar@optussnet.com.au>
wrote:

>On Wed, 15 Sep 2004 19:42:31 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> put finger to keyboard and
>composed:
>
<<snip>>

>>Anybody as interested as you should have the VIA data sheets.
>
>Unfortunately such internal documents are available only to a select
>few. Mere mortals don't qualify.

True now but back in the days of the MVP3, VIA had pretty good general
availability of data sheets.

<<snip>>

>Thanks for your offer of the .pdf file. I suspect the OP would
>appreciate a copy, too. I don't really need it myself, though, as I
>don't doubt your integrity, nor your knowledge. OTOH, I have proven
>Keith to be wrong on so many occasions, on even basic issues, that I'm
>loathe to accept anything he says without independent confirmation.

I guess we can all be rubbed the wrong way but I've always found Keith a
valuable source of in depth info. Have you still not figured where he
works and what he does?

>May I suggest you upload the VIA datasheet to your own webspace and
>post a link to same.

I've never even bothered to use any "webspace" I might have from my ISP...
and would be concerned that it's allocation might work against my e-mail
quota.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 18, 2004 2:18:35 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Thu, 16 Sep 2004 19:37:45 -0500, David Maynard <dNOTmayn@ev1.net> wrote:

>George Macdonald wrote:
>
>> On Wed, 15 Sep 2004 23:05:41 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>
>>
>>>George Macdonald wrote:
>>>
>>>
>>>>On 14 Sep 2004 22:17:23 -0700, q_q_anonymous@yahoo.co.uk (Anon) wrote:
>>>>
>>>>
>>>>
>>>>>keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>>>>>
>>>>>
>>>>>>On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I believe that pseudo-sync is synchronized thus not asynchronized.
>>>>>>
>>>>>>You would be correct.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>However, is pseudo-sync also called 'asynchronous mode'?
>>>>>>
>>>>>>No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>>>>>>pseudo-sync, which meant a non-integral, but synchronous multiplier
>>>>>>between the processor bus and the PCI bus.
>>>>>
>>>>>there are a number of sites that seem to refer to 1 clock chipsets as
>>>>>being able to run in 'asynchronous mode'
>>>>>
>>>>>http://www.hardwarepage.nl/viaapollomvp4.html
>>>>>and http://www6.tomshardware.com/motherboard/19980731/socke...
>>>>>"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
>>>>>mode for your memory"
>>>>
>>>>
>>>>Amazing the fiction you can find on WWW, presented as fact. The MVP3 did
>>>>*NOT* support "asynchronous" (not a good term anyway since it means
>>>>something different in other apps) clocking of any kind. The memory was
>>>>clocked the same as the FSB; the AGP was clocked at 2x PCI and the FSB:p CI
>>>>allowed ratios of 2, 2.5 and 3.
>>>
>>>And what makes you think tomshardware is wrong?
>>
>>
>> <titter> Well err, it usually is.:-)
>
>That's a useless accusation, especially since they were right and you were
>wrong on the support of asynchronous memory.

I already explained... at the end... meaning I'd missed the EDO/SDRAM dual
capability of the chipset... and the existence of the Soyo (previously
M-Tech) mbrd which implemented both socket styles. The "asynchronous
memory" post was a red herring in the context of
synchronous/pseudo-synchronous FSB:p CI ratios. So I got hooked??:-)

>>>http://www.mtiusa.com/sy-5eh.htm
>>>
>>>That board uses the MPV3 chipset and supports FPM and EDO; both of which
>>>are asynchronous memory.
>>
>>
>> I forgot about the Soyo 5EHM (were there others - don't think so) and we
>> have a couple in the office. Never used FPM/EDO with them though and it
>> was a glaring waste of mbrd real estate... given the relative prices in
>> hmm, 1998(?).
>
>All of which, even if true, means nothing as it only takes one to prove the
>chipset supports it whether you think it was a 'good idea' or not.
>
>> Did any company make FPM/EDO PC memory SIMMs which would
>> respond to a 100MHz FSB pass-through rate?... 40ns?
>
>The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.

See Dave's post.

>To illustrate the point, how did you come up with 40ns in order to "respond
>to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
>*synchronous* memory would need a 10ns access rate to keep up. Asynchronous
>can be anything because it's, ahem, asynchronous.

35-40ns EDO memory would probably be about what you'd need to operate at a
FSB of 100MHz without an excessive number of wait states on the (100MHz)
memory controller strobes and "dead" FSB clock periods. FPM/EDO was rated
by acccess time delay from RAS#, i.e. tRAC... not by clock cycles.

>And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
>either. The effective data rate for 60ns memory would be, at best (ignoring
>all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.

I'd suggest you read up on it a bit more - docs are probably still
available.. and no 60ns FPM/EDO did not have an effective 16.7MHz - the
66MHz FSB was a match.

SDRAM was "better" because it spec'd reference clocks for the memory,
eventually 4 per DIMM, and did away with much of the morass of delay,
setup, transition and hold times which had to spec'd between the memory
controller and the memory chips.. and because it implemented a command
based access structure which was much more amenable to pipelined and burst
accessing.

>> Of course that was not the "asynchronous" being discussed here anyway..
>> which was to do with the FSB:p CI ratio. I guess I fell into the trap the
>> previous poster set for himself.
>
>The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
>is there 'the one here'. Asynchronous is asynchronous.

What was being discussed, "the one here", was the relative FSB:p CI clocking
schemes available from various chipset mfrs, in particular synchronous,
pseudo-synchronous and asynchronous. Seems you somehow missed that with
the "asynchronous memory" canard.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 18, 2004 7:00:06 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:

> On Thu, 16 Sep 2004 19:37:45 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>George Macdonald wrote:
>>
>>
>>>On Wed, 15 Sep 2004 23:05:41 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>>
>>>
>>>>George Macdonald wrote:
>>>>
>>>>
>>>>
>>>>>On 14 Sep 2004 22:17:23 -0700, q_q_anonymous@yahoo.co.uk (Anon) wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>I believe that pseudo-sync is synchronized thus not asynchronized.
>>>>>>>
>>>>>>>You would be correct.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>However, is pseudo-sync also called 'asynchronous mode'?
>>>>>>>
>>>>>>>No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>>>>>>>pseudo-sync, which meant a non-integral, but synchronous multiplier
>>>>>>>between the processor bus and the PCI bus.
>>>>>>
>>>>>>there are a number of sites that seem to refer to 1 clock chipsets as
>>>>>>being able to run in 'asynchronous mode'
>>>>>>
>>>>>>http://www.hardwarepage.nl/viaapollomvp4.html
>>>>>>and http://www6.tomshardware.com/motherboard/19980731/socke...
>>>>>>"VIA's MVP3 chipset allows you to use a synchronous or asynchronous
>>>>>>mode for your memory"
>>>>>
>>>>>
>>>>>Amazing the fiction you can find on WWW, presented as fact. The MVP3 did
>>>>>*NOT* support "asynchronous" (not a good term anyway since it means
>>>>>something different in other apps) clocking of any kind. The memory was
>>>>>clocked the same as the FSB; the AGP was clocked at 2x PCI and the FSB:p CI
>>>>>allowed ratios of 2, 2.5 and 3.
>>>>
>>>>And what makes you think tomshardware is wrong?
>>>
>>>
>>><titter> Well err, it usually is.:-)
>>
>>That's a useless accusation, especially since they were right and you were
>>wrong on the support of asynchronous memory.
>
>
> I already explained... at the end... meaning I'd missed the EDO/SDRAM dual
> capability of the chipset... and the existence of the Soyo (previously
> M-Tech) mbrd which implemented both socket styles. The "asynchronous
> memory" post was a red herring in the context of
> synchronous/pseudo-synchronous FSB:p CI ratios. So I got hooked??:-)

Could be. It's just not wise to 'titter' about someone else being wrong
when they were right. Kinda keeps the mistake 'alive', as CBS is learning.


>>>>http://www.mtiusa.com/sy-5eh.htm
>>>>
>>>>That board uses the MPV3 chipset and supports FPM and EDO; both of which
>>>>are asynchronous memory.
>>>
>>>
>>>I forgot about the Soyo 5EHM (were there others - don't think so) and we
>>>have a couple in the office. Never used FPM/EDO with them though and it
>>>was a glaring waste of mbrd real estate... given the relative prices in
>>>hmm, 1998(?).
>>
>>All of which, even if true, means nothing as it only takes one to prove the
>>chipset supports it whether you think it was a 'good idea' or not.
>>
>>
>>> Did any company make FPM/EDO PC memory SIMMs which would
>>>respond to a 100MHz FSB pass-through rate?... 40ns?
>>
>>The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.
>
>
> See Dave's post.

I *am* 'Dave'.


>>To illustrate the point, how did you come up with 40ns in order to "respond
>>to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
>>*synchronous* memory would need a 10ns access rate to keep up. Asynchronous
>>can be anything because it's, ahem, asynchronous.
>
>
> 35-40ns EDO memory would probably be about what you'd need to operate at a
> FSB of 100MHz without an excessive number of wait states on the (100MHz)
> memory controller strobes and "dead" FSB clock periods. FPM/EDO was rated
> by acccess time delay from RAS#, i.e. tRAC... not by clock cycles.

"Without an excessive number." That's just arm waving.


>>And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
>>either. The effective data rate for 60ns memory would be, at best (ignoring
>>all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.
>
>
> I'd suggest you read up on it a bit more - docs are probably still
> available.. and no 60ns FPM/EDO did not have an effective 16.7MHz - the
> 66MHz FSB was a match.

Try doing some simple math: like invert 60ns.

I'd point out that 66MHz FSB wasn't a 'match' but after your arm waving
about "excessive number" your version of 'match' could mean anything.


> SDRAM was "better" because it spec'd reference clocks for the memory,
> eventually 4 per DIMM, and did away with much of the morass of delay,
> setup, transition and hold times which had to spec'd between the memory
> controller and the memory chips.. and because it implemented a command
> based access structure which was much more amenable to pipelined and burst
> accessing.

That 'burst' processing and reduced delays you speak of are because the
stuff streams at 15ns instead of 60ns read access times.


>>>Of course that was not the "asynchronous" being discussed here anyway..
>>>which was to do with the FSB:p CI ratio. I guess I fell into the trap the
>>>previous poster set for himself.
>>
>>The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
>>is there 'the one here'. Asynchronous is asynchronous.
>
>
> What was being discussed, "the one here", was the relative FSB:p CI clocking
> schemes available from various chipset mfrs, in particular synchronous,
> pseudo-synchronous and asynchronous. Seems you somehow missed that with
> the "asynchronous memory" canard.

What you missed is that asynchronous is not dependent on there being ANY
clocks, as I said in the first post and again just above, nor is it
dependent on busses, or memory, or anything else. Asynchronous is asynchronous.

>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 18, 2004 5:35:08 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Fri, 17 Sep 2004 22:18:35 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> put finger to keyboard and
composed:

>Have you still not figured where he
>works and what he does?

Why should anyone care? The only thing that should matter in Usenet is
one's written word, not one's reputation, whatever that may be.

>>May I suggest you upload the VIA datasheet to your own webspace and
>>post a link to same.
>
>I've never even bothered to use any "webspace" I might have from my ISP...
>and would be concerned that it's allocation might work against my e-mail
>quota.

IMO, people should avoid sending large attachments via email for that
very reason.

>Rgds, George Macdonald
>
>"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
Anonymous
a b à CPUs
September 19, 2004 7:20:08 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Sat, 18 Sep 2004 03:00:06 -0500, David Maynard <dNOTmayn@ev1.net> wrote:

>George Macdonald wrote:
>
>> On Thu, 16 Sep 2004 19:37:45 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>
>>
>>>George Macdonald wrote:
<<snip>>
>>>That's a useless accusation, especially since they were right and you were
>>>wrong on the support of asynchronous memory.
>>
>>
>> I already explained... at the end... meaning I'd missed the EDO/SDRAM dual
>> capability of the chipset... and the existence of the Soyo (previously
>> M-Tech) mbrd which implemented both socket styles. The "asynchronous
>> memory" post was a red herring in the context of
>> synchronous/pseudo-synchronous FSB:p CI ratios. So I got hooked??:-)
>
>Could be. It's just not wise to 'titter' about someone else being wrong
>when they were right. Kinda keeps the mistake 'alive', as CBS is learning.

What part of "red herring" is it you don't understand? Tom doesn't need me
to blacken his reputation.

>>>>>http://www.mtiusa.com/sy-5eh.htm
>>>>>
>>>>>That board uses the MPV3 chipset and supports FPM and EDO; both of which
>>>>>are asynchronous memory.
>>>>
>>>>
>>>>I forgot about the Soyo 5EHM (were there others - don't think so) and we
>>>>have a couple in the office. Never used FPM/EDO with them though and it
>>>>was a glaring waste of mbrd real estate... given the relative prices in
>>>>hmm, 1998(?).
>>>
>>>All of which, even if true, means nothing as it only takes one to prove the
>>>chipset supports it whether you think it was a 'good idea' or not.
>>>
>>>
>>>> Did any company make FPM/EDO PC memory SIMMs which would
>>>>respond to a 100MHz FSB pass-through rate?... 40ns?
>>>
>>>The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.
>>
>>
>> See Dave's post.
>
>I *am* 'Dave'.

<snigger> Did your server not pick up David Wang's post? Read it in detail
- Google if necessary. Hint: don't argue with David - it'll be an uphill
fight which you will certainly lose.:-)

>>>To illustrate the point, how did you come up with 40ns in order to "respond
>>>to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
>>>*synchronous* memory would need a 10ns access rate to keep up. Asynchronous
>>>can be anything because it's, ahem, asynchronous.

Note: SDRAM does not have a "10ns access rate". It's just a single clock
cycle of a 100MHz SDRAM clock.

>> 35-40ns EDO memory would probably be about what you'd need to operate at a
>> FSB of 100MHz without an excessive number of wait states on the (100MHz)
>> memory controller strobes and "dead" FSB clock periods. FPM/EDO was rated
>> by acccess time delay from RAS#, i.e. tRAC... not by clock cycles.
>
>"Without an excessive number." That's just arm waving.

Read the last sentence above again!... "FPM/EDO was rated......."
"Excessive" would be more wait states than a 60ns EDO DRAM needs with a
66MHz FSB bus... which would be just a waste of the enhanced 100MHz FSB
speed. There is, of course, more to it than just wait states... in the
timing tolerances.

>>>And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
>>>either. The effective data rate for 60ns memory would be, at best (ignoring
>>>all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.
>>
>>
>> I'd suggest you read up on it a bit more - docs are probably still
>> available.. and no 60ns FPM/EDO did not have an effective 16.7MHz - the
>> 66MHz FSB was a match.
>
>Try doing some simple math: like invert 60ns.

That's not how it works. Clearly you do not know how EDO DRAM works nor
what the 60ns means. Again, read D. Wang's post and the above referenced
sentence - the 60ns is the time for a complete random access, tRAC,
including RAS# and CAS#**. In contrast, the 10ns of a 100MHz SDRAM clock
is just one event in a series (usually 5 or 6) required for the same random
access.

**Note that tRAC is the delay from RAS# till data is output on the bus. A
complete cycle is much longer: tRC, the time between successive RAS# is
~100ns.

>I'd point out that 66MHz FSB wasn't a 'match' but after your arm waving
>about "excessive number" your version of 'match' could mean anything.

Once you've digested how FPM/EDO DRAM is rated... all will be clear.:-)

>> SDRAM was "better" because it spec'd reference clocks for the memory,
>> eventually 4 per DIMM, and did away with much of the morass of delay,
>> setup, transition and hold times which had to spec'd between the memory
>> controller and the memory chips.. and because it implemented a command
>> based access structure which was much more amenable to pipelined and burst
>> accessing.
>
>That 'burst' processing and reduced delays you speak of are because the
>stuff streams at 15ns instead of 60ns read access times.

Nope - apples 'n' oranges. EDO rated at 60ns "streams" at ~25ns per access
(with pipelining) and of course did not have a burst mode so requires a
fresh CAS# for each open page access. In fact early SDRAMs did not
effectively operate any faster, apart from the added advantage of bursting
- they had only two banks and the chipsets did not manage the interleaving
properly... in fact some (most ?) early SDRAM chipsets worked only with
auto-precharge on every access.

>>>>Of course that was not the "asynchronous" being discussed here anyway..
>>>>which was to do with the FSB:p CI ratio. I guess I fell into the trap the
>>>>previous poster set for himself.
>>>
>>>The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
>>>is there 'the one here'. Asynchronous is asynchronous.
>>
>>
>> What was being discussed, "the one here", was the relative FSB:p CI clocking
>> schemes available from various chipset mfrs, in particular synchronous,
>> pseudo-synchronous and asynchronous. Seems you somehow missed that with
>> the "asynchronous memory" canard.
>
>What you missed is that asynchronous is not dependent on there being ANY
>clocks, as I said in the first post and again just above, nor is it
>dependent on busses, or memory, or anything else. Asynchronous is asynchronous.

"Asynchronous" can mean different things to different people in different
situations. I'm afraid you're just ill-equipped for this discussion.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 19, 2004 11:02:20 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:

> On Sat, 18 Sep 2004 03:00:06 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>George Macdonald wrote:
>>
>>
>>>On Thu, 16 Sep 2004 19:37:45 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>>
>>>
>>>>George Macdonald wrote:
>
> <<snip>>
>
>>>>That's a useless accusation, especially since they were right and you were
>>>>wrong on the support of asynchronous memory.
>>>
>>>
>>>I already explained... at the end... meaning I'd missed the EDO/SDRAM dual
>>>capability of the chipset... and the existence of the Soyo (previously
>>>M-Tech) mbrd which implemented both socket styles. The "asynchronous
>>>memory" post was a red herring in the context of
>>>synchronous/pseudo-synchronous FSB:p CI ratios. So I got hooked??:-)
>>
>>Could be. It's just not wise to 'titter' about someone else being wrong
>>when they were right. Kinda keeps the mistake 'alive', as CBS is learning.
>
>
> What part of "red herring" is it you don't understand? Tom doesn't need me
> to blacken his reputation.

I understand "red herring" just fine. But your mixing of what you claim was
someone's 'red herring' (someone bringing up async RAM) with
unsubstantiated ad hominens is pure illogic.

But whether it was a 'red herring', or not, doesn't alter the fact you
claimed "The MVP3 did *NOT* support "asynchronous"... clocking of any kind"
nor does it suddenly make that incorrect declaration somehow 'correct'.

>>>>>>http://www.mtiusa.com/sy-5eh.htm
>>>>>>
>>>>>>That board uses the MPV3 chipset and supports FPM and EDO; both of which
>>>>>>are asynchronous memory.
>>>>>
>>>>>
>>>>>I forgot about the Soyo 5EHM (were there others - don't think so) and we
>>>>>have a couple in the office. Never used FPM/EDO with them though and it
>>>>>was a glaring waste of mbrd real estate... given the relative prices in
>>>>>hmm, 1998(?).
>>>>
>>>>All of which, even if true, means nothing as it only takes one to prove the
>>>>chipset supports it whether you think it was a 'good idea' or not.
>>>>
>>>>
>>>>
>>>>>Did any company make FPM/EDO PC memory SIMMs which would
>>>>>respond to a 100MHz FSB pass-through rate?... 40ns?
>>>>
>>>>The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.
>>>
>>>
>>>See Dave's post.
>>
>>I *am* 'Dave'.
>
>
> <snigger> Did your server not pick up David Wang's post? Read it in detail
> - Google if necessary. Hint: don't argue with David - it'll be an uphill
> fight which you will certainly lose.:-)

How silly of me to not know that there's only one "Dave" in the world. I
guess I missed that memo.


>>>>To illustrate the point, how did you come up with 40ns in order to "respond
>>>>to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
>>>>*synchronous* memory would need a 10ns access rate to keep up. Asynchronous
>>>>can be anything because it's, ahem, asynchronous.
>
>
> Note: SDRAM does not have a "10ns access rate". It's just a single clock
> cycle of a 100MHz SDRAM clock.

After setup SDRAM streams at 100Mhz, which is a 10ns clock cycle and the
rate for each subsequent access in the data set to keep up with the stream.

>>>35-40ns EDO memory would probably be about what you'd need to operate at a
>>>FSB of 100MHz without an excessive number of wait states on the (100MHz)
>>>memory controller strobes and "dead" FSB clock periods. FPM/EDO was rated
>>>by acccess time delay from RAS#, i.e. tRAC... not by clock cycles.
>>
>>"Without an excessive number." That's just arm waving.
>
>
> Read the last sentence above again!... "FPM/EDO was rated......."
> "Excessive" would be more wait states than a 60ns EDO DRAM needs with a
> 66MHz FSB bus... which would be just a waste of the enhanced 100MHz FSB
> speed. There is, of course, more to it than just wait states... in the
> timing tolerances.

You didn't originally say anything about "in order to have equal wait
cycles as 60ns FPM on a 66MHz Bus" as the definition of "respond to a
100MHz FSB pass-through rate," which is still arbitrary arm waving

It was the motherboard cache, when included, that 'matched' the 66Mhz FSB
and the purpose of it.

>>>>And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
>>>>either. The effective data rate for 60ns memory would be, at best (ignoring
>>>>all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.
>>>
>>>
>>>I'd suggest you read up on it a bit more - docs are probably still
>>>available.. and no 60ns FPM/EDO did not have an effective 16.7MHz - the
>>>66MHz FSB was a match.
>>
>>Try doing some simple math: like invert 60ns.
>
>
> That's not how it workss
> Clearly you do not know how EDO DRAM works nor
> what the 60ns means.

You never put anything 'clear'.

> Again, read D. Wang's post and the above referenced
> sentence - the 60ns is the time for a complete random access, tRAC,
> including RAS# and CAS#**.

Of course.

> In contrast, the 10ns of a 100MHz SDRAM clock
> is just one event in a series (usually 5 or 6) required for the same random
> access.

SDRAM streams at that 10ns at 100Mhz.

I.E. The initial setup requires more than one clock. After that each bus
wide set comes in 10ns increments.

>
> **Note that tRAC is the delay from RAS# till data is output on the bus. A
> complete cycle is much longer: tRC, the time between successive RAS# is
> ~100ns.

What you're apparently calling a 'complete cycle' is actually a stream
burst of multiple reads.

>>I'd point out that 66MHz FSB wasn't a 'match' but after your arm waving
>>about "excessive number" your version of 'match' could mean anything.
>
>
> Once you've digested how FPM/EDO DRAM is rated... all will be clear.:-)

Try mulling over the purpose of motherboard cache for a while.


>>>SDRAM was "better" because it spec'd reference clocks for the memory,
>>>eventually 4 per DIMM, and did away with much of the morass of delay,
>>>setup, transition and hold times which had to spec'd between the memory
>>>controller and the memory chips.. and because it implemented a command
>>>based access structure which was much more amenable to pipelined and burst
>>>accessing.
>>
>>That 'burst' processing and reduced delays you speak of are because the
>>stuff streams at 15ns instead of 60ns read access times.
>
>
> Nope - apples 'n' oranges. EDO rated at 60ns "streams" at ~25ns per access

Speaking of apples and oranges, nice try at arbitrarily switching from from
FPM to EDO. Even so, you will note that ~25ns is not 15.

> (with pipelining) and of course did not have a burst mode so requires a
> fresh CAS# for each open page access. In fact early SDRAMs did not
> effectively operate any faster, apart from the added advantage of bursting
> - they had only two banks and the chipsets did not manage the interleaving
> properly... in fact some (most ?) early SDRAM chipsets worked only with
> auto-precharge on every access.

A lot of smoke to hide the fact that the topic *was* the SDRAM burst rate,
which is the bus clock rate. The thing you dismiss with 'apart from'.

All of which has been an even bigger smoke screen to cover up the fact you
were incorrect when you said "the MVP3 chipset did *NOT* support
'asynchronous' ... clocking of any kind.

>>>>>Of course that was not the "asynchronous" being discussed here anyway..
>>>>>which was to do with the FSB:p CI ratio. I guess I fell into the trap the
>>>>>previous poster set for himself.
>>>>
>>>>The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
>>>>is there 'the one here'. Asynchronous is asynchronous.
>>>
>>>
>>>What was being discussed, "the one here", was the relative FSB:p CI clocking
>>>schemes available from various chipset mfrs, in particular synchronous,
>>>pseudo-synchronous and asynchronous. Seems you somehow missed that with
>>>the "asynchronous memory" canard.
>>
>>What you missed is that asynchronous is not dependent on there being ANY
>>clocks, as I said in the first post and again just above, nor is it
>>dependent on busses, or memory, or anything else. Asynchronous is asynchronous.
>
>
> "Asynchronous" can mean different things to different people in different
> situations.

Even if true you covered that 'diversity' well, and incorrectly, with "does
not support asynchronous of any kind."

> I'm afraid you're just ill-equipped for this discussion.

Throwing ad hominems accomplishes nothing.

>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 19, 2004 1:21:04 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

David Wang wrote:

> In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:
>
>>George Macdonald wrote:
>
>
>>The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.
>
>
>>To illustrate the point, how did you come up with 40ns in order to "respond
>>to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
>>*synchronous* memory would need a 10ns access rate to keep up. Asynchronous
>>can be anything because it's, ahem, asynchronous.
>
>
> Nothing is truly "asynchronous" in this context. The DRAM is considered
> "asynchronous" because it did not explicitly move from one state to
> another state in response to s clock input, rather, it changed states
> relative to the timing of some control signals, but those control
> signals were generated by a DRAM controller, which is itself
> "synchronous" and operated on a base clock frequency.

The confusion comes from it being 'converted', if you will, from
asynchronous, at the RAM, to synchronous by the chipset.


> "Asynchronous" PB EDO could have a 10ns "cycle rate" in the sense that
> it could burst out the data at the 10ns (100MHz) rate, if you so pushed
> the margins and picked the right parts, but I agree, it would have been
> tough.
>
>
>>And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
>>either. The effective data rate for 60ns memory would be, at best (ignoring
>>all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.
>
>
> "60ns" memory is 60ns tRAC**, and that has nothing to do with the effective
> datarate,

Yes, I misspoke.

> since the DRAM manufacturers were actually pipelining and
> spitting out data on xEDO parts just as they were on SDRAM parts.

Yes, except that FPM/EDO is simply holding the Row Address so the chipset
'can' do subsequent reads without that delay, if the data is in that range.
The chipset 'can', then, do multiple reads, setting the column address, as
in a 'stream' but it is not required to (by the RAM) nor are the column
addresses required to be in any particular order (beyond the dictates of
practicality). Of course, doing a stream 'makes sense' but the async RAM
doesn't care; it's a function of the chipset design.

With SDRAM, however, the stream (burst mode) is inherent to the RAM itself,
not just good sense, with each subsequent data set in the stream implicit
and internally incremented (synchronous with the clock) by the SDRAM.

The more significant difference, in the context of async vs sync, is that
SDRAM does not look to the edges of multiple 'strobe' signals for timing.
All timing comes from the clock edges. e.g. addresses are not latched, I.E.
'clocked', by CAS and RAS, as with async RAM, they're latched on clock
edges. All timing comes directly from the clock (which does not even exist
on the async RAM bus) and therein lies the 'synchronous' nature of it.

Now, one might argue that all those 'async' strobe signals generated by the
chipset are traceable to the chipset clock and so, in some manner,
'synchronous' with it but that's talking about the nature of the chipset;
not the async RAM. I.E. the async RAM doesn't care if the strobes come from
a 'clocked' chipset or a bank of one-shots, as long as they meet the setup
and hold times, but you aren't going to get squat out of SDRAM without the
clock that all it's internal timing is derived in synchrony with.

>>>Of course that was not the "asynchronous" being discussed here anyway..
>>>which was to do with the FSB:p CI ratio. I guess I fell into the trap the
>>>previous poster set for himself.
>
>
>>The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
>>is there 'the one here'. Asynchronous is asynchronous.
>
>
> Asynchronous is asynchronous, except when it's not really asynchrnous.
> Even when it's "synchronous", it's not really "synchronous". What does
> "clock" mean when the strobe signals arrive the device interfaces at
> different times? It's all relative... To something... Usually an
> explicit clock or strobe, but could be implicitly relative to the clock.

I'll add that to my list of Zen quotes ;) 

>
> ** tRAC is Randomc access latency. Which is basically tRCD + tCAS.
> Micron's data sheet on obsolete FPM and EDO parts are still available
> online at www.micron.com.
>
September 19, 2004 4:47:01 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Wed, 15 Sep 2004 08:14:07 +1000, Franc Zabkar wrote:

> On Mon, 13 Sep 2004 22:51:21 -0400, keith <krw@att.bizzzz> put finger
> to keyboard and composed:
>
>>On Tue, 14 Sep 2004 06:36:11 +1000, Franc Zabkar wrote:
>
>>> The scenario which was the basis of the old thread involved a single
>>> 14MHz crystal oscillator and a single clock generator IC. This would
>>> have made the chip's FSB/PCI clock outputs pseudo-synchronous, as
>>> defined by Asus. However, the IC manufacturer's datasheet made no such
>>> distinction and referred to it simply as async.
>>>
>>> IIRC, Keith claimed that he was in possession of two versions of the
>>> same Asus motherboard which used both clocking schemes, but when I
>>> challenged him to identify the respective clock chip(s) he was
>>> strangely silent. So the matter was never conclusively resolved.
>>
>>Yes, I found the evidence, and there were indeed different versions of
>>the SP97(?). I simply found it uninteresting to argue with someone who
>>was *so* wrong.
>
> You avoided several opportunities to present the "evidence" which you
> claimed was at your fingertips. Instead you chose to fabricate a
> preposterous lie because you were not man enough to admit that you
> were wrong.

I can't help it if you can't understand how wrong you are. The databases
have been purged, so I no longer have access to the original information.
It's only been five and a half years since I worked in x86.

>> BTW, the board I had in my drawer indeed did have only
>>one oscillator. ...so you were right there.
>
> Of course I was. The photographs on Asus's website were evidence enough.

The original SP97s were either pseudo-sync or async (now you have me
thinking), though async was more in the SiS style. ...and I wouldn't have
spent so much time on the SP97-V if it were pseudo-sync.


>> OTOH, I had the records from
>>*hundreds* of boards (from every manufacturer - including the SP97) that
>>said there were both.
>
> BS. IIRC, there were only two versions of the SP97, one with both SIMMs
> and DIMMs, the other with SIMMs only. Both used a single oscillator and
> clock generator.

Read the sentence again. I was talking about the "yndreds of boards"
here, not specifically the SP97. Slow down, kid.

>>The SiS chipsets could do either.
>
> At that time many users discovered that a combination of AMD K6 CPU and
> SiS5597/5598 chipset was unstable when using a pseudo-synchronous
> PCI/FSB clock in the ratio of 2:5. This problem was well documented in
> various forums.

I didn't use the K6 on that board. Since the K6 was only specified for a
66MHz bus, it's not surprising that it would be unstable in psuedo-sync
(75MHz) operation. The M2 was quite happy with the 5598 at 75MHz, though.

>> Via was indeed
>>pseudo-sync (non-integral synchronous) only.
>
> I doubt it. Show me the evidence.

Read the datasheets. Via coined the term, meanwhile SiS was busy doing
async.

--
Keith
September 19, 2004 4:54:29 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Fri, 17 Sep 2004 07:03:26 +1000, Franc Zabkar wrote:

> On Wed, 15 Sep 2004 19:42:31 -0400, George Macdonald
> <fammacd=!SPAM^nothanks@tellurian.com> put finger to keyboard and
> composed:
>
>>On Wed, 15 Sep 2004 08:14:07 +1000, Franc Zabkar <fzabkar@optussnet.com.au>
>>wrote:
>>
>>>On Mon, 13 Sep 2004 22:51:21 -0400, keith <krw@att.bizzzz> put finger
>>>to keyboard and composed:
>>
>>>>The SiS chipsets could do either.
>>>
>>>At that time many users discovered that a combination of AMD K6 CPU
>>>and SiS5597/5598 chipset was unstable when using a pseudo-synchronous
>>>PCI/FSB clock in the ratio of 2:5. This problem was well documented in
>>>various forums.
>>>
>>>> Via was indeed
>>>>pseudo-sync (non-integral synchronous) only.
>>>
>>>I doubt it. Show me the evidence.
>>
>>Anybody as interested as you should have the VIA data sheets.
>
> Unfortunately such internal documents are available only to a select
> few. Mere mortals don't qualify.

Ah, so you openly admit that you haven't a clue what you're talking about.
Before you ask, yes in a previous job I had datasheets to everyting that
was going into PCs (most marked &company. Confidential). You really
should talk like a god, if you're a lesser mortal.
>
>> Look up the
>>MVP3 chipset (598.pdf), specifically the VT82C598 North Bridge. It
>>supported FSB:p CI clock ratios of 2, 2.5 and 3 and that's err, all
>>folks. FWIW there were many mbrds which were scripted for 2.5 jumpering
>>but I never heard of one which actually implemented it - even when there
>>was a jumper, instead of a couple of spare pads, it did not actually
>>force a 2.5 ratio. AIR a look at the clock chips used showed that it
>>was just not supported - mbrd mfr cheaped out or possibly the the VIA
>>598 didn't actually work right that way.

On the contrary, there were many boards that supported 2.5x clocking (and
async PCI). Apparently the clock-gens were difficult to come by at
times though, since board manufacturers did slip in other clock chips
from time to time. We went through *every* socket-7 board (even though
some were identical, we had them all) looking for those that supported
75Mhz and 83MHz. Over-clocking the PCI bus (or anything else) was an
automatic failure, and wasn't listed as supporting that frequency.

>>If you don't have the .pdf and are umm, nice (for a change :-}) I'll
>>e-mail it to you.
>
> I'm always nice ... to nice people. But I detest liars and pompous
> blowhards.

You dislike yourself that much?
>
> Thanks for your offer of the .pdf file. I suspect the OP would
> appreciate a copy, too. I don't really need it myself, though, as I
> don't doubt your integrity, nor your knowledge. OTOH, I have proven
> Keith to be wrong on so many occasions, on even basic issues, that I'm
> loathe to accept anything he says without independent confirmation.

Ah, so you really don't care about the facts. Not that I ever suspected
anythign else.

> May I suggest you upload the VIA datasheet to your own webspace and post
> a link to same.

....a likely violation of copyright.

--
Keith
September 19, 2004 8:25:04 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Tue, 14 Sep 2004 22:18:03 -0700, Anon wrote:

> keith <krw@att.bizzzz> wrote in message news:<pan.2004.09.14.02.43.39.901503@att.bizzzz>...
>> On Sat, 11 Sep 2004 21:20:13 -0700, Anon wrote:
>>
>> > I believe that pseudo-sync is synchronized thus not asynchronized.
>>
>> You would be correct.
>>
>> > However, is pseudo-sync also called 'asynchronous mode'?
>>
>> No. Some manufacturers did an asynchronous chipset (eg. SiS). Via's were
>> pseudo-sync, which meant a non-integral, but synchronous multiplier
>> between the processor bus and the PCI bus.
>
> there are a number of sites that seem to refer to 1 clock chipsets as
> being able to run in 'asynchronous mode'

There are a lot of web sites out there that are wrong. Just because you
read it...

> http://www.hardwarepage.nl/viaapollomvp4.html and
> http://www6.tomshardware.com/motherboard/19980731/socke... "VIA's
> MVP3 chipset allows you to use a synchronous or asynchronous mode for
> your memory"
>
>
> If async means 2 clocks,

It means litterally, without clock. Practically it means an interface
that isn't clocked - crosses a clock domain that is not synchronized. Two
oscillators implies not-synchronized (a little more complicated, but...).


> and given the quote above - then maybe
> 'asynchronous mode' is different from 'real' async. If that were the
> case, then maybe 'async mode' is a pseudonym for pseudo-sync

I'd say that's a good analysis of the situation. Note that pseudo-sync
*is* really synchronous, with a non-integral relationship beteen the
domains. Syncronous interfaces (integral multipliers, or not) avoid many
pitfalls of asynchronous interfaces. Though there are many asynchronous
interfaces in a typical PC.

--
Keith
Anonymous
a b à CPUs
September 20, 2004 11:53:21 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

q_q_anonymous@yahoo.co.uk (Anon) wrote:

>I believe that pseudo-sync is synchronized thus not asynchronized.

Why don't you cross-post to a few more groups, you idiot?
September 20, 2004 5:47:24 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

chrisv <chrisv@nospam.invalid> wrote in message news:<nlktk011c2puu1uso0ulo8vlb9qnj0ar5r@4ax.com>...
> q_q_anonymous@yahoo.co.uk (Anon) wrote:
>
> >I believe that pseudo-sync is synchronized thus not asynchronized.
>
> Why don't you cross-post to a few more groups, you idiot?

All those newsgroups were relevant. If I'd have wanted a bunch of
arrogant bastards replying to my post then I would have posted to a
newsgroup for arrogant bastards, such as comp.os.linux.advocacy a
newsgroup which you love so much.

It was extremely amusing reading the number of times you call people
'idiot' in the elitist newsgroups that you visit like
rec.music.classical and comp.os.linux.advocacy. Actually, it's
probably very unfair to label those newsgroups elitist. Perhaps there
are just small cells of elitists that make all the decent folk look
bad. Or maybe you're all alone in your little elitist cell!
Anonymous
a b à CPUs
September 20, 2004 11:07:30 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Sun, 19 Sep 2004 12:47:01 -0400, keith <krw@att.bizzzz> put finger
to keyboard and composed:

>On Wed, 15 Sep 2004 08:14:07 +1000, Franc Zabkar wrote:
>
>> On Mon, 13 Sep 2004 22:51:21 -0400, keith <krw@att.bizzzz> put finger
>> to keyboard and composed:
>>
>>>On Tue, 14 Sep 2004 06:36:11 +1000, Franc Zabkar wrote:
>>
>>>> The scenario which was the basis of the old thread involved a single
>>>> 14MHz crystal oscillator and a single clock generator IC. This would
>>>> have made the chip's FSB/PCI clock outputs pseudo-synchronous, as
>>>> defined by Asus. However, the IC manufacturer's datasheet made no such
>>>> distinction and referred to it simply as async.
>>>>
>>>> IIRC, Keith claimed that he was in possession of two versions of the
>>>> same Asus motherboard which used both clocking schemes, but when I
>>>> challenged him to identify the respective clock chip(s) he was
>>>> strangely silent. So the matter was never conclusively resolved.
>>>
>>>Yes, I found the evidence, and there were indeed different versions of
>>>the SP97(?). I simply found it uninteresting to argue with someone who
>>>was *so* wrong.
>>
>> You avoided several opportunities to present the "evidence" which you
>> claimed was at your fingertips. Instead you chose to fabricate a
>> preposterous lie because you were not man enough to admit that you
>> were wrong.
>
>I can't help it if you can't understand how wrong you are. The databases
>have been purged, so I no longer have access to the original information.
>It's only been five and a half years since I worked in x86.

I could care less about your mythical databases or other pathetic
attempts at obfuscation. You had *several* opportunities to present
the evidence that you claimed was in your hands. All you had to do was
to identify the part number(s) of the clock chip(s). The fact that you
avoided doing so speaks volumes for your character, or lack thereof.


- Franc Zabkar
--
Please remove one 's' from my address when replying by email.
Anonymous
a b à CPUs
September 21, 2004 1:27:58 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On 20 Sep 2004 13:47:24 -0700, q_q_anonymous@yahoo.co.uk
(Anon) wrote:


>> Why don't you cross-post to a few more groups, you idiot?
>
>All those newsgroups were relevant. If I'd have wanted a bunch of
>arrogant bastards replying to my post then I would have posted to a
>newsgroup for arrogant bastards, such as comp.os.linux.advocacy a
>newsgroup which you love so much.
>

Yeah, but it's not really appropriate to post to ALL
"potentially" relevant newsgroups either, since there is a
lot of overlap that would result in many, many groups
getting swamped with posts. Try one or two MOST APPROPRIATE
groups.

Now onto the main issue, why do you post this?
Is there a specific problem or do you expect the entire
world to stop what they're doing and educate you instead of
bothering to use a search engine?
September 21, 2004 5:25:17 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

kony <spam@spam.com> wrote in message news:<6fiuk0tm701tba2fj0o1av7t42hg826f2u@4ax.com>...
> On 20 Sep 2004 13:47:24 -0700, q_q_anonymous@yahoo.co.uk
> (Anon) wrote:
>
>
> >> Why don't you cross-post to a few more groups, you idiot?
> >
> >All those newsgroups were relevant. If I'd have wanted a bunch of
> >arrogant bastards replying to my post then I would have posted to a
> >newsgroup for arrogant bastards, such as comp.os.linux.advocacy a
> >newsgroup which you love so much.
> >
>
> Yeah, but it's not really appropriate to post to ALL
> "potentially" relevant newsgroups either, since there is a
> lot of overlap that would result in many, many groups
> getting swamped with posts. Try one or two MOST APPROPRIATE
> groups.
>
> Now onto the main issue, why do you post this?
> Is there a specific problem or do you expect the entire
> world to stop what they're doing and educate you instead of
> bothering to use a search engine?

I did use a search engine - the great google, and the results that
seemed most appropriate were those of toms hardware. Which were very
unhelpful. Did you know some people are actually happy to have
information archived to help many others?

If it were just for education, it would not just be for my education,
but for the rest of the world since google archives everything. Plus,
since it archives everything and there was nothing explaining the term
'asynchronous mode', on usenet or the web, that I could find, I feel
that WE are all doing a great service to the world, moreso those gerat
people like keith frank george and dave M and dave W that respond with
answers or questions or debate on the topic (not you kony of course).
Infact, if you look at archives and study my post. You will see that I
spent a lot of time going through earlier posts which included reading
posts from people that performed the same crime as me, posting a
question on usenet. Those questions and the responses were extremely
helpful and benefit people till the end of time. Infact some of the
posters that posted a similar question in earlier years did not
research previous answers as much as I did. Their crime was and is
helping future posters. And my crime is theirs.
I even referenced those posts in my first post. Since I am not asking
the question just to serve my own purposes, but to help others that
are interested in years to come. Infact, I even summarised the
opinions of keith and frank from a long previous thread. I have made a
great effort to be extremely helpful to people who want to know what
the term means. I invested a lot of time researching previous posts,
referencing them, summarising the opinions of authors writing in other
long threads that were hard to follow since the authors assigned
different meaning to their terminology and realised/cleared it up at
the end. And this thread actually answers that 'asynchronous mode'
question completely, and shows that Toms Hardware was extremely
unclear and misleading in its implications.

It is YOU that has not done his research. Had you bothered to read my
original post, you would have seen that I had done a lot of research
and made great efforts (as mentioned above) so that my post would help
others in the future.

How could I have researched for writing my post, summarised opinions
from previous posts, without a search engine? Without making thorough
use of a search engine?
How can you be so stupid as to think I didn't bother to use a search
engine???

How does my crime compare with the crime of earlier posters that
posted questions about pseudo-sync which were very helpful to me and
others?

Why do you think I summarised the research that I had done from
previous threads, even though that research contained no questions?
That's a hard question for you to answer, since you don't read posts,
but the answer is written in this post. I'll give you a hint
hint: that huge chunk of my post is archived to help others.

I wonder why you don't always notice when soembody is helping others
or using search engines. Even when it's blatantly obvious. Perhaps
it's because these qualities are alien to you.
Anonymous
a b à CPUs
September 21, 2004 12:14:56 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

q_q_anonymous@yahoo.co.uk (Anon) wrote:

>chrisv <chrisv@nospam.invalid> wrote in message news:<nlktk011c2puu1uso0ulo8vlb9qnj0ar5r@4ax.com>...
>> q_q_anonymous@yahoo.co.uk (Anon) wrote:
>>
>> >I believe that pseudo-sync is synchronized thus not asynchronized.
>>
>> Why don't you cross-post to a few more groups, you idiot?
>
>All those newsgroups were relevant. If I'd have wanted a bunch of
>arrogant bastards replying to my post then I would have posted to a
>newsgroup for arrogant bastards, such as comp.os.linux.advocacy a
>newsgroup which you love so much.
>
>It was extremely amusing reading the number of times you call people
>'idiot' in the elitist newsgroups that you visit like
>rec.music.classical and comp.os.linux.advocacy. Actually, it's
>probably very unfair to label those newsgroups elitist. Perhaps there
>are just small cells of elitists that make all the decent folk look
>bad. Or maybe you're all alone in your little elitist cell!

Heh. I always get a kick out of you weirdos who, when offended,
immediately run-off to google to try to dig-up some "dirt" on the
other person. In this case, you discovered that I also post in the
linux advocacy group (which you claim is evidence of my being an
"elitist"). Wow, I am so ashamed of the fact that I post in the linux
advocacy group, and that I've used the word "idiot" to describe the
many trolls that frequent that group. Not.

It's difficult to not feel superior when surrounded by idiots like
you. 8)
Anonymous
a b à CPUs
September 21, 2004 5:21:11 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On 21 Sep 2004 01:25:17 -0700, q_q_anonymous@yahoo.co.uk
(Anon) wrote:

<snip>

> Perhaps
>it's because these qualities are alien to you.

.... or perhaps you go off on a tangent and just assume it's
a noble cause, ingoring that the end does not always justify
the means.
Anonymous
a b à CPUs
September 22, 2004 3:09:06 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

keith wrote:

> On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard wrote:
>
>

<snip of B.S.>

>>Yes, and we might as well let Crucial-Micron sum it up.
>>
>>http://www.crucial.com/library/sfiles2.asp
>>
>>"Both FPM and EDO are said to be asynchronous. In other words, the
>>memory and the system clock are not synchronized."
>
>
> Bullshit! The memory *is* synchronous to the processor clock. The chipset
> makes it so.
>

Go argue with Crucial-Micron.
September 23, 2004 3:25:25 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Tue, 21 Sep 2004 23:09:06 -0500, David Maynard wrote:

> keith wrote:
>
>> On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard wrote:
>>
>>
>
> <snip of B.S.>
>
>>>Yes, and we might as well let Crucial-Micron sum it up.
>>>
>>>http://www.crucial.com/library/sfiles2.asp
>>>
>>>"Both FPM and EDO are said to be asynchronous. In other words, the
>>>memory and the system clock are not synchronized."
>>
>>
>> Bullshit! The memory *is* synchronous to the processor clock. The chipset
>> makes it so.
>>
>
> Go argue with Crucial-Micron.

David, asnwer one question: Are you an engineer? Ok, two, have you ever
designed a computer system or any such animal? If you can honestly answer
'yes' to both questions, you have just earned the awart for being obteuse.
If not, let's just say you haven't a clue what you're talking about. You
*are* wrong, in any of the four quadrants. Ok, let's just say you're
hopelessly tangled up in terminology (and ego). It isn't all that
difficult, and it has been explained to you several times now.

--
Keith
Anonymous
a b à CPUs
September 23, 2004 3:25:26 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

keith wrote:

> On Tue, 21 Sep 2004 23:09:06 -0500, David Maynard wrote:
>
>
>>keith wrote:
>>
>>
>>>On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard wrote:
>>>
>>>
>>
>><snip of B.S.>
>>
>>>>Yes, and we might as well let Crucial-Micron sum it up.
>>>>
>>>>http://www.crucial.com/library/sfiles2.asp
>>>>
>>>>"Both FPM and EDO are said to be asynchronous. In other words, the
>>>>memory and the system clock are not synchronized."
>>>
>>>
>>>Bullshit! The memory *is* synchronous to the processor clock. The chipset
>>>makes it so.
>>>
>>
>>Go argue with Crucial-Micron.
>
>
> David, asnwer one question: Are you an engineer? Ok, two, have you ever
> designed a computer system or any such animal? If you can honestly answer
> 'yes' to both questions, you have just earned the awart for being obteuse.
> If not, let's just say you haven't a clue what you're talking about. You
> *are* wrong, in any of the four quadrants. Ok, let's just say you're
> hopelessly tangled up in terminology (and ego). It isn't all that
> difficult, and it has been explained to you several times now.
>

As I already said, go argue with Crucial-Micron. Maybe they'll enjoy the
chest pounding.
Anonymous
a b à CPUs
September 23, 2004 9:01:22 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:
> David Wang wrote:

> > Nothing is truly "asynchronous" in this context. The DRAM is considered
> > "asynchronous" because it did not explicitly move from one state to
> > another state in response to s clock input, rather, it changed states
> > relative to the timing of some control signals, but those control
> > signals were generated by a DRAM controller, which is itself
> > "synchronous" and operated on a base clock frequency.

> The confusion comes from it being 'converted', if you will, from
> asynchronous, at the RAM, to synchronous by the chipset.

The real problem is that the word "asynchronous" has real meanings
to EE's. There are research into asynchronous processors and RAM,
and those need explicit handshakes to move data around. FPM/EDO
does not come close to fitting in the definition there. You should
perhaps call it something else other than "asynchronous".

> > since the DRAM manufacturers were actually pipelining and
> > spitting out data on xEDO parts just as they were on SDRAM parts.

> Yes, except that FPM/EDO is simply holding the Row Address so the chipset
> 'can' do subsequent reads without that delay, if the data is in that range.
> The chipset 'can', then, do multiple reads, setting the column address, as
> in a 'stream' but it is not required to (by the RAM) nor are the column
> addresses required to be in any particular order (beyond the dictates of
> practicality). Of course, doing a stream 'makes sense' but the async RAM
> doesn't care; it's a function of the chipset design.

> With SDRAM, however, the stream (burst mode) is inherent to the RAM itself,
> not just good sense, with each subsequent data set in the stream implicit
> and internally incremented (synchronous with the clock) by the SDRAM.

You're going to lose this angle if you're hanging the differentiation
of "asynchronous" FPM/EDO vs "synchronous" SDRAM. What you're looking
at is the difference in feature list. SDRAM contains a superset of
features, and you can design it to

"holding the Row Address so the chipset 'can' do subsequent reads
without that delay, if the data is in that range. The chipset 'can',
then, do multiple reads, setting the column address, as in a 'stream'
but it is not required to (by the RAM) nor are the column addresses
required to be in any particular order (beyond the dictates of
practicality"

For a given address, SDRAM has different programmability, and it can
give you burst in lengths of 1, 2, 4, or 8 beats of data. You can
pipeline multiple accesses and get 1 beat of data each. In that case,
the SDRAM is just holding the row access so the chipset can do
subsequent reads without delay to the same open row. The SDRAM device
does not care if you give it a new address every cycle. It will give
you data in any address order you choose to give it, just like FPM/EDO.

You can also pipeline EDO, and PB EDO (which is still hopefully
"asynchronous" by your definition) also bursts out data in 4 consective
beats. The stream is "inherant" to the DRAM device, and there's no
need of a "clock" signal here. The PB EDO device internally wraps around
the 2 least significant address bits and gives the data to you in bursts
of 4 beats, in consective "cycles". The "bursting" nature is a feature
list, not anything you can use to support the asynchronous/synchronous
argument.

> The more significant difference, in the context of async vs sync, is that
> SDRAM does not look to the edges of multiple 'strobe' signals for timing.
> All timing comes from the clock edges. e.g. addresses are not latched, I.E.
> 'clocked', by CAS and RAS, as with async RAM, they're latched on clock
> edges. All timing comes directly from the clock (which does not even exist
> on the async RAM bus) and therein lies the 'synchronous' nature of it.

This is a poor definition because DDRx SDRAM, Direct RDRAM and SLDRAM
look to multiple clock/strobe signal references for timing. Different
parts of the DRAM devices do different things in response to the
different clock/strobes. It's rather interesting how Direct RDRAM's
clock-from-master and clock-to-master scheme works, and each part of
the same chip can actually be in two different timing domains. Perhaps
Direct RDRAM may be considered as "synchronous interface" and
"asynchronous internally". :) 

Then there's SLDRAM. Three sets of clock/strobes IIRC. What would that
be? Tri-synchronous?



--
davewang202(at)yahoo(dot)com
Anonymous
a b à CPUs
September 23, 2004 9:01:23 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

David Wang wrote:

> In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:
>
>>David Wang wrote:
>
>
>>>Nothing is truly "asynchronous" in this context. The DRAM is considered
>>>"asynchronous" because it did not explicitly move from one state to
>>>another state in response to s clock input, rather, it changed states
>>>relative to the timing of some control signals, but those control
>>>signals were generated by a DRAM controller, which is itself
>>>"synchronous" and operated on a base clock frequency.
>
>
>>The confusion comes from it being 'converted', if you will, from
>>asynchronous, at the RAM, to synchronous by the chipset.
>
>
> The real problem is that the word "asynchronous" has real meanings
> to EE's. There are research into asynchronous processors and RAM,
> and those need explicit handshakes to move data around. FPM/EDO
> does not come close to fitting in the definition there. You should
> perhaps call it something else other than "asynchronous".
>
>
>>>since the DRAM manufacturers were actually pipelining and
>>>spitting out data on xEDO parts just as they were on SDRAM parts.
>
>
>>Yes, except that FPM/EDO is simply holding the Row Address so the chipset
>>'can' do subsequent reads without that delay, if the data is in that range.
>>The chipset 'can', then, do multiple reads, setting the column address, as
>>in a 'stream' but it is not required to (by the RAM) nor are the column
>>addresses required to be in any particular order (beyond the dictates of
>>practicality). Of course, doing a stream 'makes sense' but the async RAM
>>doesn't care; it's a function of the chipset design.
>
>
>>With SDRAM, however, the stream (burst mode) is inherent to the RAM itself,
>>not just good sense, with each subsequent data set in the stream implicit
>>and internally incremented (synchronous with the clock) by the SDRAM.
>
>
> You're going to lose this angle if you're hanging the differentiation
> of "asynchronous" FPM/EDO vs "synchronous" SDRAM. What you're looking
> at is the difference in feature list. SDRAM contains a superset of
> features, and you can design it to
>
> "holding the Row Address so the chipset 'can' do subsequent reads
> without that delay, if the data is in that range. The chipset 'can',
> then, do multiple reads, setting the column address, as in a 'stream'
> but it is not required to (by the RAM) nor are the column addresses
> required to be in any particular order (beyond the dictates of
> practicality"
>
> For a given address, SDRAM has different programmability, and it can
> give you burst in lengths of 1, 2, 4, or 8 beats of data. You can
> pipeline multiple accesses and get 1 beat of data each. In that case,
> the SDRAM is just holding the row access so the chipset can do
> subsequent reads without delay to the same open row. The SDRAM device
> does not care if you give it a new address every cycle. It will give
> you data in any address order you choose to give it, just like FPM/EDO.
>
> You can also pipeline EDO, and PB EDO (which is still hopefully
> "asynchronous" by your definition) also bursts out data in 4 consective
> beats. The stream is "inherant" to the DRAM device, and there's no
> need of a "clock" signal here. The PB EDO device internally wraps around
> the 2 least significant address bits and gives the data to you in bursts
> of 4 beats, in consective "cycles". The "bursting" nature is a feature
> list, not anything you can use to support the asynchronous/synchronous
> argument.
>
>
>>The more significant difference, in the context of async vs sync, is that
>>SDRAM does not look to the edges of multiple 'strobe' signals for timing.
>>All timing comes from the clock edges. e.g. addresses are not latched, I.E.
>>'clocked', by CAS and RAS, as with async RAM, they're latched on clock
>>edges. All timing comes directly from the clock (which does not even exist
>>on the async RAM bus) and therein lies the 'synchronous' nature of it.
>
>
> This is a poor definition because DDRx SDRAM, Direct RDRAM and SLDRAM
> look to multiple clock/strobe signal references for timing. Different
> parts of the DRAM devices do different things in response to the
> different clock/strobes. It's rather interesting how Direct RDRAM's
> clock-from-master and clock-to-master scheme works, and each part of
> the same chip can actually be in two different timing domains. Perhaps
> Direct RDRAM may be considered as "synchronous interface" and
> "asynchronous internally". :) 
>
> Then there's SLDRAM. Three sets of clock/strobes IIRC. What would that
> be? Tri-synchronous?

http://www.ece.neu.edu/students/dmorano/talks/nucar9905...
Anonymous
a b à CPUs
September 23, 2004 7:16:58 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard <dNOTmayn@ev1.net> wrote:

>George Macdonald wrote:
>> "Irrelevant .... as long as" That's a good one.:-[]
>
>And accurate. Obviously the controller must operate properly with the RAM
>it 'supports' (the "as long as" part) but the 'nature' of the RAM is not
>'dependent' on the memory controller (the "irrelevant" part) or else we'd
>have RAM sticks spontaneously changing their 'type' every time someone
>creatively engineered a new memory solution.
>
>I.E. "What kind of RAM is that stick? Gee, I dunno. Yesterday it was async
>but Bob over there is designing a new memory controller so..."
>
>> Nearly as good as you
>> trying to argue with Dave Wang... utterly oblivious!
>
>You apparently didn't understand that conversation either.

That's rich! Coming from someone who, a coupla days ago, was telling us
that the 60ns full random access cycle time for FPM/EDO DRAM was comparable
to a 10ns tick on the SDRAM interface. No - SDRAM is not 6 times faster
than EDO DRAM. Got it.....yet.:-[]

I *do* understand that you claim to have err, "mispoke".<titter>

>>>SDRAM will simply not function without the proper clock, that is wholly non
>>>existent with async FPM/EDO RAM, and you better be in SOME form of
>>>synchrony with that clock or you aren't going to be able to send commands,
>>>read data, or anything else.
>>
>>
>> That clock runs the I/O interface of the SDRAM
>
>And everything inside.

Nope. You simply don't have a clue how it works. In SDRAM the memory
array is not clocked off the external clock; the sense amp charge/precharge
is not clocked off it either - it's still an asynchronous device at that
level. The real need for the I/O clock is to synchronize the latching of
the various I/O signals which can be slightly skewed wrt each other... to
provide an "event", the clock transition, so that any given combination can
be recognized as a "command".

>> - uhh, that's what it's for.
>
>And why it's called synchronous.

Yes the I/O interface is synchronous.

>> The clock has been basically moved from the FSB+memory controller to
>> multiple clocks on the modules and ultimately to the chip interfaces.
>
>It doesn't exist on FPM/EDO memory busses because they're asynchronous.
>There's no place for it to go and nothing for it to 'synchronize'.

It exists at the level of the memory controller - uhh, it got moved... and
multiplied... to usually 12 or 16 clocks depending on the number of DIMM
slots. In fact if Micron had had their way it would have stayed the same
for BEDO (Burst EDO)... which would have had approximately the same
performance as SDRAM... err, thank you RAMBUS.:-(

>>>>is irrelevant to the fact that, in any system
>>>>implementation, it effectively operates in lock step with the memory
>>>>controller clock.
>>>
>>>The memory controller operates from a clock for it's own reasons but there
>>>is no 'clock' going to FPM/EDO RAM for them to be in 'synchrony' with. They
>>>operate asynchronously.
>>
>>
>> I never said there was a clock to the chips.
>
>I didn't say you did. I'm pointing it out to help you understand it.

<snigger>

>> Why do you insist on stating
>> the obvious?
>
>Because you keep having problems understanding it.

<guffaw> Is that also why you keep splitting text to alter context too?...
an old Usenet trick that!... seen it before.:-)

>> The memory has to be
>> capable of working in concert with it.
>
>No, the memory controller has to be able to operate the RAM type it
>'supports' but I can use the RAM in anything I like. It is a device with
>it's own specifications and doesn't 'depend' on the memory controller for
>it's 'nature', or what 'type' it is. I could interface FPM/EDO to a simple
>microprocessor that has no 'memory controller' at all, or use it in
>something that's not even a 'computer'.

No memory controller eh? What would you call the circuitry on your
non-"computer" which generates RAS and CAS strobes and row and column
addresses and has data transceivers? Do tell!

The "specifications" of the RAM are derived from a desire to keep up with a
clock, in this case the FSB clock. To imply that RAM was designed in a
vacuum, independently of system & memory controller needs, is sheer heresy.

>> As usual you have started from a position of ignorance and folksy
>> self-invented ideas. Then you have set out to defend this madness by
>> reading data sheets and fitting their facts into your weird framework. You
>> could have the honesty to acknowledge where you were wrong, instead of
>> which you make statements which are elementary knowledge of DRAM operation
>> as though it somehow elevates your position. I've had enough of this.
>
>All you're doing is making a fool of yourself by thinking the throwing of
>insults constitutes a technical case.

It's the only explanation for your obstinate refusal to see the facts as
they are.

>> If you feel that TomsHardware enriches your pool of knowledge, that's your
>> problem. I think we're done here!
>
>Yes, and we might as well let Crucial-Micron sum it up.
>
>http://www.crucial.com/library/sfiles2.asp
>
>"Both FPM and EDO are said to be asynchronous. In other words, the memory
>and the system clock are not synchronized."

No argument - they are asynch devices. They operate in a PC system off the
FSB clocking of the memory controller. At that level, everything in a
computer could be considered an asynch device which just has to respond
within a defined clock tick framework.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 23, 2004 8:14:38 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:

> http://www.ece.neu.edu/students/dmorano/talks/nucar9905...

Mr Morano's presentations do not address the points I had raised
about your definitions.

Burst capability != synchronous.

DDRx SDRAM/D RDRAM/SLDRAM use multiple clock/strobe signals for
synchronization.


--
davewang202(at)yahoo(dot)com
Anonymous
a b à CPUs
September 23, 2004 8:14:39 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

David Wang wrote:
> In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>http://www.ece.neu.edu/students/dmorano/talks/nucar9905...
>
>
> Mr Morano's presentations do not address the points I had raised
> about your definitions.

It addresses *the* point: EDO/FPM asynchronous memory.

> Burst capability != synchronous.

I didn't mean to suggest it did and sorry if you got that impression.

> DDRx SDRAM/D RDRAM/SLDRAM use multiple clock/strobe signals for
> synchronization.

The key word is "clock."
Anonymous
a b à CPUs
September 23, 2004 10:42:08 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:

> On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>

<snip of wasted 'titters', word games, and assorted chest thumpings>

>>
>>Yes, and we might as well let Crucial-Micron sum it up.
>>
>>http://www.crucial.com/library/sfiles2.asp
>>
>>"Both FPM and EDO are said to be asynchronous. In other words, the memory
>>and the system clock are not synchronized."
>
>
> No argument - they are asynch devices.

I'm glad we finally got that part straightened out.

> They operate in a PC system off the
> FSB clocking of the memory controller. At that level, everything in a
> computer could be considered an asynch device which just has to respond
> within a defined clock tick framework.

Not quite. When there is a common bus clock that the devices are
synchronized to then they're on a synchronous bus. But an EDO/FPM memory
bus has no common clock and is a classic asynchronous memory bus.

http://www.ece.neu.edu/students/dmorano/talks/nucar9905...


>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 26, 2004 12:29:45 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Thu, 23 Sep 2004 18:42:08 -0500, David Maynard <dNOTmayn@ev1.net> wrote:

>George Macdonald wrote:
>
>> On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>
>
><snip of wasted 'titters', word games, and assorted chest thumpings>

Sorry but your pants are down!

>>>
>>>Yes, and we might as well let Crucial-Micron sum it up.
>>>
>>>http://www.crucial.com/library/sfiles2.asp
>>>
>>>"Both FPM and EDO are said to be asynchronous. In other words, the memory
>>>and the system clock are not synchronized."
>>
>>
>> No argument - they are asynch devices.
>
>I'm glad we finally got that part straightened out.

I have never argued that point. I believe I've made my point clearly
enough already - the horse is dead!

>> They operate in a PC system off the
>> FSB clocking of the memory controller. At that level, everything in a
>> computer could be considered an asynch device which just has to respond
>> within a defined clock tick framework.
>
>Not quite. When there is a common bus clock that the devices are
>synchronized to then they're on a synchronous bus. But an EDO/FPM memory
>bus has no common clock and is a classic asynchronous memory bus.
>
>http://www.ece.neu.edu/students/dmorano/talks/nucar9905...

Says nothing of the sort... re: your ability to adapt the facts to your
distorted view.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Anonymous
a b à CPUs
September 26, 2004 9:04:27 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:
> On Thu, 23 Sep 2004 18:42:08 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>George Macdonald wrote:
>>
>>
>>>On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>
>><snip of wasted 'titters', word games, and assorted chest thumpings>
>
>
> Sorry but your pants are down!
>
>
>>>>Yes, and we might as well let Crucial-Micron sum it up.
>>>>
>>>>http://www.crucial.com/library/sfiles2.asp
>>>>
>>>>"Both FPM and EDO are said to be asynchronous. In other words, the memory
>>>>and the system clock are not synchronized."
>>>
>>>
>>>No argument - they are asynch devices.
>>
>>I'm glad we finally got that part straightened out.
>
>
> I have never argued that point. I believe I've made my point clearly
> enough already - the horse is dead!
>
>
>>> They operate in a PC system off the
>>>FSB clocking of the memory controller. At that level, everything in a
>>>computer could be considered an asynch device which just has to respond
>>>within a defined clock tick framework.
>>
>>Not quite. When there is a common bus clock that the devices are
>>synchronized to then they're on a synchronous bus. But an EDO/FPM memory
>>bus has no common clock and is a classic asynchronous memory bus.
>>
>>http://www.ece.neu.edu/students/dmorano/talks/nucar9905...
>
>
> Says nothing of the sort... re: your ability to adapt the facts to your
> distorted view.
>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Since your replies have degenerated to gibberish I take it you've finally
realized that FPM/EDO memory, and the bus it's on, is asynchronous.

Which does, indeed, make it a dead horse.
September 27, 2004 2:58:11 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Wed, 22 Sep 2004 22:14:01 -0500, David Maynard wrote:

> keith wrote:
>
>> On Tue, 21 Sep 2004 23:09:06 -0500, David Maynard wrote:
>>
>>
>>>keith wrote:
>>>
>>>
>>>>On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard wrote:
>>>>
>>>>
>>>
>>><snip of B.S.>
>>>
>>>>>Yes, and we might as well let Crucial-Micron sum it up.
>>>>>
>>>>>http://www.crucial.com/library/sfiles2.asp
>>>>>
>>>>>"Both FPM and EDO are said to be asynchronous. In other words, the
>>>>>memory and the system clock are not synchronized."
>>>>
>>>>
>>>>Bullshit! The memory *is* synchronous to the processor clock. The chipset
>>>>makes it so.
>>>>
>>>
>>>Go argue with Crucial-Micron.
>>
>>
>> David, asnwer one question: Are you an engineer? Ok, two, have you ever
>> designed a computer system or any such animal? If you can honestly answer
>> 'yes' to both questions, you have just earned the awart for being obteuse.
>> If not, let's just say you haven't a clue what you're talking about. You
>> *are* wrong, in any of the four quadrants. Ok, let's just say you're
>> hopelessly tangled up in terminology (and ego). It isn't all that
>> difficult, and it has been explained to you several times now.
>>
>
> As I already said, go argue with Crucial-Micron. Maybe they'll enjoy the
> chest pounding.

You really are stupid, eh? Perhpas you'd like to slide around some more,
since your butt's been turned to lard by *many* enngineers in the industry.

--
Keith
September 27, 2004 3:03:34 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard wrote:

> George Macdonald wrote:
>> On Thu, 23 Sep 2004 18:42:08 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>
>>
>>>George Macdonald wrote:
>>>
>>>
>>>>On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>>
>>>
>>><snip of wasted 'titters', word games, and assorted chest thumpings>
>>
>>
>> Sorry but your pants are down!
>>
>>
>>>>>Yes, and we might as well let Crucial-Micron sum it up.
>>>>>
>>>>>http://www.crucial.com/library/sfiles2.asp
>>>>>
>>>>>"Both FPM and EDO are said to be asynchronous. In other words, the memory
>>>>>and the system clock are not synchronized."
>>>>
>>>>
>>>>No argument - they are asynch devices.
>>>
>>>I'm glad we finally got that part straightened out.
>>
>>
>> I have never argued that point. I believe I've made my point clearly
>> enough already - the horse is dead!
>>
>>
>>>> They operate in a PC system off the
>>>>FSB clocking of the memory controller. At that level, everything in a
>>>>computer could be considered an asynch device which just has to respond
>>>>within a defined clock tick framework.
>>>
>>>Not quite. When there is a common bus clock that the devices are
>>>synchronized to then they're on a synchronous bus. But an EDO/FPM memory
>>>bus has no common clock and is a classic asynchronous memory bus.
>>>
>>>http://www.ece.neu.edu/students/dmorano/talks/nucar9905...
>>
>>
>> Says nothing of the sort... re: your ability to adapt the facts to your
>> distorted view.
>>
>> Rgds, George Macdonald
>>
>> "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
>
> Since your replies have degenerated to gibberish I take it you've finally
> realized that FPM/EDO memory, and the bus it's on, is asynchronous.

Fool! The memory system is *SYNCHRONOUS* on all PCs. Hell, the *wire*
between any two points is "asynchronous", but that doesn't help the
understanding of how the system works!

In the case *HERE* there is a difference between synchronous chipsets and
*asynchronous* chipsets, and it has *ZERO* to do with the type of memory
attached. You can now slither further...
>
> Which does, indeed, make it a dead horse.

Your donky is dog food. ..has been for weeks.

--
Keith
Anonymous
a b à CPUs
September 27, 2004 3:11:59 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

keith wrote:

> On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard wrote:
>
>
>>George Macdonald wrote:
>>
>>>On Thu, 23 Sep 2004 18:42:08 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>>
>>>
>>>>George Macdonald wrote:
>>>>
>>>>
>>>>
>>>>>On Tue, 21 Sep 2004 19:46:35 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>>>
>>>>
>>>><snip of wasted 'titters', word games, and assorted chest thumpings>
>>>
>>>
>>>Sorry but your pants are down!
>>>
>>>
>>>
>>>>>>Yes, and we might as well let Crucial-Micron sum it up.
>>>>>>
>>>>>>http://www.crucial.com/library/sfiles2.asp
>>>>>>
>>>>>>"Both FPM and EDO are said to be asynchronous. In other words, the memory
>>>>>>and the system clock are not synchronized."
>>>>>
>>>>>
>>>>>No argument - they are asynch devices.
>>>>
>>>>I'm glad we finally got that part straightened out.
>>>
>>>
>>>I have never argued that point. I believe I've made my point clearly
>>>enough already - the horse is dead!
>>>
>>>
>>>
>>>>>They operate in a PC system off the
>>>>>FSB clocking of the memory controller. At that level, everything in a
>>>>>computer could be considered an asynch device which just has to respond
>>>>>within a defined clock tick framework.
>>>>
>>>>Not quite. When there is a common bus clock that the devices are
>>>>synchronized to then they're on a synchronous bus. But an EDO/FPM memory
>>>>bus has no common clock and is a classic asynchronous memory bus.
>>>>
>>>>http://www.ece.neu.edu/students/dmorano/talks/nucar9905...
>>>
>>>
>>>Says nothing of the sort... re: your ability to adapt the facts to your
>>>distorted view.
>>>
>>>Rgds, George Macdonald
>>>
>>>"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
>>
>>Since your replies have degenerated to gibberish I take it you've finally
>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>
>
> Fool! The memory system is *SYNCHRONOUS* on all PCs.

No, it's not (if it's FPM/EDO, or any other asynchronous RAM), and thank
you for demonstrating how some people can't see straight even when a
tutorial is placed right in front of them, as in the above link explaining
asynchronous FPM/EDO and the corresponding asynchronous memory bus they
operate on.

As pointed out earlier, it is intuitively obvious that all timing must
operate so that the signals communicate properly (a condition you seem to
think automatically means 'synchronous'). That is not, however, the digital
electronics world definition of 'synchronous'. Synchronous is a specific
means for accomplishing that timing, which is by means of a common clock.

Asynchronous accomplishes it without the benefit of a common clock, as in
the asynchronous memory bus in the above pdf link.

I'll put it simple for you: no common clock; no synchronous (regardless of
how wonderful or tightly timed you may think things are)

> Hell, the *wire*
> between any two points is "asynchronous", but that doesn't help the
> understanding of how the system works!
>
> In the case *HERE* there is a difference between synchronous chipsets and
> *asynchronous* chipsets, and it has *ZERO* to do with the type of memory
> attached. You can now slither further...

You are apparently confused between busses operating asynchronously, or
synchronously, with respect to each other vs a bus that is, of itself, an
asynchronous, or synchronous, bus.

There is, however, a common characteristic of the two: a common clock.
!