Topic: RollProxy - a bandwidth-saving mining proxy - page 2. (Read 14358 times)
Rolled back to v0.5.1. On pool errors v0.5.2 started rotating over all configured pools in a endless loop...
Thanks again!
Whenever rollproxy has a connection issue between itself and a pool, CPU usage goes crazy (it's stuck in a loop, I'd imagine). With enough rigs running against it, rollproxy can no longer keep up with providing work while this is happening.
I have added a 1-second pause between retries as a quick-and-dirty fix for this issue.What's this "cannot decode byte"-message? Happens everytime I try to access rollproxy with a browser... the webinterface is not displayed.
After exchanging a few private messages with ShadesOfMarble, this turned out to be a OS-and-locale-dependent issue; it should be fixed now.Version 0.5.2 should also support miners that (like Phoenix) issue long polling requests using the GET method.
What's this "cannot decode byte"-message? Happens everytime I try to access rollproxy with a browser... the webinterface is not displayed.
Getting this endlessly:
however the proxy still seems to be redirecting shares perfectly, it just has high CPU usage now...
Any ideas?
however the proxy still seems to be redirecting shares perfectly, it just has high CPU usage now...
Any ideas?
I have the same issue (although the error message in rollproxy varies a bit). Whenever rollproxy has a connection issue between itself and a pool, CPU usage goes crazy (it's stuck in a loop, I'd imagine). With enough rigs running against it, rollproxy can no longer keep up with providing work while this is happening.
Getting this endlessly:
however the proxy still seems to be redirecting shares perfectly, it just has high CPU usage now...
Any ideas?
however the proxy still seems to be redirecting shares perfectly, it just has high CPU usage now...
Any ideas?
I have the same issue (although the error message in rollproxy varies a bit). Whenever rollproxy has a connection issue between itself and a pool, CPU usage goes crazy (it's stuck in a loop, I'd imagine). With enough rigs running against it, rollproxy can no longer keep up with providing work while this is happening.
This is pretty slick. Thanks!!
For those windows users out there like me:
I couldn't get ez_setup to install urllib. It complained about a config file be missing.
So instead of I copied the urllib3 folder into my python\lib folder, and voila, it works.
For those that aren't used to the somewhat odd URL format this uses (I've seen it elsewhere, only reason I could figure it out), it's:
http://username:password@server:port
M
For those windows users out there like me:
I couldn't get ez_setup to install urllib. It complained about a config file be missing.
So instead of I copied the urllib3 folder into my python\lib folder, and voila, it works.
For those that aren't used to the somewhat odd URL format this uses (I've seen it elsewhere, only reason I could figure it out), it's:
http://username:password@server:port
M
Do you plan to add support for ntime rolling to the miners ? I'm asking because my config is a little odd and I have to cascade 2 rollproxy and I notice that second one does not see any support for ntime rolling from the first proxy.
If miners were allowed to do ntime rolling themselves, they could end up working on the exact same work unit, so it's not a good idea. Maybe it is possible to allow for little variations using a very low "expire" parameter, assuming of course that miners interpret that correctly, but honestly I can't see why you need the miners to roll the work themselves when they can just ask the proxy to do it.Quote
Do you plan to support the new getblocktemplate protocol in the proxy ?
Support for additional protocols is not planned at this time. I have very limited time to dedicate to this project, so right now I can only fix bugs and maybe add a few minor features.
Do you plan to add support for ntime rolling to the miners ? I'm asking because my config is a little odd and I have to cascade 2 rollproxy and I notice that second one does not see any support for ntime rolling from the first proxy.
Do you plan to support the new getblocktemplate protocol in the proxy ?
Do you plan to support the new getblocktemplate protocol in the proxy ?
Getting this endlessly:
however the proxy still seems to be redirecting shares perfectly, it just has high CPU usage now...
Any ideas?
however the proxy still seems to be redirecting shares perfectly, it just has high CPU usage now...
Any ideas?
Just for the fun - cascading the proxies (miner -> rollproxy -> stratum-proxy -> pool) works.
Yes, it's quite expected, because stratum proxy provides full getwork API, including long polling and ntime rolling.
pooler, looks like you're concerned about mining efficiency. Maybe you would be interested in supporting Stratum in your proxy as well? 
Just for the fun - cascading the proxies (miner -> rollproxy -> stratum-proxy -> pool) works.
pooler, looks like you're concerned about mining efficiency. Maybe you would be interested in supporting Stratum in your proxy as well?
I'm really busy with other stuff in this period, so no, or at least not any time soon.
pooler, looks like you're concerned about mining efficiency. Maybe you would be interested in supporting Stratum in your proxy as well?
As I understand, this helps for situation where miner don't support ntime rolling and pool does, right? [...]
The way I understand it, a miner can only do rolling within itself. If you have several miners on different machines, this proxy will help a lot. But please correct me if this is nonsense!Yes, macavity is right, that's the true raison d'être of this program, and why it was developed.
RollProxy allows multiple miners to reuse the same work unit. And this can bring huge bandwidth savings.
Use socat.
for mining through tor,
socat tcp-listen:18332,fork,reuseaddr socks4a:127.0.0.1:pool.com:8332,socksport=9050
But that would still leak DNS requests, wouldn't it? That has always been the issue with tools like socat or tsocks.for mining through tor,
socat tcp-listen:18332,fork,reuseaddr socks4a:127.0.0.1:pool.com:8332,socksport=9050
Your miner connects to 127.0.0.1 - no dns there
if you use the socks4a option on socat, it does the dns lookup for the pool through the proxy.
As I understand, this helps for situation where miner don't support ntime rolling and pool does, right? What miners don't support ntime rolling yet?
I lived in the opinion that ntime rolling is widely supported everywhere. Then I found that some big pools still don't support such simple and important extension, like Deepbit or even 50BTC. But as I understand, this proxy don't help in such situation - pool have to support ntime rolling itself.
Maybe the best thing is just to switch to miner and pool which supports ntime rolling, or even give a try to Stratum which implements mining protocol in quite innovative way (yes, this is kind of advertisement for my pool and BtcGuild.
The way I understand it, a miner can only do rolling within itself. If you have several miners on different machines, this proxy will help a lot. But please correct me if this is nonsense!I lived in the opinion that ntime rolling is widely supported everywhere. Then I found that some big pools still don't support such simple and important extension, like Deepbit or even 50BTC. But as I understand, this proxy don't help in such situation - pool have to support ntime rolling itself.
Maybe the best thing is just to switch to miner and pool which supports ntime rolling, or even give a try to Stratum which implements mining protocol in quite innovative way (yes, this is kind of advertisement for my pool and BtcGuild
.Besides, even without this feature, mining proxies are great tools to have if you use many machines. It makes monitoring, maintenance, setup of new machines or changing the pool and propagating that change to all clients so much easier.
I especially like Rollproxy because it's so small and efficient. I've used another proxy before, but it required apache, php, mysql, regular database cleanups, and while it worked well, it was a bit cumbersome to use.
As I understand, this helps for situation where miner don't support ntime rolling and pool does, right? What miners don't support ntime rolling yet?
I lived in the opinion that ntime rolling is widely supported everywhere. Then I found that some big pools still don't support such simple and important extension, like Deepbit or even 50BTC. But as I understand, this proxy don't help in such situation - pool have to support ntime rolling itself.
Maybe the best thing is just to switch to miner and pool which supports ntime rolling, or even give a try to Stratum which implements mining protocol in quite innovative way (yes, this is kind of advertisement for my pool and BtcGuild.
I lived in the opinion that ntime rolling is widely supported everywhere. Then I found that some big pools still don't support such simple and important extension, like Deepbit or even 50BTC. But as I understand, this proxy don't help in such situation - pool have to support ntime rolling itself.
Maybe the best thing is just to switch to miner and pool which supports ntime rolling, or even give a try to Stratum which implements mining protocol in quite innovative way (yes, this is kind of advertisement for my pool and BtcGuild
.Unfortunately that doesn't help. What is needed is a way for RollProxy to connect to the Internet through a SOCKS4/5 proxy, not a way for the miners to connect to RollProxy through an additional local proxy.
Use socat.
for mining through tor,
socat tcp-listen:18332,fork,reuseaddr socks4a:127.0.0.1:pool.com:8332,socksport=9050
Your miner connects to 127.0.0.1 - no dns there
if you use the socks4a option on socat, it does the dns lookup for the pool through the proxy.
Unfortunately that doesn't help. What is needed is a way for RollProxy to connect to the Internet through a SOCKS4/5 proxy, not a way for the miners to connect to RollProxy through an additional local proxy.
Use socat.
for mining through tor,
socat tcp-listen:18332,fork,reuseaddr socks4a:127.0.0.1:pool.com:8332,socksport=9050
say, pooler, would it be possible to add support for socks proxies in addition to http? this could quite possibly be the best thing since cgminer, if only it had socks support
cgminer does:
--socks-proxy
Unfortunately that doesn't help. What is needed is a way for RollProxy to connect to the Internet through a SOCKS4/5 proxy, not a way for the miners to connect to RollProxy through an additional local proxy.
Use socat.
for mining through tor,
socat tcp-listen:18332,fork,reuseaddr socks4a:127.0.0.1:pool.com:8332,socksport=9050
Jump to: