Re: [openib-general] [ofw] [Fwd: Re: [Fwd: Re: winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]]

[Tzachi Dar]

OK, Hal let's try to close this.

The windows openib project was agreed by everyone to be BSD only.
The fact that it is BSD means that any partner (or non partner) of the
Community can download the code and use it, the way he wants.
This includes:
1) Running the code as is.
2) Making changes to the code and contributing them back.
3) Making changes to the code and *NOT* giving them back to the
community.

Starting to depend on GPL (or LGPL) code means that the freedom of the
users to do (3) is broken.
Mellanox thinks that this needs a wider agreement of the open-IB
consortium, which we don't have.

More than that, the ideas that were introduced here about sending users
to other places in order for
them to find the pthread implementation are also not that great as this
starts to make the life of
our users harder. Also it is not clear who will give support once there
are problems, and who is
responsible that the license of the library won't change.

So, I hope this closes the subject of using LGPL software in open-IB.

By the way, what implementation of pthreads were you thinking of? I have
noticed that the first implementation that Google brings was only tested
on uni-processor system.
(http://sourceware.org/pthreads-win32/news.html). (this is really
amazing, I thought that these servers were out of the market a long time
ago).

To be more practical:
Can you give us a better view of what you are trying to achieve? In
other words, as far as I know 
Opensm is using complib apis to handle threads. The implementation of
this functions on windows is usually trivial.
Do you intend to make a re-write of opensm so that it will use pthreads
or do you intend to make a find/replace
And replace the complib functions with Pthreads ones? If we are talking
about the second, than one can simply implement the pthread functions
using trivial win32 calls.

And another question: What is the functionality that you are currently
missing? Can this functionality be added?

Thanks
Tzachi

By the way, rumors I have heard say that Voltaire doesn't always give
it's code back to the community, but this are just rumors, right?

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Fab Tillier
> Sent: Tuesday, February 20, 2007 11:56 PM
> To: Hal Rosenstock
> Cc: ofw@lists.openfabrics.org; Gilad Shainer; OPENIB
> Subject: RE: [ofw] [Fwd: Re: [openib-general] [Fwd: Re: 
> winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]]
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Hal Rosenstock
> Sent: Tuesday, February 20, 2007 1:43 PM
> 
> On Tue, 2007-02-20 at 16:08, Fab Tillier wrote:
> > -Original Message-
> > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 20, 2007 10:57 AM
> > 
> > On Tue, 2007-02-20 at 13:56, Fab Tillier wrote:
> > [ftillier] This isn't just an install issue - it's a build issue.
> > Anyone that wants to build OpenSM will need to find/download/install
> the
> > pthreads library so that the build will succeed.  If linking
> statically,
> > the resulting executable will not require any special installation.
> > It's only an install issue if you link dynamically to pitheads.
> 
> OK; then build and install. How big an issue is this ?
> 
> I thought DLLs were dynamically linked but I'm a Windows plebe. 
> 
> [ftillier] When you build, the linker needs the import 
> library for pthreads so that the functions get resolved as 
> being imported from the pthreads DLL.  The dependency on the 
> pthreads DLL is then created and the DLL will be loaded 
> dynamically, assuming it can be found in the path.
> 
> So for the build process, you need to have the pthreads 
> library available to the build tool (path to the lib).  This 
> requires installing the pthreads developer package or however 
> it's done.
> 
> If you statically link the pthreads lib, rather than 
> dynamically link, then all the pthreads goodies go directly 
> into the executable and you remove the dependency on an 
> external DLL.  The build process requirements are no 
> different than for the dynamically linked case.
> 
> There is also the possibility to remove the link-time 
> dependency by calling GetProcAddress to explicitly resolve 
> the pthreads entrypoints.
> This method still requires having the DLL loaded on the 
> user's systems.
> 
> Pesonally, I would rather see static linkage to the pthreads 
> library so that only the builds are affected (something only 
> 'experts' will be doing), while not affecting the common user.
> 
> -Fab
> ___
> ofw mailing list
> ofw@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
> 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/

Re: [openib-general] [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]

[Tzachi Dar]

See bellow.

