|
Every few days I seem to see a few shares accepted by my secondary pool. It's as if there are intermittent connection problems to WafflePool, so my rigs point at the secondary. When the primary connection comes back up, the rigs point back at WafflePool.
While this is not a serious problem, it is a bit annoying. It means that there's always some dust on my secondary pool. Since the secondary is also a multi-pool, it eventually gets paid out. Although I never hit the daily minimum on the secondary, so the dust doesn't clear for a week or two.
Both of my rigs are running in a small data center with reliable power and Internet. It seems unlikely that the connectivity problems would be on my side.
This happened again today. Looks like the last accept on the secondary pool was around 17:37:02 PDT. I'm specifically pointing at uswest.wafflepool.com.
If more information is needed, I can dig into the logs on my rig to see if I can spot the error messages associated with pointing at the secondary.
Like I said, this isn't that big a deal. I figure that all mining pools have occasional connectivity issues. In fact when I was pointed at that other multi-pool as the primary, sometimes my rigs would temporarily connect to WafflePool (which was the secondary then).
|
|
|
|
Thank you for that advice. I like this site. So I guess a good move is to just scrypt whatever is hot at the moment(top of the chart) and convert to Bit. Makes sense.
You should check out this thread. The OP posts actual returns from hash power pointed at various pools: https://bitcointalk.org/index.php?topic=514242.0Short answer: You should mine scrypt and point at either WafflePool or CleverMining. I've mined at both and like both of them. Given that their profitability is usually very close, I slightly prefer WafflePool because it's somewhat more transparent and has tons of statistics. It also has JSON API that third parties have used to create stats applications. If you want the simplest configuration and want to get going as quickly as possible, consider getting some DualMiner USB devices. But don't pay full price. Try to get them for their sales price of around $45, otherwise you can forget about the possibility of ROI. You have to buy 10 of them though to get that price. An alternative that's probably more cost effective, but is harder and requires more DYI and tweaking, would be to get some GridSeed 5 chip units. The price of these have fallen considerably. When overclocked, you can get about 360 Kh/s out of them. At this point I would steer clear of using graphics cards for mining scrypt. They are much more power hungry. The only advantage of going with graphics cards would be if you want to mine something beyond scrypt, like scrypt-N. Some people think that is where mining will go after ASICs decimate the scrypt mining scene. For what it's worth, I've got both a DualMiner and GridSeed 5 chip rigs. I have no plans to go to graphics cards. I've found this to be a fascinating hobby. Nowhere else can you find this combination of crypto, computers, software configuration, currency speculation, and an admittedly slightly artificial sense of the gold rush. |
|
|
|
|
Does this version of bfgminer support setting individual frequencies on a per Gridseed device basis? If not, does any variant of bfgminer have device specific frequency support?
I've got my Gridseed rig pretty well dialed in with individual frequencies that maximize utility. I can't go back to a version of miner software that only lets me set one frequency for all devices.
|
|
|
|
I've used the girnyau and mox235 versions of cgminer, but have seen stability issues with my GridSeeds. I've mostly worked through the issues, but have had to leave the cron jobs of Scripta off due to what I think is a bug in cgminer that can happen when the API is called simultaneously. I also have seen a case where cgminer completely crashed, as well as a more subtle problem where a Gridseed will just stop submitting shares even though it's still hashing. I'm interested in this bfgminer branch because some people have indicated that it's more stable. I'd like to give it a try, but I'm concerned about power usage. The girnyau version disabled the BTC cores, as per this note from the github page: This version of cgminer turns off all BTC cores so that power usage is low. On a 5-chip USB miner, power usage is around 10 W. GPUs are also supported.
I've built the Gridseed branch of bfgminer as per the instructions from the OP, with the scrypt option on. However, I noticed that the resulting built version also supports SHA256 based algorithms and hardware. I have no interest in mining BTC. I just want to use bfgminer with my Gridseeds for scrypt mining. I'm concerned that even if I'm passing the --scrypt option when mining that the Gridseed BTC cores might still be on and drawing power with this version. But honestly I don't know if that's the case or not. Can anyone tell me if this version of bfgminer will use more power than the girnyau version when mining script? |
|
|
|
Thanks for the block reader link. I didn't know about that site (still new to this stuff). For grins I grabbed the list and sorted by BTC. I assume that the 63.23467726 payout was to the whale? There were only 4 other payouts a BTC or greater, and all of them were single digits. Nice to know that a lot of miners (1313) are in my shoes at around 0.01-ish ;-) |
|
|
|
|
Long updates, and a local block chain size of 20 GB. Something is going to have to change or this will get untenable.
|
|
|
|
Ok... I'll try to explain this problem again and hopefully someone else has experience and can help me.
Problem #1: 11 GS miners hashing power degrading and not maintaining advertised hash rates. This is a problem on 3 sites currently. I continue to see the hash rate degrade on MP, IPOM and CM. It does not matter the coin or site. GS's supposedly should run at 0.333MH/s but mine are degrading over time until all 11 are at 0.27MH/s.
Suggestions I have tried but will not work... MP suggested setting share difficulty to 64. Tried but no improvement observed.
Mine on equip set for mining only. Rasp Pi is dedicated 100% to GS mining. i.e. suggestion no help!
Problem #2: Eventually, all 11 miners will shutdown... MinePeon shows no miners active even though miners are still running? Failover fails (no pun) and backup pools never activated even though software is set and supposedly is capable of restarting on backup?
Here are my settings from MinePeon.... Please if anyone has success running GS's with minepeon and can give me some real help, please contact me.
#!/bin/bash
sleep 10
/usr/bin/screen -dmS miner /opt/minepeon/bin/bfgminer -S all -c /opt/minepeon/etc/miner.conf --scrypt --set-device gridseed:clock=805
Isn't 805 an odd frequency? Did you mean 850? BTW, there seems to be some anecdotal evidence that GridSeeds are happier with frequency values that are an even multiple of 25. Since moving my GSDs to frequencies like that, I've seen more predicable performance. |
|
|
|
Yep, this is the major downside of no user accounts. For this to work it will require signed messages. We'll try to make it as easy as possible, but would be signing something like "doge=xxxxxxx, ltc=yyyyyyy" from your BTC account, so we can verify it was you. I expect a huge number of "HOW DOES I SINE?" emails, and a lot of "My address is at my exchange, so I can't sign" problems, so we'll see how that goes...
Maybe the answer is to add optional user accounts? If you want to use the pool as it is today with default payout options, you would not need an account. But if you want non-default payouts, you'd need to get an account and set up your profile and payout options. I know that adding accounts has its own set of complications, like database schema changes, email verification, SSL certificates (and avoiding Heartbleed), two factor options, etc. But it's probably simpler to support because users are familiar with accounts and managing profiles and options. Also, you can build new features on an account system later, like hash rate drop alerts, etc. I think it's more complicated than that. Current users wishing to convert to a user account would still have to go through message signing, otherwise they wouldn't be able to claim their existing BTC address. It also opens some attack vectors that don't exist with an anonymous service. 2FA would help somewhat but is it all really worth the trouble and risk. That's a good point. You need proof of ownership of a BTC address in order to claim it. But that could be a onetime event. After that managing your addresses and payout options under an account profile GUI would be much easier and supportable than sending a signed message for every option change. |
|
|
|
Yep, this is the major downside of no user accounts. For this to work it will require signed messages. We'll try to make it as easy as possible, but would be signing something like "doge=xxxxxxx, ltc=yyyyyyy" from your BTC account, so we can verify it was you. I expect a huge number of "HOW DOES I SINE?" emails, and a lot of "My address is at my exchange, so I can't sign" problems, so we'll see how that goes...
Maybe the answer is to add optional user accounts? If you want to use the pool as it is today with default payout options, you would not need an account. But if you want non-default payouts, you'd need to get an account and set up your profile and payout options. I know that adding accounts has its own set of complications, like database schema changes, email verification, SSL certificates (and avoiding Heartbleed), two factor options, etc. But it's probably simpler to support because users are familiar with accounts and managing profiles and options. Also, you can build new features on an account system later, like hash rate drop alerts, etc. |
|
|
|
None of what I'm about to say is fully fleshed out yet, its just my first stab at how it would be handled (what makes sense as fitting into the existing payout/balances system). It is very likely to change. Payouts would still be done at the normal timings (2x daily). We wouldn't be offering to exchange coins into anything other than BTC, just offering to send out coins we had mined (and possibly only a subset of the actively mining coins) instead of exchanging them to BTC first. For this example, lets say we added payouts in LTC. When we did the normal process of exchanging coins to BTC, we would look at how many people wanted payouts in LTC, what their balances were, and keep that amount of LTC off to the side (instead of exchanging), the rest would be sent to the exchange as usual. When were to run payouts later, we would have some users who requested LTC. These users would be paid from the LTC that was held aside from exchanging, and any other balance in BTC. For example, if we didn't mine any LTC that day and didn't have any LTC, you may have requested LTC as a payout option, but would be getting payouts that day in BTC (no LTC held aside, no earnings in LTC for the day). Other days, if we mined 50% LTC, 50% others, you would get 50% of your payout in LTC, 50% in BTC. Essentially everything would stay the same in terms of exchanging. Coins would always go XX -> BTC, just some coins could bypass our exchange process, and be held for payouts. The issue of what price they're "sold" at I hadn't thought much about yet. I imagine we'd have two valid options there, neither is quite right, but both seem close-enough to be acceptable. One option is to use the last-trade price (or highest bid), since these aren't actually being sold immediately, they don't affect depth/etc. So if we sent you 1 LTC, we would count that as exchanged to BTC (for profitability calculations) at the current price. The other alternative would be to use our existing pricing system, which accounts for depth/markets. The first option would be high (not everyone can sell at the highest bid), the 2nd option would be low (we estimate prices extremely cautiously). Maybe we average them? Most likely (at least to start), we'll only be adding a few of our larger coins that we mine on a daily basis (and mine in enough quantity to justify payouts). The ones that come to mind immediately are LTC/DOGE. Adding more wouldn't be difficult, but those two are a good starting point I think  An extension to this (and a decently sized extension it is), would be to allow for some of your BTC balance to be "exchanged" to LTC locally. For example, if you wanted LTC payouts, and we had another user who didn't want LTC payouts, we could theoretically move "exchange" some of your already converted BTC earnings (non LTC earnings) for his not-yet-converted LTC earnings (exchange price makes more of a difference here). This is just something we could theoretically do, it wouldn't be planned for the initial implementation (way more things could go wrong here comparatively). This really does sound like an interesting feature. The option of receiving coin in the currency mined (as specified by the user) would let us more or less automatically diversify our coin holdings. Of course the percentage of diversification per day would be based on what was mined, which is arbitrary and based on profit. But still I think this is a useful feature. I also agree the priority of offering this in the larger coins only to start. I'm personally not interested in holding coins other than BTC, LTC, and DOGE right now. I don't quite understand the issue you raise about what price is "sold". Is this just a statistics reporting issue? Because if there's no exchange, then there's just a transfer from the pool to the user. Or is the issue that in order to determine the share or fees for a user you have to come up with the equivalent of a "sold" price? Thanks for thinking about this feature. |
|
|
|
Hello all,
I have ordered my first gridseed from GAWminers, and have followed the guide to download cgminer for Ubuntu from this post. I believe I have succussfully downloaded it as I was able to get it to start up at the end, but obviously it says no USB device detected.
I have been mining with 3 r7 265's for the past month, but before that had no experiece in linux or computer building. I built my first computer and with some help was able to get my cards mining. I use sgminer and get it started by cd ~/ and then ./mine.sh.
I was wondering if there was a way to start cgminer like that, as I think the only way I was able to get it running was by calling cd ~/ then ./cgminer/cgminer -o xxxxx and all the information for gridseed after. I was wondering if there was a way to start the gridseed mining by calling on a .sh file like I do for my gpus. I am hoping someone doesn't mind answering my elementary question. I want to be prepared to have the gridseed up and running right when it gets here and not have any software issues. Will the gridseed work by running cd ~/ then ./cgminer/cgminer -o stratum+tcp://server:port -u username.worker -p password --gridseed-options=baud=115200,freq=888,chips=5 --hotplug 30? It currently starts to look for a pool when I type that in now and feel like it should work once the gridseed is hooked up, and is there any easier way to get it running other than how I stated.
I also plan to just open cgminer in a second terminal, as my gpu's currently run on sgminer. Will this cause any problems?
Thanks!
Are you running cgminer as root? I think you have to do that or it won't be able to talk to the GSD's. I have two rigs, one is Gridseed 5 chip based and the other uses DualMiners. In both cases I run cgminer as a service via Daemontools. I've posted a "how to" here in case you're interested: https://bitcointalk.org/index.php?topic=577018.0If you're on a real linux box and not a Raspbery Pi, then you can probably skip my instruction about installing ramlog because you probably don't need it. If your cgminer still can't see the GDSs, then you can tell if they're visible on the USB bus via this command. This might help rule out a USB hub or connection problem: lsusb -t If you need an example config, here's the one that I'm using with the mox235 variant of cgminer (same as girnyau but with better JSON API output): {
"gridseed-options": "baud=115200,freq=850,chips=5",
"gridseed-freq" : "8D6E50A55748=900,8D9136685748=875",
"kernel-path": "/usr/local/bin",
"failover-only": true,
"verbose": true,
"api-listen": true,
"api-port": "4028",
"expiry": "120",
"hotplug": "5",
"log": "5",
"no-pool-disable": true,
"queue": "1",
"scan-time": "30",
"scrypt": true,
"shares": "0",
"pools": [
{
"url" : "stratum+tcp://uswest.wafflepool.com:3333",
"user" : "REPLACEME_workername",
"pass" : "x"
},
{
"url" : "stratum+tcp://sf.clevermining.com:3333",
"user" : "REPLACEME",
"pass" : "x"
},
{
"url" : "stratum+tcp://us-west.coinshift.com:3333",
"user" : "REPLACEME.workername",
"pass" : "x"
}
]
}
The above config defaults to a frequency of 850 unless overridden. You can see that the "gridseed-freq" option demonstrates overriding the frequency on a per serial number basis. You have to replace "REPLACEME" in all cases above with your bit coin address. Do yourself a favor and copy and paste the address. These addresses are case sensitive, so one upper or lower case mistake and your earnings go into a hole. Change "workername" to the name you want for your rig, in case you have more than one and you want to be able to tell them apart. I'm also using the mox235 version of Scripta as the web front end, but it's kind of involved getting it installed and working on an existing Linux system. Here's a link to the basic instructions I followed, if you're feeling up to it: https://litecointalk.org/index.php?topic=9908.msg138403#msg138403Remember to use the mox235 version of scripta with the mox235 version of cgminer. They've both been modified to provide improved information, including displaying the serial number and frequency of each GSD (which is insanely useful if you have more than one and want to tune them). Note that if you use my mechanism of running cgminer under a service, you don't want to integrate the Scripta rc.local file. Also you should replace their start/stop scripts with your own that call daemontools to start and stop the miner. But frankly I just use Script for status, not control. Also, when I leave the Scripta cron jobs on, they cause USB disconnects. I suspect this is a cgminer bug when multiple cron jobs hit the API simultaneously. Some people have successfully staggered their Script cron jobs to avoid the problem. Probably too much information, but I hope some of it helps... |
|
|
|
I run my rigs completely headless. I want the miner software to automatically start at reboot or when it crashes. I also want a few days worth of logs for troubleshooting, but I don't want the logs to chew up too much disk space and I don't want to wear out the SD card in my Raspberry Pi. There are a number of ways that people autostart their miner software under Linux. But some of the techniques are really not very clean. I'm not interested in running the miner under "screen" and having no reasonable log history. When I want to check on my miners, I prefer to a web front end or a script that calls the miner software's JSON API. So what I've done is use daemontools from D. J. Bernstein to manage the mining software. It's a simple and awesome set of tools that reminds me of "launchd" for the Mac, but better. If anyone is interested in going this route, here's how to setup cgminer (although any mining software should work) under daemontools. Install daemontoolssudo apt-get install daemontools-run daemontools
Create the directories for the run and log scripts: sudo mkdir /etc/service/cgminer
sudo mkdir /etc/service/cgminer/log
Put the following script in a file called "run" in the /etc/service/cgminer directory: #!/bin/sh
# cgminer/run
# run script for cgminer daemon
# Minimal environment
PATH=/usr/local/bin:/usr/bin:/bin:/
# Redirect stderr to std out so that our log will pick it up
exec 2>&1
echo "*** Starting service cgminer..."
# Exec cgminer, which preserves the same process. Change the path and options as needed.
# Note that you have to run cgminer in text-only, non-terminal mode. I opted to force that
# option here rather than rely on it being set correctly in the conf file.
exec /usr/local/bin/cgminer --config /home/pi/config/cgminer.conf.ltc --text-only
Note that you may have to change the path to the cgminer executable and your conf file above. By default daemontools will run services as root. This works well for me because I found that cgminer seems to need root permissions to access the USB devices anyway. But if you prefer to run your miner software as another user, it's easy to do. See the "More information" section at the end of this post for links to daemontools documentation. If you want logging enabled, then you need to put this script in a file called "run" in the /etc/service/cgminer/log directory: #!/bin/sh
# cgminer/log
# log script for cgminer daemon
# Minimal environment
PATH=/usr/local/bin:/usr/bin:/bin:/
# Define the path to the log folder
logFolder=/var/log/cgminer
# Make a folder fo the cgminer log files
mkdir -p ${logFolder}
chmod 755 ${logFolder}
# Set up multilog to handle logging the output from cgminer. It will rotate after 10 meg and
# keep two historical copies in addition to the current one.
exec multilog s10485760 n3 ${logFolder}
The above script will put the log files in the /var/log/cgminer directory. The current log file will be called "current". The parameters to multilog above indicate that it should limit the log file size to 10 meg, and that it should keep the most recent 2 log files plus the current one. This way old log data is deleted and you won't run out of disk space. You have to also make sure that both scripts are executable: sudo chmod 755 /etc/service/cgminer/log/run
sudo chmod 755 /etc/service/cgminer/run
If you've done everything right, then cgminer should be running. If you reboot, cgminer will be auto started. If cgminer crashes, then daemontools will restart it automatically. Check the serviceYou can use the following command to check on the status of cgminer running under daemontools: sudo svstat /etc/service/cgminer
And you can see what's happening in the log with a tail command like this: tail -500f /var/log/cgminer/current
If you need to stop cgminer, maybe because you want to change the config file or other maintenance, this command will stop the cgminer service: sudo svc -d /etc/service/cgminer
This command will start the service back up again: sudo svc -u /etc/service/cgminer
A couple of thoughts regarding logging. First, I'm not sure how safe it is to run a Rasperry Pi from an SD card with lots of log churn. I'm not an expert on flash technology, but I was concerned that at some point lots of log writes might wear out the flash. Again, I must stress that I don't know if this is a real problem or one that I've imagined. Originally I thought that I'd have logging on only while my rig was new and that I'd disable it later to conserve flash write cycles. But after running two rigs for over a month, I came to the conclusion that logging is essential. Problems crop up with my rigs, and access to historical logs are the only way to figure out what happened. Second, when I first set up logging, I could not get it to work. Apparently there's an issue with daemontools where if you create the service "run" script first, then you create the "log/run" script, the daemontools service scanner doesn't see the change and does not enable logging. To work around this, I rebooted my system after configuring logging. After that, logging worked like a charm. There's probably a more elegant way to work around this issue, but I didn't look into it further. Using ramlogSince I decided that logging was essential, but I didn't want to burn up my flash, I decided to use a package called ramlog. This useful package keeps the log files in ram, committing them to disk only on reboot. This should save on flash wear and tear. Instructions for installing ramlog follow here. EDIT: If you're using Raspbian Jessie, then don't install ramlog. Use log2ram instead. See my post below for details. First, you need to figure out how big to make the ramlog partition. So how big is my log folder now? sudo du -sh /var/log
9.9M /var/log
How much of that is the miner log? sudo du -sh /var/log/cgminer
5.9M /var/log/cgminer
So the regular log files amount to about 4M on my Pi. I've set the miner logging to only keep 3 log files at a time and limit them to 10 meg. I think that means it can grow to 30 meg (including the "current" log). How much ram do I have left? free -m
total used free shared buffers cached
Mem: 437 180 256 0 15 82
But I've seen it a lot lower (like 160M). So I think 50 meg for the ramlog is probably enough and won't impact the system too bad. Once I knew how big to make my ramlog mount point, I followed these ramlog installation instructions: https://raw.github.com/swirepe/personalscripts/master/pi/setup-ramlog.shIn case the above URL goes away, here's the steps I took: sudo apt-get install lsof
mkdir ~/packages
cd ~/packages/
wget https://raw.github.com/swirepe/personalscripts/master/pi/ramlog_2.0.0_all.deb
sudo dpkg -i ramlog_2.0.0_all.deb
echo "TMPFS_RAMFS_SIZE=50m" | sudo tee /etc/default/ramlog
sudo reboot
So now all log files are written to a RAM disk based mount point and have no ongoing impact on the flash. When the system is rebooted, the log files are committed to flash, and then read out on the other side, so they aren't lost. But that's a lot less wear and tear than continuously writing log file data. Shortcuts for convenienceIt's nice when I log in via ssh to have a simple set of commands to check on the miner software status, start/stop the miner, etc. Rather than try to remember the commands, I've made a few simple shortcuts that I've added to my .profile, plus help text that's displayed at log in time. This is of course a completely optional step, but I find it helpful. Here's the script code to add to your .profile file: # Miner system shortcuts
alias miner_shutdown='sudo shutdown now'
alias miner_reboot='sudo reboot'
# Shortcuts for miner service
export MINER_SERVICE_PATH="/etc/service/cgminer"
alias miner_stat='sudo svstat ${MINER_SERVICE_PATH}'
alias miner_start='sudo svc -u ${MINER_SERVICE_PATH}'
alias miner_stop='sudo svc -d ${MINER_SERVICE_PATH}'
alias miner_restart='miner_stop; miner_start'
# Miner log shortcuts
export MINER_SERVICE_LOG_PATH="${MINER_SERVICE_PATH}/log"
export MINER_SERVICE_LOG_HIDDEN_PATH="${MINER_SERVICE_LOG_PATH}_hide"
alias miner_log_stat='sudo svstat ${MINER_SERVICE_LOG_PATH}'
alias miner_log_start='sudo svc -u ${MINER_SERVICE_LOG_PATH}'
alias miner_log_stop='sudo svc -d ${MINER_SERVICE_LOG_PATH}'
alias miner_log_tail='tail -500f /var/log/cgminer/current'
# Misc miner shortcuts
alias miner_list='sudo cgminer -n --usb-devs'
# Show some useful commands
miner_help()
{
echo "Here are some helpful mining commands:"
echo
echo " miner_shutdown - Shut down the system."
echo " miner_reboot - Reboot down the system."
echo
echo " miner_stat - Shows how long the cgminer service has been running."
echo " miner_stop - Stops cgminer service."
echo " miner_start - Starts cgminer service."
echo " miner_restart - Restarts cgminer service."
echo
echo " miner_log_tail - Tails the current mining log."
echo
echo " miner_list - Asks the miner app to list known devices."
echo
}
# Display a welcome message
miner_welcome()
{
echo
echo "Welcome to $HOSTNAME!"
echo
miner_help
}
# Show the welcome when logging in
miner_welcome
So if something is wrong, I can ssh in and look at the current log via miner_log_tail. If I've changed my config and I want to restart the miner service, I use miner_restart (which just stops and starts the service). More informationLastly, if you're interested in more information regarding daemontools, here are some links that I used to get my feet wet: http://lgallardo.com/en/2013/05/06/daemontools-o-como-relanzar-un-proceso-si-muere/http://blog.teksol.info/pages/daemontools/tutorialhttp://thedjbway.b0llix.net/daemontools/overview.htmlHopefully someone finds this info helpful. |
|
|
|
please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real
LOL! Amen to that! No one else seeing extremely Low hash rates on WP??? Trying to determine where my issues is at.. My poolside hash rate look fairly close to my local reported rate. I've got two asic rigs, one is based on DualMiners and the other on Gridseed 5 chip units. If you have multiple pools in your config, maybe some of the hash is pointing at another pool? I see a small amount of leakage to my second configured pool every day. I assume that there are occasional connection problems to WP, so hash gets briefly redirected. But my config is such that it always returns to the primary pool. Do you have logs that you can check? I run cgminer as a service under Daemon Tools, so I always have a rotating log that I can check when stuff goes weird. |
|
|
|
please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real, please let the stats be real
LOL! Amen to that! |
|
|
|
My question is on which pool everyone is using. I am mining litecoin on netcodepool.org. Its been fine but only about 120 workers. My hash rate is pretty good but I am wondering if I would earn more from a different pool that has more workers?
I've mostly been on CleverMining, but now I'm on WafflePool. Both are well run multi-pools with similar profitability over time. They both automatically convert to and pay out BTC. They both charge a 2% fee. But I prefer WafflePool's better transparency and an abundance of stats. Also WafflePool has quite a bit more hash power at the moment, which reduces variance. You might want to check out this thread where the OP tracks multiple pools and the actual results from hash pointed at them (as opposed to using the advertised stats from the pool operators): https://bitcointalk.org/index.php?topic=514242.0 |
|
|
|
|
Looks like things have gotten quiet on this thread. Does that mean that people are largely happy with the move to 0.1% fees and mBTC?
|
|
|
|
|
I think that WafflePool provides a pretty nice balance where it comes to transparency. Yes, today was odd because the largest percentage of mined coin was hidden. But that's an anomaly, as far as I can tell from the relatively short time I've been mining on the pool.
Previously I was on CleverMining, where there is no transparency. So to me WafflePool is like a breath of fresh air.
|
|
|
|
...having endless trouble trying to get my 37 DM 2.0 rig with 5 Orico ten ports running with rasp pi. I followed all steps correctly, ensured that the pi was not buggy (interchanged it with working 5 chip rig), and don't seem to have any connection happening (no lnk light) via Ethernet to ssh with putty.
Any ideas much appreciated.
Ps anyone have luck with 30 plus dms on windows dualminer software?
I had a heck of a time just getting ten goin stably....
I have 29 working and completely stable on a Raspberry Pi with the dual miner cgminer and mineninja. This sucker will run for weeks on end without any problems. My current uptime is nearly 15 days. It's much better than my GridSeed 5 chip rig which I've found to be much less stable, and a pain to set up and tune. One thing you have to be very careful about is making sure that you don't have more than 9 DMs in an Orico. Also, due to the underlying Orico sub-hub layout, you have to leave the slot nearest the power switch empty. This is absolutely critical. If you leave the wrong slot empty, you're going to see stability problems. So you should follow the diagram on this thread or the DM site exactly. Regarding your connection to your Pi, that sounds like a fundamental Ethernet problem and unrelated to the DMs or any USB problem. If you don't see a link light, it could be anything from a bad Ethernet cable, to a bad switch, to a damaged Pi. |
|
|
|
thanks that help we out alot i go give it a try right now. 1 last question do you have to state every device speed?
The way it works is you can specify a default frequency, plus any serial number/frequency combinations that override the default. That's what I did initially, but in the end I put all of my GS units serial numbers in the config because I found it was more convenient for tuning. Here's an example of what you could put in your Scripta miner.options.json file, where 850 is the base frequency for any units for which you haven't specified an S/N specific frequency: {
"key": "gridseed-options",
"value": "baud=115200,freq=850,chips=5"
},
{
"key": "gridseed-freq",
"value": "8D6E50A55748=900,8D9136685748=875"
},
|
|
|
|
I hope someone can point me in the right direction here. i been looking for hours and cant get individual unit freq tuned. And i cant find a good post on it.
i running 31 units on a ubuntu box. i modded 5 units some with resistors and some with just the bridges. i ran each unit individual on my raspi and found the freq they will run at without Hw's. i was using scripta or the pi to do this with.
i did a git pull from "git://github.com/dtbartle/cgminer-gc3355.git"
when i enter
"
sudo ./cgminer --scrypt -o site -u username -p x --gridseed-options=baud=115200,freq=850,chips=5 --gridseed-freq 8D8B16785748=1150,8D9123A95748=950,8D6A187B5355=950,8D6A187B5355=900,8D70218C5355=950,6D95246D5650=950 --hotplug 0
"
it says "./cgminer: --gridseed-freq: unrecognized option"
i running 31 units on a ubuntu box. i modded 5 units some with resistors and some with just the bridges. i ran each unit individual on my raspi and found the freq they will run at with out Hw's. i was using scripta or the pi to do this with.
Does this version not support freq tuning? i believe i read else where it does per miner but im thinking that was a different version and not this one.
This is the version that supports the per-unit frequency mods: https://github.com/girnyau/cgminer-gc3355.gitNote that it also outputs different values for the API, so Scripta as-is cannot display the hash rate. I ended up moding Scripta to handle the girnyau output. But now I'm using this version of cgminer that outputs the serial number and frequency for each unit (which is insanely useful): https://github.com/mox235/cgminer-gc3355.gitThe above mox235 version is based on the girnyau fork. I code reviewed the changes and it's identical except for the API JSON output changes. Here's the matching mox235 version of Scripta to handle the display of the new API output (and fixes a bunch of Scripta bugs): https://github.com/mox235/scriptaI additionally merged in my mods to the mox235 Scripta variant and can provide them if they're useful. I find it nicer to view the Gridseed unit output in KH/s and the total in MH/s. |
|
|
|
|
Show Posts
