Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 505 of 808  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Email Category OSdown ELOG Version Subject
  67273   Mon May 14 22:19:50 2012 Reply Tim Thieltt2005@thieleng.comQuestionLinux2.9.0Re: HW Requirements to run elog / Performance issues running on ARM

Stefan Ritt wrote:

Tim Thiel wrote:

Yoshio Imai wrote:

Hi!

Looking at your config file it seems that a lot of the attributes are not user-specified but rather auto-generated content. You may want to consider using the elog client to submit such entries; this might avoid performance issues related to communication of the server with the web browser used for entry generation. This way, event entries can even be automatically created by other software rather than having a user to submit them.

Yoshio

 Yoshio,

Thanks for the suggestion.

We have actually tried running the elog server with a very minimal set of attributes, all of which were human entries, and still had response times that were entirely unacceptable.  So, unfortunately this path won't solve all our issues.

tt

 

Yes there is lots of string handling in elogd, but compared with PHP this is still faster. The getcfg() call actually caches the contents of the config file to improve its performance. I stopped optimization when the response was quick on a 800 MHz Pentium originally, but your 250 MHz ARM might be slower. What you can try is to

1) Verify that the CPU is really the limit, just check that the CPU is at 100% with elogd during your 10 second response time. On some installations, the submit command triggers some email notification, and actually the email server was the bottleneck.

2) If it's indded the CPU for elogd, run it under the gcc profiler. Identify which routines take most CPU and let me know. Maybe I can do something about that.

 

- Stefan

 Stefan,

Thanks for your feedback. 

We had confirmed that the CPU load is running at at least 95% while these requests are being processed.  Additionally, we were attempting to use gprof to determine where the code was spending its time.  We have had several problems with trying to use gprof on that platform, both with using it for elog (we get seg faults) and then with using it on a small program created to test gprof on our particular setup (program runs; we get an output file; but all routines show that zero seconds were used).  So, unfortunately, I can not, at this point, provide a good idea of which routines are using the most CPU on this platform.  If we are able to get profiling results on this particular platform, I will certainly share them with you.

A possibly more relevant angle is that we have determined that executing floating-point operations seems to have a drastic impact on software execution times.  Can you point us to routines in the elogd code where floating point operations are taking place?

Thanks,

Tim

  67275   Tue May 15 08:35:16 2012 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.9.0Re: HW Requirements to run elog / Performance issues running on ARM

Tim Thiel wrote:

Stefan Ritt wrote:

Tim Thiel wrote:

Yoshio Imai wrote:

Hi!

Looking at your config file it seems that a lot of the attributes are not user-specified but rather auto-generated content. You may want to consider using the elog client to submit such entries; this might avoid performance issues related to communication of the server with the web browser used for entry generation. This way, event entries can even be automatically created by other software rather than having a user to submit them.

Yoshio

 Yoshio,

Thanks for the suggestion.

We have actually tried running the elog server with a very minimal set of attributes, all of which were human entries, and still had response times that were entirely unacceptable.  So, unfortunately this path won't solve all our issues.

tt

 

Yes there is lots of string handling in elogd, but compared with PHP this is still faster. The getcfg() call actually caches the contents of the config file to improve its performance. I stopped optimization when the response was quick on a 800 MHz Pentium originally, but your 250 MHz ARM might be slower. What you can try is to

1) Verify that the CPU is really the limit, just check that the CPU is at 100% with elogd during your 10 second response time. On some installations, the submit command triggers some email notification, and actually the email server was the bottleneck.

2) If it's indded the CPU for elogd, run it under the gcc profiler. Identify which routines take most CPU and let me know. Maybe I can do something about that.

 

- Stefan

 Stefan,

Thanks for your feedback. 

We had confirmed that the CPU load is running at at least 95% while these requests are being processed.  Additionally, we were attempting to use gprof to determine where the code was spending its time.  We have had several problems with trying to use gprof on that platform, both with using it for elog (we get seg faults) and then with using it on a small program created to test gprof on our particular setup (program runs; we get an output file; but all routines show that zero seconds were used).  So, unfortunately, I can not, at this point, provide a good idea of which routines are using the most CPU on this platform.  If we are able to get profiling results on this particular platform, I will certainly share them with you.

A possibly more relevant angle is that we have determined that executing floating-point operations seems to have a drastic impact on software execution times.  Can you point us to routines in the elogd code where floating point operations are taking place?

Thanks,

Tim

As far as I can remember there is no floating point in elog. 

  67284   Mon May 21 14:41:25 2012 Question Roland Gsellroland.gsell@oeaw.ac.atQuestionLinux2.9.1-2435Periodic backup doesn't work ..

Hi,

