Thanks

Hi

I have 2 FB Apollos which i have just re-directed to Litepool (EU pool litecoinpool.org:3333). Hashrate and HW errors seem fine but discard rates are very high - 1228 accepted 53k discarded. I am using #skipcbcheck in the stratum URL.

The other FB is running at 1.2k accpeted to 9.8k discarded.

Both units are in balanced mode. Is this a hardware or possible pool/latency issue?

any help appreciated.

Buddy.

HI

thanks iot was the different coin stuff.

I have kept donation on... its great kit.

Buddy_hell

Hi

Been working on the Apollo and its a nice job but i have a couple of errors that i cant see fully addressed for my dim mind.

I am trying to run some mining on two pools i can get ML2s running on no issues as long as i use the /#skipcbcheck option.

I run the same pools on apollo then i go inactive after about 2 minutes. System is stable and i am quite happly running up the accepted shares on the donation pool.

I put in the /#skipcbcheck on the two mining pools and hardware errors go through the roof (north of 40%) and we are talking discards in the 3E7 range in a few minutes. At time hash rate will drop to a ML2 level.

take it all off reset and the donation pool runs fine.

Frustrated. Is there a command i can use that will stabilise the units on pools i want to mine? or do i need ot search for pools that surviave the cbcheck?

Thanks
Buddy_hell

Tomorrow i join the Scottish contingent (!) of apollo miners.

I will have "fly me to the moon" playing the background as i watch the hashrate build up..........

Your Buddy Hell

Tried it on two different RPI. executed update and upgrade commands prior to install. Running two different hubs - Orico 9 port runing 3 MLD 2s and an anker 7 port running 3 MLD 2s. Both have the same error.

i have the libjannson and libcurl libraries need to check on the others. I might try refresshing and the autoremove command to see if i have some orphaned routines causing issues.

Both hubs run fine under v34- especially if i use a modest difficulty etc. If i use a low difficulty coin they tend to fallover every hour.

Both.

I set up using a keyboard and mouse, then run the pi's and connect remote via VNC.

I have 9 ML2's ssplit over 3 RPIs and they exhibit similar levels of instability on v34 irrespective of USB hub, frequency or voltage settings. So hopeful for new version if i can get it running, but i get the missing bfgminer error.

andy

To measure voltage you need to physically measure it - instructions on page 1 of this thread.

To change clock depends on version and how you are starting ./bfgminer. Again syntax i think is on page 1. on my setup i can do it through the start up scrypt and edit the command line there, or i go to the bfgminer config file and edit it there.

failing that if you are starting from command line with the the --set... command at the end.

hope that helps.

struggling now. Got the screen command to work and worked out how to reconnect ot the screen etc, but get a bfgminer not found error.......

guessing something went wrong in the process, any tips?

andy

HI

trying to run new update on RP3. Managed to get and compile, but being an idiot i cant see the bfgminer start command. I have a screen start scrypt but it does not execute giving me a "screen not found" error.

any pointers woudl be great. Currently runing v34 which needs restarting periodically.

andy

** idiot indeed - now running the screen install package! Can you add this to instruciton set as not sure this dependency is in the v34 on page 1.

I found that if the MIners are pointing at vardiff ports and they start to change th difficulty often the ML2s will slowly decrease hashrate to 0 and not auto-restart. So i spend my time trying to find the right dfficulty on the port to match the miner and get enough shares to be meaningful. Try as low as you can go on XVG and look for a fixed diff that works on Nyancoin and see if that helps stability.

Pi Update 2:

So for those interested.

I am pretty sure it is not power but an issue when the communication. The ML2s trip-up when the pool and Miner get out of sync (crude so more elegant explanation welcome!).

So i am mining a lowdiff coin on a vardiff port. If i put it on med-diff start on the var-diff or low on the vardiff, the ML2s quickly start throwing accepted shares at the pool but just as quickly start to mount up the hardware errors, or start to slow down. This coincides with old share or pool issued old block messages at times, but can also be when the pool starts shifting difficulty a lot.

If i mine a higher difficulty altcoin or using the high vardiff port or a high fixed-diff port, errors remain below 1% for all ML2s at the higher 768 Hz frequency.

As everything else is the same it is pointing strongly towards communication.

When mining a low diff altcoin that is finding blocks really fast on the pool the setup will still get out of sync, but at least i am starting to see a pattern.

Most likely this is my kit, and i am sure more seasoned miners may have figured this out, but if it helps a fellow newbie then hopefully there is some help in here.

bye for now

Quick footnote. Since writing this initially some 5 hours ago i have the system stable on a more difficult setting on same altcoin.  definetly some for of synch issue between BFGminer and the pool.

Update on the Pi experiment.

So i got two running fine then added a third unit.

The issue i get is that just now i get mining at 20 minute intervals before the ML2's start to effectively start hashing.

I have tried 2 units and messing with the clock frequency but same issue.

Problem seems to be if the miner gets out of synch with the pool - so i get a steady 10-20 minutes now at about 4.3MH/s but after the 20 minute mark i have to reset which takes 2-3 times to get all three hashing (or two when i unplugged one).

I know the most common error is power. I am using a 7 port Anker 60W unit with only the 3 ML2s on it so i would have hoped this would be no issue. I have also tried with 2 rather than 3 with no impact unless it is the maximum draw per USB port that is the issue? For info the pot slots are vertical when tuning - running MLD of 768.

I will play with the pots now and turn them down a litle to see if this stabilises issues.

In the meantime is there a config option that allows a restart to happen when hash rate hits 0 or kH/s so i dont have to keep monitoring it?

thanks

Note: In the time it toook me to write this i have had to reset again!

HI

probably a complete newbie Q.

using CPU miner and happy wiht Devfee, but currently experimenting with a low difficulty altcoin that means devfee goes on the default pools.

Thats all good apart from the Diff setting on the default devfee pools is v.high for my poor old CPU.

I did an xmr altcoin previously and that worked fine, can i set the default devfee pool? or does the highdiff devfee impact on the hashrate on the lowdiff coin?

I have a feeling this is down to my poor understadning of the use of threads. So if 1 thread is chugging away on devfee highdiff, other threads can be running the low diff stuff?

I know it shoud not impact on accepted shares etc just wan to make sure i am optimising correctly?

thx for any help

Hi

I have a ML2-BFGMiner-RPi3b setup which gives me about 2-3Mh/s stock.

The system works well until about 3-4 hours of hashing then the red LED stops flashing and no new accepted shares on the pool.

The pool is still active and the jobs are being received but hash rate falls to zero.

I have tried a couple fo pools and different coins same thing.

I can then software restart the miner and the ML2 starts hashing away again. No hardware reset required.

Is there some setting i need to implement to allow the system to sit more stable? or a way to ether dump the memory or restart miner if it looses the red LED for over a certain time?

any help appreciated