Back Midas Rome Roody Rootana
  Midas DAQ System  Not logged in ELOG logo
Entry  09 May 2007, Carl Metelko, Forum, Splitting data transfer and control onto different networks 
    Reply  09 May 2007, Stefan Ritt, Forum, Splitting data transfer and control onto different networks 
    Reply  09 May 2007, Konstantin Olchanski, Forum, Splitting data transfer and control onto different networks 
    Reply  14 May 2007, Carl Metelko, Forum, Splitting data transfer and control onto different networks 
Message ID: 371     Entry time: 09 May 2007     In reply to: 369
Author: Konstantin Olchanski 
Topic: Forum 
Subject: Splitting data transfer and control onto different networks 
> I'm setting up a system with two networks with the intension of having
> control info (odb, alarm) on the 192.168.0.x
> and the frontend readout on 192.168.1.x

We have some experience with this at TRIUMF - the TWIST experiment we run with the main data 
generating frontends on a private network - it is a supported configuration and it works fine.

We ran into one problem after adding some code to the frontends for stopping the run upon detecting 
some data errors - stopping runs requires sending RPC transactions to every midas client, so we had to 
add static network routes for routing packets between midas nodes on the private network and midas 
nodes on the normal network.

> I'm also trying to separate processes onto different machines, is there
> any way to not have mserver,mhttpd and (mlogger,mevt) all run on the same machine?

mserver runs on the machine with the ODB shared memory by definition (think of it as "nfs server").

mhttpd typically runs on the machine with the ODB shared memory and until recently it had no code for 
connecting to the mserver. I recently fixed some of it, and now you can run mhttpd in "history mode" 
through the mserver. This is useful for offloading the generation of history plots to another cpu or 
another machine. In our case, we run the "history mhttpd" on the machine that holds the history files.

mlogger could be made to run remotely via the mserver, but presently it will refuse to do so, as it has 
some code that requires direct access to midas shared memory. If data has to be written to a remote 
filesystem, the consensus is that it is more efficient to run mserver locally and let the OS handle remote 
filesystem access (NFS, etc).

All other midas programs should be able to run remotely via the mserver.

K.O.
ELOG V3.1.4-2e1708b5