I installed ELOG on other machine for making automatic backups. I copied the .cfg file to the slave and edited the .cfg file on the original machine (mirror server entries).
(automatic configuration with -C didn't work somehow - maybe a firewall problem)

Then I tried to synchronize manually, which works great.
I set the mirror cron = 0 7-18 * * 1-5, as written as example in the documents, but nothing happens at full hours.

There's something else strange: I can't access "https://lx0.mydomain.org/" or "http://lx1.mydomain.org:8082/" directly. The browser just keeps loading - showing an empty page (and an error message after a long while). I have to add the name of the logbook to the link. Why is that?
If I set different paths in the [global HBAR] and [global SMI] areas (like URL = https://lx0.mydomain.org/hbar/), I can access the links above (giving me the overview page as expected), but I can't access the logbooks itself anymore.

However, that's not a big problem (I can access the logbooks via direct link and see all the others in the same group and switch to them), but the backup thing is.

 

So, main machine is lx0.mydomain.org and the backup machine is lx1...

Attached are my config files.
I deleted many of the logbook specific entries, since they aren't important and just look like the first one.

Hope anyone can help,
Roland.

Attachment 1: lx0_elogd.cfg.txt
[global]
SSL = 1

Mirror server = http://lx1.mydomain.org:8082
Mirror config = 1
Mirror cron = 0 7-18 * * 1-5
Mirror user = gsell
Mirror simulate = 0
Mirror exclude = 0

SMTP host = smtp.mydomain.org

Group HBAR-HFS = Detektor, Simulation, Cavity, Shielding_and_Helmholtz_coils, Sextupole, DAQ
Group non-ERC = SIDDHARTA, VIP, FAIR, HP3_Leannis, HP3_Joint_GEM, HP3_SiPM, HP3_Future_Jet

Top group HBAR = HBAR-HFS
Top group SMI = non-ERC

Theme = default

; attributes
Attributes = Author, Type, Category, Subject
Options Type = Logbook, Configuration, Other
Options Category = Routine entry, Shift summary, Problem, Fix, Question, Info, Other
Extendable Options = Category
Required Attributes = Author, Category, Subject
Thread display = $Subject, entered by $author on $Entry date

; Title shown in the browser
Page Title = HBAR-HFS - $subject
Reverse sort = 1
Quick Filter = Date, Category

Preset Author = $long_name

Locked Attributes = Author, Author Email

; only author can change its own entry
Restrict edit = 1

; options for reply
Subst on reply subject = Re: $Configuration Name
Remove on reply = Author, Author Email

[global HBAR]
URL = https://lx0.mydomain.org/
Password file = elogpass_hbar
Admin user = gsell, malbrunot

[global SMI]
URL = https://lx0.mydomain.org/
Password file = elogpass_smi
Admin user = gsell



[Detektor]

;User
Login user = gsell, widmann, diermaier, federmann, malbrunot, massiczek, sauerzopf, wuenschek, zmeskal, suzuki

Attachment 2: lx1_elogd.cfg.txt
[global]
SSL = 0
Port = 8082

SMTP host = smtp.mydomain.org

Group HBAR-HFS = Detektor, Simulation, Cavity, Shielding_and_Helmholtz_coils, Sextupole, DAQ
Group non-ERC = SIDDHARTA, VIP, FAIR, HP3_Leannis, HP3_Joint_GEM, HP3_SiPM, HP3_Future_Jet

Top group HBAR = HBAR-HFS
Top group SMI = non-ERC

Theme = default

; attributes
Attributes = Author, Type, Category, Subject
Options Type = Logbook, Configuration, Other
Options Category = Routine entry, Shift summary, Problem, Fix, Question, Info, Other
Extendable Options = Category
Required Attributes = Author, Category, Subject
Thread display = $Subject, entered by $author on $Entry date

; Title shown in the browser
Page Title = HBAR-HFS - $subject
Reverse sort = 1
Quick Filter = Date, Category

Preset Author = $long_name

Locked Attributes = Author, Author Email

; only author can change its own entry
Restrict edit = 1

; options for reply
Subst on reply subject = Re: $Configuration Name
Remove on reply = Author, Author Email

[global HBAR]
URL = http://lx1.mydomain.org:8082/
Password file = elogpass_hbar
Admin user = gsell, malbrunot

[global SMI]
URL = http://lx1.mydomain.org:8082/
Password file = elogpass_smi
Admin user = gsell



[Detektor]

;User
Login user = gsell, widmann, diermaier, federmann, malbrunot, massiczek, sauerzopf, wuenschek, zmeskal, suzuki

  67287   Tue Jun 12 10:38:34 2012 Reply Roland Gsellroland.gsell@oeaw.ac.atQuestionLinux2.9.1-2435Re: Periodic backup doesn't work ..

The synchronize feature is totally worthless to me.

First of all the automatic backup doesn't work - and nobody seems to know why - and pressing the synchronize button by hand from time to time also doesn't work if the entry is too big:

Error sending local entry: Error transmitting message

 

So, copying the files manually helps, but for this I don't need a "fancy" synchronize feature.

  67288   Tue Jun 19 04:02:43 2012 Reply Ken Harveyrichard.harvey@l-3com.comQuestionLinux2.9.1-2435Re: author field in reply

A. Tuttle wrote:
Look in https://midas.psi.ch/elog/config.html
--
Fun things to set are:
Preset on first reply <attribute> = <string>
and
Preset on reply <attribute> = <string>


I am a newbie to being the administrator to ELog, but have used it for a while now. We just updated and have the same issue with the reply now. Unfortunatley I am not much of a programmer, yet, still learning. In our config file it has "Preset Name = $long_name", "Preset Author = $long_name", "Preset on reply Author = $long_name". By looking in the Syntax of elogd.cfg section, it seems to be correct, but I am not sure. Can you give me a suggestion on how it should look? Or tell me why it is not working and lead me in the right direction on how to correctly set it up? Thank you for your time.
  67289   Wed Jun 20 14:02:45 2012 Question Ocanereuldky@yahoo.comQuestionLinux2.9.1-2435Protect Selection page=1

 Hi,

I have several top groups and each has several logbooks.

If I use the global option Protect Selection page=1 and Show top groups = 1, after an user logs in to the top group selection URL, the elog steers away from the top group selection page, and automatically brings him to the logbook selection page of the first top group. Is the elog programmed to exhibit this behavior?

What I would prefer is that, after an user logs in, the elog stays on the top group selection page, sine each user has his preferred destination, not always the logbooks in the first top group. Is there any setting I can use in the config file to do this? 

(My users need to access different top groups and logbooks on regular basis).

Thank you and regards.

  67290   Wed Jun 20 16:16:56 2012 Reply Andreas Luedekeandreas.luedeke@psi.chQuestionLinux2.9.1-2435Re: author field in reply

Ken Harvey wrote:

A. Tuttle wrote:
Look in https://midas.psi.ch/elog/config.html
--
Fun things to set are:
Preset on first reply <attribute> = <string>
and
Preset on reply <attribute> = <string>


I am a newbie to being the administrator to ELog, but have used it for a while now. We just updated and have the same issue with the reply now. Unfortunatley I am not much of a programmer, yet, still learning. In our config file it has "Preset Name = $long_name", "Preset Author = $long_name", "Preset on reply Author = $long_name". By looking in the Syntax of elogd.cfg section, it seems to be correct, but I am not sure. Can you give me a suggestion on how it should look? Or tell me why it is not working and lead me in the right direction on how to correctly set it up? Thank you for your time.


A common mistake is to think that "Author" is some kind of keyword: it is not.
You can use any defined attribute, if you want to use "Author" this attribute needs to be defined in the "Attributes=" command line.
Attributes = Author, ...
Then you can use the "Preset" command.
Preset Author = $long_name
Preset on reply Author = $long_name


I've just tested it with 2.9.0-2435 and it works fine.
If the following 4 line minimal logbook configuration does not work for 2.9.1, then please post again:
Attributes = Author
Preset Author = $long_name
Preset on reply Author = $long_name
Locked Attributes = Author

Cheers
Andreas
  67291   Thu Jun 21 05:29:59 2012 Reply Ken Harveyrichard.harvey@l-3com.comQuestionLinux2.9.1-2435Re: author field in reply

Andreas Luedeke wrote:

Ken Harvey wrote:

A. Tuttle wrote:
Look in https://midas.psi.ch/elog/config.html
--
Fun things to set are:
Preset on first reply <attribute> = <string>
and
Preset on reply <attribute> = <string>


I am a newbie to being the administrator to ELog, but have used it for a while now. We just updated and have the same issue with the reply now. Unfortunatley I am not much of a programmer, yet, still learning. In our config file it has "Preset Name = $long_name", "Preset Author = $long_name", "Preset on reply Author = $long_name". By looking in the Syntax of elogd.cfg section, it seems to be correct, but I am not sure. Can you give me a suggestion on how it should look? Or tell me why it is not working and lead me in the right direction on how to correctly set it up? Thank you for your time.


A common mistake is to think that "Author" is some kind of keyword: it is not.
You can use any defined attribute, if you want to use "Author" this attribute needs to be defined in the "Attributes=" command line.
Attributes = Author, ...
Then you can use the "Preset" command.
Preset Author = $long_name
Preset on reply Author = $long_name


I've just tested it with 2.9.0-2435 and it works fine.
If the following 4 line minimal logbook configuration does not work for 2.9.1, then please post again:
Attributes = Author
Preset Author = $long_name
Preset on reply Author = $long_name
Locked Attributes = Author

Cheers
Andreas


Thanks Andreas,

That cleared up a lot for me. With your information I was able to figure it out. I got rid of the Author and just went with Name, and now it all works good.

Again, thanks for your help,

Ken Harvey
ELOG V3.1.5-3fb85fa6