Pages:
Author

Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 35. (Read 308807 times)

newbie
Activity: 22
Merit: 0
Just updated to the new binaries. Working great for me.

Same here...awesome work Sandor.  Not sure why it's "freezing" or "locking up" for some people, I've never had the problem, but I don't have a lot of gridseeds either.  Maybe it's a memory allocation issue with enabling autotune for all those gridseeds?  I'm not sure if you're using hashtables, arrays, or dictionaries to record and keep track of autotune info but maybe people with a lot of gridseeds are hitting a limitation within the method? 

If someone wants to send me 100 or more gridseeds to "test" I have 32GB ram in my system to test the theory   Grin

Found my 'crash' - batch file set with --retries=5 and so if the pool timed out it just ended

Any way to put in multiple pools? or any kind of management once the program is running?
Apologies if I've missed anything obvious, trying to read 67 pages in 3 days is hard!
hero member
Activity: 546
Merit: 500
Looks like "--freq=950" overrides the "--gc3355-freq=\\.\COM42:700"
How could i set one device lower/higher than all the rest without typing each individually?

Edit: OK. I got it. I needed to write individual freq before the overall.
sr. member
Activity: 252
Merit: 254
It's a work in progress, people shouldn't expect perfection with every release. 

Unless you are called Wolfey2014. Roll Eyes

 Wink
hero member
Activity: 616
Merit: 500
It's a work in progress, people shouldn't expect perfection with every release. 

Unless you are called Wolfey2014. Roll Eyes
sr. member
Activity: 252
Merit: 254
Just updated to the new binaries. Working great for me.

Same here...awesome work Sandor.  Not sure why it's "freezing" or "locking up" for some people, I've never had the problem, but I don't have a lot of gridseeds either.  Maybe it's a memory allocation issue with enabling autotune for all those gridseeds?  I'm not sure if you're using hashtables, arrays, or dictionaries to record and keep track of autotune info but maybe people with a lot of gridseeds are hitting a limitation within the method?  

If someone wants to send me 100 or more gridseeds to "test" I have 32GB ram in my system to test the theory   Grin

It's none of that. The curses TUI isn't thread safe, so I have to use pthread_mutex to keep stuff synchronized between threads. My shitty coding lead to some deadlocks I think, where one thread was waiting forever for a lock to release. I have no idea about the top stat on Windows though, the same code works perfectly fine on any Unix system I tested (Rpi, Ubuntu, OpenWrt) which are using ncurses lib, so I guess it's a bug in the pdcurses lib which Windows uses (specifically printw/wprintw).

That's good to know, at least you know where to look.  It's a work in progress, people shouldn't expect perfection with every release.  My hat's off to you for your awesome work though.  The top bar was just a 'technicality' in my opinion as the rest of it worked just fine.
hero member
Activity: 616
Merit: 500
Just updated to the new binaries. Working great for me.

Same here...awesome work Sandor.  Not sure why it's "freezing" or "locking up" for some people, I've never had the problem, but I don't have a lot of gridseeds either.  Maybe it's a memory allocation issue with enabling autotune for all those gridseeds?  I'm not sure if you're using hashtables, arrays, or dictionaries to record and keep track of autotune info but maybe people with a lot of gridseeds are hitting a limitation within the method?  

If someone wants to send me 100 or more gridseeds to "test" I have 32GB ram in my system to test the theory   Grin

It's none of that. The curses TUI isn't thread safe, so I have to use pthread_mutex to keep stuff synchronized between threads. My shitty coding lead to some deadlocks I think, where one thread was waiting forever for a lock to release. I have no idea about the top stat on Windows though, the same code works perfectly fine on any Unix system I tested (Rpi, Ubuntu, OpenWrt) which are using ncurses lib, so I guess it's a bug in the pdcurses lib which Windows uses (specifically printw/wprintw).
member
Activity: 86
Merit: 10
I had no problems overnight running the first version compiled today (30 Apr) - windows version, that is. Now using the 3rd compile of today, v0.9a. Top stats are working. Smiley  Thanks as ever for your work.
sr. member
Activity: 252
Merit: 254
Just updated to the new binaries. Working great for me.

