Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DRAM has a design flaw from 1966. I bypassed it [video]

youtube.com

Post reply on HN
Print view View original

11–20 of 174 posts

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#11

Post by rkagerer »

Halfway through this great video and I have two questions:

1) Can we take this library and turn it into a a generic driver or something that applies the technique to all software (kernel and userspace) running on the system? i.e. If I want to halve my effective memory in order to completely eliminate the tail latency problem, without having to rewrite legacy software to implement this invention.

2) What model miniature smoke machine is that? I instruct volunteer firefighters and occasionally do scale model demos to teach ventilation concepts. Some research years back led me to the "Tiny FX" fogger which works great, but it's expensive and this thing looks even more convenient.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#12

Post by gopalv »

kreelman wrote: post #4

This is very much worth watching. It is a tour de force. Laurie does an amazing job of reimagining Google's strange job optimisation technique (for jobs running on hard disk storage) that uses 2 CPUs to do the same job. The technique simply takes the result of the machine that finishes it first, discarding the slower job's results... It seems expensive in resources, but it works and allows high priority tasks to run…

>> It replicates data across multiple, independent DRAM channels with uncorrelated refresh schedules

This is the sort of thing which was done before in a world where there was NUMA, but that is easy. Just task-set and mbind your way around it to keep your copies in both places.

The crazy part of what she's done is how to determine that the two copies don't get get hit by refresh cycles at the same time.

Particularly by experimenting on something proprietary like Graviton.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#13

Post by rcbdev »

ufocia wrote: post #7
kreelman wrote: post #4

This is very much worth watching. It is a tour de force. Laurie does an amazing job of reimagining Google's strange job optimisation technique (for jobs running on hard disk storage) that uses 2 CPUs to do the same job. The technique simply takes the result of the machine that finishes it first, discarding the slower job's results... It seems expensive in resources, but it works and allows high priority tasks to run…

I like the video, but this is hardly groundbreaking. You send out two or more messengers hoping at least one of them will get there on time.

Yeah. These are literally just mainframe techniques from yesteryear.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#15

Post by rockskon »

gopalv wrote: post #12
kreelman wrote: post #4

This is very much worth watching. It is a tour de force. Laurie does an amazing job of reimagining Google's strange job optimisation technique (for jobs running on hard disk storage) that uses 2 CPUs to do the same job. The technique simply takes the result of the machine that finishes it first, discarding the slower job's results... It seems expensive in resources, but it works and allows high priority tasks to run…

>> It replicates data across multiple, independent DRAM channels with uncorrelated refresh schedules This is the sort of thing which was done before in a world where there was NUMA, but that is easy. Just task-set and mbind your way around it to keep your copies in both places. The crazy part of what she's done is how to determine that the two copies don't get get hit by refresh cycles at the same time. Particularly…

She determines that by having three copies. Or four. Or eight.

Tis just probabilities and unlikelihood of hitting a refresh cycle across that many memory channels all at once.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#17

Post by imp0cat »

rkagerer wrote: post #11

Halfway through this great video and I have two questions: 1) Can we take this library and turn it into a a generic driver or something that applies the technique to all software (kernel and userspace) running on the system? i.e. If I want to halve my effective memory in order to completely eliminate the tail latency problem, without having to rewrite legacy software to implement this invention. 2) What model miniatu…

Brio 33884. It has a tiny ultrasonic humidifier in there.
Post reply on HN