Show Posts
|
Pages: [1] 2 »
|
listed on decentralised exchanges yet?
|
|
|
sandor111,
Any chance you could enable API listen support? Those of us using Rig Leasing services really benefit from being able to accurately report hashrates directly from the miner instead of relying on pool based statistics!
Things are running great on my RPi so i'm definitely a low priority, but it seems like you're making great strides in the original LA hardware performance and i'm considering a switch back.
Best of luck and keep up the good work!
-Eric
|
|
|
I have both a customer account and provider account, both were using the same email address. Got the new password email for the customer account, but didn't get anything for the provider account although I did have the email registered in there.
I am having the exact same issue. I can log into my customer account with the new password, but have not received an email for provider account and neither old nor new password works. EMoomjean
|
|
|
Doesn't work for me. My 6MH/s suddenly turned into 0.3MH/s no matter which frequency/pool I use or how many times I restart them. I strongly recommend that people do not upgrade at this time.
Which pool? I've tried a few different pools now. It doesn't seem to be pool related. Interestingly, if I only have a couple miners plugged into each hub, it seems to work. I'm playing plugging/unplugging games right now to see how many I can get working at once. So far I can't get more than 4 working with a single controller/hub. It's obviously pool related, we had no problems testing with 40+ units. What pool works then? Seems odd that I can get full speed out of 4 units, but when I plug in 10 to the hub, I get almost 0. I would think it was power related had they not been running fine for weeks on v1. Miner status (hashrate: 8 Kh/s) (miners: 11/11 uptime: 4:10, memory usage: 65%, load average: 0.41) Same pool, same controller, same hub, but only 4 miners: Miner status (hashrate: 1212 Kh/s) (miners: 4/4 uptime: 1:50, memory usage: 58%, load average: 0.11) Please PM me the pool that you are using, so I can further debug what is going on... we have tested with wafflepool, and dogehouse. Fyi, I have been getting 100% rejects when connecting to Scryptguild.
|
|
|
Sure the IP didn't change?
Pretty sure. Theres no new lease on my DHCP server. I've noticed that IPs don't always show up in my DHCP table. I would recommend using AngryIP scanner to find all devices on your subnet and plug in any IPs you don't recognize into your browser. http://angryip.org/
|
|
|
Where was that originally posted? here Would you mind posting an updated screencap with a longer run time and details on your config? That's a remarkable hashrate for only 744mhz... -EMoomjean There you go , http://imgur.com/eRItNxl . Very cool! I see you're running this in Linux, can you provide any details regarding your config or mods that you've made to the miners? I'm specifically interested in anything out of the ordinary you have done to achieve those results... I'm sure we could probably come up with a community reward for you! I know i'd chip in .5 btc if you could increase my hashrates across the board that significantly! -Eric
|
|
|
Where was that originally posted? here Would you mind posting an updated screencap with a longer run time and details on your config? That's a remarkable hashrate for only 744mhz... -EMoomjean
|
|
|
Where was that originally posted?
|
|
|
9. Patch: More Stability for Raspberry Pi add the parameter ( no new line! ) press Ctrl + o , Return, Ctrl + x to save changes Manfred slub_debug is a bad idea. It will slow down your hashrate by 20%. I've tried it . you should switch to BFGMiner. I have never heard anyone else having a slowdown from this command. I have always gotten around ~360kh per miner at 850mhz with or without slub_debug. Please provide more info! -EMoomjean
|
|
|
can it be run nohup - so that it can run even when I don;t have an ssh session?
Use screen: "miner" can be anything, it's just a name that you can use later to get back to it. This will give you a new shell. Start cgminer there. Ctrl-A, then Ctrl-D will exit the new shell and will keep cgminer running. To verify that it's indeed running in the background use this: You can now disconnect SSH etc. To get back to your cgminer: Or conversely you could just edit the miner_start.sh script in /opt/minerpeon/startup/ folder and replace the existing cgminer string with your path and custom commands. With the updated info saved your config will be retained and automatically loaded everytime the RPI starts up (which can be handy if you experience a power loss or the RPI crashes/reboots on its own). -EMoomjean
|
|
|
you need a monitor initially because it's IP address is unknown and even a scanner cant't find what has not been set. I grabbed a TV and hookup it up via hdmi and had it running in about 45 minutes then it went to my always cool and dry basement where the mining equip is located. I give mine a static ip so after a reboot I always know where to find it. That is incorrect. By default the Scripta image uses DHCP and its actually quite easy to find the device using angryip scanner ( http://angryip.org/) Be sure to use the proper SSH port 7722 when connecting! -EMoomjean
|
|
|
What if I have a Pi? Then No? No Leaserig proxy? Sad Sad I'll sign a nondisclosure and compile the pos for amd64 and armv61 or just send you directions. Mostly type make miaviator, I'm running 2 RPI's with the LRP and haven't had any issues. Just run it from a Linux or Windows box on your LAN (I know you have some dedicated machines around) or even run it as a Service if you don't like having the CMD box open/minimized. I know you're asking for an installer so you can run it entirely on an RPI, but saying that users with RPI's cant use LRP is slightly innacurate. FYI, I run mine with the API listening ports enabled so I get accurate hashrates and everything is peachy. You might need to poke some holes in your local firewall to make things work, but once you point your RPIs at the machine running LRP it makes things actually easier to manage pools and such (especially if you're running more than 1 RPI) Msg me if you want specifics on my configuration settings. -EMoomjean
|
|
|
I take this isn't like the old GPU limit thing and it's an unkown to a lot of people?
If you don't have any automation software you shouldn't run 100 of these.
It's just idiotic to think that you should run 30+ mhash or 100+ devices on one system.
Spread the control out to 10-64 per control system and develop some automation tools or use the ones I post all over for linux.
I do have software automation setup for alerts, restart cgminer, etc.. so no problem there. The 127 usb device limit is my problem as stated here: http://en.wikipedia.org/wiki/USB_hub@wolfey2014, you stated if I knew what I was looking for this should be easy to find? Can you give me some hints? I dislike you. Haha well thank you kind sir So maybe using a motherboard with multiple USB controllers will work? Just thinking out loud. Any ideas there? Though I fundamentally disagree with the idea of trying to run hundreds of miners from a single controller, you can always use one of these: http://www.ioiusb.com/Host-Adapter/U2X4-PCIE1X01.htm (i'm not a big fan of single points of failure so please at least get a cheap server case with dual power supplies and RAID-1. And don't forget UPSs!) Its a 4x1 USB 2.0 card with 4 independent ports that supports 127 devices each, so that'll get you to 500 miners at least. How the OS will address them is up to you (I have no idea if there are any limitations). Best of luck, -EMoomjean
|
|
|
I have pre-ordered :-) Just hoping for an update. Jack said design was almost completed last I talked to him, which would put delivery 30 days or so away.. but he needed a minimum number of orders. Jack,
Updates on the LA15M please?
11k USD , based on preorder only The problem is, the only difference between this and getting 50 of the 300Kh/s miners is, it's in a rack mount case. Price, power and ROI are about the same, otherwise (maybe a little worse, if you can't overclock it). If they were able to reduce the price by $200-$300, we might be talking. That would actually be pretty good if it was 50 of the 300kh/s miners since they overclock quite easily 20% to 360kh/s, which would yield a net system hash power of 18MH. But i'm betting the OC is already factored into that reported speed. I'm running 40 miners and getting 14.4MH so its conceivable they will just ship something with ~42 miners and call it 15MH. I hope i'm wrong and welcome any input from Jack on this! -EMoomjean
|
|
|
Has anyone tried a large amount of gridseeds on cgminer? I am trying 28 of them on a rasberry pi and it stops accepting shares and eventually crashes after about 2 minutes. Running 28 instances of cpuminer works great, stable, and multipool reports right about where the hash rate should be.
Mine's been stable since upgrading to the "next" kernel (3.10.30+): sudo apt-get install rpi-update sudo BRANCH=next rpi-update This is potentially great news! I've been having stability issues and set a cron job to do a reboot every 6 hours. I've applied the update and disabled the cron job on 1 of 2 of my Pi's and i'll monitor over the next 24 hours. Oh and just a recommendation, i've been using JuiceSSH for Android to remotely manage my RPI's and it works great. I even set up some port forwarding on my router so I can remote access from anywhere I have cell service! Has come in handy on several occasions (issuing a quick reboot command when needed). -EMoomjean I tried that and now cgminer just crashes on startup. Did you have to recompile cgminer after updating? Nope, I just executed the 2 commands and performed a reboot afterwards. BTW, I double checked and the slub debug command in the cmdline.txt persists through the update (I only mention it because I saw cmdline.txt scroll by as one of the files that was touched in the patch). -EMoomjean Just recompiled and checked my cmdline.txt, was missing the stability fix. Changed and now cgminer starts, but I get some HW errors and some miners dont accept any shares. Power usage is only 140 watts compared to 240 running cpuminer. Sounds like either cgminer isn't seeing all your miners or the RPI isnt seeing them. I would try running the lsusb -t command to verify all of your miners are recognized by the RPI as a first step. If you're using the 10 port hub that came with the Lightning Asic kits the ports with comm/data are the miner ports (should be 1-6, then 7 is Class=hub under which you'll see another 1-4). -EMoomjean Thanks for all your help. I am using the monoprice 24 port hub, with another 7 port hub daisy chained. Cpuminer sees all of the devices so I assume cgminer would as well. 28 total gridseeds screen -dmS 1 sudo ./cgminer --scrypt -o stratum+tcp://us-west2.multipool.us:7777 -u myuser.gs1 -p x --gridseed-options=baud=115200,freq=800,chips=5 --hotplug 0 When I run lsusb -t I get this: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 480M |__ Port 1: Dev 3, If 0, Class=vend., Driver=smsc95xx, 480M |__ Port 2: Dev 4, If 0, Class=hub, Driver=hub/7p, 480M |__ Port 1: Dev 5, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 1: Dev 5, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 2: Dev 6, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 2: Dev 6, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 3: Dev 7, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 3: Dev 7, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 4: Dev 8, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 4: Dev 8, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 5: Dev 9, If 0, Class=hub, Driver=hub/7p, 480M |__ Port 1: Dev 12, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 1: Dev 12, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 2: Dev 13, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 2: Dev 13, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 3: Dev 14, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 3: Dev 14, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 4: Dev 15, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 4: Dev 15, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 6: Dev 16, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 6: Dev 16, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 7: Dev 17, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 7: Dev 17, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 6: Dev 10, If 0, Class=hub, Driver=hub/7p, 480M |__ Port 1: Dev 18, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 1: Dev 18, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 2: Dev 19, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 2: Dev 19, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 3: Dev 20, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 3: Dev 20, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 4: Dev 21, If 0, Class=hub, Driver=hub/4p, 480M |__ Port 1: Dev 32, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 1: Dev 32, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 2: Dev 33, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 2: Dev 33, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 4: Dev 34, If 0, Class=hub, Driver=hub/4p, 480M |__ Port 1: Dev 35, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 1: Dev 35, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 2: Dev 36, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 2: Dev 36, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 3: Dev 37, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 3: Dev 37, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 5: Dev 22, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 5: Dev 22, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 6: Dev 23, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 6: Dev 23, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 7: Dev 24, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 7: Dev 24, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 7: Dev 11, If 0, Class=hub, Driver=hub/7p, 480M |__ Port 1: Dev 25, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 1: Dev 25, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 2: Dev 26, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 2: Dev 26, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 3: Dev 27, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 3: Dev 27, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 4: Dev 28, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 4: Dev 28, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 5: Dev 29, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 5: Dev 29, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 6: Dev 30, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 6: Dev 30, If 1, Class=data, Driver=cdc_acm, 12M |__ Port 7: Dev 31, If 0, Class=comm., Driver=cdc_acm, 12M |__ Port 7: Dev 31, If 1, Class=data, Driver=cdc_acm, 12M The command line argument you are using looks like the cgminer for windows version (boy do I spend too much time reading all these threads to spot that). I don't use the chips=5 or --hotplug 0 variables and mine works fine. Its a stab in the dark, but worth a try... (though i'll admit your USB topology is slightly different so hotplug *might* be needed, though I doubt it). -EMoomjean Edit: Out of curiosity, why are you daisy chaining the hubs? The RPI has 2 USB ports (excluding the power port) Why not plug the 24-port into one of the RPI's USB ports and the 7-port into the other?
|
|
|
And check these massive orders:
There is 1.5 BTC prepared to buy your rigs for rated price 0.00777, which is way better than what was going on previous days.
Whoever is making less than this is simply s.upid for not taking the chance!
That bottom one looks like whoevers orders I've been filling with gridseeds: miaviator, I switched to a Raspberry Pi and am running Cgminer with my Gridseeds. I am now able to enable the built in api commands for reporting hashrates directly to the LeaseRig Proxy. Take a look at how things look now! (FYI I had some brief downtimes for reboots and updated the firmware on both RPI's during this window, which accounts for the occasional sags in hashrate):
|
|
|
Has anyone tried a large amount of gridseeds on cgminer? I am trying 28 of them on a rasberry pi and it stops accepting shares and eventually crashes after about 2 minutes. Running 28 instances of cpuminer works great, stable, and multipool reports right about where the hash rate should be.
Mine's been stable since upgrading to the "next" kernel (3.10.30+): sudo apt-get install rpi-update sudo BRANCH=next rpi-update This is potentially great news! I've been having stability issues and set a cron job to do a reboot every 6 hours. I've applied the update and disabled the cron job on 1 of 2 of my Pi's and i'll monitor over the next 24 hours. Oh and just a recommendation, i've been using JuiceSSH for Android to remotely manage my RPI's and it works great. I even set up some port forwarding on my router so I can remote access from anywhere I have cell service! Has come in handy on several occasions (issuing a quick reboot command when needed). -EMoomjean I tried that and now cgminer just crashes on startup. Did you have to recompile cgminer after updating? Nope, I just executed the 2 commands and performed a reboot afterwards. BTW, I double checked and the slub debug command in the cmdline.txt persists through the update (I only mention it because I saw cmdline.txt scroll by as one of the files that was touched in the patch). -EMoomjean Just recompiled and checked my cmdline.txt, was missing the stability fix. Changed and now cgminer starts, but I get some HW errors and some miners dont accept any shares. Power usage is only 140 watts compared to 240 running cpuminer. Sounds like either cgminer isn't seeing all your miners or the RPI isnt seeing them. I would try running the lsusb -t command to verify all of your miners are recognized by the RPI as a first step. If you're using the 10 port hub that came with the Lightning Asic kits the ports with comm/data are the miner ports (should be 1-6, then 7 is Class=hub under which you'll see another 1-4). -EMoomjean
|
|
|
Has anyone tried a large amount of gridseeds on cgminer? I am trying 28 of them on a rasberry pi and it stops accepting shares and eventually crashes after about 2 minutes. Running 28 instances of cpuminer works great, stable, and multipool reports right about where the hash rate should be.
Mine's been stable since upgrading to the "next" kernel (3.10.30+): sudo apt-get install rpi-update sudo BRANCH=next rpi-update This is potentially great news! I've been having stability issues and set a cron job to do a reboot every 6 hours. I've applied the update and disabled the cron job on 1 of 2 of my Pi's and i'll monitor over the next 24 hours. Oh and just a recommendation, i've been using JuiceSSH for Android to remotely manage my RPI's and it works great. I even set up some port forwarding on my router so I can remote access from anywhere I have cell service! Has come in handy on several occasions (issuing a quick reboot command when needed). -EMoomjean I tried that and now cgminer just crashes on startup. Did you have to recompile cgminer after updating? Nope, I just executed the 2 commands and performed a reboot afterwards. BTW, I double checked and the slub debug command in the cmdline.txt persists through the update (I only mention it because I saw cmdline.txt scroll by as one of the files that was touched in the patch). -EMoomjean
|
|
|
Has anyone tried a large amount of gridseeds on cgminer? I am trying 28 of them on a rasberry pi and it stops accepting shares and eventually crashes after about 2 minutes. Running 28 instances of cpuminer works great, stable, and multipool reports right about where the hash rate should be.
Mine's been stable since upgrading to the "next" kernel (3.10.30+): sudo apt-get install rpi-update sudo BRANCH=next rpi-update This is potentially great news! I've been having stability issues and set a cron job to do a reboot every 6 hours. I've applied the update and disabled the cron job on 1 of 2 of my Pi's and i'll monitor over the next 24 hours. Oh and just a recommendation, i've been using JuiceSSH for Android to remotely manage my RPI's and it works great. I even set up some port forwarding on my router so I can remote access from anywhere I have cell service! Has come in handy on several occasions (issuing a quick reboot command when needed). -EMoomjean
|
|
|
|