Thanks
Tzachi 

> -Original Message-
> From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, February 08, 2007 9:47 PM
> To: Tzachi Dar
> Cc: Yossi Leybovich; Gilad Shainer; Yevgeny Kliteynik; 
> OPENIB; Michael S. Tsirkin; Hal Rosenstock
> Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2] 
> opensm: sigusr1: syslog() fixes]]
> 
> On 20:31 Thu 08 Feb , Tzachi Dar wrote:
> > The windows open IB has decided on using a BSD only license. 
> > The common implementation of pthreads as far as I know is 
> LGPL, which 
> > means that it can not be used in open IB.
> 
> Why not? AFAIK it works perfectly (see (5,6 and Preamble)):
> http://www.gnu.org/copyleft/lesser.html
> 
> And of course there are tons of examples when BSD software 
> links against LGPLed glibc.

I can of course write you an answer that will be more than 5 pages long
of why *I* don't think that 
Using GPL software is bad for everyone, but I guess that my opinion
doesn't really meter, so I
Won't do it.
The page that you have referenced is of the GNU org, and even there it
is hard to say that they
are trying to encourage you to use the LGPL license. In any case, the
main point is that 
When open IB windows was formed there was a general decision that it
will use BSD license. If we
Start having components with the LGPL this will break that decision, and
therefore this requires
some voting of the open IB organization.


> > The only two ways that I see around this are 1) Change the 
> license of 
> > open IB windows which might be a complicated thing. 2) Find an 
> > implementation of pthreads that is BSD.
> 
> BTW, just wondering... What is relation between windows open 
> IB and OFA (and OFA's "dual-license rule")?
Well, the way I see it one can take code from the Linux part under the
BSD licance and use it in 
The windows part. The otherway around seems fine to me but some say that
since the windows BSD liscance
Reqires that some text will always remain there, the other way around is
not possibale. As I'm not an 
Expert in that erea I don't know who is right.


> Sasha
> 
> > 
> > Thanks
> > Tzachi
> > 
> > > -Original Message-
> > > From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, February 08, 2007 7:46 PM
> > > To: Tzachi Dar; Yossi Leybovich
> > > Cc: Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock
> > > Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2]
> > > opensm: sigusr1: syslog() fixes]]
> > > 
> > > On 11:24 Sun 21 Jan , Yevgeny Kliteynik wrote:
> > > > Tzachi, Yossi, please join the thread.
> > > > What do you think about distributing a copy of the pthread DLL 
> > > > with opensm?
> > > 
> > > Any news here? Thanks.
> > > 
> > > Sasha
> > > 
> > > > 
> > > > -- Yevgeny.
> > > > 
> > > >  Original Message 
> > > > Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: 
> > > > syslog() fixes]
> > > > Date: Fri, 19 Jan 2007 00:20:32 +0200
> > > > From: Sasha Khapyorsky <[EMAIL PROTECTED]>
> > > > To: Michael S. Tsirkin <[EMAIL PROTECTED]>
> > > > CC: Yevgeny Kliteynik <[EMAIL PROTECTED]>,
> > > OPENIB 
> > > > References: <[EMAIL PROTECTED]>
> > > > <[EMAIL PROTECTED]>
> > > > 
> > > > On 23:50 Thu 18 Jan , Michael S. Tsirkin wrote:
> > > > > > Quoting Sasha Khapyorsky <[EMAIL PROTECTED]>:
> > > > > > Subject: Re: win related [was: Re: [PATCH 1/2] 
> opensm: sigusr1: 
> > > > > > syslog() fixes]
> > > > > > 
> > > > > > On 07:00 Thu 18 Jan , Michael S. Tsirkin wrote:
> > > > > > > > What about pure opensource - 
> > > > > > > > http://sourceware.org/pthreads-win32/? It is licensed 
> > > > > > > > under LGPL, I see on the net many positive reports about
> > > stability and usability.
> > > > > > > 
> > > > > > > I used it to do a windows port of linux complib at some 
> > > > > > > point and opensm seemed to work fine with it. What it was
> > > lacking at
> > > > > > > that point was support for 64 bit applications, 
> and for some 
> > > > > > > reason (which is still unclear to me) there was a
> > > strong desire to run opensm in 64 bit mode.
> > > > > > > Seems to have been fixed now, BTW.
> > > > > > 
> > > > > > So this seems to be good option for OpenSM on 
> Windows. Right?
> > > > > 
> > > > > No idea. Distributing a copy of the pthread DLL with
> > > opensm does not
> > > > > look like a problem. But is it worth it?
> > > > 
> > > > Sure, it makes windows porting much more transparent and
> > > let us to use
> > > > standard *nix stuff w/out #ifndef WIN32. Other 
> (generic) benefit 
> > > > is that posix is more standard and powerful than 
> wrappers like complib.
> > > > 
> > > > Sasha
> > > > 
> > > 
> 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [Fwd: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]]

[Tzachi Dar]

The windows open IB has decided on using a BSD only license. 
The common implementation of pthreads as far as I know is LGPL, which
means that it can not be used in open IB.

The only two ways that I see around this are 1) Change the license of
open IB windows which might be a complicated thing. 2) Find an
implementation of pthreads that is BSD.

Thanks
Tzachi

> -Original Message-
> From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, February 08, 2007 7:46 PM
> To: Tzachi Dar; Yossi Leybovich
> Cc: Yevgeny Kliteynik; OPENIB; Michael S. Tsirkin; Hal Rosenstock
> Subject: Re: [Fwd: Re: win related [was: Re: [PATCH 1/2] 
> opensm: sigusr1: syslog() fixes]]
> 
> On 11:24 Sun 21 Jan , Yevgeny Kliteynik wrote:
> > Tzachi, Yossi, please join the thread.
> > What do you think about distributing a copy of the pthread DLL with 
> > opensm?
> 
> Any news here? Thanks.
> 
> Sasha
> 
> > 
> > -- Yevgeny.
> > 
> >  Original Message 
> > Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: 
> > syslog() fixes]
> > Date: Fri, 19 Jan 2007 00:20:32 +0200
> > From: Sasha Khapyorsky <[EMAIL PROTECTED]>
> > To: Michael S. Tsirkin <[EMAIL PROTECTED]>
> > CC: Yevgeny Kliteynik <[EMAIL PROTECTED]>,
> OPENIB 
> > References: <[EMAIL PROTECTED]> 
> > <[EMAIL PROTECTED]>
> > 
> > On 23:50 Thu 18 Jan , Michael S. Tsirkin wrote:
> > > > Quoting Sasha Khapyorsky <[EMAIL PROTECTED]>:
> > > > Subject: Re: win related [was: Re: [PATCH 1/2] opensm: sigusr1: 
> > > > syslog() fixes]
> > > > 
> > > > On 07:00 Thu 18 Jan , Michael S. Tsirkin wrote:
> > > > > > What about pure opensource - 
> > > > > > http://sourceware.org/pthreads-win32/? It is licensed under 
> > > > > > LGPL, I see on the net many positive reports about 
> stability and usability.
> > > > > 
> > > > > I used it to do a windows port of linux complib at some point 
> > > > > and opensm seemed to work fine with it. What it was 
> lacking at 
> > > > > that point was support for 64 bit applications, and for some 
> > > > > reason (which is still unclear to me) there was a 
> strong desire to run opensm in 64 bit mode.
> > > > > Seems to have been fixed now, BTW.
> > > > 
> > > > So this seems to be good option for OpenSM on Windows. Right?
> > > 
> > > No idea. Distributing a copy of the pthread DLL with 
> opensm does not 
> > > look like a problem. But is it worth it?
> > 
> > Sure, it makes windows porting much more transparent and 
> let us to use 
> > standard *nix stuff w/out #ifndef WIN32. Other (generic) benefit is 
> > that posix is more standard and powerful than wrappers like complib.
> > 
> > Sasha
> > 
> 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Re: [openib-general] [Openib-windows] File transfer performance options

[Tzachi Dar]

Hi Paul,

In the beginning of this mail thread you have described a problem of
passing files from a Linux server to windows server. You have described
many experiments that you did and the fact that the performance that you
received was not as good as expected.

In reply I have advised you to consider using SDP for this file
transfers. if to summarize your answer in one sentence you said that SDP
is still not ready. I would have loved to tell you that SDP is ready,
but unfortunately the windows SDP is not a product yet. However, it is
mature enough to start doing some measurements which is what I did.

I have changed a simple benchmark program that I had to also write it's
data to disk. As a disk I have used AMT Ramdisk (512 MB). I have run two
instances of this program, and got the results of 578 MB/sec which is
considerably higher than results that you have achieved using other
experiments. (one client gave me 450 MB/sec)
Please note that since data is being copied 3 times in this scenario, we
are standing near the theoretical speed of the machine (one copy is from
the HCA to the kernel buffer, another is from the kernel buffer to the
application buffer, and that last copy is from the application buffer to
the Ram Disk).

It is true that the development road of your application might force you
not to use SDP, as SDP is not in production right now, but if you can
wait the extra time than please note that SDP can supply the BW.

Thanks
Tzachi

> -Original Message-
> From: Paul Baxter [mailto:[EMAIL PROTECTED] 
> Sent: Friday, September 01, 2006 1:11 AM
> To: openib-windows@openib.org; Tzachi Dar
> Subject: Re: [Openib-windows] File transfer performance options
> 
> >
> From: "Tzachi Dar" <[EMAIL PROTECTED]> There is one 
> thing that is missing from your mail, and that is if you want 
> to see the windows machine as some file server (for example 
> SAMBA, NFS, SRP), or are you ready to accept it as a normal 
> server. The big difference is that on the second option the 
> server can be running at user mode (for example FTP server).
> <
> 
> The windows machine has to list and then choose amongst a set 
> of files from our Linux system and retrieve only relevant 
> files e.g. those whose filename relates to particular time slots.
> We prefer not to write a Linux 'client' application to do 
> this explicitly but would rather have the windows machine's 
> application access our data files directly.
> A few application-level locks are in place so that we won't 
> be writing new files to our local disks at the same time as 
> the remote archiving accesses them.
> 
> Other than that the main goal is to make the inter-OS (and 
> inter-company) interface as simple as possible. It currently 
> doesn't seem that there is a proven solution to support this 
> at any transfer rate that takes significant advantage of Infiniband.
> 
> I've specced my disks for 200 MB/s and we have DDR cards etc. 
> (for other reasons!), just no means to flex their muscles too 
> easily using existing COTS infrastructure.
> 
> >
> When (the server application is) running at user mode, SDP 
> can be used as a socket provider.  This means that 
> theoretically every socket application should run and enjoy 
> the speed of Infiniband. Currently there are two projects of 
> SDP under development: one is for Linux and the other for 
> Windows, so SDP can be used to allow machines from both types 
> to connect.
> <
> 
> The key here is 'theoretical'. IMHO, Linux-Linux and 
> Windows-Windows get a lot more testing and priority than a 
> Linux-Windows combination. (Which is fair enough if that's 
> where the market is.)
> 
> We've been burnt by this not being robustly tested and proven 
> in reality in cross-platform cases. (Note that this was 
> before the current openfabrics windows driver initiative).
> 
> >
> Performance that we have measured on the windows platform, 
> using DDR cards was bigger than 1200 MB/Sec. (of course, this 
> data was from host memory, and not from disks).
> <
> 
> We've used SDP previously in our Linux message interface and 
> were very happy with the results. Then someone included an 
> old (v9 ) Solaris machine into the mix so even before we 
> tested on Windows, we ended up using sockets/gigabit ethernet 
> for command transfers.
> 
> SDP as an option for other parts of our application (large 
> data transfers) took a big turn for the worse when the 
> previous Linux SDP implementation was mothballed without a 
> mature replacement. We've ended up writing our application to 
> use RDMA write directly now.
> 
> Note that I'm not too critical of the way SDP went away since 
> I can apprecia

Re: [openib-general] [Openib-windows] File transfer performance options

[Tzachi Dar]

There is one thing that is missing from your mail, and that is if you
want to see the windows machine as some file server (for example SAMBA,
NFS, SRP), or are you ready to accept it as a normal server. The big
difference is that on the second option the server can be running at
user mode (for example FTP server).

When (the server application is) running at user mode, SDP can be used
as a socket provider.  This means that theoretically every socket
application should run and enjoy the speed of Infiniband. Currently
there are two projects of SDP under development: one is for Linux and
the other for Windows, so SDP can be used to allow machines from both
types to connect. Performance that we have measured on the windows
platform, using DDR cards was bigger than 1200 MB/Sec. (of course, this
data was from host memory, and not from disks).

So, if all you need to do is to pass files from one side to the other, I
would recommend that you will check this option.

One note about your experiments: when using ram disks, this probably
means that there is one more copy from the ram disk to the application
buffer. A real disk, has it's DMA engine, while a ram disk doesn't.
Another copy is probably not a problem when you are talking about
100MB/sec, but it would become a problem once you will use SDP (I hope).

Thanks
Tzachi





We've been testing an application that archives large quantities
of data 
from a Linux system onto a Windows-based server (64bit server
2003 R2).

As part of the investigation into relatively modest transfer
speeds in the 
win-linux configuration, we configured a Linux-Linux transfer
via IpoIB with 
NFS layered on top (with ram disks to avoid physical disk
issues)

[Whilst for a real Linux-Linux configuration I would look for
the RDMA over 
NFS solution, this wouldn't translate to our eventual win-linux 
inter-operable system.]

I was surprised that even on linux-linux I hit a wall of 100MB/s
(test notes 
below). Are others doing better? I was hoping for 150MB/s -
200MB/s

Does anyone have any hints on tweaking of an IPoIB/NFS solution
to get 
better throughput for large files (not so concerned about
latency).

Are there any other inter-operable windows-linux solutions now? 
(cross-platform NFS over RDMA or SRP initiator/target?)

Paul Baxter




___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] Microsoft virtual machine and Infiniband

