[SI-LIST] Re: Disscussion on DRAM technoly
- From: "Cheng, Chris" <chris.cheng@xxxxxx>
- To: Tesla <emcesd@xxxxxxx>
- Date: Wed, 13 Jun 2012 21:26:43 +0000
That said, there are those who run gigantic application such as hadoop, google
search engines or facebook that will gladly trade memory access latency for
huge memory density. For them, the latency penalty is when they run out of DRAM
and have to go to SSD or spin up the motor drive of a disk or go across the
cluster.
Unfortunately desktop PC drives DRAM volume, we all have to live with that fact
and work our solutions around it.
Chris Cheng
Distinguished Technologist , Electrical
Hewlett-Packard Company
+1 510 413 5977 / Tel
chris.cheng@xxxxxx / Email
4209 Technology Dr
Fremont, CA 94538
USA
[hp logo]
From: Tesla [mailto:emcesd@xxxxxxx]
Sent: Wednesday, June 13, 2012 2:27 AM
To: Cheng, Chris
Cc: si-list@xxxxxxxxxxxxx
Subject: Re:RE: [SI-LIST] Disscussion on DRAM technoly
Thanks, Chris
You see it from the the point veiw of latency to the first byte, it is also
very useful standpoint.
Best Regards.
Tesla
At 2012-06-13 17:07:33,"Cheng, Chris" <chris.cheng@xxxxxx> wrote:
>I am not a computer architect, but if I have to pretend to be one.....
>1) It's been done and it's called FB-DIMM. But it may not be the best
>performance you can get for a given CPU architecture because latency,
>specifically the latency to get the first random access cache line may be more
>important than the absolute bandwidth you can get out of a memory bus. Having
>a SerDes means you need to waste time in serializing the data and de-serialize
>it again. Some architect dreams about a cache line wide EDO DRAM bus because
>it offers the lowest possible latency to get the first cache miss.
>2) Adding ODT setup for a single burst event like control/address will just
>add more latency. RCD and CAS latency means there is so much you can squeeze
>between control/address signals spacing.
>
>
>-----Original Message-----
>From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
>Behalf Of Tesla
>Sent: Tuesday, June 12, 2012 11:49 PM
>To: si-list@xxxxxxxxxxxxx
>Subject: [SI-LIST] Disscussion on DRAM technoly
>
>1Why not use Serdes as I/O interface?
>
>Serdes I/O technology became faster and faster now has may advantage compare
>with parrelel bus, why not use Serdes for memory interface such as DDR(Next)?
>
>2Why not use ODT for CMD/CTL/ADD signal lines?
>
>Use ODT for CMD/CTL/ADD signal lines, this will save us a lot time and money.
>why not make the termination in chip?
>
>Thanks.
>
>Tesla
>------------------------------------------------------------------
>To unsubscribe from si-list:
>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
>or to administer your membership from a web page, go to:
>//www.freelists.org/webpage/si-list
>
>For help:
>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>
>List forum is accessible at:
> http://tech.groups.yahoo.com/group/si-list
>
>List archives are viewable at:
> //www.freelists.org/archives/si-list
>
>Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
