Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 369 of 808  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Versiondown Subject
  67204   Mon Feb 20 20:33:32 2012 Question Arno TeunisseA.Teeling3@chello.nlQuestionWindows2.9.0Hyperlink in attributes and autoincrement

Hello

Want a hyperlink in one of the attributes like this : http://Someserver/someDir/perl.pl#subject

In this way I should be able to redirect to a certain part of the html that the perl script is generating. When I setup this manually it works. ( typing directly the html link into the attribute )

 
When I put the html link into elog config file it will never show up the correct format : everything after the '#' is translated into the digit 1. ( So you get  http://Someserver/someDir/perl.pl1 . ) 

I tried to escape with \# used quoting " and '. No luck.  Tried to use the a , No luck. 

I've tested with several versions of elog but it seems that it has never worked. 

Allow HTML = 1 dit not work for me.

Has it to do with the autoincrement  ? ( Subst Number = XYZ-##### ) I think so because of the 1 that is returned if i use a http link . When I use the same link  http://Someserver/someDir/perl.pl#subject a second time i'll get back :
http://Someserver/someDir/perl.pl2 . So it seems that the auto increment feature plays a role in this one. 

 

Can this be done in the attributes of elog.? Can I have a # in a hyperlink ?

 

Thanks for your time.

 

 

  67235   Tue Apr 10 15:53:48 2012 Reply Stefan Rittstefan.ritt@psi.chQuestionWindows2.9.0Re: Hyperlink in attributes and autoincrement

Arno Teunisse wrote:

Hello

Want a hyperlink in one of the attributes like this : http://Someserver/someDir/perl.pl#subject

In this way I should be able to redirect to a certain part of the html that the perl script is generating. When I setup this manually it works. ( typing directly the html link into the attribute )

 
When I put the html link into elog config file it will never show up the correct format : everything after the '#' is translated into the digit 1. ( So you get  http://Someserver/someDir/perl.pl1 . ) 

I tried to escape with \# used quoting " and '. No luck.  Tried to use the a , No luck. 

I've tested with several versions of elog but it seems that it has never worked. 

Allow HTML = 1 dit not work for me.

Has it to do with the autoincrement  ? ( Subst Number = XYZ-##### ) I think so because of the 1 that is returned if i use a http link . When I use the same link  http://Someserver/someDir/perl.pl#subject a second time i'll get back :
http://Someserver/someDir/perl.pl2 . So it seems that the auto increment feature plays a role in this one. 

 

Can this be done in the attributes of elog.? Can I have a # in a hyperlink ?

Nobody needed such a functionality so far. I implemented it for you in SVN revision 2449. So you can simply escape it like "\#" 

  67268   Wed May 9 21:48:42 2012 Question Tim Thieltt2005@thieleng.comQuestionLinux2.9.0HW Requirements to run elog / Performance issues running on ARM

Our group is interested in installing elog on a small/low-cost processing platform so that we can provide ready-to-run systems for our collaborators to use.  We selected a candidate platform form Technologic Systems, their wifibox-2 (http://www.embeddedarm.com/products/board-detail.php?product=TS-WIFIBOX-2).  This product is based on the TS7553 CPU board (http://www.embeddedarm.com/products/board-detail.php?product=TS-7553#) which has a 250MHz Cavium ARM9 CPU.

We have had good success getting the elogd executable cross-compiled for use on this platform and have a working system.  However, we are having significant issues with performance.  When we click the "New" item to enter a new event there is a noticable delay.  When clicking "Submit" there is a delay of approximately 10 seconds before the browser window displays the new event.  With the elogd running on other platforms (Virtual Machine or netbook) the delays for these actions are very small - typically less than a second or imperceptible.

So here are some specific questions:

- Is it reasonable to expect a 250 MHz ARM processor to serve an elog logbook with user acceptable performance?

- Our cfg file is attached.  Is there anything in the cfg file creating this performance problem.

- I have spent some time looking at this, and suspect that the delay is due to the cpu load of all the string manipulation and comparison operations (1200 calls to getcfg() on a submit).  Are there other candidate sources of performance issues that should be considered?

- Does anyone have any suggestions on how to improve our performance?

- Does anyone have a suggestion for an alternative small and low-cost COTS platform to use to host the elogd application?  (We would prefer to attain satisfactory performance on the Wifibox-2.)

Thanks for any help that can be offered.

Tim

 

Attachment 1: elogd-001.cfg
# === CONFIG FILE GENERATION DOCUMENTATION ===
#
# === GLOBAL PARAMETERS ===
# Note: Setup CruiseId and Logbooks
# Note: Datasnap logbook not in this version
#[global]
#Main Tab = oc3334
#Group Cruise = oc3334-SE 

# === GENERAL OPTIONS ===
# Note: From general options of elogd.cfg part of administrators guide
#Comment =  oc3334_COMMENT
#Subject = oc3334 Cruise Log
#Page title = oc3334 Cruise Log
Time format = %d %b %Y %H:%M
# === LOGBOOK: Science Eventlog ===
[oc3334-SE]
# === Execute Shell Command ===
# Note: execute shell command to enter a datasnap to DS logbook at new
# Note: needs to run in background
#Execute new = $shell(/shipdata/oc3334/r2r/eventlog/datasnap/CRUISEID_ds2elog.pl &)
# === Menu: List ===
# Note: Menu list
# Note: Needs to be commented out for local copy, use on synced logbooks
# Note: Used for shore view
#Menu commands = List, Find, Help
#List Menu commands = List, Find, Help
# Note: Used on ship, config option is in ECFM  
#Menu commands = List, New, Edit, Delete, Reply, Duplicate, Find, Help
#List Menu commands = List, New, Edit, Delete, Reply, Duplicate, Find, Help

# === DISPLAY: List ===
# Note: directives related to how attributes are listed on the display page
# Note: default is ID, Date, <full attribute list>
#List display = Event, dateTimeUTC, Instrument, Action, Transect, Station, Cast, Latitude, Longitude, Seafloor, Author, Comment, Revisions
#Sort attributes = Event
# === DISPLAY: Entry ===
# Note: directives related to how attributes are configured on the data entry page 
# Note: unlock these temporarily if it is necessary to edit the fields
# Note: locked Latitude, Longitude, and Seafloor
##Locked Attributes = Revisions, Cruise, Event, R2R_Event, dateTimeUTC, GPS_Time, Latitude,  Longitude, Seafloor
# Note: unlocked Latitude, Longitude, and Seafloor
#Locked Attributes = Revisions, Cruise, Event, R2R_Event, dateTimeUTC, GPS_Time, dateTime8601
#Required Attributes = Author, Instrument, Action

# === ATTRIBUTES (GENERAL) ===
# Note: Specify the attributes for this event log
# Note: An event = Instrument + Action; e.g. event = a CTD cast is started
Attributes = Event, Instrument, Action, Transect, Station, Cast, Latitude, Longitude, Seafloor, Author, Comment, Cruise, R2R_Event, dateTimeUTC, GPS_Time, dateTime8601, Revisions 
#Attributes = Instrument, Action 

# === ATTRIBUTE: Entry Time
# Note: This attribute is generated automatically by ELOG software

# === ATTRIBUTE: Event ===
# Characteristics: Locked
# Note: UTC time-based attributes
# Note: Science event number must be unique within a cruise
# Note: YYYYMMDD.HHMMSS.###
# Note: ### starts at 001 and updates to 002 if the date part of the attribute has not changed
#
#Preset Event = $shell(date +%Y%m%d.%H%M).### 
#Subst Event = $shell(date +%Y%m%d.%H%M).###
#Preset on Duplicate Event = $shell(date +%Y%m%d.%H%M).###

# === ATTRIBUTE: Transect ===
Preset Transect = NaN

# === ATTRIBUTE: Station ===
Preset Station = NaN

# === ATTRIBUTE: Cast
Preset Cast = NaN

# === ATTRIBUTE: Latitude ===
# Characteristics: Locked
#Subst Latitude = $shell(/shipdata/oc3334/r2r/eventlog/elog/scripts/get_gps_latlon -o lat -p 55150) 
Tooltip Latitude = filled on entry

# === ATTRIBUTE: Longitude ===
# Characteristics: Locked
#Subst Longitude = $shell(/shipdata/oc3334/r2r/eventlog/elog/scripts/get_gps_latlon -o lon -p 55150)
Tooltip Longitude = filled on entry

# === ATTRIBUTE: Seafloor ===
# Characteristics:
# Subst Seafloor = $shell(/shipdata/oc3334/r2r/eventlog/elog/scripts/get_depth -o depth -p 55200)

# === ATTRIBUTE: Comment ===
Preset on Duplicate Comment =
Tooltip Comment = Enter additional information
Comment Comment = Please be brief; no commas

# === ATTRIBUTE: Cruise ===
# Characteristics: Locked
# Note: Get Cruise from Cruise_ID file when on board
Preset Cruise = oc3334 

# === ATTRIBUTE: R2R_Event ===
# Characteristics: Locked
# Note: Preset this attribute and then reset it on submit
#Preset R2R_Event = $shell(/shipdata/oc3334/r2r/eventlog/elog/scripts/r2r_event_se.oc).###
#Subst R2R_Event = $shell(/shipdata/oc3334/r2r/eventlog/elog/scripts/r2r_event_se.oc).###
#Preset on Duplicate R2R_Event = $shell(/shipdata/oc3334/r2r/eventlog/elog/scripts/r2r_event_se.oc).###

# === ATTRIBUTE: dateTimeUTC ===
# Characteristics: Locked
# Note: Preset this attribute and then reset it on submit
# Note: other event number formats
# Note: using UTC YrDay:  Preset Event = $shell(echo 'date -u +%j%y.%H%M`)
#Preset dateTimeUTC = $shell(date -u +%Y%m%d.%H%M)
#Subst dateTimeUTC = $shell(date -u +%Y%m%d.%H%M)
#Preset on Duplicate dateTimeUTC = $shell(date -u +%Y%m%d.%H%M)

# === ATTRIBUTE: GPS_Time ===
# Characteristics: Locked
#Subst GPS_Time = $shell(/shipdata/oc3334/r2r/eventlog/elog/scripts/get_gps_latlon -o gps_time -p 55150)
Tooltip GPS_Time = filled on entry

# === ATTRIBUTE: dateTime8601 ===
# Characteristics: Locked
# Note: Preset this attribute and then reset it on submit
# Note: other event number formats
# Note: using ISO 8601 YrDay:  Preset Event = $shell(echo '--iso-8601=seconds`)
#Preset dateTime8601 = $shell(date --iso-8601=seconds)
#Subst dateTime8601 = $shell(date --iso-8601=seconds)
#Preset on Duplicate dateTime8601 = $shell(date --iso-8601=seconds)


# === ATTRIBUTE: Depth ===
Tooltip Depth = filled on entry

# === ATTRIBUTE: Revisions ===
# Characteristics: Locked
# Note:  if we require logins, then revisions could be authored too using $short or $long_name
Preset on Duplicate Revisions =
Subst on Edit Revisions = $Revisions & $date

# === FLAGS ===
# sort order for event display
Reverse sort = 0

# Configure the default behavior
# Do not allow a text entry box with attachments (this is different from the Comment field)
Show text = 0

# Do not allow attachments 
Enable attachments = 0

# Suppress email notification and do not even display email notification option
Suppress default = 3
Suppress Email on edit = 3
Resubmit default = 2

# quick filter options for display
Quick filter = Author, Instrument, Action
#
#
# List of instruments created by elogcfm
#
Options Instrument = ADCP150{10}, CTD911{1}, Echosounder12{2}, Echosounder3.5{3}, Other{4}, Ship{5}, Thermosalinograph SBE45{6}, XBT{7}, MeteorologicalSensor{8}, Fluorometer{9}, 

#
# List of instrument actions created by elogcfm
#
{10} ROptions Action = start,stop,service,other
{1} ROptions Action = deploy,maxDepth,recover,abort,other
{2} ROptions Action = startLine,endLine,abortLine
{3} ROptions Action = startLine,endLine,abortLine
{4} ROptions Action = start,end
{5} ROptions Action = startCruise,endCruise,other
{6} ROptions Action = start,stop,other
{7} ROptions Action = release
{8} ROptions Action = startLine,endLine,abortLine,sampleLine
{9} ROptions Action = startLine,endLine,abortLine,sampleLine
  67269   Thu May 10 15:34:39 2012 Reply Yoshio Imai$user_emailQuestionLinux2.9.0Re: HW Requirements to run elog / Performance issues running on ARM

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

  67270   Thu May 10 16:35:50 2012 Reply Tim Thieltt2005@thieleng.comQuestionLinux2.9.0Re: HW Requirements to run elog / Performance issues running on ARM

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

 

  67271   Fri May 11 13:20:35 2012 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.9.0Re: HW Requirements to run elog / Performance issues running on ARM

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

  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. 

ELOG V3.1.5-3fb85fa6