|
Thanks for this philipma1957! Now I can run my SP20 on my 1k PSU and use my other for something else.
M
|
|
|
|
Were you guys able to get ssh access on this? i log in with root/root and get invalid password.
It's built like an S2... try root/admin. M |
|
|
|
reason i ask, out of my 18 S3's - i wanna punch at least 7 of them, and kick at least 2 if i had the chance.
I am so sick to death of most of my S3's I just want to have 2 x SP35's as long as they arent to belligerently noisy
Thanks for your help guys. Appreciate any advice
Louder than an S2 I think. SP35 is probably a good deal if you have the power to drive it. If I were you I'd sell some S3s and get some SPxxs. I'm also reading they are good underclockers, if you're into that. I hope to revise to my app so that it works with all SPxxs. M Yep, I'm thinking of getting 2 SP35's - gonna keep my S2's and 6 of the S3's that should give me about 15TH I would add that: 1 - definitely louder, however it defaults to running at 80% fan speed. The Ants are pretty loud at 80% too. 2 - you have PSUs for your S3s.. so unless you intend to sell them too, maybe look at an SP that requires external PSUs? M |
|
|
|
 Loving the cold weather  This is right after a reboot btw Must be running it outside?  I'm thinking of doing the same, but I'm concerned about the dust. M |
