Minor graphical bug to report:
The pool window for BitMiner shows a field "network hashrate" - this field should be titled "pool hashrate".
Would anyone be able to explain quickly what files I need to edit to make this change? It seems like it should be really simple, I tried editing the only occurrence of the term "network hashrate" in the bitminter.php file (\application\includes\classes\pools) but that did not change it. after you edited it did you remove the pool and readd it? Shouldn't need to remove and re-add. Only have to wait +2 minutes (or something like that, it's a hard-coded "cache" value so pools don't block your IP when fetching data). If nothing has changed after 2 minutes prior to the code change, refresh the dashboard... Or, remove the pool "cache" inside user_data/pools/bitminter/* I did remove the pool, log out and quit the program, then restart it and re-add the pool and that field still read "network hashrate", so it must be cached data. I'll try changing it again tonight, thanks.  Also, going back a few pages to this post, https://bitcointalk.org/index.php?topic=569924.msg13113378#msg13113378, as a feature request I think it would be great to have all sorts of fields in these tables that are user selectable so that we can pick and choose what we want to see for each device/pool. I need to send you guys another donation as soon as I get some more coins... |
|
|
|
Thanks Mike. Have you any ideas about a heat sink and fan that would fit? Or some idea if it's a standard fitment for something else.
Nope, I do not know anything about the heat sink or fitment. I assume it's probably a standard size of some sort. I found that the U3 actually passes a lot of its heat out the bottom, so I put a fan beneath my U3 and that cooled it way way down (there's a pict or two in this thread a few pages back), simple mod with good results. I have a broken U3 I would sell just for the shipping cost (0.03 BTC to continental USA) if you want one to disassemble and measure and experiment with. PM me if interested, I was holding it for someone else but they never got back to me. |
|
|
|
The final setup will probably use the insulated tubing to connect the S5 to the vent and see if that makes it quieter as well.
My 3D printed ducts should arrive today, so I spent last night whipping up an insulated vent tube for the S5. I used standard 4" dryer ducting and some sticky foil-backed duct insulation. Adding this vent tube dropped the temp on the miner 1-2*C, I'm guessing the hot air wasn't getting out of the way fast enough without the tube and the hot air was backing up a little in the previous configuration.  |
|
|
|
I think the reason why the difficulty stayed the same is because if you look at ETH hashrate, it went up by 300,000MHs, which is about 15,000 280X, each 280X uses about 175 Watts so about 2,625,000 Watts which at 0.50W/GHS is about 5,250,000 GHS.
So its accounts for the 5PH/s loss in BTC hashrate.
You're assuming that 100% of the Eth mining is being done with psu's that were taken from active bitcoin miners; I don't think that's an accurate assumption. |
|
|
|
Anyone powered the U3 from an ATX power supply? If so can someone point me in the direction of a suitable adaptor cable. Preferable an 8pin to barrel of its possible. You can look on eBay, people used to sell them there. Or you can build you own, it's simple and what I did, then you can build it however you want. The barrel plug on the U3 is 2.5mm x 5.5mm so you know the right one to buy. |
|
|
|
It will not make your USB sticks fail and need to reset. It will not cause lower actual hashrates. If those things happen then it's for other reasons. New work from the server is normal. But how often do you get disconnected? To illustrate what I am seeing I just ran a single gekko stick at kano and bitminter for the same amount of time (couple minutes), look at the hash rate difference (stick should and has average 12-14GH/s) and also the work restarts when pointed to bitminter. Note this is not the miner receiving new work, this is something different that I have only experience since pointing the sticks here:   I will try the other servers and see if that changes the connection drops, but I've never had that happen at other pools. I made no changes to my gear or setup (that have been running for months) other than to point them at bitminter. Hash rate shown in the shift page appears to be more accurate as you stated. For the first 2 full shifts my total hash was about expected, just a little lower than it has been historically, but the next two look at the loss of hash, this is what I'm trying to figure out.  |
|
|
|
well, my S5 controller has 4 ports, and they seem to sell controller cables:
My S5 has 4 ports, also, two are being used by the machine and 2 are open. Are the open ones what would control the pod? Would be an interesting pod if it could run alongside an already running S5, like a piggy back system almost. An S5 will run with 4 S5 Hash cards connected, so if the BM1384 Pod existed and if it had the same interface it would probably work. Rich Maybe this project could transform into a "beef up your S5" type of project. Like they build a couple "gekko S5 boards" that users could either replace their existing S5 boards with, or if they have the controller with empty spots plug in 2 more boards (add cooling, etc.) and get like a 3TH S5-gekko or something... |
|
|
|
If we agree that all pools are equally well connected to the network, then obviously broadcasting an empty block (~200 bytes) vs a full block (~1,000,000 bytes) will be faster.
I don't think it's that obvious. When does a node "timestamp" the block it's receiving, when it first starts seeing data, or when the data is 100% received? I think it's when it first sees data coming in, therefore rendering the size of the block a moot point with respect to propagation rate. We're not comparing 10k to 10,000,000k, we're comparing 200k to 800k and with today's technology those values are essentially the same. |
|
|
|
I was told the same thing last year May 1st 2014 that bitcoin is too volatile, miners cost too much (S5=$350-400) and you would never make a profit. I bought 1, then I went big and bought $20K in miners. 4 months later I paid the miners off, sold them for the same and MORE than I paid for them. I made a nice profit. The biggest difference between early 2014 and early 2016 is now we have the halving on the immediate horizon and that throws a whole box of monkey wrenches into the machine. Things could go exactly the same now as they did then and we might be seeing people selling their S7s for a profit this summer, or we could see a dramatic loss of value in these same miners. Hosting is a great option right now, but I really enjoy the hardware aspect of bitcoin, so I like having my miners where I can interact physically with them. Sometime I just sit and stare at them hashing away... |
|
|
|
Okay exclude Kano then. Take Antpool and F2Pool for example. Wouldn't e.g. Antpool's empty block propagate faster than F2Pool's full block? After all, Antpool has the highest percentage of empty blocks.
I don't think a block being full or empty has anything to do with its propagation speed, i.e. I don't think there is any valid reason for producing empty blocks. |
|
|
|
because im running 2 fans instead of one is it safe to say i should be able to drop the fan speed percentage to 50%?
I am running just the 1 stock fan at 60% and mine doesn't get any hotter than 53.5. I'll probably add a pull fan, too, and then over clock a little and keep the fans turned down as much as possible to keep the dB down as much as possible. |
|
|
|
|
Thanks, I'm on the west coast so I will keep using us1. I am having a few other issues here, maybe you all can help.
Firstly, I am seeing fairly regular "Stratum connection to pool 0 interrupted" and "Stratum from pool 0 requested work restart". Why all the work restarts all the time?
After about 24 hours on this pool I've noticed my usb sticks do not seem to be performing like the have previously. One of my gekko compacs constantly gets "no valid hashes for over 10 secs, attempting to reset" and it only hashes at about 1/3 speed of what it should be. 4 of my 6 nanofury sticks are down about 20% in hash speed also. The worker page on the website constantly shows my miners at 0 hash rate even though they are hashing away, often when I refresh some of the 0s will get replaced with a hash value, but then another miner might show 0. I think this is all related to the min. difficulty of 64 on small miners that do 2GH-14GH each, but I'm not sure.
I added the easy mode perk for low difficulty and set appropriate difficulties under each worker in the field "minimum difficulty". I waited for a while (website said it could take 20 mins) then restarted my miners but they do not seem to be mining at the reduced difficulty that I set, did I do something wrong?
I would like to give this pool a shot but if I can't get my miners to cooperate here I'm going to have to move them back to kano.is. Thanks in advance.
|
|
|
|
Minor graphical bug to report:
The pool window for BitMiner shows a field "network hashrate" - this field should be titled "pool hashrate".
Would anyone be able to explain quickly what files I need to edit to make this change? It seems like it should be really simple, I tried editing the only occurrence of the term "network hashrate" in the bitminter.php file (\application\includes\classes\pools) but that did not change it. |
|
|
|
Off the top of my head I could only come up with this post by ck: https://bitcointalk.org/index.php?topic=789369.msg13822317#msg1382231715 mins ago we got another block
okay I see it on blocktrail but not blockchaininfo The block explorers seem to really struggle around the time the orphans hit. Sometimes they may even need manual intervention to keep working it seems... blockchain is showing Eligius as having won that block yet if you click on their block it then says orphan. Regardless, it's our block as all nodes have synced up to ours and confirmed it numerous times since. Our extensive propagation network (and numerous ckpool improvements to distant nodes) may well have paid off on saving that one. |
|
|
|
Your more likely to get some coin here on those old miners. Cool, thanks for the answers. What are the physical locations of us1.bitminter and us2.bitminter? Is one better for west coast? |
|
|
|
(-3.43%) this is nice
Well, it is nice relative to big double digit positive jumps, but the overall diff is still way ugly. I wish it would at least go under 150G; I would feel better knowing it was closer to 100G than 200G. |
|
|
|
Are you sure about that last part?
Yes. Not true at all, kano.is has about the fastest network block propagation and never mines empty blocks.
If that were true, why would miners bother mining empty blocks in the first place? They lose out on fees by doing so. It's not "if" it were true because it is true. Read Kano's posts about block changes, they do it faster than the guys who mine empty blocks. The empty block miners do it because they are lazy coders who don't care about bitcoin or the network, all they see is $$$. |
|
|
|
|
Minor graphical bug to report:
The pool window for BitMiner shows a field "network hashrate" - this field should be titled "pool hashrate".
|
|
|
|
time and time again we have told people on the forum that paying the vat makes mining a losing investment.
It's almost to the point that anyone paying anything for electricity won't be able to ROI the S7 before the halving. Having to pay more taxes on top of everything only makes it worse. |
|
|
|
empty blocks result from bursts
Uh, what is a "burst"? Whatever it is, it's not why empty blocks happen. Empty blocks come from bad/lazy coders looking for a shortcut. A empty block will propagate faster through the network and a full block would most likely get orphaned (if both are solved in similar times).
Not true at all, kano.is has about the fastest network block propagation and never mines empty blocks. |
|
|
|
|
Show Posts
