Thanks all,
The TP-Link TL-WN722N wireless USB adapter worked fine with Linuxcoin, which is also Debian based. So I guess we'll just have to test it with BAMT. Keep your fingers crossed ;-)
UPDATE: 9/11/11
Well, no joy. BAMT just does't seem to see the TP-Link the way Linuxcoin does.
Topic: BAMT - Easy persistent USB key based linux for dedicated miners/mining farms - page 36. (Read 167480 times)
September 09, 2011, 11:59:21 AM
September 09, 2011, 09:47:38 AM
Has anyone been successful using BAMT with a wireless connection? I need to temporarily move one of my miners and would prefer not to go back to Linuxcoin just because of the wireless issue.
the short answer is yes, some have been successful with this. however, it is not supported and as I have no wireless hardware on any miners here, I cannot help you. but, some have told me they have it working ok. maybe they can elaborate.
From my (probably limited) understanding of this, BAMT is mostly a live debian distro as far as hardware goes: So if you can find a wireless device that works with debian, and/or a guide to make it work, I think you would be ok. I haven't had to mess with linux wireless for a while myself, I have been spoiled by ubuntu and carefully buying standard, mass-market devices so they are more likely to be supported :p
September 09, 2011, 07:49:49 AM
Has anyone been successful using BAMT with a wireless connection? I need to temporarily move one of my miners and would prefer not to go back to Linuxcoin just because of the wireless issue.
the short answer is yes, some have been successful with this. however, it is not supported and as I have no wireless hardware on any miners here, I cannot help you. but, some have told me they have it working ok. maybe they can elaborate.
September 09, 2011, 07:39:05 AM
Has anyone been successful using BAMT with a wireless connection? I need to temporarily move one of my miners and would prefer not to go back to Linuxcoin just because of the wireless issue.
I've already asked. Nobody could give an answer and I couldn't make my wlan work using BAMT
September 09, 2011, 07:33:49 AM
Has anyone been successful using BAMT with a wireless connection? I need to temporarily move one of my miners and would prefer not to go back to Linuxcoin just because of the wireless issue.
September 09, 2011, 12:09:36 AM
you could share more exactly and prevent any miner from sticking on a single pool by just using the maximum shares option in your pools file. use the same pools file for all your gpus, and put all the different pools you want to mine at in it, with different max shares depending on how much time you want to spend at each. the miners will do X shares at the first pool, then move to the next and do however many you want there, and so on till they finish at the last pool in the file. then they will start at the beginning again. if any pool fails, the miners just move on to the next one early. no more stuck miners, and you can specify exactly what ratio of time you want to split between each pool.
What exactly is the syntax to put the max shares option in the pools file? It doesn't seem to be documented anywhere in the wiki and I couldn't find it by searching.
I just started using BAMT on a dedicated minner and its great except for this issue!
https://bitcointalksearch.org/topic/m.399636
September 09, 2011, 12:04:00 AM
you could share more exactly and prevent any miner from sticking on a single pool by just using the maximum shares option in your pools file. use the same pools file for all your gpus, and put all the different pools you want to mine at in it, with different max shares depending on how much time you want to spend at each. the miners will do X shares at the first pool, then move to the next and do however many you want there, and so on till they finish at the last pool in the file. then they will start at the beginning again. if any pool fails, the miners just move on to the next one early. no more stuck miners, and you can specify exactly what ratio of time you want to split between each pool.
What exactly is the syntax to put the max shares option in the pools file? It doesn't seem to be documented anywhere in the wiki and I couldn't find it by searching.
I just started using BAMT on a dedicated minner and its great except for this issue!
September 06, 2011, 02:34:29 AM
Any chance to implement displaying pool stats in mgpumon? So that we have all information in one place. Thanks.
mgpumon is a stand alone tool designed to run on any computer with perl, not just bamt machines. it requires no configuration files and has no dependencies. this means it cannot read a bamt.conf or assume other things that are only true on bamt machines.
i think it is better to keep it this way, but if someone else writes a mgpumon/gpumon hybrid thing, I'll include it in BAMT.
September 06, 2011, 02:17:52 AM
Any chance to implement displaying pool stats in mgpumon? So that we have all information in one place. Thanks.
September 05, 2011, 05:04:40 AM
I am one of those who likes to split my GPUs over different mining pools but I admit that I cant give a really strong logic reason.
Anyway these are my reasons:
1. Help medium mining pools that are doing a good job but still using some of the bigger ones.
2. The more mining pools competing each other, the best for us the miners.
3. Dont give all my hashpower to a big mining pool to avoid it getting too big (OK I dont have a lot of haspower but I hope you get my point on this)
4. Using more pools reduces variance, since your are using a bigger total hashpower.
So, my setup is using a pool config file for each gpu with failover to the the other pools. Usually after a period of time I have to restart BAMT because I see all GPUs got working with the same pool.
Anyway these are my reasons:
1. Help medium mining pools that are doing a good job but still using some of the bigger ones.
2. The more mining pools competing each other, the best for us the miners.
3. Dont give all my hashpower to a big mining pool to avoid it getting too big (OK I dont have a lot of haspower but I hope you get my point on this)
4. Using more pools reduces variance, since your are using a bigger total hashpower.
So, my setup is using a pool config file for each gpu with failover to the the other pools. Usually after a period of time I have to restart BAMT because I see all GPUs got working with the same pool.
you could share more exactly and prevent any miner from sticking on a single pool by just using the maximum shares option in your pools file. use the same pools file for all your gpus, and put all the different pools you want to mine at in it, with different max shares depending on how much time you want to spend at each. the miners will do X shares at the first pool, then move to the next and do however many you want there, and so on till they finish at the last pool in the file. then they will start at the beginning again. if any pool fails, the miners just move on to the next one early. no more stuck miners, and you can specify exactly what ratio of time you want to split between each pool.
September 05, 2011, 03:42:55 AM
I am one of those who likes to split my GPUs over different mining pools but I admit that I cant give a really strong logic reason.
Anyway these are my reasons:
1. Help medium mining pools that are doing a good job but still using some of the bigger ones.
2. The more mining pools competing each other, the best for us the miners.
3. Dont give all my hashpower to a big mining pool to avoid it getting too big (OK I dont have a lot of haspower but I hope you get my point on this)
4. Using more pools reduces variance, since your are using a bigger total hashpower.
So, my setup is using a pool config file for each gpu with failover to the the other pools. Usually after a period of time I have to restart BAMT because I see all GPUs got working with the same pool.
Anyway these are my reasons:
1. Help medium mining pools that are doing a good job but still using some of the bigger ones.
2. The more mining pools competing each other, the best for us the miners.
3. Dont give all my hashpower to a big mining pool to avoid it getting too big (OK I dont have a lot of haspower but I hope you get my point on this)
4. Using more pools reduces variance, since your are using a bigger total hashpower.
So, my setup is using a pool config file for each gpu with failover to the the other pools. Usually after a period of time I have to restart BAMT because I see all GPUs got working with the same pool.
September 05, 2011, 01:26:44 AM
I have been using this in a rig for 2 or 3 days without any problems. Suddenly the CPU start to go to 100% use and collapse the rig, this occurs every 15 mins aprox. Any idea? Need the specification of the rig ?
as mikeo said, probably too aggressive with overclocking, or getting too hot. turn off all over clocking, see if it goes away.
September 04, 2011, 11:23:04 PM
I have been using this in a rig for 2 or 3 days without any problems. Suddenly the CPU start to go to 100% use and collapse the rig, this occurs every 15 mins aprox. Any idea? Need the specification of the rig ?
This sounds just like what happens to one of my machines if I get too aggressive with overclocking. Back 'em off and see if that fixes it. September 04, 2011, 11:17:59 PM
Ok. In this situation, it seems you would want to specify a certain hashrate is to be used for a certain purpose, because dividing based on a percentage of total would suck if you're trying to deliver on a commitment and your total hashrate is in flux (miners going offline, being added, etc).
So.. say I make it so that you can say something like: dedicate 1 Ghash to purpose A, dedicate 3Ghash to purpose B, and the rest to purpose C. This would be better than dedicating GPUs or percentage of total, right?
So.. say I make it so that you can say something like: dedicate 1 Ghash to purpose A, dedicate 3Ghash to purpose B, and the rest to purpose C. This would be better than dedicating GPUs or percentage of total, right?
Right. Good point. I suppose, the actual controls of this would be independent from the rig the hashpower originates from, right? so, that you can deliver a given hashrate based on priorities, even when a rig fails (the proxy then takes another rig out of work from the least-preferred pool and points it to the one where we have a higher priority on).
Quote
Also, rather than saying "purpose A" is a single pool, shouldn't a purpose be it's own list of pools with their own priority? This way you can fallback for customer A to their own backup account when their primary fails, etc.
Yes, that would ease out things a lot, when in charge of a specific commitment.
Quote
Note that I am not promising to implement any of this, since I really don't need it myself. Just want to understand the "problem" so I at least lay the framework for a good solution in the future.
Well, just as you please. If you like, place sort of a "quote" on how much you'd like to be donated for implementing this feature. I'm sure there would be some subjects out there to pay for it.
Just one voice, but my needs are simple and this seems pretty esoteric to me and my little 3.1Gh/s. I'm still trying to work out central config control ;-)
September 04, 2011, 11:11:01 PM
I have been using this in a rig for 2 or 3 days without any problems. Suddenly the CPU start to go to 100% use and collapse the rig, this occurs every 15 mins aprox. Any idea? Need the specification of the rig ?
September 04, 2011, 07:14:16 PM
Ok. In this situation, it seems you would want to specify a certain hashrate is to be used for a certain purpose, because dividing based on a percentage of total would suck if you're trying to deliver on a commitment and your total hashrate is in flux (miners going offline, being added, etc).
So.. say I make it so that you can say something like: dedicate 1 Ghash to purpose A, dedicate 3Ghash to purpose B, and the rest to purpose C. This would be better than dedicating GPUs or percentage of total, right?
So.. say I make it so that you can say something like: dedicate 1 Ghash to purpose A, dedicate 3Ghash to purpose B, and the rest to purpose C. This would be better than dedicating GPUs or percentage of total, right?
Right. Good point. I suppose, the actual controls of this would be independent from the rig the hashpower originates from, right? so, that you can deliver a given hashrate based on priorities, even when a rig fails (the proxy then takes another rig out of work from the least-preferred pool and points it to the one where we have a higher priority on).
Quote
Also, rather than saying "purpose A" is a single pool, shouldn't a purpose be it's own list of pools with their own priority? This way you can fallback for customer A to their own backup account when their primary fails, etc.
Yes, that would ease out things a lot, when in charge of a specific commitment.
Quote
Note that I am not promising to implement any of this, since I really don't need it myself. Just want to understand the "problem" so I at least lay the framework for a good solution in the future.
Well, just as you please. If you like, place sort of a "quote" on how much you'd like to be donated for implementing this feature. I'm sure there would be some subjects out there to pay for it.
September 04, 2011, 05:48:19 PM
Quote
I am just trying to understand why anyonewants to mine at multiple pools in the first place.. is that the end goal in itself, simply to spread your work around for no reason other than .. you want to?
Just imagine there are commercial mining services that rent hashpower to customers. a certain hashrate that a customer rents is advised to go to a specific pool, chosen by the customer. this hashpower is maybe greater than one card can deliver, so you can't point only one GPU at it, what otherwise could be done via a specific pool file. for availability reasons, it would be good to dedicated a certain amount of the whole machine (multiple GPU)s) in percent to a pool, and the rest of it to another. if one of them is failing, we have backup pools that can take this hashpower until the primary one arrives back again.
Ok. In this situation, it seems you would want to specify a certain hashrate is to be used for a certain purpose, because dividing based on a percentage of total would suck if you're trying to deliver on a commitment and your total hashrate is in flux (miners going offline, being added, etc).
So.. say I make it so that you can say something like: dedicate 1 Ghash to purpose A, dedicate 3Ghash to purpose B, and the rest to purpose C. This would be better than dedicating GPUs or percentage of total, right?
Also, rather than saying "purpose A" is a single pool, shouldn't a purpose be it's own list of pools with their own priority? This way you can fallback for customer A to their own backup account when their primary fails, etc.
Note that I am not promising to implement any of this, since I really don't need it myself. Just want to understand the "problem" so I at least lay the framework for a good solution in the future.
September 04, 2011, 05:14:08 PM
Quote
I am just trying to understand why anyonewants to mine at multiple pools in the first place.. is that the end goal in itself, simply to spread your work around for no reason other than .. you want to?
Just imagine there are commercial mining services that rent hashpower to customers. a certain hashrate that a customer rents is advised to go to a specific pool, chosen by the customer. this hashpower is maybe greater than one card can deliver, so you can't point only one GPU at it, what otherwise could be done via a specific pool file. for availability reasons, it would be good to dedicated a certain amount of the whole machine (multiple GPU)s) in percent to a pool, and the rest of it to another. if one of them is failing, we have backup pools that can take this hashpower until the primary one arrives back again.
September 04, 2011, 03:24:47 PM
Ok.. for this type of thing, help me to understand the reason someone would do this. It adds quite a bit of complexity to the configuration file, so I want to make sure we can do what you want to do but also want to make it straightforward. It would help to know why this is desired.
I like mining at more than 1 pool and using multiple pool files is a pain...you didn't say it had to be a logical reason. Not worth adding some complex configuration to me, but think of all those cgminer and smartcoin users who would love to try BAMT (and hopefully donate) if only it had a feature like this.
BTW check .conf example wiki, big bold typo "valis"
I am just trying to understand why anyonewants to mine at multiple pools in the first place.. is that the end goal in itself, simply to spread your work around for no reason other than .. you want to?
or is there some problem that doing this is an attempt to solve, some reason people would do this (beyond simply 'i want to'
it seems many people were doing this as a way to increase reliability, but the new features coming out in BAMT eliminate the need for anything like that, as far as reliability is concerned.if the answer is simply "well, there is no reason, i just want to" then this feature will have to take a back seat to simplicity, so that it doesn't get in the way of 'normal' mining. if there is some justifiable reason that doing this is important, then we will make it part of the main configuration and everyone who doesn't want to do this will just have to put up with the added options/complexity/etc.
i just don't know which is the correct path at the moment.
September 04, 2011, 03:07:47 PM
Ok.. for this type of thing, help me to understand the reason someone would do this. It adds quite a bit of complexity to the configuration file, so I want to make sure we can do what you want to do but also want to make it straightforward. It would help to know why this is desired.
I like mining at more than 1 pool and using multiple pool files is a pain...you didn't say it had to be a logical reason. Not worth adding some complex configuration to me, but think of all those cgminer and smartcoin users who would love to try BAMT (and hopefully donate) if only it had a feature like this.
BTW check .conf example wiki, big bold typo "valis"
Jump to: