ELOG Midas

Back Midas Rome Roody Rootana

Midas DAQ System, Page 118 of 126

Not logged in

Find | Login | Help

New entries since:

Wed Dec 31 16:00:00 1969

Full | Summary | Threaded | Hide attachments

2501 Entries

Goto page Previous 1, 2, 3 ... 117, 118, 119 ... 124, 125, 126 Next

Redesign of status page links

> The custom and alias links in the standard midas status page were shown as HTML 
> links so far. If there are many links with names having spaces in their names, 
> it's a bit hard to distinguish between them. Therefore, they are packed now into 
> individual buttons (see attachment) starting from SVN revision 4633 on. This makes 
> also the look more homogeneous. If there is any problem with that, please report.

Would you consider using a different colour for the alias buttons (or background
colour)? At present it's hard to know whether a button is an alias link, a custom page
link or a user-button especially if you are not familiar with the button layout.

custom page - flashing filled area

Hi,

On a custom web page, can a "filled" area be made to flash (i.e. cycle between 
two colours)? This area would have to update faster than the whole page update.
 
I have a custom page representing a gas system, and the users
want the heaters to flash when they are on, as is done in their EPICS page.

Thanks,
Suzannah

AJAX jmsg "get messages since t" ability - add to docs?

> I recently needed to watch the Midas messages for a particular error - and 
> thus needed a command to "get all the messages since a time t".
> 
> The documentation (https://midas.triumf.ca/MidasWiki/index.php/AJAX#jmsg) 
> documents a way to "get the most recent n messages" - but when I dug into the 
> code, I was delighted to find that the existing Midas code also supports the 
> "get all messages since t" query.
> 
> For the "get all messages since t" query, the parameter t should be the unix 
> timestamp in seconds, and the parameter n should be zero: curl -X GET 
> "http://localhost:8081/?cmd=jmsg&n=0&t=1473437918".
> 
> Pretty useful!  Perhaps this should be added to the AJAX documentation?

Thank you - I have added it to the documentation.

link to an array element displays whole array in mhttpd

A link to an array variable such as

[local:npet:Stopped]/>ls /rcparams/ControlVariables/
TRFC:PB5 (V) -> /Equipment/Beamline/Variables/Demand[56]
                                17835

displays the whole Demand array on the mhttpd ODB page (see attachment)
rather than just the one element Demand[56].
This behaviour also occurs with older versions of mhttpd.
 
Not sure if it's a bug or a feature, but my suggestion is that it
ought to display the one element only (as odbedit does) and not the whole array.

Suzannah

Attachment 1: controlvar.png

link to an array element displays whole array in mhttpd

Further to my last message, I see that a midas version from 2013 does indeed display
links to arrays as I would expect (see attachment). Therefore the problem in later
versions  is a bug rather than a feature.


> A link to an array variable such as
> 
> [local:npet:Stopped]/>ls /rcparams/ControlVariables/
> TRFC:PB5 (V) -> /Equipment/Beamline/Variables/Demand[56]
>                                 17835
> 
> displays the whole Demand array on the mhttpd ODB page (see attachment)
> rather than just the one element Demand[56].
> This behaviour also occurs with older versions of mhttpd.
>  
> Not sure if it's a bug or a feature, but my suggestion is that it
> ought to display the one element only (as odbedit does) and not the whole array.
> 
> Suzannah

Attachment 1: controlvar_good.png

link to an array element displays whole array in mhttpd

> It might have worked some ~5 years ago, but it never really showed the target value of a link, just the 
> link itself. I reworked the code now to show both the link and the target of the link, so you can change 
> both in the mhttpd ODB page. Should be consistent now with odbedit. Have a look if it works for you.
> 
> Stefan

Thank you. That has solved the problem.
Suzannah

Gyrations of custom pages and ODB /Custom/Path

I see two separate issues here. 

One is restricting the custom pages to ONE directory such as 
<exptab>/resources -> /home/users/exp/resources
and its subdirectories which seems like a good solution for all the
reasons you've mentioned. 

The other issue is the use of the "Path" key in /Custom, which is used to differentiate
between the "new" way (all resources served from the Path directory) 
and the original way where all the custom keys are specified with their full directories.

Recent versions of Midas had broken the original behaviour by insisting on the presence of the
"Path" key.  Konstantin fixed this by allowing the "Path" key to take the value "".  It is true
that some experiments currently may be serving resources from more than one directory tree, but changing
to storage of all custom pages in one directory (and its subdirectories) does not necessarily mean that
the original way of serving resources must be made obsolete.
 
I actually like the original way of specifying the custom keys for the pages and resources under /Custom, which
is presently selected  without the /Custom/Path key present at all (older versions) or with the
/Custom/Path key set to "" (latest versions). I like it for debugging, and I like to be able to see 
at a glance what resource files are in use from /Custom. 

I have a suggestion:

The resources could still be served from the /Custom directory if desired, except now mhttpd will ALWAYS add the 
fixed path in front of the given paths in /Custom. This would mean a fixed path and a minimal disruption to older pages 
(the <script> and <link> statements in the HTML code to include the resources would not need to be changed).
The "/Path" key is no longer be useful, since the resource path is now fixed. Instead a key e.g. "FlagRS"  could 
be used to select the desired behaviour,  with the default being the "new" (no key present).

For example, the full directory paths in /custom
ScanParams&                     /home/users/online/custom/scan/scan_select_popup.html
mpet.css!                       /home/users/online/custom/rs/mpet.css
scanvoltages!                   /home/users/online/custom/scan/scan_voltages.js

would become subdirectory path(s)
ScanParams&                     custom/scan/scan_select_popup.html
mpet.css!                       custom/rs/mpet.css
scanvoltages!                   custom/scan/scan_voltages.js
FlagRS                          y

The pages would be served from /home/users/exp/resources/custom/...

Suzannah

 
> > Hi Stefan and Konstantin,
> > 
> > I think that this proposal sounds fairly reasonable.  I agree that we might as well move to a secure final solution at this point.  
> > 
> > One comment: since this change would break almost every experiment I have worked on for the last 4 years, it would be nice to add a command-line option to mhttpd that preserves the old /Custom/Path behavior.  This would allow experiments a transition 
> > period, so that they didn't immediately need to fix their setup.  The command-line option could be clearly marked as obsolete behaviour and could be removed within a year.
> > 
> > Cheers,
> > Thomas
> > 
> > 
> > 
> > > Parsing all URL in mhttpd to prevent /etc/passwd etc. to be returned is tricky, because people can use escape sequences etc. Therefore I think it is much better to restrict file access 
> > > on the file system level when opening a file. The only escape there one could have is "..", which can be tested easily. 
> > > 
> > > Therefore, I propose to restrict file access to two well-defined directories, which is one system directory and one user directory. The system directory should be defined via 
> > > $MIDASSYS/resources, and the user directory should be the experiment directory (as defined in exptab) followed by "resources". So if MIDASSYS equals to /usr/local/midas and the 
> > > experiment directory equals to /home/users/exp for example, we would only have these two directories (and of course the subdirectories within these) served by mhttpd:
> > > 
> > > $MIDASSYS/resource -> /usr/local/midas/resources
> > > <exptab>/resources -> /home/users/exp/resources
> > > 
> > > These directories should be hard-wired into mhttpd, and not go through and ODB entry, since otherwise one could manipulate the ODB entries (knowingly or unknowingly) and open a 
> > > back-door. 
> > > 
> > > If users need a more complex structure, they can put soft links into these directories.
> > > 
> > > The code which opens a resource file should then first evaluate $MIDASSYS, then add "/resources/", then add the requested file name, make sure that there is no ".." in the file name, 
> > > then open the file. If not existing, do the same for the <exptab>/resources/ directory.
> > > 
> > > This change will break most experiments, and forces people to move their custom pages to different directories, but I think it's the only clean solution and we just have to bite the 
> > > bullet.
> > > 
> > > Comments are welcome.
> > > 
> > > Stefan

Replacing MIDAS status page with custom status page

Replacing the MIDAS status page with a custom status page documented at

https://midas.triumf.ca/MidasWiki/index.php/Custom_Page_Features#Replace_Status_Page_by_a_Custom_page

does not appear to be supported in the current MIDAS version. 

As two of my experiments use this feature may I suggest its reinstatement?

Suzannah

2125

05 Mar 2021

Svetlana Chesnevskaya

Bug Report

New MIDAS old frontend incompatibility

Hello!

Could you help me solve the problem of compatibility between our frontend (created in 2017) and the fresh MIDAS? The old MIDAS (2017) worked well, then we did not use it.
While compiling the frontend, I get a lot of warnings and a few compilation errors.

Any help will be greatly appreciated.

Thanks in advance.
With the best regards,
Svetlana

Attachment 1: error.log

g++ -c -m64 -g -O0 -Wall -Wextra  -I. -I/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include -I/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/drivers/vme -I/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/drivers/vme/sis3100 -I/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/drivers/vme/sis3100/linux -L/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/drivers/vme/sis3100/lib -Wunused-variable -DHAVE_MIDAS__  -D__HAVE_MIDAS -I./include -I./include/CP80190_80057 -DOS_LINUX -Dextname src/realEventFrontend.cc -o src/realEventFrontend.o
In file included from ./include/v1742.hh:4:0,
                 from src/realEventFrontend.cc:16:
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1336:21: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD event_id = 0;
                     ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1338:18: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD n_tag = 0;
                  ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1343:19: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int hist_fh  = 0;
                   ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1344:19: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int index_fh = 0;
                   ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1345:19: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int def_fh   = 0;
                   ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1346:23: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD base_time  = 0;
                       ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/midas.h:1347:23: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD def_offset = 0;
                       ^
In file included from src/realEventFrontend.cc:18:0:
./include/CP80057.hh: In Konstruktor »CP80057::CP80057(unsigned int, MVME_INTERFACE*, HNDLE)«:
./include/CP80057.hh:20:45: Warnung: Konvertierung in Nicht-Zeiger-Typ »uint32_t {aka unsigned int}« von NULL [-Wconversion-null]
       vme_port_addr(vmeBaseAdress), port(0x0)                          {}
                                             ^
src/realEventFrontend.cc: Im globalen Gültigkeitsbereich:
src/realEventFrontend.cc:32:42: Warnung: verengende Umwandlung von »2425356288u« von »unsigned int« nach »const int« in { } ist in C++11 ungültig [-Wnarrowing]
                                0x90910000};
                                          ^
src/realEventFrontend.cc:32:42: Warnung: verengende Umwandlung von »2425421824u« von »unsigned int« nach »const int« in { } ist in C++11 ungültig [-Wnarrowing]
In file included from src/realEventFrontend.cc:48:0:
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:348:22: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    BOOL is_mserver = 0;             /*  this is an mserver server-side connection */
                      ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:349:20: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int send_sock = 0;               /*  tcp send socket         */
                    ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:350:20: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int recv_sock = 0;               /*  tcp receive socket      */
                    ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:351:21: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    int event_sock = 0;              /*  tcp event socket        */
                     ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:352:25: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT remote_hw_type = 0;          /*  hardware type           */
                         ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:353:27: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT watchdog_timeout = 0;        /*  in milliseconds         */
                           ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:354:26: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    DWORD last_activity = 0;         /*  time of last recv       */
                          ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:355:24: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT convert_flags = 0;           /*  convertion flags        */
                        ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:358:26: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT net_buffer_size = 0;         /*  size of TCP cache       */
                          ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:359:18: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT write_ptr=0, read_ptr=0, misalign=0;   /* pointers for cache */
                  ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:359:30: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT write_ptr=0, read_ptr=0, misalign=0;   /* pointers for cache */
                              ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:359:42: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT write_ptr=0, read_ptr=0, misalign=0;   /* pointers for cache */
                                          ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:360:21: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT ev_write_ptr=0, ev_read_ptr=0, ev_misalign=0;
                     ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:360:36: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT ev_write_ptr=0, ev_read_ptr=0, ev_misalign=0;
                                    ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:360:51: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    INT ev_write_ptr=0, ev_read_ptr=0, ev_misalign=0;
                                                   ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:361:23: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    HNDLE odb_handle = 0;            /*  handle to online datab. */
                       ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:362:26: Warnung: nicht-statische Initialisierungen für Datenelemente nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäßig aktiviert]
    HNDLE client_handle = 0;         /*  client key handle .     */
                          ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:525:34: Fehler: Deklaration der C-Funktion »std::string cm_get_path()« steht in Konflikt mit
    std::string EXPRT cm_get_path();
                                  ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:524:14: Fehler: vorherige Deklaration »INT cm_get_path(char*, int)« hier
    INT EXPRT cm_get_path(char *path, int path_size);
              ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:629:31: Fehler: Deklaration der C-Funktion »std::string ss_gethostname()« steht in Konflikt mit
    std::string ss_gethostname();
                               ^