[Tzachi Dar]

Hi 
Fab,
 
When trying to run 
windows 2003 server on a Microsoft virtual machine we have found out that there 
is one problem that prevents IPOIB from running.
 
The problem as you 
can guess is related to the way MAC addresses are being handled. On such a 
machine, a fake Mac addresses is being created and it is later used for 
communication (one MAC per guest OS). However although this packets return to 
the correct computer, IPOIB doesn't restore their correct dest MAC and 
therefore pinging to a remote host is impossible.
 
In order to solve 
this problem there is a need to create a mechanism that will allow the IPOIB 
driver to correct the MAC addresses of packets based on their IP 
addresses.
 
It seems that the 
best way to do this is to have a "static" table of IP's and MAC addresses and to 
check every IP packet as well as every ARP reply. We have done such an 
experiment and it did seems to work.
 
We are still looking 
for a way to configure the table of guest OS and their IPs and MACs. One way to 
achieve this is simply having a static table that will be entered through some 
file. Although this is the simplest way, it has an obvious disadvantage (the 
need to manually configure the machine). A different way is to find some 
configuration API's that the remote machine has, while the last possibility is 
trying to find the information by sniffing for packets (the way that an Ethernet 
switch does things).
 
One bug that I have 
already found is that if a broadcast packet is sent for example an ARP 
request, we send the packet as a multicast, and we also receive the packet 
ourselves, and later we send this packet to NDIS. This is not the correct 
behavior (assuming we are emulating Ethernet behavior) and we should remove this 
packets.
 
In the next week 
I'll try to create a patch that will allow the virtual machine to work, I just 
wanted to know what your opinion about this issue.
 
Thanks
Tzachi
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] RE: [Openib-windows] NFS performance and general disk network exportadvice (Linux-Windows)

[Tzachi Dar]

Here is some help from my side. I'm not so familiar with NFS but I'll
try to help.

IPoIB works well between Linux and windows, so running some NFS client
should work well if both sides uses IPoIB.

If, and this is a big if, both the NFS client on windows and the Linux
sides are using (TCP) sockets, one can use SDP in order to communicate
with high bandwidth.

Please note that even if both are using sockets, there is a need to
verify if the windows side is using the sockets from the user mode or
from the kernel. Currently SDP can only work with sockets at the user
level and if the client is actually a driver we should either write a
connecting layer, or find another client.

SDP on windows currently reaches ~1250MB of bandwidth, so I believe that
you will get the BW you need.

Thanks
Tzachi

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Baxter
> Sent: Thursday, February 09, 2006 10:18 PM
> To: openib-windows@openib.org
> Cc: openib-general@openib.org
> Subject: [Openib-windows] NFS performance and general disk 
> network exportadvice (Linux-Windows)
> 
> I'm looking to export a filesystem from each of four linux 
> 64bit boxes to a single Windows server 2003 64bit Ed.
> 
> Has anyone achieved this already using an IB transport? Can I 
> use NFS over IPoIB cross platform? i.e. do both ends support 
> a solution?
> 
> Is NFS over RDMA compatible with Windows (pretty sure the 
> answer is no to this one but love to be proven wrong). I've 
> attached Tom's announcement of the latest to the bottom of 
> this email. I don't think Windows has the RDMA abstraction (yet)?
> 
> Are windows IB drivers (Openib or Mellanox) compatible with 
> these options? 
> Do I layer Windows services for Unix on top of the Windows IB 
> drivers and IPoIB to achieve a cross platform NFS?
> 
> Has anyone done much in the way of NFS performance 
> comparisons of NFS over IPoIB in cross-platform situations vs 
> say Gigabit ethernet. Does it work :) What is large file 
> throughput and processor loading - I'm aiming for 150-200 
> MB/s on large files on 4x SDR IB (possibly DDR if we can fit 
> the bigger 144 port switch chassis into our rack layout for 
> 50-ish nodes).
> 
> Are there any alternatives to using NFS that may be better 
> and that would 'transparently' receive a performance boost 
> with IB compared with using a simple NFS/gigabit ethernet 
> solution. Must be fairly straightforward, ideally application 
> neutral (configure a drive and load/unload script for Linux 
> and it just happens) and compatible between Win2003 and Linux? 
> Alternatives using perhaps Samba on the Linux side?
> 
> My lack of knowledge of IB in the windows world has got me 
> concerned over whether this is actually achievable (easily).
> 
> I hope to be trying this once we get a Windows 2003 machine, 
> but hope someone can encourage me that its a breeze prior to 
> my coming unstuck in a month or so!
> 
> Some detail about the bit I do understand:
> 
> I will be using a patched Linux kernel (realtime preemption 
> patches ) but prefer not to apply/track too many kernel 
> patches as the kernel evolves. The NFS patches suggested by 
> Tom in his announcement below make me a little nervous.
> 
> The application will alternate between a real-time mode with 
> (probably) no NFS (or similar network exporting of the disk) 
> and an archiving mode where Linux will load relevant network 
> filesystem modules and let the windows machine read the disks.
> 
> The reason for this odd load/unload behaviour is because our 
> current experience with NFS has been that the driver is prone 
> to putting multi-millisecond glitches that have a habit of 
> upsetting (soft) real-time behaviour at the sorts of timing 
> latencies we're looking at (milliseond or two). NFS (and 
> network cards) do like to batch up work and then run these 
> from interrupt contexts. SoftIRQs help tremendously but don't 
> seem to be the complete answer.
> 
> Paul Baxter
> 
> Tom's announcement:
> > We have released an updated NFS/RDMA client for Linux at 
> the project's 
> > Sourceforge site:
> >
> > 
> >
> > 
>  > d=178973>
> >
> > This release updates the RPC/RDMA support as follows:
> > Linux 2.6.15.2 supported
> > Integrates with RPC via 2.6.15 transport switch Employs OpenIB RDMA 
> > verbs API (not kDAPL) Dual BSD/GPL2 licensing
> >
> > There are no protocol changes in this release, it is 
> identical to the 
> > previous release (and the IETF draft) in this respect. The 
> client has 
> > been tested with NFSv3 and passes the Connectathon test suite.
> >
> > At present, the client requires some additional transport switch 
> > patches to be applied to the Linux kernel, these are available at 
> > Chuck Lever's patches page:
> > 
> 
> >
> > The r