"SimpleFeatures" Plugin - Version 1.0.11



Recommended Posts

  • Replies 2.8k
  • Created
  • Last Reply

Top Posters In This Topic

Placed this in the rc12 topic, for completion and info for the developers of SF, i place it here as well:

 

-------------------------------

 

Ok, found something i think is very interesting.

 

After i tried rc12 with sf 1.0.5 allready on the system i saw the parity check speeds were horrible (40-50MB/s) compared to rc5/sf 1.0.5 (160MB/s)

So i re-installed rc5 and guess what... the SAME horrible speeds! This baffled me.

So i removed SimpleFeatures, and rebooted... (rc5) and speed was back (160MB/s).

I re-installed SF 1.0.5 using installplg and... the speed stayed up high.

 

So, i guess we need an addition to the up- or downgrade procedure, that states that SimpleFeatures should be REMOVED and RE-INSTALLED after an up - or downgrade.

Keeping SF on the system f*cks things up after upgrading. You HAVE to re-install it. Will place this warning at the Sf topic as well.

 

So i tested a bit more. I removed Simplefeatures again, and replaced rc5 with rc12 and rebooted.

Now i have NO simplefeatures, just unmenu and some plugins (sab/sick/dropbox/slimserver).

Parity speeds are now at about 150MB/s... that is still a little bit less then under rc5 (160MB/s) but acceptable.

This speed can be seen at the stock webgui and in unmenu.

 

Guess what. I've installed SimpleFeatures again (1.0.5) and the parity speed goes down to about 90 - 100MB/s... if you actually watch it IN simplefeatures gui.

Once you close the simplefeatures webpage, and go back to unmenu, you will see the parity speed increase to 150MB/s again...

Using the latest SimpleFeatures (1.0.11) is even worse, it basically stops the parity check with speeds from 20-30MB/s, which is unworkable.

 

Basically this means that SimpleFeatures has a huge negative effect on the performance of unraid and should be avoided.

It would be very interesting to find out why this is, and if it can be solved.

 

I know SF is not part of Limetech, but i think a lot of people use SF together with unraid and even regard it as one and the same.

At least Limetech should take a look at this and warn people about the possible sideeffects of SF, and it should be made clear that IF you are using SF, you should re-install it after an up- or downgrade.

 

So, my apologies to Limetech, rc12 is not as bad as i thought, the real problem is SimpleFeatures...

Link to comment

Are people keeping a SF  tab open in their browser continuously?  I only open a browser window to my server when I want to 'look' at something.    (If I haven't closed the browser, I don't even get a login request.)

Placed this in the rc12 topic, for completion and info for the developers of SF, i place it here as well:

 

-------------------------------

 

Ok, found something i think is very interesting.

 

After i tried rc12 with sf 1.0.5 allready on the system i saw the parity check speeds were horrible (40-50MB/s) compared to rc5/sf 1.0.5 (160MB/s)

So i re-installed rc5 and guess what... the SAME horrible speeds! This baffled me.

So i removed SimpleFeatures, and rebooted... (rc5) and speed was back (160MB/s).

I re-installed SF 1.0.5 using installplg and... the speed stayed up high.

 

So, i guess we need an addition to the up- or downgrade procedure, that states that SimpleFeatures should be REMOVED and RE-INSTALLED after an up - or downgrade.

Keeping SF on the system f*cks things up after upgrading. You HAVE to re-install it. Will place this warning at the Sf topic as well.

 

So i tested a bit more. I removed Simplefeatures again, and replaced rc5 with rc12 and rebooted.

Now i have NO simplefeatures, just unmenu and some plugins (sab/sick/dropbox/slimserver).

Parity speeds are now at about 150MB/s... that is still a little bit less then under rc5 (160MB/s) but acceptable.

This speed can be seen at the stock webgui and in unmenu.

 

Guess what. I've installed SimpleFeatures again (1.0.5) and the parity speed goes down to about 90 - 100MB/s... if you actually watch it IN simplefeatures gui.

Once you close the simplefeatures webpage, and go back to unmenu, you will see the parity speed increase to 150MB/s again...

Using the latest SimpleFeatures (1.0.11) is even worse, it basically stops the parity check with speeds from 20-30MB/s, which is unworkable.

 

Basically this means that SimpleFeatures has a huge negative effect on the performance of unraid and should be avoided.

It would be very interesting to find out why this is, and if it can be solved.

 

I know SF is not part of Limetech, but i think a lot of people use SF together with unraid and even regard it as one and the same.

At least Limetech should take a look at this and warn people about the possible sideeffects of SF, and it should be made clear that IF you are using SF, you should re-install it after an up- or downgrade.

 

So, my apologies to Limetech, rc12 is not as bad as i thought, the real problem is SimpleFeatures...

 

 

Thanks, Jowi.  From reading the posts on 'slow speeds' for several items, I came to the conclusion that Simple Features was involved (somehow) in the issue.  Since I have never directly experienced any speed-related problem,  I couldn't set up an experiment to test out my premise.  Perhaps the reason is that I just open (or start) Simple Features when I need to check something or make a change to a setting.  I then close the window when I am done using it.  I keep shortcuts to my servers on my firefox  'Bookmarks ToolBar' and I can open a window to either server with one click.  Which, by the way, is almost as quick as clicking on the tab of an open window. 

Link to comment

Just noticed this error, not sure exactly how to proceed since I'm a linux n00b

 

 Warning: strftime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PST/-8.0/no DST' instead in /usr/local/emhttp/plugins/webGui/template.php on line 41 Sat Feb 23 11:08:56 2013 PST

 

Changes from 5.0-rc10 to 5.0-rc11

---------------------------------

...

- emhttp: default timeZone "America/Los_Angeles" (eliminate first-boot error message)

...

 

Default set by Tom now when first setting up unRAID as none was set previously. Once you bring up unRAID for the first time you should then go ahead and set up time zone, etc... so this should go away.

 

So what can be done if this doesn't go away?  I have unraid setup, and just updated to rc11 from rc8.  I then installed Simple Features, and now when ever a date is displayed I get the strftime error.

 

Also, possibly related, if I turn on monthly parity check, the server starts looping through parity checks, i.e. it finishes one check and starts another.

Link to comment

You can still see parity speed in unmenu. But i want to check if SF gui effects transfer speeds as well. I suspect it does. If i do a simple speedtest from my dune mediaplayer without having the SF gui open, it basically saturates its nic with 11MB/s. If i open the SF gui while doing that, speed drops to about 9MB/s...

Link to comment

I suspect this has something to do with how SF is getting it's speed information. It is either slowing the checks down with the mechanism it utilizes, or it is misreading the speeds. Regardless, having the gui open shouldn't consume enough server resources to drag such high powered systems to their knees. I'm sure speeding_ant is hard at work trying to straighten this out. He's likely reached out to Tom at this point.

Link to comment

For test/performance purposes, is there a command to stop or start the web gui totally?

 

No.  But rumor has it that the SF impact on performance is eliminated when the gui isn't active in an open browser window.  Of course that makes it had to view parity speed :o

 

Not really.  If you have a short cut, you can open a Simple Features window (by clicking on the short cut)  in the browser and as it loads, it updates the display and shows the current speed for the parity check.  You then close the browser window.  (It has been my experience that you only need to login ONCE unless you actually shutdown the browser.)

Link to comment

I'm having difficulty locating the php.ini used by the SimpleFeatures Plugin - Version 1.0.11. Can anyone tell me the full path to this file? Thanks.

 

I'm trying to correct this error:

Warning: strftime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Denver' for 'MDT/-6.0/DST' instead in /usr/local/emhttp/plugins/webGui/template.php on line 41

Link to comment

FYI, uninstall the temp plugin to stop this issue.

 

Exactly what does this do?  I had previously disabled the temperature plugin by renaming it  (in the plugins folder) and the associated .txz  file in plugins/simple features folder. (I did the renaming by by adding a .old extension to the file name.)  After rebooting the server, I still get the drive temperatures displayed on the Main page...

Link to comment

FYI, uninstall the temp plugin to stop this issue.

 

Exactly what does this do?  I had previously disabled the temperature plugin by renaming it  (in the plugins folder) and the associated .txz  file in plugins/simple features folder. (I did the renaming by by adding a .old extension to the file name.)  After rebooting the server, I still get the drive temperatures displayed on the Main page...

 

Temp plugin will poll the drives in the background and update their values in the GUI. It does this a little too often, and disrupts I/O. The temperatures will still show up on the main page, this is a part of the standard GUI. They get polled far less regularly.

Link to comment

You are the man!  I have temps now in my SF Main page!

 

I changed the labels like you said in the sensors.conf file.  I also changed the GO file to say, modprobe w83627ehf.

 

I think I'm good to go.  Here is what the sensors command says now,

 

root@Tower:~# sensors

coretemp-isa-0000

Adapter: ISA adapter

Core 0:      +46.0 C  (high = +76.0 C, crit = +100.0 C)

Core 1:      +46.0 C  (high = +76.0 C, crit = +100.0 C)

Core 2:      +38.0 C  (high = +76.0 C, crit = +100.0 C)

Core 3:      +44.0 C  (high = +76.0 C, crit = +100.0 C)

 

w83627ehf-isa-0290

Adapter: ISA adapter

3.3V:        +2.24 V  (min =  +1.84 V, max =  +2.96 V)

Vcore:        +1.85 V  (min =  +1.65 V, max =  +1.99 V)

+5V:          +8.23 V  (min =  +7.10 V, max =  +8.65 V)

12V:        +13.99 V  (min = +12.41 V, max = +15.14 V)

3VSB:        +6.66 V  (min =  +5.92 V, max =  +7.26 V)

Battery:      +6.53 V  (min =  +5.92 V, max =  +7.26 V)

in9:          +0.00 V  (min =  +1.24 V, max =  +1.33 V)  ALARM

CPU:        1834 RPM  (min =  712 RPM, div = 8)

System2:    1163 RPM  (min =  712 RPM, div = 8)

fan5:        1028 RPM  (min =  712 RPM, div = 8)

CPU Temp:    +39.0 C  (high = +60.0 C, hyst = +55.0 C)  sensor = thermistor

MB Temp:      +38.0 C  (high = +80.0 C, hyst = +75.0 C)  sensor = CPU diode

System:        +0.0 C  (high = +80.0 C, hyst = +75.0 C)  sensor = CPU diode

cpu0_vid:    +1.513 V

intrusion0:  ALARM

 

root@Tower:~#

 

and I have this in SF Main page,

 

Thanks!

 

@dmacias - I just upgraded to v5 RC12a and rebooted, now I have no temps again.  I confirmed that my sensors.d file was copied by the GO file and the "modprobe w83627ehf" command via the GO file.

 

Any idea why this happened as a result of RC12a?

 

output of sensors command;

 

root@Tower:~# sensors

coretemp-isa-0000

Adapter: ISA adapter

Core 0:      +47.0 C  (high = +76.0 C, crit = +100.0 C)

Core 1:      +47.0 C  (high = +76.0 C, crit = +100.0 C)

Core 2:      +37.0 C  (high = +76.0 C, crit = +100.0 C)

Core 3:      +43.0 C  (high = +76.0 C, crit = +100.0 C)

 

w83627dhg-isa-0290

Adapter: ISA adapter

Vcore:        +1.12 V  (min =  +0.92 V, max =  +1.48 V)

in1:          +1.85 V  (min =  +1.65 V, max =  +1.99 V)

AVCC:        +3.33 V  (min =  +2.96 V, max =  +3.63 V)

+3.3V:        +3.33 V  (min =  +1.09 V, max =  +0.83 V)  ALARM

in4:          +1.57 V  (min =  +1.35 V, max =  +1.65 V)

in5:          +1.27 V  (min =  +1.13 V, max =  +1.38 V)

in6:          +1.43 V  (min =  +1.42 V, max =  +1.52 V)

3VSB:        +3.33 V  (min =  +2.96 V, max =  +3.63 V)

Vbat:        +3.26 V  (min =  +2.96 V, max =  +3.63 V)

fan1:        1814 RPM  (min =  712 RPM, div = 8)

fan2:        2057 RPM  (min =  712 RPM, div = 8)

fan3:        1171 RPM  (min =  712 RPM, div = 8)

fan4:        1117 RPM  (min =  712 RPM, div = 8)

fan5:        1028 RPM  (min =  712 RPM, div = 8)

temp1:        +39.0 C  (high = +60.0 C, hyst = +55.0 C)  sensor = thermistor

temp2:        +39.0 C  (high = +80.0 C, hyst = +75.0 C)  sensor = CPU diode

temp3:        +0.0 C  (high = +80.0 C, hyst = +75.0 C)  sensor = CPU diode

cpu0_vid:    +1.513 V

intrusion0:  ALARM

 

 

Link to comment

I haven't updated but maybe I will.  I would double check through telnet and something like winscp. I'll try here in a little bit.  Does the modprobe w83627ehf give an error from the command prompt?

 

No error,

 

root@Tower:~# modprobe w83627ehf

root@Tower:~#

 

I haven't changed the config or even touched it, since you helped me get it working.  The only change was rc12a.  Perhaps it broke or changed something for SF.

 

Thanks for your help!

Link to comment

FYI, uninstall the temp plugin to stop this issue.

We are having slow parity speeds with version 1.0.5 on rc12, NOT with the 1.0.11 version.

I understand this 1.0.5 version does not poll for temps? There is no separate temp plugin.

 

Sf 1.0.5 on unraid rc5 is working ok, 1.0.5 on unraid rc12 is slow.

Why is 1.0.5 working ok on rc5 and not on rc12?

Link to comment
  • Squid locked this topic
Guest
This topic is now closed to further replies.