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

[ANON]

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=76b91b820399d27c78b4ccdd5528cb7a&show
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
(FSBRAM 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.

 

[keith]

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

 

[Guest]

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.

 

[keith]

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.

 

[ANON]

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/socket7-02.html
"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

 

[ANON]

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/socket7-02.html
"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

 

[Guest]

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/socket7-02.html
> "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.

 

[ANON]

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/socket7-02.html
> > "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!

 

[Guest]

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.

 

[Guest]

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/socket7-02.html
>>>"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.

 

[Guest]

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 FSBCI 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??

 

[Guest]

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/socket7-02.html
>"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 FSBCI
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??

 

[Guest]

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/socket7-02.html
>>"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 FSBCI
> 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??

 

[Guest]

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.

 

[Guest]

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/socket7-02.html
>>>"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 FSBCI
>> 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 FSBCI 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??

 

[Guest]

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/socket7-02.html
>>>>"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 FSBCI
>>>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 FSBCI 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??

 

[Guest]

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 FSBCI 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

 

[Guest]

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 FSBCI 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.

 

[Guest]

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.

 

[Guest]

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??

 

[Guest]

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/socket7-02.html
>>>>>"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 FSBCI
>>>>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 FSBCI 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 FSBCI 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 FSBCI 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??

 

[Guest]

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/socket7-02.html
>>>>>>"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 FSBCI
>>>>>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 FSBCI 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 FSBCI 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 FSBCI 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??

 

[Guest]

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.

 

[Guest]

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 FSBCI 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 FSBCI 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 FSBCI 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??

 

[Guest]

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 FSBCI 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 FSBCI 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 FSBCI 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??