Slashdot Mirror
Remote Direct Memory Access Over IP
doormat writes "Accessing another computer's memory over the internet? It might not be that far off. Sounds like a great tool for clustering, especially considering that the new motherboards have gigabit ethernet and a link directly to the northbridge/MCH."
I tried something like this a while ago -- I wanted to mount an NFS-exported file via loopback and use it as swap.
The file in question actually resided in a RAM drive on another machine on the LAN.
I couldn't get it to work in the 45 minutes or so I messed around with it. I'm not sure if Linux was unhappy using an NFS-hosted file for swap, or what exactly the problem was, but I did get some funny looks from people to whom I explained the idea (ie, to determine whether the network would be faster than waiting for my disk-based swap).
Of course, this was back when RAM wasn't cheap...
Somebody get that guy an ambulance!
That's where the TCP offload engines come in. It's in the same ballpark as the prestoserv NFS cards that offloaded some of that overhead from the OS.
Land of the free, void where prohibited.
The article says that Microsoft is part of this "consortium".
What kind of problems will develope once virus & worm writers, and spammers get access to this mechanism?
Of course, if DRM (digital restriction management) comes along, at least it will give a back door into the system.
Security does not mean 100% exploit-proof, it means it secures your information/services given certain desired lengths of protection and certain operating conditions.
While M$ is probably not going to get this one right, it doesn't mean that someone can't. This *is* a desirable feature for some applications, and it is possible to make a secure environment (where secure is defined for the application), and make it seamless as well. That is the whole goal of network security professionals.
If anything, the fact that people already know what kinds of "old" exploits this may be vulnerable to, it means that we are already headed in the right direction.
Um... easier said than done there, hotshot.
When a program asks for memory there's a reasonable amount of loops it has to go through in the processor to get the memory, because the processor manages memory. Making a program that toys with memory over the internet wouldn't be slightly exciting.
DMA channels let something, usually a video card, sound card, IDE bus, etc. do what it needs to do with the system's memory without bothering the processor. The speed gained by not bothering the processor when accessing memory is what makes UltraDMA hard drives so fast, video cards accelerated (in addition to a lot of other l337 tricks), etc.
Now, you take a cluster, connected via gigabit network, in which each computer can directly access each other's memory as opposed to using a program to do it that just takes the target processor's cycles. THAT is slightly exciting.
this is still fairly uninteresting, at the core. so they tied the IP stack to DMA. given that the bottleneck is still going to be the line speed, which is going to be far, far slower than the bus, the 'loops' you speak of will probably be negligible by comparison. increases in line speed aren't likely to bring the throughput close to bus speeds anytime soon. as for clustering via a gigabit network, fine and dandy, but there have been solutions to do this very thing for other platforms for awhile now - all this does is widen the area within which this can be done. not innovative and not really useful, in my opinion, but the proof will be in the pudding. show me a distributed application that scales more effectively using this as opposed to some other method of sharing information between clients that also offsets the obvious overhead of managing such a wide shared memory pool (and we don't even have to think about That ball of wax to discount this) and you'll make a believer out of me. i do not expect that this will happen.
Scott McNealy said that, but the vision was implemented by others. CMU's Mach (1985), Andrew Tanenbaum's Amoeba (1986), and Plan 9 (1987) were OSes that made a network into a computer.
To be fair, Sun does have ChorusOS , but that seems to have died the death (i.e. gone Sun Public Source) despite Scott's best intentions.
Sigmentation fault - core dumped
I work at InfiniCon Systems and we do a lot of InfiniBand related things. We have switching, adapters, and connections from IB to gigabit ethernet and IB to fibre channel. See http://www.infinicon.com/.
The real next steps for IB is 12X (30 Gb) and on mother board IB. 12 X is in development. Currently, IB adapters are limited by the PCI-X slot they sit in. PCI-X DDR and PCI Express should help, but just having it on the mother board and throwing PCI out would be interesting. Small form factor clusters would really benefit to just having memory, CPU, and an HCA.
-- soldack
I wonder why noone pointed that out before. This might enable (more or less) DRI to remote X-server...
Imagine running accelerated X-server and being able to start [insert your favourite 3D game] on a remote host.
Of course _if_ 1Gbps is enough.
The approach you describe relies on CPU intervention on both ends of the connection.
Not allways. The ssh example was for show only. But about a decade ago I saw a diploma thesis advertised that should develop a hardware implementation for shared memory that could work without special drivers. True it was SCSI-based and therefore did not allow non-local networking. But with non-local networking the transfer dominates the latency anyway and hardware does not help.
All I am saying is that the idea is neither new nor interessting.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted and ignored otherwise.
Well, sort of...
"Back in the day", I wrote a virtual memory handler for my Amiga's accelerator card (which had a 68030 and MMU). Meanwhile, some friends of mine had developed this networking scheme that involved wiring the serial ports of our Amiga's together in a ring, which allowed us to have a true network without network cards.
Then came the true test: I configured my virtual memory to use a swapfile located in a friend's RAM-disk (he had way more memory than I did), fired up an image editor, opened a large image, and lo and behold: I was swapping at a whopping 9600 bytes per second! The fact that every packet had to pass through multiple other machines (because of the ring-nature of the network) didn't make it any faster either...
Perhaps this is an opportunity to implement something else of use. Right now, OSes implement rough security for memory access (see SIGSEGV). Why not elevate such security to the same level as FS permissions (and simultaneously elevate both to a Kerberos style network auth).
I think Mauve has the most RAM. --PHB (Dilbert Comic)