Quoting myself for relevant content here: The way they make announcements to a wide audience without ever communicating directly with any of the users here on the forums reminds me of the smug behaviour of deepbit during its dying/quietly fading days but in an even worse manner showing what looks like a complete lack of respect to miners. Compare their communication to Eleuthria's of BTCGuild who has continually responded to almost every single comment no matter how mundane.
Users have more power than they think and the bitcoin mining community at large has held many groups to task over the last few years and it remains the responsibility of users to continue protecting other users and bitcoin. The reason ghash did not reach 51% was because of the many warnings posted here and elsewhere. While you're all complaining that a simple announcement by ghash to tell miners to direct their hashes elsewhere is nowhere near enough of a total solution to the possible destabilisation of the network by them receiving a majority of the hashrate, bear in mind the only reason they have made this announcement is because of continued pressure by the community and it should be seen as a major milestone, but I agree we must not become complacent by this one step alone.
I absolutely agree that we should not become complacent. As you point out, the community at large has some power, and also has responsibility. Yes, we as a community of miners are actively keeping an eye on things, pointing out areas that require attention, etc. The pool operators are also responsible for taking proper action. The warning message is certainly a great start. It is only that, though: a start. Further action needs to be taken by the pool. If GHash.io truly means what they say, then such action would be taken by them. Posting warnings here is useless. They should raise fees and start disconnecting slower miners.
How is disconnecting slower miners the solution? What is considered "slow"? Wouldn't that just encourage faster miners to then connect since they don't have to be concerned? I'm also not too sure about the raising fees proposition. What does that do except get GHash.io richer? They buy more hardware, have more "cloud" mining on cex.io. |
|
|
|
So, I have now had my batch 1 Antminer S3s running for about 18 hours. Throughout this time, I've been playing with them, tweaking settings, changing pools, etc. Here are my results regarding p2pool to this point: - Overclocking. Everyone wants to know, "How well do they over clock?" The answer is, at least from my experience thus far, "Not well." You can over clock them up to a chip frequency of 250 using the asic-freq configuration file - which is the same file you used in the S1. The stock clock is set to 218.75. My recommendation is to keep them right there for the best stability and consistent hash rate on the pool.
- Hashing speed, hardware errors and ASIC failures. I had different experiences with each of my S3s (I only have 2). I left them both overclocked to 250 overnight to get a gauge on things. On my first unit, the miner stats page reported about 450GH/s, and had an "x" or two sprinkled in the ASICs. My second unit reported about 387GH/s average. It had a "-" on one of the ASICs. I noticed this behavioral pattern throughout my tests (set a clock speed, let it hash for an hour or so and look). The hardware errors actually were exceptionally good no matter what clock speed I tried - I think 0.5% was about the highest I saw in one test.
- Hashing on a different pool. I tried experiments on Eligius, BTCGuild and Ghash.io, hashing on each for about an hour or so at different clock speeds. While I did see slightly higher reported rates in the S3 stats, it was not like what we saw with the S2 losing 10-15%. Yes, at one point, one of my S3s was telling me it was hashing at 500GH/s, but that didn't last long and I got a bunch of "x" in the ASIC stats.
- Power. I didn't try playing around with different cable configurations - like what happens if I try to set the clock to 250 but only put in 2 cables? I might try something like that today. I have all 4 PCI-e connectors powered on each device currently because I was playing around with over clocking. I will be going down to 2 each, and will report back later on the effects running at stock clocks. By the way, both S3s are driven on a single EVGA G2 1300.
- Draw at the wall. Unfortunately I don't have a Kill-a-Watt, or any other tool to measure actual wattage, so hopefully somebody who does can chime in here. All I can tell you is that even running full out at max over clocking the PSU fans were never spinning loudly. I'm pretty sure it was barely even noticing the draw.
- Under clocking. I have yet to try lower clock speeds and would be interested to see the hash rate and power draw results from somebody who does it. If you could get a consistent 400-420GH/s for 250-300 watts, then running 4 on a single PSU would be a very worthwhile operation.
- Random weirdness. I don't know how to describe this, or why it happens, but my S3s will randomly let out a beep. It's the same beep as the "just coming online" or "you just rebooted" beep. At first I thought my units were just constantly rebooting themselves, but that's not the case. They just like to emit a random beep, I guess to let me know that they are still there. There is a configuration in the Miner Configuration tab that allows you to switch off beeping - and it works for when you lose connection to the network - but it has no effect on this random beep.
At this point, I'm keeping my S3s running stock clocks and pointed to my local p2pool node. Below are the screenshots of my 2 S3s at stock clocks hashing to my local node:   |
|
|
|
I'm wondering, with high variance on p2pool or another somewhat smaller pool, is it possible to actually lose money? Like in the long run luck is irrelevant, but what if you have really bad luck and then the difficulty goes up 30%?
In this situation do you lose money because of high variance?
Yes you can. Consequently you can also gain money. Contrary to what people will insist on, it does NOT even out in the end because difficulty keeps rising. However luck determines if you're ahead long term or behind long term in an irretrievable way. If diff did not continually rise and rose-and-fell or stayed the same it would even out. Your argument is based on the statement that difficulty keeps rising. While historically this is true, it is not a guarantee of future patterns. Yes, we have seen some insane rises in difficulty, but that is due to a number of factors including wider acceptance, general knowledge of crypto-currencies, incredible hardware advances, etc. I don't think we can state as a fact that difficulty will forever continuously rise. I did not argue that it will rise indefinitely. However, it's realistic to predict it will continue to rise until it levels off. Once it levels off, it is never going to fluctuate as much as it did to pre-rise diff levels. Until it levels off (and this could be years away) this issue will hold true, and all the variance experienced till that point can never be caught up on. As I said though it's not a guaranteed loss, it's almost as likely a guaranteed win. The fact that by definition bad luck means blocks take longer means the statistical bias is towards a loss, but that statistical bias is nowhere near as large as the variance effect itself is. Put it this way, many diffs ago, on a lucky day in mining, you could earn 10 bitcoin in one day or 1 bitcoin on a bad day with 60GH. In today's diffs, even if they fluctuate a little instead of just going up, there is no way in an eternity you could ever make up those 9 bitcoin with 60GH unless you used your avalon as a weapon to hit someone over the head and steal their money.The next block halving will probably be the only time we'll ever see a significant drop again (unless BTC value crashes). What effect that will have on a tight margin network (unlike the GPU days) is unpredictable. Con, the statement that I bolded is absolutely fantastic. I laughed out loud at it. I see what you're getting to here as well, that good luck in the past might have earned you 10 BTC on a good luck day, but only 1 BTC on a bad luck day. The earnings are considerably less now, and I wonder if that same statement holds. On a good day, you can earn 1 BTC but on a bad day you might get 0.1 BTC. Can you make up that 0.9? With the current state, would the variance be that large now - i.e. swinging by as much as 10x? Personally, I've not noticed my payouts vary that wildly. They have their up and down swings, but nothing that extreme. It would be fun to see this kind of thing plotted out. |
|
|
|
When you setup the fixed address, did you do it at your router by mac address, or on the S3?
EDIT: Never mind... I re-read what you wrote. Since you included the comment about setting up the DHCP server, you obviously didn't just put a static IP in the S3. Duh... sorry about the stupid question back at you.
Yes by MAC @ your router.. Well after 5 hours of testing all I have to say is BLAH!! Overclocking even with 4 PCI-e connections does little. 218.75 Clock: miner 1 / 444.95 @ Miner / 463.36 @ Pool miner 2 / 427.78 @ Miner / 432.18 @ Pool miner 3 / 443.52 @ Miner / 454.49 @ Pool miner 4 / 410.05 @ Miner / 410.58 @ Pool --- Indicates 1 chip as " - " miner 5 / 427.41 @ Miner / 413.85 @ Pool 250 Clock: miner 6 / 464.32 @ Miner / 479.65 @ Pool --- Indicates 1 chip as " x " miner 7 / 450.27 @ Miner / 417.84 @ Pool will continue to mess with timeouts to see if anything works as for now not getting a stable 441 GH/s, but on a few. ;( Hope B2 is better! I hear ya. I left mine at 250 overnight and checked when I woke up a few minutes ago. One miner had a "-", the other had 2 "x". The one with a "-" only averaged 387GH/s from the miner stats, and pool stats (my local p2pool node) showed just about the same. The one with 2 "x" did better. It showed an average hash rate of 454GH/s on the miner and about 450 on my node. I've set them back to stock clocks and will see where I am in 8 hours or so. By the way, I'm driving the S3s on an EVGA G2 1300 with 4 PCI-e connections to each miner. |
|
|
|
The actual solution would be to deny new connections once it has reached the limit it wants to. That way, there is no new hashpower. Their current policy is to send out messages and warnings, but that is useless.
Another option is to disconnect all miners, and only the ones that reconnect quickest will be able to stay. They can also increase fees to reduce hashrate.
This is probably the best solution. We ask end users to control themselves and this of keeping the network distributed. If they fail to do so then it is up to the pool op to see a workaround (assuming ghash.io truly doesn't want to see 51%). Don't allow any new connections. Other coins already do this when they get above 35% on some pools, this should have been implemented some time ago. Most, if not all, of us are saying exactly the same thing... that the POOL needs to take action. Simply sending out tweets and posting in forums asking miners to pretty please with sugar on top stop mining on the pool is only the first step, and it should be done when the pool hits 35%. When the pool hits 39.99% simply deny connections. 51% problem is solved. |
|
|
|
My miners were doing the same random beep as you describe, I setup the dchp server to fix an ip for each and the beeping stopped. Too many iDevices on the network seemed to cause too much conflict for temp. leases.
When you setup the fixed address, did you do it at your router by mac address, or on the S3? EDIT: Never mind... I re-read what you wrote. Since you included the comment about setting up the DHCP server, you obviously didn't just put a static IP in the S3. Duh... sorry about the stupid question back at you. Well, that didn't solve it on my side unfortunately. Still random beeps. That's going to get annoying quick... |
|
|
|
General questions about the S3 now that mine have been hashing for a few hours...
1) Why in the name of all that's holy does it randomly beep? Every now and then it just goes "BEEEEEP!" It's not like it's rebooting... it just decides to let everyone know, "Hey, I'm here! Pay attention to me!"
2) I know the "o" in the miner status means "OK" and that "x" means "error". What does "-" mean?
General comments:
1) At stock clocks it hashes almost exactly to spec on p2pool (my local node). Initially it was around 450GH/s, but after settling down and going for a few hours now, it's about 439GH/s.
2) Overclocking it has far less effect on p2pool than on another pool. For example, at 250, I get about 455GH/s on p2pool. I get 500GH/s elsewhere with the same settings.
The beep is internet connection lost or failed to get work. It will retry to get work or listen for the internet connection up to a point. If it keeps hashing then its doing what its supposed too. The config now allows you to turn it off if it is really annoying. I did turn it off, yet it still will randomly just let out a beep. It hashes away happily...then BEEP...still hashing...I think I'll beep now... It happens at all clock speeds on every pool I've configured (my local p2pool node, another p2pool node, Eligius, BTCGuild, and yes, the pool that shall not be named). My miners were doing the same random beep as you describe, I setup the dchp server to fix an ip for each and the beeping stopped. Too many iDevices on the network seemed to cause too much conflict for temp. leases. When you setup the fixed address, did you do it at your router by mac address, or on the S3? EDIT: Never mind... I re-read what you wrote. Since you included the comment about setting up the DHCP server, you obviously didn't just put a static IP in the S3. Duh... sorry about the stupid question back at you. |
|
|
|
General questions about the S3 now that mine have been hashing for a few hours...
1) Why in the name of all that's holy does it randomly beep? Every now and then it just goes "BEEEEEP!" It's not like it's rebooting... it just decides to let everyone know, "Hey, I'm here! Pay attention to me!"
2) I know the "o" in the miner status means "OK" and that "x" means "error". What does "-" mean?
General comments:
1) At stock clocks it hashes almost exactly to spec on p2pool (my local node). Initially it was around 450GH/s, but after settling down and going for a few hours now, it's about 439GH/s.
2) Overclocking it has far less effect on p2pool than on another pool. For example, at 250, I get about 455GH/s on p2pool. I get 500GH/s elsewhere with the same settings.
The beep is internet connection lost or failed to get work. It will retry to get work or listen for the internet connection up to a point. If it keeps hashing then its doing what its supposed too. The config now allows you to turn it off if it is really annoying. I did turn it off, yet it still will randomly just let out a beep. It hashes away happily...then BEEP...still hashing...I think I'll beep now... It happens at all clock speeds on every pool I've configured (my local p2pool node, another p2pool node, Eligius, BTCGuild, and yes, the pool that shall not be named). |
|
|
|
|
General questions about the S3 now that mine have been hashing for a few hours...
1) Why in the name of all that's holy does it randomly beep? Every now and then it just goes "BEEEEEP!" It's not like it's rebooting... it just decides to let everyone know, "Hey, I'm here! Pay attention to me!"
2) I know the "o" in the miner status means "OK" and that "x" means "error". What does "-" mean?
General comments:
1) At stock clocks it hashes almost exactly to spec on p2pool (my local node). Initially it was around 450GH/s, but after settling down and going for a few hours now, it's about 439GH/s.
2) Overclocking it has far less effect on p2pool than on another pool. For example, at 250, I get about 455GH/s on p2pool. I get 500GH/s elsewhere with the same settings.
|
|
|
|
|
I don't know if this has been mentioned yet... but the S3 has wireless. I've got mine in hand, saw the wifi tab, figured I would try it out. Bam!
So, while I don't see any place to hook in an antenna, having it sitting right next to my router, that's kind of irrelevant.
I'm getting ~450GH/s on p2pool (my local node). Not bad at all!
|
|
|
|
Your argument is based on the statement that difficulty keeps rising. While historically this is true, it is not a guarantee of future patterns. Yes, we have seen some insane rises in difficulty, but that is due to a number of factors including wider acceptance, general knowledge of crypto-currencies, incredible hardware advances, etc. I don't think we can state as a fact that difficulty will forever continuously rise.
Just wondering... I thought that the difficulty levels where built in to the whole pattern... or design of bitcoin and mining... I thought that it was set well in advance every level? Is it possible that it will stop going up?? I figured for sure within a few months I would be pushed out because of this and the expenses...? Running 4 TH for a few months now and it has gone way down..... The difficulty is not set in advance, it is a byproduct of the network "resetting" itself to ensure 10 minute block generation time. Every 2016 blocks, the network basically says, "Ok, it's been 2016 blocks. How long did it take me to get here? How does that compare to what it was supposed to be? Adjust to compensate." Yes, that's a simplification, but you get the point. Given this description, you can see that it indeed can stop going up. If the average time for the previous 2016 blocks is greater than 10 minutes, then it would go down to compensate. Last time that happened? January, 2013. |
|
|
|
Woot here is my S3 hashing away....  Stable at 454GH Look at the average, not the 5s to see a better gauge of your speed. That 5s one will fluctuate all over. You're at ~443 stable. |
|
|
|
|
Why get so complicated? At 39.99%, stop accepting new connections. No need to do anything like examine when a miner connected to determine if it is eligible to be dropped.
|
|
|
|
no all they need to do is put you in a bitsolo.net or solopool.net type server
type section when they get over 38 percent. auto notify you that you are now solo mining and giving you a chance to go to another pool or continue to solo mine.
even if another 10% is in that section they are all solo-mining (thus not causing the 51% danger) not a difficult solution for them to offer.
most will not want to solo mine and will go to btcguild or bitminter or eligus or slush
I would think implementing a forced redirect to another pool would be more complex than simply not allowing a connection at all. |
|
|
|
The actual solution would be to deny new connections once it has reached the limit it wants to. That way, there is no new hashpower. Their current policy is to send out messages and warnings, but that is useless.
Another option is to disconnect all miners, and only the ones that reconnect quickest will be able to stay. They can also increase fees to reduce hashrate.
All viable potential solutions. What they are doing now is no solution at all. |
|
|
|
|
It's great that GHash.io is making this statement; however, what is it that they are doing to actively prevent this from happening? As the pool's hash rate approaches 40%, you're asking the community to move to another pool. What if they don't?
There is nothing actually being done by GHash.io here. Sending out tweets and posting in the forum requires MINERS to be proactive. It's time for the POOL to take action. Check out what BTCGuild does... might want to consider some similar approach.
|
|
|
|
I'm wondering, with high variance on p2pool or another somewhat smaller pool, is it possible to actually lose money? Like in the long run luck is irrelevant, but what if you have really bad luck and then the difficulty goes up 30%?
In this situation do you lose money because of high variance?
Yes you can. Consequently you can also gain money. Contrary to what people will insist on, it does NOT even out in the end because difficulty keeps rising. However luck determines if you're ahead long term or behind long term in an irretrievable way. If diff did not continually rise and rose-and-fell or stayed the same it would even out. Your argument is based on the statement that difficulty keeps rising. While historically this is true, it is not a guarantee of future patterns. Yes, we have seen some insane rises in difficulty, but that is due to a number of factors including wider acceptance, general knowledge of crypto-currencies, incredible hardware advances, etc. I don't think we can state as a fact that difficulty will forever continuously rise. Just as you can have swings of bad luck, you can also have swings of good luck, which you correctly argue. It would be an interesting experiment to see where the "tipping point" is. In other words if we assume X change in difficulty, what is the point Y of bad luck from which you will likely never be able to recover? There is a forum member named davejh who does some really great statistical analysis. I'd love to see him plot this kind of thing. |
|
|
|
Chinese friends on the 1st order, on the 17th of arrival.
Here is the actual situation of ants running P2POOL S3, and much better than expected
very good, although, it is as would be expected, since it's a local node. Not really. My S2s lose ~10% of their hashrate local or not on p2pool. This is good news indeed for p2pool. M Juan from 112bit put up screenshots of his S3 mining on GHash.io yesterday and had an average of 450GH/s. If the S3 is reporting 439GH/s on p2pool, that's pretty much right on target for Bitmain's claimed specs of 441. Looks like I'll be plugging mine into my local node after all  |
|
|
|
Hi guys,
scammer crap removed
Where is the security?  Report it to the mods/admins. It amazes me that people fall for these things... Hi! I have a group buy thread going, but haven't posted anything about pricing there. I am, however, writing to you in a PM to let you know about this absolutely fantastic deal! Just for you, if you send me 50 BTC I'll send you the new time machine I've created! That's right... go back in time to visit ancient Greece, or head to Egypt to see how the pyramids were really built (let me tell you, it's not what you think  ). |
|
|
|
When I had my SP10 sent to me it was held up at shipping. They wanted me to send them an FCC paper stating what the device was and something along with homeland security. Held up my delivery and extra day.
One form was called - department of homeland security. IMPORTER ID INPUT RECORD
and the other form was STATEMENT REGARDING THE IMPORTATION OF RADIO FREQUENCY DEVICES CAPABLE OF CAUSING HARMFUL INTERFERENCE.
Both these forms were sent to me by the shipping company via email. Had to fill them out and then email them back.
Thanks for the info opentoe. I'll be on the lookout for an email and will send an email to UPS for details. I had to do the same. I got an email from Fedex and filled out the forms and emailed them back - all while I was sitting at the Sky Club lounge in JFK waiting for my flight to Tokyo. The girl I was chatting with stated that anything over $2500 declared value needed to have importer forms filed. If you're a business they require your tax ID. If you're an individual, it's your social. Just checked UPS... my S3s have departed Anchorage and are on their way. Still scheduled on time delivery for tomorrow. |
|
|
|
|
Show Posts
