CrashOD
Newbie
Offline
Activity: 41
Merit: 0
|
|
March 20, 2014, 08:03:58 PM |
|
After over 24 hours mining on the new stratum server, I have <1% rejects down from 6%, but my average hashrate has dropped 17%! I went from an average of 6MH/s before, to 5MH/s over the last 30 hours. At first I thought it was just variance, but it seems to be consistently staying lower. No config has changed on my end. Any clues what could cause such a dramatic change/loss in hashrate?
I noticed something similar as well. I lost close to 10% of my reported hashrate according to wafflestats. I went from 10.2 MH/s over the last few weeks down to 9.25 MH/s since the update. Quite concerning. Have you noticed your hashrate bouncing around and averaging to a lower than normal hashrate, or is it fairly consistent around 9.25 MH/s? I ask because I noticed that my hashrate now bounces around from 1.5 to 7.5 MH/s whereas it used to always be within a tighter range of 5-7 MH/s.
|
|
|
|
|
|
|
|
|
Remember that Bitcoin is still beta software. Don't put all of your money into BTC!
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
daeminium
|
|
March 20, 2014, 08:06:56 PM |
|
crazy hash
|
|
|
|
ziddey
Newbie
Offline
Activity: 16
Merit: 0
|
|
March 20, 2014, 08:24:20 PM |
|
poolwaffle, I don't have access to the btc address I've been using any more, and so can't send you a signed message from it. Is there any other way I could verify that the address was mine and transfer the balance to a different address? It's not a lot, but enough to be sent out on the Sunday 0.001 payout and get vaporized.
|
|
|
|
boxofspuds
Newbie
Offline
Activity: 51
Merit: 0
|
|
March 20, 2014, 08:41:33 PM |
|
poolwafle : do i need to tweak my expiry setting to avoid stales ? do they mean any kind of loss when if they are accepted ?
on another topic
with all the extra server capacity : what u think about seting up a scrypt-n based "altpool" on a different port ? or the current sever already capable to handle scrypt-n ? is there actually ANY scrypt-n based multipool around ? could it be a possible direction for WP to evolve , or pool mining those would simply destroy that market ? or its just way to early to work on or even to think about the implementation ?
yeah i suck at english but i think u might get my point
There is another multipool that has a scrypt n port. I think it closed registration. I am not involved with it(but do mine there at times) but I'll also not name it in this thread as I dont think it is right to advertise a diff pool in another pool's thread.
|
|
|
|
semajjames
|
|
March 20, 2014, 10:24:26 PM |
|
Hi Do we have to use a different ip address to log in now the new system is here ??
thanks
|
|
|
|
comeonalready
|
|
March 20, 2014, 10:34:05 PM Last edit: March 20, 2014, 11:59:55 PM by comeonalready |
|
author=comeonalready
And it is payout per MHD!
I see you insist... Ok. Let me show you my reasoning for why IT IS NOT MHD and then you can just slam down your irrefutable proof and I'll stand rebuked. let's say that your hashrate is 1 MHs. Meaning that your computational power can "solve" 1 million hashes in a second. Analogous to active power being measured in kW, the energy consumption is measured based on the consumption of power in a unit of time thus the kWh unit of measure. When you want to see how much energy you consumed in a DAY you just count the kWh which means you consumed 24 kWh/day (for 1 kWh). when you use BTC/MHD you are implying that your hash rate is 1 "MH per day" which is false. your hash rate is an average of 1 MHs over a day's time and you contributed with 3600* 1 MH in a day's time. WP states [0.01 btc/(average MHs) in a day] and not the amount of hashes in a day. And lastly, the unit of measure is MHs. you can twist that figure to show a day or a year but it's still MHs as reported by your miners. BTC/Day BTC s 1 Day BTC -------- = --- x --- x ------- = -------- 1MH / s Day 1MH 86000 s 86000 MH
For convenience I suggested that we create a unit named MegaHashDay (or MHD) to equal 86000 MH, but that has proven to be anything but convenient. So let's call it a Thump instead, as that is the sound you hear when you bang your head against a wall. Until you hear nothing at all that is... BTC / Thump
|
|
|
|
zSprawl
|
|
March 21, 2014, 12:26:07 AM |
|
author=comeonalready
And it is payout per MHD!
I see you insist... Ok. Let me show you my reasoning for why IT IS NOT MHD and then you can just slam down your irrefutable proof and I'll stand rebuked. let's say that your hashrate is 1 MHs. Meaning that your computational power can "solve" 1 million hashes in a second. Analogous to active power being measured in kW, the energy consumption is measured based on the consumption of power in a unit of time thus the kWh unit of measure. When you want to see how much energy you consumed in a DAY you just count the kWh which means you consumed 24 kWh/day (for 1 kWh). when you use BTC/MHD you are implying that your hash rate is 1 "MH per day" which is false. your hash rate is an average of 1 MHs over a day's time and you contributed with 3600* 1 MH in a day's time. WP states [0.01 btc/(average MHs) in a day] and not the amount of hashes in a day. And lastly, the unit of measure is MHs. you can twist that figure to show a day or a year but it's still MHs as reported by your miners. BTC/Day BTC s 1 Day BTC -------- = --- x --- x ------- = -------- 1MH / s Day 1MH 86000 s 86000 MH
For convenience I suggested that we create a unit named MegaHashDay (or MHD) to equal 86000 MH, but that has proven to be anything but convenient. So let's call it a Thump instead, as that is the sound you hear when you bang your head against a wall. Until you hear nothing at all that is... BTC / Thump Doesn't that prove it is BTC/MH*D? The point being the D is not in the lower part of the fraction...
|
BTC: 1EyCRbT3YeskViEtH9KfRLpjdR2nsrrcW6
|
|
|
comeonalready
|
|
March 21, 2014, 12:32:24 AM |
|
author=comeonalready
And it is payout per MHD!
I see you insist... Ok. Let me show you my reasoning for why IT IS NOT MHD and then you can just slam down your irrefutable proof and I'll stand rebuked. let's say that your hashrate is 1 MHs. Meaning that your computational power can "solve" 1 million hashes in a second. Analogous to active power being measured in kW, the energy consumption is measured based on the consumption of power in a unit of time thus the kWh unit of measure. When you want to see how much energy you consumed in a DAY you just count the kWh which means you consumed 24 kWh/day (for 1 kWh). when you use BTC/MHD you are implying that your hash rate is 1 "MH per day" which is false. your hash rate is an average of 1 MHs over a day's time and you contributed with 3600* 1 MH in a day's time. WP states [0.01 btc/(average MHs) in a day] and not the amount of hashes in a day. And lastly, the unit of measure is MHs. you can twist that figure to show a day or a year but it's still MHs as reported by your miners. BTC/Day BTC s 1 Day BTC -------- = --- x --- x ------- = -------- 1MH / s Day 1MH 86000 s 86000 MH
For convenience I suggested that we create a unit named MegaHashDay (or MHD) to equal 86000 MH, but that has proven to be anything but convenient. So let's call it a Thump instead, as that is the sound you hear when you bang your head against a wall. Until you hear nothing at all that is... BTC / Thump Doesn't that prove it is BTC/MH*D? The point being the D is not in the lower part of the fraction... Has no one here taken middle/high school level math classes and actually passed them? For an answer to your question, please refer to www.mathisfun.com.
|
|
|
|
suchmoon
Legendary
Offline
Activity: 3654
Merit: 8922
https://bpip.org
|
|
March 21, 2014, 12:42:16 AM |
|
author=comeonalready
And it is payout per MHD!
I see you insist... Ok. Let me show you my reasoning for why IT IS NOT MHD and then you can just slam down your irrefutable proof and I'll stand rebuked. let's say that your hashrate is 1 MHs. Meaning that your computational power can "solve" 1 million hashes in a second. Analogous to active power being measured in kW, the energy consumption is measured based on the consumption of power in a unit of time thus the kWh unit of measure. When you want to see how much energy you consumed in a DAY you just count the kWh which means you consumed 24 kWh/day (for 1 kWh). when you use BTC/MHD you are implying that your hash rate is 1 "MH per day" which is false. your hash rate is an average of 1 MHs over a day's time and you contributed with 3600* 1 MH in a day's time. WP states [0.01 btc/(average MHs) in a day] and not the amount of hashes in a day. And lastly, the unit of measure is MHs. you can twist that figure to show a day or a year but it's still MHs as reported by your miners. BTC/Day BTC s 1 Day BTC -------- = --- x --- x ------- = -------- 1MH / s Day 1MH 86000 s 86000 MH
For convenience I suggested that we create a unit named MegaHashDay (or MHD) to equal 86000 MH, but that has proven to be anything but convenient. So let's call it a Thump instead, as that is the sound you hear when you bang your head against a wall. Until you hear nothing at all that is... BTC / Thump Wow... just one question though, what is 86000?
|
|
|
|
zSprawl
|
|
March 21, 2014, 01:04:12 AM |
|
author=comeonalready
And it is payout per MHD!
I see you insist... Ok. Let me show you my reasoning for why IT IS NOT MHD and then you can just slam down your irrefutable proof and I'll stand rebuked. let's say that your hashrate is 1 MHs. Meaning that your computational power can "solve" 1 million hashes in a second. Analogous to active power being measured in kW, the energy consumption is measured based on the consumption of power in a unit of time thus the kWh unit of measure. When you want to see how much energy you consumed in a DAY you just count the kWh which means you consumed 24 kWh/day (for 1 kWh). when you use BTC/MHD you are implying that your hash rate is 1 "MH per day" which is false. your hash rate is an average of 1 MHs over a day's time and you contributed with 3600* 1 MH in a day's time. WP states [0.01 btc/(average MHs) in a day] and not the amount of hashes in a day. And lastly, the unit of measure is MHs. you can twist that figure to show a day or a year but it's still MHs as reported by your miners. BTC/Day BTC s 1 Day BTC -------- = --- x --- x ------- = -------- 1MH / s Day 1MH 86000 s 86000 MH
For convenience I suggested that we create a unit named MegaHashDay (or MHD) to equal 86000 MH, but that has proven to be anything but convenient. So let's call it a Thump instead, as that is the sound you hear when you bang your head against a wall. Until you hear nothing at all that is... BTC / Thump Doesn't that prove it is BTC/MH*D? The point being the D is not in the lower part of the fraction... Has no one here taken middle/high school level math classes and actually passed them? For an answer to your question, please refer to www.mathisfun.com. Basic math? lol... So you're saying 5/(5*5) = 5/5*5? If so, sorry for even wasting your time because you're lost. :p
|
BTC: 1EyCRbT3YeskViEtH9KfRLpjdR2nsrrcW6
|
|
|
comeonalready
|
|
March 21, 2014, 01:20:47 AM Last edit: March 21, 2014, 02:07:09 AM by comeonalready |
|
author=comeonalready
And it is payout per MHD!
I see you insist... Ok. Let me show you my reasoning for why IT IS NOT MHD and then you can just slam down your irrefutable proof and I'll stand rebuked. let's say that your hashrate is 1 MHs. Meaning that your computational power can "solve" 1 million hashes in a second. Analogous to active power being measured in kW, the energy consumption is measured based on the consumption of power in a unit of time thus the kWh unit of measure. When you want to see how much energy you consumed in a DAY you just count the kWh which means you consumed 24 kWh/day (for 1 kWh). when you use BTC/MHD you are implying that your hash rate is 1 "MH per day" which is false. your hash rate is an average of 1 MHs over a day's time and you contributed with 3600* 1 MH in a day's time. WP states [0.01 btc/(average MHs) in a day] and not the amount of hashes in a day. And lastly, the unit of measure is MHs. you can twist that figure to show a day or a year but it's still MHs as reported by your miners. BTC/Day BTC s 1 Day BTC -------- = --- x --- x ------- = -------- 1MH / s Day 1MH 86000 s 86000 MH
For convenience I suggested that we create a unit named MegaHashDay (or MHD) to equal 86000 MH, but that has proven to be anything but convenient. So let's call it a Thump instead, as that is the sound you hear when you bang your head against a wall. Until you hear nothing at all that is... BTC / Thump Doesn't that prove it is BTC/MH*D? The point being the D is not in the lower part of the fraction... Has no one here taken middle/high school level math classes and actually passed them? For an answer to your question, please refer to www.mathisfun.com. Basic math? lol... So you're saying 5/(5*5) = 5/5*5? If so, sorry for even wasting your time because you're lost. :p No, I am making no such claim. You're the one who is adding parenthesis to change the order of operations in an effort to make a point that does not apply in this case. Disprove my expression if you can and stop making analogies, even if they are mathematical ones. Perhaps I oversimplified it by leaving out a step for you to follow along. Try this: BTC/Day BTC s BTC * s 1 Day BTC -------- = --- x --- = --------- x ------- = -------- 1MH / s Day 1MH Day * 1MH 86400 s 86400 MH
If I made an error, point out specifically where it was made, not generally using an analogy. Why do you believe that I am improperly removing parenthesis from this expression?
|
|
|
|
ziddey
Newbie
Offline
Activity: 16
Merit: 0
|
|
March 21, 2014, 02:03:25 AM |
|
Wow... just one question though, what is 86000?
Seconds in a day. Should be 86400. Regardless, mhs as a unit doesn't make too much sense. kwh (3600kJ) came to be because it can allow for easy mental math (e.g. 100w light bulb x 24h operation = 2400wh = 2.4kwh). Otherwise, if your electric rate were simply $ per kJ, you'd have to do more calculations. For our case of profitability, the current standard of btc/day per mh/s makes perfect sense, other than being long to express. You simply take your hashrate in mh/s and multiply it by this profitability and you get your expected btc/day.
|
|
|
|
|
comeonalready
|
|
March 21, 2014, 02:10:41 AM |
|
Wow... just one question though, what is 86000?
For our case of profitability, the current standard of btc/day per mh/s makes perfect sense, other than being long to express. You simply take your hashrate in mh/s and multiply it by this profitability and you get your expected btc/day. Yes, and because "btc/day per mh/s" is too long to express, barely anyone uses the proper units in their discussion and it often leads to a semi-retarded conversation. Like this one.
|
|
|
|
aagert
Sr. Member
Offline
Activity: 330
Merit: 250
📱 Electroneum 📱 cryptocurrency
|
|
March 21, 2014, 03:12:21 AM |
|
First, slightly offtopic: comeonalready and others, please, STOP flooding this topic with your "MHD or not MHD" garbage, there is too much of that on several last pages. Do it somewhere else.
Now, to real questions. 1. PW, do you have some plans on implementation of a pool for algorithms other than scrypt? Scrypt-N or Scrypt-Jane, for example. I strongly believe that it is the future of altcoins market. There are already good coins, such as VertCoin, YACoin, CACHEcoin, maybe some others. It would be great to mine them on a pool like yours - transparent and reliable. 2. What about payments in LTC? For example: for each mined coin count percent of workers who wants to be payed in LTC (they can tell it through password or maybe username in format like "payment_address.LTC.worker_name") and exchange that percent for LTC instead of BTC. Or pay them directly, if mined coin is LTC itself, of course. Is it difficult to implement?
I know that these questions were asked already, but I haven't seen any answers.
|
|
|
|
comeonalready
|
|
March 21, 2014, 03:13:20 AM |
|
author=comeonalready
And it is payout per MHD!
I see you insist... Ok. Let me show you my reasoning for why IT IS NOT MHD and then you can just slam down your irrefutable proof and I'll stand rebuked. let's say that your hashrate is 1 MHs. Meaning that your computational power can "solve" 1 million hashes in a second. Analogous to active power being measured in kW, the energy consumption is measured based on the consumption of power in a unit of time thus the kWh unit of measure. When you want to see how much energy you consumed in a DAY you just count the kWh which means you consumed 24 kWh/day (for 1 kWh). when you use BTC/MHD you are implying that your hash rate is 1 "MH per day" which is false. your hash rate is an average of 1 MHs over a day's time and you contributed with 3600* 1 MH in a day's time. WP states [0.01 btc/(average MHs) in a day] and not the amount of hashes in a day. And lastly, the unit of measure is MHs. you can twist that figure to show a day or a year but it's still MHs as reported by your miners. BTC/Day BTC s 1 Day BTC -------- = --- x --- x ------- = -------- 1MH / s Day 1MH 86000 s 86000 MH
For convenience I suggested that we create a unit named MegaHashDay (or MHD) to equal 86000 MH, but that has proven to be anything but convenient. So let's call it a Thump instead, as that is the sound you hear when you bang your head against a wall. Until you hear nothing at all that is... BTC / Thump Doesn't that prove it is BTC/MH*D? The point being the D is not in the lower part of the fraction... Has no one here taken middle/high school level math classes and actually passed them? For an answer to your question, please refer to www.mathisfun.com. Basic math? lol... So you're saying 5/(5*5) = 5/5*5? If so, sorry for even wasting your time because you're lost. :p And as for zSprawl, on his order of operations argument and retarded analogy proving absolutely nothing... You are correct that a specific order of operations in the denominator would be necessary if the denominator still contained an irreducible operation. But what you failed to realize is that both Day in the numerator of the larger fraction and s in the denominator of the larger fraction are both units of time in different scales, and 1 Day always equals 86400 seconds. So either time unit contained in the denominators of the smaller fractions can be rewritten to share a time scale with the other, and the larger fraction can be further reduced to a point at which there is no operation remaining its denominator because time can be factored outside of it, hence order of operation restrictions would no longer apply as there are no operations remaining in the denominator of the larger fraction. Do it if you don't believe me because I know you won't want to.
|
|
|
|
comeonalready
|
|
March 21, 2014, 03:15:50 AM Last edit: March 21, 2014, 04:03:15 AM by comeonalready |
|
First, slightly offtopic: comeonalready and others, please, STOP flooding this topic with your "MHD or not MHD" garbage, there is too much of that on several last pages. Do it somewhere else.
I know, right? Math, yuck! I'm going to create a pool of my own and no one else but me will be allowed to join it! And maybe sfire...
|
|
|
|
zSprawl
|
|
March 21, 2014, 03:34:33 AM |
|
And as for zSprawl, on his order of operations argument and retarded analogy proving absolutely nothing...
You are correct that a specific order of operations in the denominator would be necessary if the denominator still contained an irreducible operation. But what you failed to realize is that both Day in the numerator of the larger fraction and s in the denominator of the larger fraction are both units of time in different scales, and 1 Day always equals 86400 seconds. So either time unit contained in the denominators of the smaller fractions can be rewritten to share a time scale with the other, and the larger fraction can be further reduced to a point at which there is no operation remaining its denominator because time can be factored outside of it, hence order of operation restrictions would no longer apply as there are no operations remaining in the denominator of the larger fraction. Do it if you don't believe me because I know you won't want to.
I failed at nothing other than getting you realize your not always right, but hey... comeonalready!
|
BTC: 1EyCRbT3YeskViEtH9KfRLpjdR2nsrrcW6
|
|
|
comeonalready
|
|
March 21, 2014, 03:39:56 AM Last edit: March 21, 2014, 04:30:07 AM by comeonalready |
|
And as for zSprawl, on his order of operations argument and retarded analogy proving absolutely nothing...
You are correct that a specific order of operations in the denominator would be necessary if the denominator still contained an irreducible operation. But what you failed to realize is that both Day in the numerator of the larger fraction and s in the denominator of the larger fraction are both units of time in different scales, and 1 Day always equals 86400 seconds. So either time unit contained in the denominators of the smaller fractions can be rewritten to share a time scale with the other, and the larger fraction can be further reduced to a point at which there is no operation remaining its denominator because time can be factored outside of it, hence order of operation restrictions would no longer apply as there are no operations remaining in the denominator of the larger fraction. Do it if you don't believe me because I know you won't want to.
I failed at nothing other than getting you realize your not always right, but hey... comeonalready! You oversimplified your example to the point of eliminating units of representation thereby eliminating the possibility of being able to see how the the time scale units could be combined and factored. But I understand your position... You want to be right even if you're not correct.
|
|
|
|
tachyon_john
Newbie
Offline
Activity: 28
Merit: 0
|
|
March 21, 2014, 03:42:41 AM |
|
I'm not convinced that the only way to parallelize these algorithms is the way that it's being done currently. It is often possible to write GPU codes where several threads or even a whole warp/wavefront work collectively on an algorithm step. I haven't looked at the details of scrypt-chacha specifically, but I wouldn't be surprised if there are alternative algorithm formulations other than the one you refer to. The top-end GPUs today have 8GB to 12GB of RAM. In the next two years, there will be GPUs and other GPU-like hardware (e.g. Xeon Phi) that will have significantly more memory than they do now, likely in the range of 32GB. I've read analyst articles that expect that Intel will put at least 16GB of eDRAM onto the next Xeon Phi (though likely on its own separate die), a much larger scale variant of what Intel is already doing for integrated graphics. Next week is NVIDIA's GPU conference, perhaps there will be some public announcements about what they're doing for their next-gen GPUs.
That's all good information, and I'm sure you're quite correct on there being alternate ways to rework these hashes for new hardware - that's the one aspect of mining my knowledge is very shallow on. Regarding those badboy GPU's with 8 and 12GB of memory - they aren't real common, and their cost would be prohibitive compared to running multiple "smaller" GPU's, but that's where the schedule of increasing N comes in - it's taking a stab at where computing power will be in the future, and it could be very wrong, but it's still scaling up the requirements over time. The Xeon Phi looks to be an interesting beast, and I was unfamiliar with it until you brought it up. The specs call for 61 cores at 1.238GHz for the high end machine, which doesn't sound massively parallel. Time will tell, but I'm not going to be the guinea pig to plunk down $4,000 USD to find out. Christian Buchner (of cudaminer) has been in touch with nVidia, and they're on board with crypto-mining - I believe they've evan assisted with optimizaing some of his kernel code. Regarding their announcement, I do know that their Maxwell architecture is already providing improved performance per watt on the mid-range 750Ti card. The NVIDIA Titan cards have 6GB, and they tend to hover close to a kilobuck. The Xeon Phi (in its current form at least) is no match for state-of-the-art GPUs. I mentioned Xeon Phi only to provide context that multiple vendors are already building hardware with large high bandwidth memories now, and that the memory capacities (again, from multiple vendors) are expected to go up dramatically in the near future. I understand the sticker shock, $2K to $4K is costly, but then that's what the high-end ASIC boards cost for crypto currency mining. To keep the ASICs out, there just has to be a commodity option that's price-competitive, and there are definitely high-end GPUs that, for a memory-bandwidth-bound algorithm at least, should still be more cost effective than low-volume ASIC boards for any non-trivial memory capacity.
|
|
|
|
|