Same here...awesome work Sandor.  Not sure why it's "freezing" or "locking up" for some people, I've never had the problem, but I don't have a lot of gridseeds either.  Maybe it's a memory allocation issue with enabling autotune for all those gridseeds?  I'm not sure if you're using hashtables, arrays, or dictionaries to record and keep track of autotune info but maybe people with a lot of gridseeds are hitting a limitation within the method? 

If someone wants to send me 100 or more gridseeds to "test" I have 32GB ram in my system to test the theory   Grin
hero member
Activity: 616
Merit: 500
New windows version is still broken. Only lists 0-29 devices and overall output numbers still showing 0 or - .

I wish you'd tell me earlier about it only listing 30 miners, now I have to recompile again :|
Edit: Fixed + added miner version.
sr. member
Activity: 292
Merit: 250
Just updated to the new binaries. Working great for me.
hero member
Activity: 616
Merit: 500
New windows version is still broken. Only lists 0-29 devices and overall output numbers still showing 0 or - .

Sorry, some issues with Dropbox not updating the files, try re-downloading please.
hero member
Activity: 546
Merit: 500
New windows version is still broken. Only lists 0-29 devices and overall output numbers still showing 0 or - .
sr. member
Activity: 378
Merit: 250
Try now, Dropbox behaving strangely.

Checked my miners this morning. The whole smash is CRASHED!
NOT HAPPY!  Angry
FIX IT PLEASE!
hero member
Activity: 616
Merit: 500
Try now, Dropbox behaving strangely.


is there an easy way to write out the autotune result to use it the next start?
For now, the best way is to turn on logging (--log), and CTRL+F "0@0: autotune stopped", "0@1: autotune stopped", ... Pretty tedious if you have lots of miners or G-Blades.
I'm going add a config generator to the autotune feature.
sr. member
Activity: 252
Merit: 254
Important! You MUST update to the latest binaries (Download on Github)

Have fixed the top stat on Windows (weird bug), and I think lock ups are fixed now too. I have been testing on Rpi and Windows for 6 hours now.

Are the links to the binaries updated?  I downloaded the 'new' version and still have the same problem as before with the top stats - and the dropbox link says "13 hours ago".
sr. member
Activity: 292
Merit: 250
Important! You MUST update to the latest binaries (Download on Github)

Have fixed the top stat on Windows (weird bug), and I think lock ups are fixed now too. I have been testing on Rpi and Windows for 6 hours now.

The binaries on github not updated yet?
hero member
Activity: 616
Merit: 500
Important! You MUST update to the latest binaries (Download on Github)

Have fixed the top stat on Windows (weird bug), and I think lock ups are fixed now too. I have been testing on Rpi and Windows for 6 hours now.
newbie
Activity: 22
Merit: 0
Yes, same for me. Two latest versions still freeze after some hours.
Im back to old version currently.

I believe I'm 2 versions behind and have now been running stably on Win7 for over 24 hours without a problem (1 blade for now)

Just a suggestion though - might be worth putting a version number at the top, somewhere on the:
 cpuminer-gc3355 - Started: [2014-04-29 00:36:40]
line as then we could give you better debug feedback!
sr. member
Activity: 330
Merit: 252
love the single chip autotune function!
is there an easy way to write out the autotune result to use it the next start?

using current version on raspbian.


@sandor111 - great work!
it would be the perfect combination with scripta, or hashra...
member
Activity: 71
Merit: 10
The previous update was working great, but the most recent after the TUI recode and stratum fix crashes after about 2 hours.  The previous version was running solid for 15 hours until I stopped to update.  I can still view the screen but all text has stopped updating on the worker is not online anymore.  Very similar looking crash to the update from 2 revisions ago, before the "TUI stuck" issue was addressed.  I'm sorry if this is no help.   Roll Eyes

RBPi with 3.10.30+ kernel
All updates done
21 5 chip miners

Have you tried running the program in background? (With -t option, TUI will be disabled)
Mine has been running for 8 hrs without problem, using the latest binary on RPi with -D and -t option.
However the drop out issue on Windows 7 seems still persist even with FIFO is disabled. So I'm sticking with PRi build now. With log output and web interface it's still manageable

Which webinterface you using for rassbery pi?
Pages:
Jump to: