|
No one is bidding for a very good reason: Those sellers are looking to ripoff un-educated buyers.
At best they are worth maybe $20 w/o PSU and perhaps $40 with a PSU. Plus shipping of course.
|
|
|
|
|
This most likely belongs in the Pools area.
Setup sub accounts in the pool is best. However, not all pools allow it.
|
|
|
|
See my latest Node size post re: more advances in the pipeline regarding things that will increase performance. |
|
|
|
[...]
Excellent. Now if we can just get some input from folks at poolin and Nova we'll be getting somewhere. re:balls, thanks but not really. I play the long game and just have a lot of patience. Also helps that the majority of my farm is at work where I get the power as part of my compensation.  Having been mining there since late 2014 I've been paid a fair bit over 100 BTC - and as an aside plowed the vast majority of that back into the farm for upgrades/expansion over the years... All in all, excellent track record along with a pool op who has impressive IT chops with a passion to do things (programming/testing) right and who is willing to engage with the pools users is what keeps me there.  |
|
|
|
|
Assuming the cord on the burnt brick is long enough cut it off at the brick and wire it to the PSU leads. That's what I did for powering my ancient 10GH Jalapenos.
|
|
|
|
As I said elsewhere bare-bones ckpool with minimal logging for the front-end can be fine for a solo pool where a single miner takes all the risk regarding what they point at it but ckpool can also supply all sorts of performance data about the miners connected as well. That is, provided pool operators chooses to extract, archive, and use it not only to analyze events after-the-fact but also catch/flag them as they are occurring. For a shared rewards pool I feel that should be paramount. Kudos for doing that or at least thinking about it. Best example of a worst case 'why' is of course the infamous Slush kerfuffle a couple years back. |
|
|
|
Ja. The "other" thread went off the rails a while back. I tried to steer it back on point (concerns about the back end) to no avail... LP is able to monitor poor acting fw as their share quality would be horrendous and hr is often intermittent at best. Herp would be terrible and luck as displayed would be low overtime. Easy to weed out in conjunction with their reward would be extremely low at best making it worthless for the miner to use fw like this maliciously on our pool or if not malicious the miner would be able recover by flashing stock or quality fw to continue mining if compatible. Worst case if the miner is unresponsive to adjustment we'd simply block them and with a low reward would leave the rest of the pool relatively unaffected hashing through an entire diff adj. *That* ^^ is what I for one was looking for. Some assurance that the pool is not going to just be running mostly on autopilot with little to no performance logs being kept (and checked) as a certain someone apparently thinks (or now, hopefully - thought - ) a shared rewards pool should do. |
|
|
|
That's a great point, as far as I know, germanium costs way more than Silicon, way harder to keep cold and but can achieve much higher frequency, but the fact that in most applications Silicon is the preferred semiconductor shows that up to now and perhaps in the near future there is no changing in that.
Yep. Fun fact: the 1st transistors created in 1947 were made from Ge and it is still the preferred material for high-radiation areas such as in space because Ge is pretty much immune to lattice damage caused by high-energy particles and gamma rays. In the early 1960's Si really took over not only because its temperature drift coefficient for switching levels (digital on/off thresholds) and bias needs for analog applications is far more stable over temp changes but also because it can withstand far higher temperatures before thermal avalanche occurs and Si has much lower current leakage than Ge. Those 3 points are what is continuing to be roadblocks to using it. edit: Found a good article from 2016 on the push to replace Si with Ge |
|
|
|
Indeed. I remember Kano being an opponent of SPV mining and some drama between him and F2Pool. As in f2pool and Antpool mining 4 empty blocks in a row in 2015(?) that were off-chain thanks to their jumping the gun to be 1st out the gate to start a new (un-validated) block by using results from their previous also empty and un-validated block?  Turns out that someone else had won the Orphan race for that 1st empty & un-validated block that Antpool & f2 had based their chain on.... Oops. Thanks to the back-end monitoring that Kano has he was very quickly alerted to the issue and contacted Antpool ops about it who then quickly relayed the info to f2pool who promptly switched tracks back to the valid current chain and of course invalidating the off-chain blocks they found. Kano.is uses a modified version of ckpool as its front-end in conjunction with KDB which also directly monitors the network via bitcoind. Most of the code is out there in gits. Mind you his changes to ckpool are not there despite him being one of the major developers of it (the 'k' stands for Kano) thanks to a certain someone kicking him off the ckpool github due to irreconcilable differences in their views on proper coding/testing & pool financial safety. Anywho, the core code is there for anyone to peruse & use but Kano's mods to ckpool and updates to his KDB remain private. Since he does not distribute his changes that does not violate the GPL . |
|
|
|
|
One has to wonder about the date of that video.
Per-Kano it takes around 120-150ms to fully validate blocks. Being the operator of a pool that only uses fully validated blocks and has NEVER mined an empty one, he knows what it takes.
|
|
|
|
This means that the more Bitcoin mining facilities the faster Bitcoin transactions have. No, it means the higher diff will go to maintain the target of an average of 10 min per-block.. As for the farm's RO, ja it will be years. So what? That just means the investment is on-par with just about every (non-crypto) sort of industry on the planet. |
|
|
|
1st off, a disclaimer - I've exclusively mined @ kano.is since late 2014 so am rather spoiled when it comes to stats  . That said, in another discussion the topic of a pools back-end monitoring came up. If a pool has a comprehensive database running as a back-end tracking miner type, shares sent/received, worker diff, IP stats, share results eg stale, hi/lo/dupes etc. to make sure everything is running as expected then it should also provide their users with fairly detailed stats. After, all, data collection and generating tailored reports *is* what a DB is written for... If other pools have a back-end DB, how do things happen like the Slush kerfuffle a few years back? Inattention to operations? Just not caring to track things? Running a pool IS running a financial enterprise and must be treated as such. My questions are: What kind of stats do the various pools eg, Antpool, ViaBTC, F2pool, etc. provide? Can (and will) they pull up records of past performance when asked by their users? Obviously, truly large farms with hundreds/thousands of miners will be connecting to a pool through a proxy(s) to minimize connections and their proxies will show up as a single (very large) miner or groups of miners but even they should be able to pull up stats regarding what the pool sees. It'd be interesting to hear what users of the other pools have to say  edit: This is worker stats from part of my farm pointed at Kano.is:  |
|
|
|
|
I agree, esp with point-1.
Chip technology started hitting the point of diminishing return regarding cost vs efficiency with BM's 7nm miners. Ja their 5nm are a bit better but I do not see them pushing for anything smaller for at least another few years. For one, the needed support technology to make, much less mass produce, smaller feature sizes does not yet exist outside of the lab. By then using Ge vs Si will be the game changer (switching threshold for Ge is 300mv or lower vs ~700mv for Si) as it is just too freakin' expensive to use a smaller size for the tiny possible gain in eff.
|
|
|
|
Ok so assuming what Kano claims is correct, does this mean every other pool that allows rental hashrate (almost all of them) lack the skills or don't have a KDB to keep records of all of the information needed to protect themselves? Well, for a start, how many provide in-depth per worker stats to their users? Seriously. It's been many-a-year since I last dabbled with other pools but AFAIK few to none have decent stats available to the user. Considering that generating tailored reports is one of the things DB's are made for, lack of said stats strongly suggest the lack of a comprehensive back-end database. Kano has records of every connection, miner type, and share sent/received going back to the very 1st miner the pool connected to. That very deep DB is what allows him to do meaningful statistics and re-run the results when things don't seem quite right - like what led to the rentals ban. I would hope that other pools DO have something monitoring their assets but are just too lazy to share it. Again, NFI. The Slush kerfuffle a few years back is a rather uncomfortable indication of how some pools and their operators do things... I trust that since running a pool is a financial enterprise, you feel it should be ran as such right? To me that means that if performance data is available one should record and use it to make sure operations are running as expected. Can I add that in all fairness to MFB and Laurentia pool we should move this particular topic of discussion (other pools monitoring practices) to the Kanopool thread or elsewhere? I have nothing against them and it's not cool to keep bumping this one w/o sticking to the point I mentioned above.edit: created a new thread aimed at this exact topic regarding back-ends and worker stats available to users of the various pools out there |
|
|
|
Did you want to lock the thread now? Otherwise I'd recommend to return to shitting on our pool service.
Or better yet, get the thread back on-topic to address the heart of the matter: Namely the fact that ckpool by itself has near zero provisions for recording performance of the pool and miners attached to it. To me at least, *That* is the main concern and reason for this thread. One has to remember that is was written to run -ck's solo pool and for a solo pool all that is needed is recording a users current hash rate, payout address and if they found a block. -ck has and will never change that. That is why the 'records' are scads of tiny text files. However, the data IS available there and can be extracted if one decides to take advantage of it. Once ckpool started being used to run -ck's now defunct shared rewards pool, a huge part of the feud between -ck and Kano dealt with Kano insisting on putting a database (KDB) behind it to record and verify everything going on including values for each and every share sent out and received. That database is the reason Kano was able to analyze performance of rentals to see that (at the time) they were submitting shares to his pool that were far lower diff than statistics said they should be which is what led to rentals being banned. It is also how he was able to discern that eBangs early miners were crap (and subsequently banned as well). How much is -ck against incorporating a database? Well, in addition to the fixes he implemented, the last changes he did to ckpool also intentionally and specifically locks out using it with KDB. No idea if it also breaks links to using other DB's. Of course since Kano wrote a lot of it (ckpool) he had no problem getting around those barriers As to why -ck feels that a proper database is not needed, NFI- ask him. Oh, and if ya did not know it already - Kanopool uses a modified ckpool as its front end which goes to prove that any 'risk' to a pool using it can be mitigated... |
|
|
|
|
Age is irrelevant. What matters is that a person is tech-savy and sad to say - many many folks of all ages - including the young'uns are not. Far too many folks have no idea how everyday things work (eg the internet, smartphones, browsers) and risks associated with blindly 'just using' them with no safeguards in place. Bitcoin and the plethora of shit altcoins are no different in that respect.
|
|
|
|
|
A9's are bigger. At least 140mm.
@Jjmoralesw - do not even think about changing fan speed until you 1st throttle the miner down to a lower speed by lowering voltage and freq.
Good luck with that as the 921 is very picky about what settings will let it run at all...
|
|
|
|
In my country due to the high electricity cost and rentals and along with the high equipment costs this is not making much sense Exactly. If BTC mining was 'easy' then every one would be doing it and like most crap altcoins it would be near worthless. BTC uses PoW to prevent that scenario. As more folks mine Diff goes up which in turn brings cost of operations into the picture. That in turn enforces financial limits on who can mine. |
|
|
|
|
^^ Exactly.
BTC mining is VERY relevant. Why on earth would someone think otherwise? If it was not relevant, no one would be mining and then diff would be far far lower than it is (and folks would then start flocking to it).
Can anyone still mine BTC? No. The entry bar is set pretty high as in many parts of the world cost of electricity is too high, temps are to high, ROI time expectations are unreasonable, etc. That said, as long as your operations cost is less than mining income and you are in it for the long game, then MINE ON!
|
|
|
|
|
Show Posts