|
|
|
reason i ask, out of my 18 S3's - i wanna punch at least 7 of them, and kick at least 2 if i had the chance.
I am so sick to death of most of my S3's I just want to have 2 x SP35's as long as they arent to belligerently noisy
Thanks for your help guys. Appreciate any advice
Louder than an S2 I think. SP35 is probably a good deal if you have the power to drive it. If I were you I'd sell some S3s and get some SPxxs. I'm also reading they are good underclockers, if you're into that. I hope to revise to my app so that it works with all SPxxs. M |
|
|
|
How you got to .27 I don't know  Yeah, it's strange. I only upgraded it a few days ago too....... I've got 2.5.27 on mine Have 2.5.26 on mine. Fresh out of the box today. M |
|
|
|
mdude, any chance you might support the SP20 in your monitor?
Funny you should ask. I just got an SP20 today for just such a purpose. And I mean, I didn't order it today, I received it today. Haven't yet hooked it up.. M SHIT THAT WAS FAST! so whats ur opinion of the SP35? So far I've heard two things about SPxx's: 1 - they are loud 2 - they are reliable and "just work" This SP20 is my first.. so I don't have any experience yet. M |
|
|
|
mdude, any chance you might support the SP20 in your monitor?
Funny you should ask. I just got an SP20 today for just such a purpose. And I mean, I didn't order it today, I received it today. Haven't yet hooked it up.. M |
|
|
|
I have a miner that runs continuously on the pool, but is has not processed a share since i rebooted the server do to having to move its location. The block was found about 4am this morning and there was no pay ut to that miner, is that due to not finding a share, it is a older antminer s1 so kind of slow at 180gh
It'll take a while at 180gh/s. I'd argue that you should have at least 1 th/s to be on a conventional p2pool node. M Rubbish... You can get regular weekly payouts on P2Pool with as little as 10MH/s if you mine on NastyPool with the -PoP flag enabled.  lol... you'll notice he wrote "conventional p2pool node". 10MH/s... you'd be better off hitting a faucet Yes, I worded it that way intentionally. M |
|
|
|
All the Bitcoin protocol cares about when re-targeting the difficulty is how close we were to 10 minutes per block since the last difficulty change. Anything before that is really irrelevant. Irrelevant at the most technical level, sure. But irrelevant on a fundamental level? Hardly. I still disagree. If you include anything prior to the last difficulty change, your estimate is going to be off because it includes data that the Bitcoin protocol doesn't care about. Your statement about hashrate determines average block time is sort of correct. Luck is a factor as well, which is why all pools can suddenly stop finding blocks for hours on end. Granted that shouldn't mean too much at the end of the difficulty period change, but it does influence it. And, as I believe you stated as well, at the end of the day what's used to determine the next difficulty is how long it took to solve X number of blocks since the last change compared to 1 per 10 minutes. Let's say the difficulty has just changed 10 blocks ago.... less than 2 hours. Your app can rely on either the last 9 blocks, or you can rely on a larger dataset telling you that the network hashrate has averaged 280,000-290,000 TH/s during the last month. Which do you think is going to give you a better estimate? If your answer is just "there will be wild swings during the first few blocks after a difficulty re-target" then your app should simply not provide an estimate during that time rather than look like a fool giving an answer based on a tiny sample size. What if the first block is found 10 seconds after the difficulty adjustment, and your app shows a 5000% projected increase? You've got to at least have some sanity checks in there.
I will agree with you there about sample size. I should put an indicator in there about the difficulty changing within the last day, or something, so therefore the sample size isn't large enough to produce a good indication of next change. Regards, M |
|
|
|
I have a miner that runs continuously on the pool, but is has not processed a share since i rebooted the server do to having to move its location. The block was found about 4am this morning and there was no pay ut to that miner, is that due to not finding a share, it is a older antminer s1 so kind of slow at 180gh
It'll take a while at 180gh/s. I'd argue that you should have at least 1 th/s to be on a conventional p2pool node. M |
|
|
|
I can't believe the guy got away with this...sucks
He seems to be an expert thief. Maybe he's sitting in jail somewhere. M |
|
|
|
anyone running these in series or sharing radiators? I am wondering if I could run 3 C1 units on a loop consiting of 2 pumps and 2 radiators. This would provide redundancy in case of failure and it seems that 1 radiator is more than sufficient per C1
I was thinking the same thing: 1st pump -> first C1 -> 1st radiator -> 2nd pump -> second C1 -> 2nd radiator -> 1st pump If you don't have a radiator between each C1, I'd think the water going to the second C1 would be pretty toasty. Might do it someday if price drops enough. M |
|
|
|
(sorry for going so far off-topic in the Eligius thread)
1) Average over how many blocks? The graphs at Bitcoinwisdom show averages over the last 2016, 1008, and 504 blocks, as well as the last 16 blocks on a different graph.... of course the average over 2016 blocks varies less (and is ultimately what determines the difficulty increase), but the average over 1008 or 504 blocks might be more reflective of trends in hashrate. If you are averaging ONLY over the blocks since the last difficulty increase, you're throwing out useful information, because....
2) Taking the average time to solve (however you determine that average), and doing some math with the current difficulty level, lets you back into an estimate of network hashrate. This is the more stable number since of course the time to solve will change at every difficulty reset. (In other words, the hashpower is more stable versus the block time.... in the real world, the block time is determined by the network hashpower, but since we have no way of knowing the true hashpower of the network due to its decentralization, we have to work backwards mathematically, and derive the hashpower from the block time.) The bitcoinwisdom graphs show that the network has reached roughly 300,000 TH/s several times on both the 504-block and 1008-block lines, and come close on the 2016-block line.
So the upshot is that you can and should use the block times prior to the latest difficulty reset. By doing calculations based on the difficulty at that earlier time, you can estimate the network hashrate, which has a tendency to monotonically increase (i.e., it may go up or stay flat, but it will rarely go down for any sustained period).
I'm not sure I agree. All the Bitcoin protocol cares about when re-targeting the difficulty is how close we were to 10 minutes per block since the last difficulty change. Anything before that is really irrelevant. If you did want to try to include prior data, how would you determine where to draw the line? Since the beginning of time? Last month? Last 3 difficulty changes? All are arbitrary, and really have no influence on the next change. One may be able to argue that since a bunch of new hardware was just sent out that it'll increase ... however the price/BTC is also an unknown variable that influences difficulty. If it drops, older hardware will be turned off. If it increases, older hardware may be turned on. M |
|
|
|
I used this for my S3's but it does not work for the C1 the files are not in the same places,
1. SSH into the miner
2. cd /etc/init.d
3. cp cgminer cgminer.bak (in case you really muck it up, cgminer.bak will be your backup)
4. Enter this in the terminal: sed -i 's/--queue 4096"/--queue 0 --scan-time 1 --expiry 1"/g' cgminer
5. press enter
6. go to the web interface of the miner - Status > Miner Configuration > Save & Apply - this will restart cgminer with the new settings
7. go tip Duce for figuring this out for us
does anyone know where to change --queue 0 --scan-time 1 --expiry 1 for the C1
also does anyone have a solution for adding extranonce to the C1
C1s behave like S2s. I think the file is /etc/init.d/cgminer.sh. However changing it is mostly pointless, because the next reboot will put it back to "factory". A much easier way is entering this command: /usr/bin/cgminer-api "setconfig|queue,0" I'd imagine you can also do "setconfig|scantime,1" and "setconfig|expiry,1", but I don't know if you can do it all at once. M |
|
|
|
The estimated next difficulty in my app projects what the next change will be IF the blocks/time solved since last diff change remain constant. is that in a time of hashrate being added to the network (which has been nearly constant over the last several years) the blocks/time solved since last diff change will decidedly NOT remain constant, but will drop. Perhaps Bitcoinwisdom has over-built this idea into their algorithm, so in times like the present where hashrate seems to be leveling off, it is more inaccurate than during times of rising hashrate. As praeluceo said, any predictor is inherently wrong because the future is unknowable, but I have found Bitcoinwisdom to be a better predictor than all others that I've seen. It certainly converges to the true value as the blocks lead up to the difficulty change. I'm not talking about using the overall blocks/time to project next change, I'm talking about only the blocks/time since last change. In other words, we know the target is 6 blocks an hour, or one every 10 minutes. We know how many blocks have been solved since the last change, and we know when the last change was. With those values we can surmise that we're currently solving one every X minutes ... and that value compared to 10 will tell us what the next change will be, assuming we stay at that solve rate. The downside to this is immediately after the difficulty change the number of blocks solved is so small it makes the estimate vary quite a bit. On the flip side, of course, the closer we get to the next change, the more accurate it is. That's what I do, and it must be what Bitcoinwisdom is now doing. (I think we're saying the same thing..) M |
|
|
|
I find the BitcoinWisdom predictor to be fairly reliable. It doesn't swing too much. I don't know what algorithm they use, but it's resistant to at least some of the flaws that I've seen with others. I think it must use some kind of upward bias where it more heavily weights the most recently seen high-point for hashrate. This works on an intuitive level because while new mining hardware might be turned on for testing then taken offline while it's shipped out to customers, after a week or two it will tend to turn on and stay on permanently. So if the network hits a hashrate peak and then drops down, it's a safe bet that it will soon hit that level again. https://bitcoinwisdom.com/bitcoin/difficultyThanks. I don't like bitcoinwisdom at all. I always find it to be wrong.  M Do you have any citation for that? I use BitcoinWisdom exclusively because it's the only forecast I've seen that doesn't swing wildly (like baddw said), and as it gets closer to the change, it's rarely off by more than 0.1%. For this last change, near the last few blocks it forecast that difficulty would go down 0.88%, but it only dropped 0.73%, so they were only off by 0.15%, not too terribly bad if you ask me. All forecasts are "wrong" in the sense that it's the future, so it's unknowable, but BitcoinWisdom seems to do a really decent job at providing a reliable number that more closely matches how difficulty actually changes, unlike many other mining forecast sites. I don't look at it often. Every time I have, it was quite different from what reality turned out to be. Maybe it's changed since the last time I looked at it? My app's calculation is based upon number of blocks solved since last change, so as it gets closer to the next change, it gets more accurate. I really don't know how else you could calculate it and be even reasonably close. M |
|
|
|
I find the BitcoinWisdom predictor to be fairly reliable. It doesn't swing too much. I don't know what algorithm they use, but it's resistant to at least some of the flaws that I've seen with others. I think it must use some kind of upward bias where it more heavily weights the most recently seen high-point for hashrate. This works on an intuitive level because while new mining hardware might be turned on for testing then taken offline while it's shipped out to customers, after a week or two it will tend to turn on and stay on permanently. So if the network hits a hashrate peak and then drops down, it's a safe bet that it will soon hit that level again. https://bitcoinwisdom.com/bitcoin/difficultyThanks. I don't like bitcoinwisdom at all. I always find it to be wrong. M |
|
|
|
Hi , just wondering if the first few posts being solved is why its showing 21G as next difficulty is happening because of cleaning house. It sounds to good to be true but I'd love some easy bitcoin for a few days. EclipseMC is on day 3 of a coin and I can't get payed anywhere till that difficulty balances out.
If you're looking at an app, such as my Pool Monitor app, that calculates next difficulty based on the number of blocks solved since the last diff change, that explains it all. Difficulty did just switch, and I think it decreased almost 1%. The estimated next difficulty in my app projects what the next change will be IF the blocks/time solved since last diff change remain constant. Right after a difficulty change, that number is a bit erratic due to luck. It'll swing wildly all over the place, and then after about 6 hours, I'd guess, it'll get more realistic. And the closer it gets to the next change, the more accurate it'll be. Note this is contrary to what most other difficulty prediction sites (that I've seen) at least do. They make assumptions based on prior increases, SWAGs, and crystal balls, none of which are entirely accurate. Lastly, I think it's unlikely that it'll drop 35%. With the SP20 sales for black Friday weekend, I'd imagine difficulty will increase at least a little. But only time will tell, as there really is no accurate way to predict immediately after a difficulty change what the next change will be. M |
|
|
|
In version 3.8 for C1 does not work reboot manually.
I found a problem and I assume it's what your issue is. If you have S1s or S3s, and then you auto detect your C1(s), it defaults to the wrong SSH password. Please double check your C1s and make sure the SSH password is correct. If you haven't changed it, it should be "admin" (not "root"). Here's version 3.9 to address that auto detect issue, as well another minor issue I've found since 3.8. Download link: MAntMonitor39.zipM |
|
|
|
|
Show Posts