/home/svetlana/packages/hodor_DAQ/ASACUSA/midas/include/msystem.h:628:8: Fehler: vorherige Deklaration »INT ss_gethostname(char*, int)« hier
    INT ss_gethostname(char* buffer, int buffer_size);
        ^
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
       };  
       ^
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::driver« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::event_descrip« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::status_color« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::hidden« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »EQUIPMENT_INFO::write_cache_size« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::readout« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::driver« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::event_descrip« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::cd_info« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::status« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_called« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::last_idle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::poll_count« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::format« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::buffer_handle« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::hkey_variables« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::serial_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::subevent_number« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_out« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::odb_in« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::bytes_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::events_sent« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:200:7: Warnung: Initialisierung für Element »eqpmnt::stats« fehlt [-Wmissing-field-initializers]
src/realEventFrontend.cc:295:5: Warnung: unbenutzter Parameter »run_number« [-Wunused-parameter]
 INT begin_of_run(INT run_number, char *error){
     ^
src/realEventFrontend.cc:295:5: Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
src/realEventFrontend.cc:337:5: Warnung: unbenutzter Parameter »run_number« [-Wunused-parameter]
 INT end_of_run(INT run_number, char *error){
     ^
src/realEventFrontend.cc:337:5: Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
src/realEventFrontend.cc:351:5: Warnung: unbenutzter Parameter »run_number« [-Wunused-parameter]
 INT pause_run(INT run_number, char *error){
     ^
src/realEventFrontend.cc:351:5: Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
src/realEventFrontend.cc:357:5: Warnung: unbenutzter Parameter »run_number« [-Wunused-parameter]
 INT resume_run(INT run_number, char *error){
     ^
src/realEventFrontend.cc:357:5: Warnung: unbenutzter Parameter »error« [-Wunused-parameter]
src/realEventFrontend.cc:395:5: Warnung: unbenutzter Parameter »cmd« [-Wunused-parameter]
 INT interrupt_configure(INT cmd, INT source, PTYPE adr){
     ^
src/realEventFrontend.cc:395:5: Warnung: unbenutzter Parameter »source« [-Wunused-parameter]
src/realEventFrontend.cc:395:5: Warnung: unbenutzter Parameter »adr« [-Wunused-parameter]
src/realEventFrontend.cc:521:5: Warnung: unbenutzter Parameter »off« [-Wunused-parameter]
 INT read_clock_event(char *pevent, INT off){
     ^
src/realEventFrontend.cc:550:5: Warnung: unbenutzter Parameter »off« [-Wunused-parameter]
 INT read_calibration_data_event(char *pevent, INT off){
     ^
src/realEventFrontend.cc:572:5: Warnung: unbenutzter Parameter »off« [-Wunused-parameter]
 INT read_tdc_event(char *pevent, INT off){
     ^
src/realEventFrontend.cc:644:7: Warnung: unbenutzter Parameter »ptr« [-Wunused-parameter]
 void *updateCUSPRunNumber(void *ptr){
       ^
src/realEventFrontend.cc:658:7: Warnung: unbenutzter Parameter »ptr« [-Wunused-parameter]
 void *restartRun(void *ptr){
       ^
make: *** [src/realEventFrontend.o] Fehler 1

mhttpd truncates string variables to 32 characters

I find that new mhttpd has strange behaviour for ODB strings.

- I create a new STRING variable in ODB through mhttpd.  It defaults to size 32.

- I then edit the STRING variable through mhttpd, writing a new string larger
than 32 characters.

- Initially everything looks fine; it seems as if the new string value has been
accepted.

- But if you reload the page, or navigate back to the page, you realize that
mhttpd has silently truncated the string back to 32 characters.

You can reproduce this problem on a test page here:

http://midptf01.triumf.ca:8081/AnnMessage

Older versions of mhttpd (I'm testing one from 2 years ago) don't have this
'feature'.  For older mhttpd the string variable would get resized when a larger
string was inputted.  That definitely seems like the right behavior to me.

I am using fresh copy of midas from bitbucket as of this morning. (How do I get
a particular tag/hash of the version of midas that I am using?)

Check if Client is running from Javascript

Andreas Suter wrote:

Is there currently an easy way to check from javascript if a midas client is
running? I mean an equivalent to cm_exist.

Sometimes this would be very useful in custom pages.

It is not as clean as what you asked, but I have in the past written javascript like this to check if a program is running

var req = new Array();
req[0]= "Programs/towerfe3_00/First failed";
var result = ODBMGet(req);
if(result[0] == 0){
// then program is running
}

jset/ODBSet using true/false for booleans

MIDAS does not seem to be consistent (or at least convenient) with how it
handles booleans in AJAX functions.

When you request an ODB value that is a boolean with AJAX call like

http://neut14.triumf.ca:8081/?cmd=jcopy&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys

then you get

{ "Hidden/last_written" : 1437065425, "Hidden" : false }

This seems correct, since the JSON convention has booleans encoded as true/false.

But this convention does not work when trying to set the boolean value. For instance

http://neut14.triumf.ca:8081/?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=true

does not set the variable to true. To make this work you need to use the
characters y/n

http://neut14.triumf.ca:8081/?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=y

I tested this with ajax/jset, but the same problem seems to occur when using the
javascript function ODBSet. The documentation doesn't say what sort of encoding
to use when using these functions, so I guess the idea is that these functions
use MIDAS encoding for booleans. But it seems to me that it would be more
convenient if jset/ODBSet allowed the option to use json/javascript encoding for
boolean values; or at least had that as a format option for jset/ODBSet.  That
way my javascript could look like

var mybool = true;
URI_command =
"?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=" + mybool;

instead of

var mybool = true;
URI_command = ""
if(mybool){
  URI_command =
"?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=y";
else
  URI_command =
"?cmd=jset&odb=/Equipment/DCRC/Common/Hidden&format=json-nokeys&value=n";


__________________________________________________________
Cross-posting from bitbucket issue tracker:

https://bitbucket.org/tmidas/midas/issues/29/jset-odbset-using-true-false-for-booleans

MIDAS message page auto-size (horizontally) is annoying

New version of MIDAS has a feature where it seems to automatically resize the
message page horizontally in order to fix each MIDAS message into one line. 
Some of my MIDAS messages (in particular error messages, where I need details)
are very long.  The result is that the MIDAS page automatically becomes very
wide and I have to scroll a lot left/right in order to read my messages.  This
is annoying.

I would vote to roll-back this new feature.

mhttpd HTTPS/SSL server updated

> 
> I recommend that you use "mhttpd --mg" as the alternative for running "mhttpd -p" behind an apache 
> proxy. Using "mhttpd -p" (no HTTPS/SSL) on an internet-connected machine is insecure and should not be 
> done. (private network such as 192.168.x.y addresses is okey for now, I guess).

Finally reading through your documentation in detail [1,2].  I find that I don't understand this recommendation to use secure mongoose 
instead of putting mhttpd behind an apache proxy.  I think that it is nice to have secure mhttpd with mongoose as an option, but your 
documentation seems to imply that mhttpd-mongoose is much better than mhttpd-behind-apache and that the latter solution is strongly 
deprecated.

Perhaps I am not understanding the benefits of the new system.  In reference [2] you say "If this is not possible, somewhat better security 
for HTTP is gained by using a password protected SSL (https) proxy."  This seems to imply that the security of mhttpd-mongoose is better 
than the security of mhttpd-behind-apache.  Is that correct?  I thought that they provided similar security (assuming you follow 
recommended configurations for APACHE).

Setting up apache is trivial and it seems that mhttpd-behind-apache has other advantages, like being able to put other web resources 
(ganglia, cameras, elog, etc) behind the same secure server.  Also you can start to build complicated custom pages that are served directly 
from apache and just use MIDAS AJAX calls.  I was imagining slowly moving away from using mhttpd at all and just having html/js/css 
resources served up by apache.

So, unless I'm missing something, at this point I would continue to recommend people use mhttpd-behind-apache and I'd suggest this be 
presented as an equally valid option in the documentation.

[1] https://midas.triumf.ca/MidasWiki/index.php/Mhttpd
[2] https://midas.triumf.ca/MidasWiki/index.php/Setup_MIDAS_experiment#Install_SSL_proxy

mhttpd HTTPS/SSL server updated

> > 
> > I find that I don't understand this recommendation to use secure mongoose 
> > instead of putting mhttpd behind an apache proxy.
> >
> 
> This is a very valid question.
> 
> I think for a small operation that does not require root access to the host computer, mhttpd+mongoose is a good light weight solution.
> ...
> So, which one to use?
> 
> - for maximum security, use httpd apache (but remember to restrict access to mhttpd web port to be "only from the proxy")
> - for light-weight cases, or when root access is not available use built-in https in mhttpd.
> 
> The midas wiki documentation should probably be updated to explain all of this.


Thanks for the detailed explanation.  I agree with your recommendations.  I was mostly interested in having both options treated equally in the documentation.

My only small complaint is that since the default mhttpd comes with mongoose security turned on, you need to explicitly disable the mhttpd+mongoose security first before you can start setting up apache.  I guess that the motivation is 
that we should force people to disable security, rather than hoping that they will enable it.  That's a convincing argument; so all I really need is that this procedure be well documented.

mhttpd/SSL error message on MacOS

On my macbook (OS X 10.10.3) I get this error message when starting mhttpd with mongoose-SSL:

[mhttpd,ERROR] [mhttpd.cxx:17092:mongoose,ERROR] mongoose web server error: set_ssl_option: 
openssl "modern cryptography" ECDH ciphers not available

mhttpd seems to start fine anyway and safari connects to the secure midas page without complaining 
about the SSL (it complains about the certificate of course).  So maybe this error message is 
relatively harmless?

I don't get this error message with Scientific Linux 6.7.

Documentation regarding specifying custom pages

Hi,

We have recently been changing the code in mhttpd that maps custom web pages and resources to 
particular files on the server file system.  Ie, changing the code that uses the ODB keys in /Custom to 
map a web address like 

http://myhost:8081/CS/MyCustomPage 

to some file like

/home/user/resource/mypage.html

This mapping gets complicated when you use the /Custom/Path key to specify a location for web 
resources like images.  We have tried to summarize how the current system works on the wiki

https://midas.triumf.ca/MidasWiki/index.php//Custom_ODB_tree

Please provide any suggestions on how either the documentation or the actual algorithm can be 
improved.

reducing sleep time in mhttpd main loop (for sequencer)

There were some complaints that the MIDAS sequencer was slow.  Specifically, the
complaint was that even lines in the sequence that didn't do any (like COMMENT
commands) tooks > 100ms to execute.  These slow sequencer steps could be a
little annoying if a script had to change a large number of ODB variables before
starting.

I tested this a little using a trivial sequence; note that I did all tests using
mhttpd with mongoose enabled on a newer macbook pro.  I found that with the
mongoose server each line in a sequencer script was taking ~100ms.  This is
consistent with the loop in the main thread, which is only doing a cm_yield and
a sleep:

   while (!_abort) {
      status = ss_mutex_wait_for(request_mutex, 0);
      status = cm_yield(0);
      if (status == RPC_SHUTDOWN)
         break;
      sequencer();
      status = ss_mutex_release(request_mutex);
      ss_sleep(100);
   }

I tested reducing the sleep to 20ms.  As expected, this made the sequencer more
zippy, able to execute ~50 commands per second.

I tried to think what would be downsides to making this change.  I think that
the main web communication should not be affected, because that communication is
all handled by the separate mongoose thread.

I checked how much extra CPU was used if the sleep was reduced from 100ms to
20ms.  I found that when a sequence was not running the CPU increased from 0% to
0.2% with my change.  When a sequence was running the CPU increased from 0.8% to
4% with my change.  4% is a little high, though I'd say still reasonable.  I
found that most of the CPU usage was occuring because every call to
'sequencer()' resulted in a call to db_set_record("/Sequencer/State"...).  I
guess that making that call 50 times causes the somewhat heavy CPU usage.

I would argue that it would still be worth making that change, so that the
sequencer can be more zippy.

reducing sleep time in mhttpd main loop (for sequencer)

> There were some complaints that the MIDAS sequencer was slow.  Specifically, the
> complaint was that even lines in the sequence that didn't do any (like COMMENT
> commands) tooks > 100ms to execute.  These slow sequencer steps could be a
> little annoying if a script had to change a large number of ODB variables before
> starting.
> ...
> I checked how much extra CPU was used if the sleep was reduced from 100ms to
> 20ms.  I found that when a sequence was not running the CPU increased from 0% to
> 0.2% with my change.  When a sequence was running the CPU increased from 0.8% to
> 4% with my change.  4% is a little high, though I'd say still reasonable.  I
> found that most of the CPU usage was occuring because every call to
> 'sequencer()' resulted in a call to db_set_record("/Sequencer/State"...).  I
> guess that making that call 50 times causes the somewhat heavy CPU usage.

One additional point: I think that it would be reasonably simple to reduce this CPU
usage even while a sequence was going on.  I would guess that for many sequences a
lot of time was spent in a 'WAIT SECONDS' command, since you would presumably want
to wait while data was being taken or conditions stabilizing.  I think that if you
are in a 'WAIT SECONDS' command that hasn't been satisfied then there probably isn't
any reason to do the db_set_record at the end of the sequencer() method.

reducing sleep time in mhttpd main loop (for sequencer)

> > I checked how much extra CPU was used if the sleep was reduced from 100ms to
> > 20ms.  I found that when a sequence was not running the CPU increased from 0% to
> > 0.2% with my change.  When a sequence was running the CPU increased from 0.8% to
> > 4% with my change.  4% is a little high, though I'd say still reasonable.  I
> > found that most of the CPU usage was occuring because every call to
> > 'sequencer()' resulted in a call to db_set_record("/Sequencer/State"...).  I
> > guess that making that call 50 times causes the somewhat heavy CPU usage.
> > 
> > I would argue that it would still be worth making that change, so that the
> > sequencer can be more zippy.
> 
> The minimal time slice on most systems is 10 ms, and nothing prevents us from switching to
> that. The original 100 ms was more for the fact that you can see the sequencer statements
> executed one after the other (with the color bar). But this is more a "debugging" feature which 
> we not really need. 

OK, I made this change; sleep is now 10ms on main thread.  Seems to work fine on SL6 and MacOS.

> To do it "right" the sequencer would have to _return_ a sleep time. Like if it is in a wait loop (as
> most of the time), the sleep time could be close to 1 second, to correctly update the wait
> progress bar. If the sequencer executes ODB set statements, the wait time could be zero, so
> thousands of statements can be executed in one second. The problem we will then have of course
> that the sequencer will block the "request_mutex" almost always, which would prevent the
> mongoose server from serving anything. So this should be carefully tested. It could be (on most OS)
> that releasing the mutex by the main loop immediately switches to the mongoose thread, which would
> make the web server still quite responsive, but I'm not sure about that. So as a first change making
> the sleep time 10ms should be fine.

Hmm, yeah, I'm not sure about how to handle reducing the wait time to zero after ODB set commands.

But it does seem like it would be straight-forward to increase the sleep time for waits; I'll look into
a clean way of doing that.

Goto page Previous 1, 2, 3 ... 117, 118, 119 ... 124, 125, 126 Next

ELOG V3.1.4-2e1708b5