Hi! Im a new miner from Spain, Barcelona. Best regards for all!  I have two questions. I hope you can help me because i dont have any idea to find the solution of my problems. My guess is your power supply for your over-clocked machine--can you swap it for a second and monitor to see if it continues to be difficult? I tried with a Power Supply ANTEC HCP 1200W and after 3 hours de hash rate downgrade to 385 GH/s from 510 GH/s  I dont understand why.... I think its not power supply. Maybe the temperature? Its operating at 47-43 ºC.... I think is not an excessive temperature... lliixi you should start low then after a few hours up the frequency to the next until you find where the miner is stable. 212.5 is a good starting point then 218.75 and so on. Many here have been down this road and there is no specific setting for all to follow, what works for one unit may not work on another. You may also look back at the previous pages to see what everybody here has gone through to get a stabilized unit. Trial and error my friend. |
|
|
|
I have not yet, but I'll give it a try. I don't think it ever made a difference on my s1 with manual diff on P2Pool. I'm going with everything default so far on P2Pool with the S3's. Pretty sure there was good bit of discussion about this many pages back. Maybe it's different on the S3, but I doubt it. Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please. https://bitcointalk.org/index.php?topic=671189.msg7598229#msg7598229There was some talk on the other thread https://bitcointalk.org/index.php?topic=671189.msg8139727#msg8139727 that I replied on about the queue which I did see a few pages back here addressed too but must have missed the difficulty post. windpath is conducting some testing with the queue. I am now following the guidance from the Norgz P2P site for the difficulty setting to see if that makes any difference. So far the BestShare value has come back but do not know if that matters. I think the S3 is working fine on P2P but I am sure if we were not trying different settings we would not be happy. |
|
|
|
Has anybody used BITMAINs guildlines for P2P by setting a static difficulty? I tried 256 and my BestShare went just over 1K, at 512 it stays at 0 after an hour. Without the static difficulty they go well over 3M for BestShares and get over 10K within minutes. Maybe I should ask does the BestShare value really mean anything with this current firmware version? On regular pools I never had a BestShare, it wasn't until I went to P2P that BestShare gave me a value. My hash rate did go up a little higher as the guidance said it would though. Education on BestShare please. https://bitcointalk.org/index.php?topic=671189.msg7598229#msg7598229 |
|
|
|
Guys 10,000 RPM is impossible. I have high RPM PC fans that size and I think they run at 2000 RPM. Not even sure I believe 4000RPM fan speed. That's what the small GPU fans on a 290x run at, 4000RPM and they are very loud.
Take the blue (PWM) wire from the fan connector if you are curious and see what you get. You will not get 10K but you will get just below 4K. |
|
|
|
|
Are they really loud? If they are truly running the indicated RPM that would be a little loud.
|
|
|
|
Anyone seeing weird fan speeds with Batch 4? I got fans showing 9000 rpm's.
Yes, it's the first thing that I noticed right after checking to see if there were any x's or -'s. Now that is odd because I think the max RPMs from the B1 fans are 3700-3900. Please let us know if rebooting or reloading the firmware helps. |
|
|
|
Are people happy with their S3 units on p2pool?
If you're on p2pool, are you using the stock queue option (4096) or did you change it?
I'm very happy with the performance of my S3s on p2pool so far, my second batch is arriving today and will pointed at p2pool without a doubt. Its just a better pool I have been testing the queue set to 1 on a single machine, after 21 hours the results are as follows: queue=1 error rate: 0.00086971453% queue=4096 error rate: 0.00180255332 % It is worth noting that both of these are impressively low, I'll keep testing with a couple more machines, but I'm 99% confident queue =1 is the way to go. I ran for 36 hours with a very low return (I know 3 days to level out) on P2P but I did get a share. The queue was set stock to 4096 (yes I changed it back to test more for those who have read this entire thread) then I changed it back to Queue=1 and within minuets my chart started going up and now starting day 3 from making the change it looks like it is going where it should be. Now could this have been luck/variance/coincidence, not sure some may say yes or just dumb luck. Take it for what it's worth but I made the change around 8 PM. What you do not see is the level remaining below 4.0mBTC for the first ~24 hours. There is also a very good P2P thread https://bitcointalk.org/index.php?topic=18313.9840 |
|
|
|
Others with a similar experience found that it was DNS related. Thank for your reply, but im 100% sure i have it setup properly. I didnt changed router, provider or anything else. So if i compare default gateway with my router (ipconfig), its the same as always: 192.168.0.1. For beeing really sure about this settings, I tried also use DHCP and it assigned to miners the same settings. Also there shouldnt be any relation between "miner status" stats and DNS. As i remember, if i even dont have miners connected to the internet, tab "miner status" was normally visible. Or am I wrong with my thoughts? Look back on page 171, this might help you out. |
|
|
|
Anyone know what the new product on Bitmaintechs website is??
Antminer Jumper Switch??? MOQ 500 Units so its for resellers.
It is a PSU power switch used vice a jumper wire. |
|
|
|
I'm also having the issue with the S3 hashrate dropping off. It generally starts around 435Gh but drops to around 390-400GHs. I'm at work now and I'm looking at my S3 on Slush's pool and I'm currently showing - Total average hash rate in last 60 minutes: 381070 Mhash/s  Has anyone found a solution to this or had word from BitMain? Some units do and some don't, try a lower clock such a 212.5 as others have identified. I have one that runs steady at 218.5 and another that does not like the stock clock but runs fine at 212.5, and is reliable at that speed. |
|
|
|
FWIW, After ~10 hours running with --queue 32, slightly overclocked to 225, share difficulty set to 256. Does not seem to have affected hashing at all, but noticeable CPU load decrease. Please, what would you suggest we set the queue, scan time and expiry to?
Again, do not touch scan time and expiry. Giving you generic advice regarding the queue setting is difficult because this is not my driver...I'd be surprised if it really needs to be that high though, and on a low powered system there is rarely anything to gain from anything even in the hundreds, let alone thousands. Thanks for this. Going to run one of my units with --queue 32 overnight and see how the stats look when I wake up. I tried it at 64 and got a high discard rate. I'll try it with 32 as you have and see if that will be my sweet spot. I removed the scan time and expiry as ck suggested. I am glad "CK" provided his input as I too removed scan and expiry from the settings for pool operation but have put them back in for P2P testing as "CK" said was worth testing. BTW apparently "BestShare" is always reported from P2P but not all major pools. Don't know if you noticed that or not so I figured I would throw that out there. |
|
|
|
I should also add that with underpowered CPUs that are always overloaded, using a pool with a large coinbase unfortunately will make things worse and increase the CPU usage further. "Generation" coinbases where your coins are generated instead of sent to you (such as those used by Eligius and p2pool) are two examples. That doesn't preclude them from being used, but it's worth experimenting to see if it matters.
Understood, thank you. |
|
|
|
I was able to get the discarded amount lowered as well as the load. I changed the queue to 0 from 4096 and added --scan-time 1 --expiry 1 to the cgminer file. ***IF YOU ARE NOT SURE WHAT THIS MEANS DO NOT TRY AS YOU WILL BRICK YOUR UNIT*** This is the first attempt, not sure if 0 is the optimal queue value for all pools but if you are a P2P miner you may want to try this out. I use a smaller pool and my numbers have gone up. This is along the same tune you could do for an S1 but a far cry from what we did in the GPU days. I have another unit running at a lower speed but have the same results. SSH in then: vim /etc/init.d/cgminer
--scan-time 1 --expiry 1 Find line 75 PARAMS...at the end change --queue 0 and add --scan-time 1 --expiry 1 before the quotation. ***DO NOT TRY THIS UNLESS YOU FULLY UNDERSTAND AS YOU WILL BRICK YOUR UNIT**** Please stop telling people to do anything but change the queue. Artificially lowering the discarded value serves no purpose whatsoever. Decreasing scan time and expiry are for the dark ages of CPU mining - paying any attention to the "discarded work" value is completely pointless and actually harmful. The only thing here that's making a difference to CPU load is decreasing the queue which they have set far too high by default. Please do not decrease it below 1 though. Perfect so the queue should be set to 1. For the P2P folks, scan time and expiry settings will not help them as there were no settings included? (yes/no) I truly appreciate and respect your inputs both positive and negative. |
|
|
|
I was able to get the discarded amount lowered as well as the load. I changed the queue to 0 from 4096 and added --scan-time 1 --expiry 1 to the cgminer file.
***IF YOU ARE NOT SURE WHAT THIS MEANS DO NOT TRY AS YOU WILL BRICK YOUR UNIT***
Hey Duce, I'm browsing these threads while I wait on my 2 S3's (currently in Louisville.). I've had an S1 for a couple months - works well but I notice it's discarded is pretty high. (currenlty 21000 discarded and 31000 accepted.) WIll your mod work for the S1 as well? Couldn't find anything on the net about high discards on the S1. In other words, adding --queue 0 and add --scan-time 1 --expiry 1 be okay for S1? Thanks! d Yes, this originally came from a mod for the S1 to tune P2P. The difference I did not address the shares as most pools now (if not all and except for P2P) use stratum. |
|
|
|
can someone share what is a single S3 on a decent PSU pulling from the wall in terms of power ?
cheers
Corsair RM750, 354-377 depending on clock speeds is what I am getting @110VAC |
|
|
|
|
I am happy to contribute.
I wonder if kano is going take a look at the code and see what he could do as he for the S1 units.
|
|
|
|
Hey Duce, could we get an update on your firmware adjustments?
Setting the Queue to anything but 0 increases both the Load and Discarded values. After another run with the Queue back to 0, accepted values are about the same as stock. My other unit is performing just like this except it likes a lower clock, such as 212.5 as others have identified. Again if you are on P2P then this should be good for you but the Queue value may interact different with your pool. The unit here is connected to a regular pool. Here is the same unit as before with the last run I started.  |
|
|
|
I was able to get the discarded amount lowered as well as the load. I changed the queue to 0 from 4096 and added --scan-time 1 --expiry 1 to the cgminer file.
***IF YOU ARE NOT SURE WHAT THIS MEANS DO NOT TRY AS YOU WILL BRICK YOUR UNIT***
Thanks for this post ! Going to try this on one of my units and see how it works out. This was default on the new firmware: PARAMS="$AOPTIONS $POOL1 $POOL2 $POOL3 $_pb $_ow $_bec --api-listen --api-network --bitmain-checkn2diff --bitmain-hwerror --queue 4096" I tried it on one by adding the --scan-time 1 --expiry 1 flags, but didn't see any difference in discards or load. Maybe some of you will have better luck. Did you change the Queue to 0? |
|
|
|
looks like the load was lowered, but it is hashing slower with less accepted shares
Poolside  The hash went up poolside. Strange the way the pools are exaggerating the rates, such as BTC G is doing as well. I will work with the Queue values to get a reading on how it effects both GUI and poolside values. BTW philipma1957 I am sure you recognize the pool used here. That is quite a significant difference between what the miner says and what the pool says. You know how if it is returning allot of work during a period the pool will normally reflect a higher rate, right now it is 497 poolside and GUI 466. Need to find the sweet spot for all of the settings. |
|
|
|
The new Firmware is up https://www.bitmaintech.com/support.htm?pid=007201407180243004432lBQW28O0633Quote "No beeper altert when there is no immediate hashing work. During the normal mining, Green LED is always on. If there is no immediate hashing work for 1 second, the Green LED will turn off. If it lasts more than 1 minute without hashing work, green LED is kept off and beeper rings" |
|
|
|
|
Show Posts
