Re:The problem with Rambus compared to SDRAM...
on
Will Rambus Go Bust?
·
· Score: 2
And that's a really difficult optimization as you basically have to optimize data accesses as well as code. Data is where it is, locality really can't be improved easily. Systems can be tuned to grab a few pages in a row, but then that may still slow you down if you only used data or code on one of them.
If there's predictability in the access stream, two or in some cases three levels of cache have already stripped it out. We're into the totally-unpredictble range now. Interrupts, table-based branches, database accesses, that kind of thing. That's why even relatively great changes in DRAM performance only make 5% or so differences in system performance -- most of the time the access hits cache and it doesn't matter.
Granularity - don't discount this one. Presently DIMMs are made with 8 chips, each organized with X8 outputs. That says that 64Mb technology makes 64MB DIMMs. It also says that 256Mb technology makes 256MB DIMMs, even though mainstream PCs today are only now making the transition from 64MB to 128MB. That's part of the reason we've dropped the 4X-per-generation habit, and are bringing out 128Mb SDRAM, because the market just isn't ready for 256Mb. 512Mb and 1Gb are on the drawing boards and early hardware now, so this problem is going to get worse. A single 1Gb chip holds 128MB. (Obviously)
Which is why DDR parts are moving to x16 wide rather than x8 for the largest volumes. Remember when DRAM was x1 and only a few x4 parts were around? x32 and x64 are on the roadmap for later generations. Basically, the width grows more slowly than the devices' size because the increasing appetite for RAM (thanks, Bill!) keeps raising the level of granularity that anyone really wants (who does 32 MB main-memory granularity any more?) Small systems are a bit different, which is why graphics controllers use x32 parts today.
RAMBUS memory is being used in the PlayStation 2. Considering that 2 million systems have shipped in Japan and the PS2 hasn't been released to the rest of the world yet, I think RAMBUS is going to get some nice business. Remember, the original PlayStation has sold over 75 million units.
This isn't even in the noise. DRAM volumes are measured in millions per day, not per year. Industry unit volumes are on the order of thirty billion devices per year. Somehow I doubt that Playstations will make a serious impact on that.
Re:The problem with Rambus compared to SDRAM...
on
Will Rambus Go Bust?
·
· Score: 4
the idea is that boosting frequency down the line (for RDRAMs) will be easier than adding more lines to SDRAM, or trying to boost SDRAM frequency (due to its more parallel nature).
DDR-SDRAM is actually less parallel than Rambus. DDR has a strobe (clock) line for each eight data lines, where Rambus uses a common clock for sixteen. DDR-II also moves to a dedicated differential strobe. The result is that the skew within byte lanes (the main limit on the transfer rate for source-synchronous signaling schemes) is lower and therefore the data rate can be higher.
In contrast, Rambus tries to keep the clock rate low by doing four transfers per clock cycle. Since the data has a frequency half of the transfer rate, more width, and is single-ended, there's really no engineering advantage to the 4x multiplier. There is a honking great cost, though, since it requires the devices to oversample the data in between clock edges. This leads to more jitter (sampling-point variability) and makes the Rambus interface (RAC) very complex and expensive. The primarily-analog circuitry in the RAC is one of the main reasons that RDRAMS have such hideously low yield -- it's just ugly getting all of those comparators and timing paths to match up in a cost-means-everything DRAM process which is basically oriented to making lots and lots of cheap capacitors.
Early DDR devices are already running at over 400 MT/s (million transfers per second) in small systems such as graphics controllers and Transmeta's low-power systems. JEDEC is now putting the finishing touches on DDR and most of the hairy design work is moving to DDR-II. As usual, the second pass mostly applies the lessons learned on the first pass. DDR-II will have less legacy support and will remove some features in the "nice but not worth the speed cost" category. The objective is to run early parts with >400 MT/s data rates in large systems -- or in other words, your 72-bit DIMM is going to have more than twice the bandwidth of those still-not-available 800 MT/s Rambus parts -- and the DDR-II parts won't require water cooling, either.
Basically, interleaving moved onchip. What interleaving did was allow you to overlap accesses when the access time was dictated by the handshake between the controller and the RAM. By having two out-of-phase banks of memory transferring at once the bandwidth could be doubled.
Since DRAMs are inherently much wider internally than externally, it's much more economical to do this inside the DRAM itself. SDRAM etc. read an entire row at once and then shift out chunks in very high speed bursts. Meanwhile they have four or more internal banks which can be accessed for overlapping row accesses. Interleaving would require either making the data bus twice as wide (fuggedaboutit) or switching ownership of the databus on every clock (which is even dumber). Thus, no more interleaving.
Further work will now happen. We wish to support other products (ie. IRE, Bluesteelnet, perhaps even 3COM or PCC-ISES if they would open their minds). Some crypto chip vendors are being extremely friendly to us. If anyone wants to help write drivers, get in touch.
In case anyone cares, specs for the VLSI (Philips) VSC115 are published. Pretty nice performance specs. The official policy is to support Linux driver development for new products, but the details are still in the works and BSD is (alas) not a priority.
ISPs have so far pretty much had the best of both worlds, with most of a common carrier's freedom from responsibility for content and none of their obligation to take any and all traffic. That idyllic period may be ending.
People who look at the British and German cases, and lesser ones that have happened in the USA, tend to propose common-carrier status for ISPs. ISPs, on the other hand, know better. The common carrier's immunity for responsibility for the traffic they carry stems directly from their obligation to take any and all comers willing to pay the tariff. If an ISP actually were to fall under common-carrier law, some very unpleasant things would happen. Like, for instance, spam.
Keep in mind that at present there is very little legal basis for the 'law of cyberspace'. System administrators, under peer pressure, keep limits on net abuse not because it's the law but because being too slack with abusers is a good way to end up firewalled. Common-carrier status would change that fundamentally by setting a legal standard for refusing packets and users alike: as long as there isn't a law against it, you have to carry it.
Of course, the response to that is a huge upswing in abuse, to which the only remaining response is to -- you guessed it -- make certain actions on the Net illegal.
The legislative process being what it is, you can bet that lawmakers' ideas of what should be illegal won't agree much with the existing Internet's cultural norms. Lawmakers, for instance, don't seem to have any objection to spam; they don't do e-mail anyway (that's for flunkies to do, with the weekly abstracts presented on nice crisp paper.) It shouldn't be necessary to enumerate the things that our Lords and Masters don't like that we want to keep safe from them.
Bad as the situation with defamation claims may be, always keep in mind that it could be lots worse.
Deja Vu all over again. Several years ago Bavarian police got after Compuserve because they were making (gasp!) pr0n available from their servers. Compuserve responded by CYA: they couldn't stay in business if they had to censor every packet, so they shut down in Germany rather than get creamed in court. Of course, the rest of the German users, as well as all of the other ISPs, decided that this was a Really Bad Idea and very shortly sanity prevailed. At this very moment, I'm confident that every single ISP doing business in Germany is letting the Powers That Be know that in light of this decision they have no choice but to cease operations in Germany (or possibly the entire EU).
Do you think that this will effect the overclockability of chips produced with this technology?
EM is a lifetime-reliability issue. Overclocking basically affects EM in two ways:
More clocks: the EM life of the device gets used up faster. If the EM life was 10 years (a common target) then 25% overclocking will reduce it to 8 years
Temperature. EM is hideously nonlinear with temperature. Assuming that your overclocking strategy involves overcooling to keep the die temp unchanged, this won't matter./UL
One possible problem is poor heat conduction from die to package, but the tradeoff is probably worth it.
Non issue. IC dice mount with the back of the die, not the active side, to the substrate. Even flip-chip (solder-bump) parts have to use a thermal contact on the other side for all but the lowest power dissipations because the total contact area on the metalized side must be a small percentage of the total.
As you know, CPU's are damaged by electro-static migration, and heat
That's either electrostatic discharge (zapping the part) or electromigration (wiring atoms getting knocked out of place by speeding electrons). Please don't combine the two.
Actually, the low-K dielectrics make the electromigration worse, not better. EM effectively causes pressure inside the 'downstream' (positive) end of the wire, where aluminum atoms pile up and press against the surrounding dielectric. All of the proposed low-K dielectrics are physically weaker than silicon dioxide, and thus the EM limit is lower.
I still end up getting tied to Windows to access my mail and calendaring tools in Lotus Notes.
Personally, I'd be thrilled just to have enough documentation on the Notes protocol to let me download my mail from a script. As it is, all too often the queue fills up and new messages end up in the bitbucket before I can find a Windows machine to log into.
Actually, back in 86 our team had a poster up with a picture of a pilot punching out of an F16, and the caption, "Fly-by-wire gives a whole new meaning to 'system crash.'"
imp worried: The only down side I can see to this is if, in the future, the purchase doesn't become optional.
At US$300 plus, they could OEM Win9x in there and hardly notice. I was all set to buy a copy when I thought it was $99 but it ain't worth three times that per seat.
Besides which, I'm still having fits with making the networking work on the eval copy.
Is it possible, under any circumstances, for Mr. Gates to be charged criminally? Is there any crime which he has committed for which he could go to jail?
As an academic point, yes. The famous meeting with Netscape to divide the market was a pretty clear violation of Section 1 of the Sherman Act, and the Act provides for jail sentences.
As a practical matter, are you outta your flippin' mind?
Upfront: I'm a JEDEC JC42.3 (DRAM) representative. Most/.ers are biased on this; I'm really biased.
Rambus is suing for infringment of the following patents:
5,953,263 Synchronous memory device having a programmable register and method of controlling same The present invention includes a memory subsystem comprising at least two semiconductor devices, including at least one memory device, connected to a bus, where the bus includes a plurality of bus lines for carrying substantially all address, data and control information needed by said memory devices, where the control information includes device-select information and the bus has substantially fewer bus lines than the number of bits in a single address, and the bus carries device-select information without the need for separate device-select lines connected directly to individual devices.
5,915,105 Synchronous memory device Same Abstract
5,995,443 Integrated circuit I/O using a high performance bus interface Same Abstract
5,954,804 Synchronous memory device having an internal register The present invention is directed to an integrated circuit device having at least one memory section including a plurality of memory cells. The device includes an internal register to store an identification value which identifies the device on a bus. The device further includes interface circuitry, coupled to the bus, to receive identification information and a read request. The interface circuitry includes a plurality of output drivers and comparison circuitry. The output drivers are coupled to the bus to output data on the bus in response to the read request. The data is output synchronously with respect to first and second external clock signals when the comparison circuitry determines the identification information corresponds to the identification value.
Part of what Rambus has patented is its self-enumerating memory scheme. (Yeah, I know; self-enumerating busses are old hat. Rambus innovated their way into the realization that memory busses could self-enumerate.) As it happens, though, SDRAM and derivatives don't self-enumerate. The USPTO full-text database is down (/.?) but if the abstract is to be believed the first three above don't apply to SDRAM.
They also patented transferring data on both clock edges (yeah, I know; IBM was doing this in the 60s, but Rambus innovated etc.) This has been in use in SRAM since before Rambus' patent app so I'm not worrying a lot.
Also not directly mentioned is that Rambus has patented programmable CAS latency (do you really want to know?) in memory devices. Since programmable CAS latency has been around in controllers since the '80s and SDRAM moved low-level controller functions to the memory this may be headed for the scrap heap; in the meantime the SDRAM manufacturers (via JEDEC) are removing the feature from their parts. Considering what this is costing them, they are not happy with Rambus.
Two of the most promising hosts are gcc and glibc.
Seriously, how many of us examine the source of large programs? Thought so. gcc is well beyond large enough to hide a lot of virus, which could be quite sophisticated. It could, for instance, recognize whether it's compiling gcc or something else. It could also do alternate-generation propagation (infecting compiled apps, which then try to infect more copies of gcc.c) Best of all, it could insert itself into the source of large target programs prior to their distribution.
Event-driven programs of the c++ flavor actually make this even easier, since the flow of control is often really nonobvious, and thus little objects can be all over the place. Little examination is usually given to either the dispatcher or any but the objects under development.
I'll have to respectfully disagree with you on point C there. Sticking files "all over the place" is a strength, not a weakness.
RPM's exist to keep track of where all the files go. Programs are installed in the path (generally/usr/bin or/usr/local/bin) so that users don't have to make "shortcuts". (although it'd be easy to type in the name of a program and make a shortcut because the binary is in a *standard* location)
Hrmmm.... I'm currently trying to keep four clients on a home network in sync. Every freaking package scatters its files in a combination of network shared and local filesystems, so instead of just loading the wretched thing into/opt/newgizmo and adding a link to the (shared) global desktop, I have to do the
rpm -qlp | egrep -v...
dance and then copy the droppings to each system. Then when it comes time to remove the fool thing, I can't just
rm -r/opt/gizmo
No, I have to track down all of the little buggers and do the whole stupid thing in reverse. Updates are the worst of both. That's a lot of work for four systems in the same area; just imagine the fun that Corporate IT will have with it.
This isn't really a Linux problem; it's a hacker (or hacker culture) problem. Too many of the packages are being set up according to rules that make perfect sense to programmer esthetics and depend on users having their own system administration skills.
I think I see the fundamental problem with their "research" group. They clearly are not technical, or endowed programmers. I don't doubt MS has all these folks, but they're basically asking hundreds of starving artists who may have never heard of a symbolic link before, a core UNIX feature, to come up with creative ideas. Of COURSE this very idea will come up and they will honestly feel it's innovative.
Actually, this is the classic MICROS~1 problem. They pride themselves on populating Redmond with people who are (1) supposedly the New Master Race, (2) utterly innocent of corruption by non-Microsoft experience. Then they toss them into a culture which is openly contemptuous of programming-in-the-large practices such as peer review and give them carte blanche to do things as the fancy takes them.
The inevitable result is a system which keeps reinventing Bright Ideas from the 60s and taking years (if ever) to discover the flaws in that Bright Idea (which were published thirty years ago.) That's how, for instance, we got the dozens of different memory management algorithms that MICROS~1 uses, most of which fragment and leak like sieves.
As many have observed, W2K reliaes massively on disk caching because the physical write performance sucks abysmally. If they're checking for redundant files on each write, we now know why.
And if you ever think for a minute that they aren't watching you, all you have to do is open NetMon from the SMS2 distrobution, and normally you'll at least get some email wanting to know WHY you've got a packet capture utility on corporate LAN. They are fairly protective of their assets.:)
How VERY interesting. Seems they have less confidence in their own network security than they want the rest of us to have.
Anyone try out the BAT keyboard? It looks really interesting -- keep one hand on the keyboard and one on the mouse, not moving back and forth. Mounts readily on a chair arm, that kind of thing.
I'm still trying to get the IT bunch here to get one for eval. Comments really appreciated.
BTW: I've been using Infogrip's mice for quite a while and love 'em -- reliable, feel good in an odd-sized hand.
Much as we all love writing documentation
on
A New DeCSS
·
· Score: 2
... wouldn't it be much more to the point to do some really good design documentation on the original DeCSS? Like, as in totally pelucid English (or Norwegian) prose. Explain in unmistakable detail how CSS works, and how to go about a key search for it.
With that in hand your average 8-year-old (or at least an 8-year-old/. reader) could crank YADeCSS in an afternoon, and I defy any judge to say that there aren't any First Amendment implications to censoring prose (or at least to do so with a straight face.)
Intel has nothing to do with it. Or at least their mainstream CPUs don't; this could be a StrongArm machine. Chances are, though, that it's another Hitachi brain.
As for the pricing, all games boxen are sold as loss leaders. MICROS~1's only reason for pushing this thing would be to make a major assault on the games publishing business, which is where the money is. Expect to see some loss leaders there for the first generation or two, since Redmond can "cut off the air supply" to Sony, Sega, and Nintendo for as long as it takes to drive them out of business. After that, of course, the story changes. (When Win3.1 came out, DOS was priced over $100 and MS threw in Windows for small change -- unless you were buying DR-DOS.)
It seems that the ruling class is hoping for the Internet to become a cheaper form of television: strictly one-way media. A classic indicator of this is that Bush and Gore have run spam campaigns and McCain (as committee chair) pulled a midnight sneaky to get prospam legislation through the Senate.
Why is is so hard for our Lords and Masters to understand that the Internet isn't television? Wiil it take the 1960 debates all over again?
Slashdot Mirror
And that's a really difficult optimization as you basically have to optimize data accesses as well as code. Data is where it is, locality really can't be improved easily. Systems can be tuned to grab a few pages in a row, but then that may still slow you down if you only used data or code on one of them.
If there's predictability in the access stream, two or in some cases three levels of cache have already stripped it out. We're into the totally-unpredictble range now. Interrupts, table-based branches, database accesses, that kind of thing. That's why even relatively great changes in DRAM performance only make 5% or so differences in system performance -- most of the time the access hits cache and it doesn't matter.
Granularity - don't discount this one. Presently DIMMs are made with 8 chips, each organized with X8 outputs. That says that 64Mb technology makes 64MB DIMMs. It also says that 256Mb technology makes 256MB DIMMs, even though mainstream PCs today are only now making the transition from 64MB to 128MB. That's part of the reason we've dropped the 4X-per-generation habit, and are bringing out 128Mb SDRAM, because the market just isn't ready for 256Mb. 512Mb and 1Gb are on the drawing boards and early hardware now, so this problem is going to get worse. A single 1Gb chip holds 128MB. (Obviously)
Which is why DDR parts are moving to x16 wide rather than x8 for the largest volumes. Remember when DRAM was x1 and only a few x4 parts were around? x32 and x64 are on the roadmap for later generations. Basically, the width grows more slowly than the devices' size because the increasing appetite for RAM (thanks, Bill!) keeps raising the level of granularity that anyone really wants (who does 32 MB main-memory granularity any more?) Small systems are a bit different, which is why graphics controllers use x32 parts today.
RAMBUS memory is being used in the PlayStation 2. Considering that 2 million systems have shipped in Japan and the PS2 hasn't been released to the rest of the world yet, I think RAMBUS is going to get some nice business. Remember, the original PlayStation has sold over 75 million units.
This isn't even in the noise. DRAM volumes are measured in millions per day, not per year. Industry unit volumes are on the order of thirty billion devices per year. Somehow I doubt that Playstations will make a serious impact on that.
the idea is that boosting frequency down the line (for RDRAMs) will be easier than adding more lines to SDRAM, or trying to boost SDRAM frequency (due to its more parallel nature).
DDR-SDRAM is actually less parallel than Rambus. DDR has a strobe (clock) line for each eight data lines, where Rambus uses a common clock for sixteen. DDR-II also moves to a dedicated differential strobe. The result is that the skew within byte lanes (the main limit on the transfer rate for source-synchronous signaling schemes) is lower and therefore the data rate can be higher.
In contrast, Rambus tries to keep the clock rate low by doing four transfers per clock cycle. Since the data has a frequency half of the transfer rate, more width, and is single-ended, there's really no engineering advantage to the 4x multiplier. There is a honking great cost, though, since it requires the devices to oversample the data in between clock edges. This leads to more jitter (sampling-point variability) and makes the Rambus interface (RAC) very complex and expensive. The primarily-analog circuitry in the RAC is one of the main reasons that RDRAMS have such hideously low yield -- it's just ugly getting all of those comparators and timing paths to match up in a cost-means-everything DRAM process which is basically oriented to making lots and lots of cheap capacitors.
Early DDR devices are already running at over 400 MT/s (million transfers per second) in small systems such as graphics controllers and Transmeta's low-power systems. JEDEC is now putting the finishing touches on DDR and most of the hairy design work is moving to DDR-II. As usual, the second pass mostly applies the lessons learned on the first pass. DDR-II will have less legacy support and will remove some features in the "nice but not worth the speed cost" category.
The objective is to run early parts with >400 MT/s data rates in large systems -- or in other words, your 72-bit DIMM is going to have more than twice the bandwidth of those still-not-available 800 MT/s Rambus parts -- and the DDR-II parts won't require water cooling, either.
Basically, interleaving moved onchip. What interleaving did was allow you to overlap accesses when the access time was dictated by the handshake between the controller and the RAM. By having two out-of-phase banks of memory transferring at once the bandwidth could be doubled.
Since DRAMs are inherently much wider internally than externally, it's much more economical to do this inside the DRAM itself. SDRAM etc. read an entire row at once and then shift out chunks in very high speed bursts. Meanwhile they have four or more internal banks which can be accessed for overlapping row accesses. Interleaving would require either making the data bus twice as wide (fuggedaboutit) or switching ownership of the databus on every clock (which is even dumber). Thus, no more interleaving.
Further work will now happen. We wish to support other products (ie. IRE, Bluesteelnet, perhaps even 3COM or PCC-ISES if they would open their minds). Some crypto chip vendors are being extremely friendly to us. If anyone wants to help write drivers, get in touch.
In case anyone cares, specs for the VLSI (Philips) VSC115 are published. Pretty nice performance specs. The official policy is to support Linux driver development for new products, but the details are still in the works and BSD is (alas) not a priority.
Because, as the saying goes, you might get it.
ISPs have so far pretty much had the best of both worlds, with most of a common carrier's freedom from responsibility for content and none of their obligation to take any and all traffic. That idyllic period may be ending.
People who look at the British and German cases, and lesser ones that have happened in the USA, tend to propose common-carrier status for ISPs. ISPs, on the other hand, know better. The common carrier's immunity for responsibility for the traffic they carry stems directly from their obligation to take any and all comers willing to pay the tariff. If an ISP actually were to fall under common-carrier law, some very unpleasant things would happen. Like, for instance, spam.
Keep in mind that at present there is very little legal basis for the 'law of cyberspace'. System administrators, under peer pressure, keep limits on net abuse not because it's the law but because being too slack with abusers is a good way to end up firewalled. Common-carrier status would change that fundamentally by setting a legal standard for refusing packets and users alike: as long as there isn't a law against it, you have to carry it.
Of course, the response to that is a huge upswing in abuse, to which the only remaining response is to -- you guessed it -- make certain actions on the Net illegal.
The legislative process being what it is, you can bet that lawmakers' ideas of what should be illegal won't agree much with the existing Internet's cultural norms. Lawmakers, for instance, don't seem to have any objection to spam; they don't do e-mail anyway (that's for flunkies to do, with the weekly abstracts presented on nice crisp paper.) It shouldn't be necessary to enumerate the things that our Lords and Masters don't like that we want to keep safe from them.
Bad as the situation with defamation claims may be, always keep in mind that it could be lots worse.
Several years ago Bavarian police got after Compuserve because they were making (gasp!) pr0n available from their servers. Compuserve responded by CYA: they couldn't stay in business if they had to censor every packet, so they shut down in Germany rather than get creamed in court.
Of course, the rest of the German users, as well as all of the other ISPs, decided that this was a Really Bad Idea and very shortly sanity prevailed.
At this very moment, I'm confident that every single ISP doing business in Germany is letting the Powers That Be know that in light of this decision they have no choice but to cease operations in Germany (or possibly the entire EU).
Let's see what that kicks off.
EM is a lifetime-reliability issue. Overclocking basically affects EM in two ways:
One possible problem is poor heat conduction from die to package, but the tradeoff is probably worth it.
Non issue. IC dice mount with the back of the die, not the active side, to the substrate. Even flip-chip (solder-bump) parts have to use a thermal contact on the other side for all but the lowest power dissipations because the total contact area on the metalized side must be a small percentage of the total.
As you know, CPU's are damaged by electro-static migration, and heat
That's either electrostatic discharge (zapping the part) or electromigration (wiring atoms getting knocked out of place by speeding electrons). Please don't combine the two.
Actually, the low-K dielectrics make the electromigration worse, not better. EM effectively causes pressure inside the 'downstream' (positive) end of the wire, where aluminum atoms pile up and press against the surrounding dielectric. All of the proposed low-K dielectrics are physically weaker than silicon dioxide, and thus the EM limit is lower.
I still end up getting tied to Windows to access my mail and calendaring tools in Lotus Notes.
Personally, I'd be thrilled just to have enough documentation on the Notes protocol to let me download my mail from a script. As it is, all too often the queue fills up and new messages end up in the bitbucket before I can find a Windows machine to log into.
Actually, back in 86 our team had a poster up with a picture of a pilot punching out of an F16, and the caption, "Fly-by-wire gives a whole new meaning to 'system crash.'"
At US$300 plus, they could OEM Win9x in there and hardly notice. I was all set to buy a copy when I thought it was $99 but it ain't worth three times that per seat.
Besides which, I'm still having fits with making the networking work on the eval copy.
Is it possible, under any circumstances, for Mr. Gates to be charged criminally? Is there any crime which he has committed for which he could go to jail?
As an academic point, yes. The famous meeting with Netscape to divide the market was a pretty clear violation of Section 1 of the Sherman Act, and the Act provides for jail sentences.
As a practical matter, are you outta your flippin' mind?
Rambus is suing for infringment of the following patents:
Synchronous memory device having a programmable register and method of controlling same
The present invention includes a memory subsystem comprising at least two semiconductor devices, including at least one memory device, connected to a bus, where the bus includes a plurality of bus lines for carrying substantially all address, data and control information needed by said memory devices, where the control information includes device-select information and the bus has substantially fewer bus lines than the number of bits in a single address, and the bus carries device-select information without the need for separate device-select lines connected directly to individual devices.
Synchronous memory device
Same Abstract
Integrated circuit I/O using a high performance bus interface
Same Abstract
Synchronous memory device having an internal register
The present invention is directed to an integrated circuit device having at least one memory section including a plurality of memory cells. The device includes an internal register to store an identification value which identifies the device on a bus. The device further includes interface circuitry, coupled to the bus, to receive identification information and a read request. The interface circuitry includes a plurality of output drivers and comparison circuitry. The output drivers are coupled to the bus to output data on the bus in response to the read request. The data is output synchronously with respect to first and second external clock signals when the comparison circuitry determines the identification information corresponds to the identification value.
Part of what Rambus has patented is its self-enumerating memory scheme. (Yeah, I know; self-enumerating busses are old hat. Rambus innovated their way into the realization that memory busses could self-enumerate.) As it happens, though, SDRAM and derivatives don't self-enumerate. The USPTO full-text database is down (/.?) but if the abstract is to be believed the first three above don't apply to SDRAM.
They also patented transferring data on both clock edges (yeah, I know; IBM was doing this in the 60s, but Rambus innovated etc.) This has been in use in SRAM since before Rambus' patent app so I'm not worrying a lot.
Also not directly mentioned is that Rambus has patented programmable CAS latency (do you really want to know?) in memory devices. Since programmable CAS latency has been around in controllers since the '80s and SDRAM moved low-level controller functions to the memory this may be headed for the scrap heap; in the meantime the SDRAM manufacturers (via JEDEC) are removing the feature from their parts. Considering what this is costing them, they are not happy with Rambus.
Seriously, how many of us examine the source of large programs? Thought so. gcc is well beyond large enough to hide a lot of virus, which could be quite sophisticated. It could, for instance, recognize whether it's compiling gcc or something else. It could also do alternate-generation propagation (infecting compiled apps, which then try to infect more copies of gcc.c) Best of all, it could insert itself into the source of large target programs prior to their distribution.
Event-driven programs of the c++ flavor actually make this even easier, since the flow of control is often really nonobvious, and thus little objects can be all over the place. Little examination is usually given to either the dispatcher or any but the objects under development.
RPM's exist to keep track of where all the files go. Programs are installed in the path (generally
Hrmmm.... I'm currently trying to keep four clients on a home network in sync. Every freaking package scatters its files in a combination of network shared and local filesystems, so instead of just loading the wretched thing into
rpm -qlp | egrep -v ...
dance and then copy the droppings to each system. Then when it comes time to remove the fool thing, I can't just
rm -r /opt/gizmo
No, I have to track down all of the little buggers and do the whole stupid thing in reverse. Updates are the worst of both. That's a lot of work for four systems in the same area; just imagine the fun that Corporate IT will have with it.
This isn't really a Linux problem; it's a hacker (or hacker culture) problem. Too many of the packages are being set up according to rules that make perfect sense to programmer esthetics and depend on users having their own system administration skills.
I think I see the fundamental problem with their "research" group. They clearly are not technical, or endowed programmers. I don't doubt MS has all these folks, but they're basically asking hundreds of starving artists who may have never heard of a symbolic link before, a core UNIX feature, to come up with creative ideas. Of COURSE this very idea will come up and they will honestly feel it's innovative.
Actually, this is the classic MICROS~1 problem. They pride themselves on populating Redmond with people who are (1) supposedly the New Master Race, (2) utterly innocent of corruption by non-Microsoft experience. Then they toss them into a culture which is openly contemptuous of programming-in-the-large practices such as peer review and give them carte blanche to do things as the fancy takes them.
The inevitable result is a system which keeps reinventing Bright Ideas from the 60s and taking years (if ever) to discover the flaws in that Bright Idea (which were published thirty years ago.) That's how, for instance, we got the dozens of different memory management algorithms that MICROS~1 uses, most of which fragment and leak like sieves.
As many have observed, W2K reliaes massively on disk caching because the physical write performance sucks abysmally. If they're checking for redundant files on each write, we now know why.
And if you ever think for a minute that they aren't watching you, all you have to do is open NetMon from the SMS2 distrobution, and normally you'll at least get some email wanting to know WHY you've got a packet capture utility on corporate LAN. They are fairly protective of their assets. :)
How VERY interesting. Seems they have less confidence in their own network security than they want the rest of us to have.
Anyone try out the BAT keyboard? It looks really interesting -- keep one hand on the keyboard and one on the mouse, not moving back and forth. Mounts readily on a chair arm, that kind of thing.
I'm still trying to get the IT bunch here to get one for eval. Comments really appreciated.
BTW: I've been using Infogrip's mice for quite a while and love 'em -- reliable, feel good in an odd-sized hand.
... wouldn't it be much more to the point to do some really good design documentation on the original DeCSS? Like, as in totally pelucid English (or Norwegian) prose. Explain in unmistakable detail how CSS works, and how to go about a key search for it.
/. reader) could crank YADeCSS in an afternoon, and I defy any judge to say that there aren't any First Amendment implications to censoring prose (or at least to do so with a straight face.)
With that in hand your average 8-year-old (or at least an 8-year-old
Intel has nothing to do with it. Or at least their mainstream CPUs don't; this could be a StrongArm machine. Chances are, though, that it's another Hitachi brain.
As for the pricing, all games boxen are sold as loss leaders. MICROS~1's only reason for pushing this thing would be to make a major assault on the games publishing business, which is where the money is. Expect to see some loss leaders there for the first generation or two, since Redmond can "cut off the air supply" to Sony, Sega, and Nintendo for as long as it takes to drive them out of business. After that, of course, the story changes. (When Win3.1 came out, DOS was priced over $100 and MS threw in Windows for small change -- unless you were buying DR-DOS.)
It seems that the ruling class is hoping for the Internet to become a cheaper form of television: strictly one-way media. A classic indicator of this is that Bush and Gore have run spam campaigns and McCain (as committee chair) pulled a midnight sneaky to get prospam legislation through the Senate.
Why is is so hard for our Lords and Masters to understand that the Internet isn't television? Wiil it take the 1960 debates all over again?