Topic: New GekkoScience product, the Smart Hub - page 2. (Read 1812 times)

Is it still your current setup? Did you have any reliability issues?

Hi, this is indicitive of CGMiner crashing, could be pool connection, internet connection or mining hardware related. For optimum diagnostics, you need to SSH in to the unit and see what CGminer is doing and if it is running, etc. This is all documented early on in this post.
I have helped several people lately that have put in Ethereum wallet addresses in the config page which causes CGMiner to fail immediatley which in turn crashes as such.

Can you go to the IP address of the device (you may need to look this up by doing an IP scan on your network if the OLED screen isnt working), go to the IP of the SmartHub in your web browser (note, the machine you are accessing the Smarthub from must be on the same network). I then want screenshots of everything you see on the screen.

If you are tech savvy, go back earlier in the post and look at SSH'ing into the unit and seeing what is causing CGMiner to crash.

Who did you get the SmartHub from?

Cheers
IamGPIO

I have had it running 7, but only because I didn't have my hands on any more. @Sidehack may have more input on this

I just set mine up for the first time. When I go to the wired (not wifi) web address I get the same error message.

I do not have a miner hooked up to it yet. I am waiting for my new PSU to come in the mail to power my R909. Could that be the issue?

The display also says "Invalid pool. Can't connect to pool." It is the default solo pool. Not using WiFi.

How many R909's will the Smarthub handle?

Hi, not yet.

It's on the to do list. It's a fairly complex task to do this but def' doable.

Hi All - Just curious....  Is there any way to have each individual miner have it's own settings (pool, frequency, etc.)?


thanks!

Another Update.

Woke up this morning and RAM usage had dropped down to 23%. Didnt have time to check anything until now. RAM usage up to 30% but cgminer has restarted. Hub remained on as the counter is now at 25 Days etc.

So not sure what the mem leak is or what happened before to start this investigation. But so far it seems to be keeping itself in check.

Only cgminer. On TOP its showing 45.3% mem usage.

Current stats are:-

74.3% RAM  after 13day 6 Hours and change.

Cheers, please do.

Is there anything one app/process that is taking up a a large chunk of this RAM?

Hi, this is indicitive of CGMiner crashing could be pool connection, internet connection or mining hardware related). For optimum diagnostics, you need to SSH in to the unit and see what CGminer is doing and if it is running, etc. This is all documented early on in this post.

Who did you get the SmartHub from?

Cheers
IamGPIO

Hello Everyone - I just got this unit and it has been running fine all night.  This morning I came in and the hashing stopped.  Went to the web browser and am getting this below.  Suggestions??

Note:  I am a total NOOB when it comes to all of this.  Please be kind!



AttributeError
AttributeError: 'NoneType' object has no attribute 'get'

Traceback (most recent call last)
File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2552, in __call__
return [Suspicious link removed]gi_app(environ, start_response)
File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2532, in wsgi_app
response = self.handle_exception(e)
File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 2529, in wsgi_app
response = self.full_dispatch_request()
File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1825, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1823, in full_dispatch_request
rv = self.dispatch_request()
File "/usr/local/lib/python3.7/dist-packages/flask/app.py", line 1799, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
File "/home/pi/Defaults/HTML/mainpage.py", line 174, in index
lcd_data = cgminer_data.get("LCD", {})
AttributeError: 'NoneType' object has no attribute 'get'
The debugger caught an exception in your WSGI application. You can now look at the traceback which led to the error.
To switch between the interactive traceback and the plaintext one, you can click on the "Traceback" headline. From the text traceback you can also create a paste of it. For code execution mouse-over the frame you want to debug and click on the console icon on the right side.

You can execute arbitrary Python code in the stack frames and there are some extra helpers available for introspection:

dump() shows all variables in the frame
dump(obj) dumps all that's known about the object

Just thought I would update this.

Its been 9Days 6Hours 48mins since it restarted and is currently on 67.7% ram usage.

Still on the same instance of cgminer and its definitely cgminer ram usage thats increasing.

I'll keep monitoring and report back in a few days.

oooh Doom in the web interface. Sounds like I should look for a little symbol on the screen like the film "The Net" 

I'll carry on as is and wait for the update(s). Like I said its only a restart once a week and I seem to be the only one affected at the moment. I may just let it run and see if it does max-out at some point and stays running.

The current image I have is no different to the one you have, except the one I have may have Doom embedded in the web interface.... somewhere... .

Aside from that, there are no implemement changes as yet that I am ina place to release. i have made changes but its all very piece-meal at the moment.  I will keep probing and see if I can figure out what is causing the memory usage to creep up.

Thanks for the reply GPIO. I've been monitoring it today and noticed that it is the cgminer "file" casuing the slow increase in ram usage. Yesterday on intitial restart they were at 2.1%. Today they are at 3.9%.

Still can't fathom why though. It hasn't restarted, still the same instance (767 after the restart) on screen as it was before, all sticks running as requested.

More than happy to flash the SD Card with your current .img file to give it a try. Just means I'll have to go and change the Price Ticker currency again 

I am happy to wait until the updates aswell. Its simply issue that a restart solves once a week really.

My first thought with this is various processor threads which is why the "17 x 13.8%" doesn't add up. If you run "top" insteads of "htop" you should get the single resource use per application running. The Python3 instances will be the BTC Price updater and also the screen program that runs the OLED screen.

I have looked at a SmartHub I have running on the desk behind me with 4 x R909's connected and I am max'd out at 67% RAM usage with zero restarts on any screen instances.

I am happy to send you the .img file for you to reflash the SD card if you want to try that.

Cheers
IamGPIO

Ok so running HTOP has revealed a couple of things that are strange to me (not being linux proficient and all that).

I have:-

15x "gekkoscreentrimmed4.py" running using 13.7% mem each

34 x cgminer config files running using 17.5% mem each

All those are highlighted green which I assume means they are running. (I know the math doesn't add up if you add all the percentages together).

EDIT:
After a restart I now have (39.7% RAM usage on screen):-

17x "gekkoscreentrimmed4.py" running using 13.8% each
35x cgminer config files running using 2.1% each

I may well be looking at the wrong thing though.

The BTC price updater scripts/files are minimal usage compared to the lot listed above.

So there is a script running on the SmartHub (BTC Price Updater) - that pulls the BTC price and sticks it in memory (RAM Disk) until it's needed (60 second intervals). I did this to reduce unnecessary writing to the SD card.

Kill this and see if that makes and difference to the RAM usage. It shouldn't do I as wrote the script to overwrite every previous intry and flush the buffer to prevent this exact issue.
As far as the smarthub software implemention goes, I believe this is the only thing I can contribute to RAM usage.

As others have said, use HTOP to get an idea of where any memory use is coming from. It sound like something has a memory leak.


Cheers
IamGPIO

SSH in and run TOP to see what's eating the RAM