Glad that you were able to get the performance you need by just changing options.
It would be cleaner if there was a new option to run completely headless, but that would be more work. It would be nice to hear from the author at some point.
In the meantime I've been very happy with this proxy, now that I got the logging under control and worked through my miner-specific problems.
Topic: New stratum/getwork proxy with Web-based GUI and pools management - page 5. (Read 120841 times)
August 16, 2016, 10:13:52 AM
August 15, 2016, 10:06:32 PM
Updating the firmware to the latest resolved my problem. I've now got my S9 happily submitting shares through the proxy.
The update had a weird side effect of changing the MAC address on my miner. So after the update I lost contact with the miner. I was afraid that I bricked it until I found that it had been given a new dynamic DHCP address.
Weird...
The update had a weird side effect of changing the MAC address on my miner. So after the update I lost contact with the miner. I was afraid that I bricked it until I found that it had been given a new dynamic DHCP address.
Weird...
Glad you worked it out!
Maybe it's a feature, maybe the new MAC is from a different set so that you can see at the first sight what firmware is given device running just from looking at its MAC.
Anyway, I succeeded with lowering the CPU and memory load, the new config options are as I suggested:
Code:
"disableApi": true,
"poolHashrateSamplingPeriod" : 2147483,
"userHashrateSamplingPeriod" : 2147483,
"connectionHashrateSamplingPeriod" : 2147483,
"hashrateDatabaseSamplingPeriod": 2147483,
"hashrateDatabaseHistoryDepth": 0,
Code:
java -d64 -server -XX:+AggressiveOpts -XX:+AggressiveHeap -jar stratum-proxy.jar
So I am not sure which of these changes contributed more to the final result but now stratum-proxy is actually taking less memory than eth-proxy (before it was taking twice as much as eth-proxy) and its CPU load is 0%, literally (before it was in tens of %):
Code:
USER PID PPID PR NI %CPU %MEM VIRT RES SHR SWAP S TTY TIME+ WCHAN COMMAND
root 21613 1 20 0 2.0 13.2 502176 134388 27380 276 S pts/7 1:31.07 ep_poll ./eth-proxy.exe
root 13122 1 20 0 0.0 10.2 3860096 103096 52044 0 S pts/7 0:02.72 futex_wai+ ./stratum-proxy.exe -f stratum-proxy.conf
So I would say a success. When the author comes back from vacation (or whatever) and checks this thread I think he will be pleased.
August 15, 2016, 02:40:43 PM
If there is nothing from the miner after it issued the mining.multi_version request then it's apparently waiting for the response. Maybe a simple non-error response would do, it should be fairly easy to implement in StratumConnection.java and StratumWorkerConnection.java.
But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.
Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.
Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.
EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.
Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.
But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.
Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.
Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.
EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.
Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.
I suspect that this might be a problem with the S9 firmware. When it first came out, the S9 could not be used on NiceHash. There was a firmware update that supposedly fixed that.
I never updated the firmware because I didn't need it. So my S9 has whatever stratum bug Bitmain introduced in their changed miner software.
Other people have been able to get this proxy to work with their S9, so it might be that all I need to do is update the firmware.
Updating the firmware to the latest resolved my problem. I've now got my S9 happily submitting shares through the proxy.
The update had a weird side effect of changing the MAC address on my miner. So after the update I lost contact with the miner. I was afraid that I bricked it until I found that it had been given a new dynamic DHCP address.
Weird...
August 15, 2016, 10:00:50 AM
If there is nothing from the miner after it issued the mining.multi_version request then it's apparently waiting for the response. Maybe a simple non-error response would do, it should be fairly easy to implement in StratumConnection.java and StratumWorkerConnection.java.
But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.
Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.
Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.
EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.
Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.
But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.
Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.
Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.
EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.
Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.
I suspect that this might be a problem with the S9 firmware. When it first came out, the S9 could not be used on NiceHash. There was a firmware update that supposedly fixed that.
I never updated the firmware because I didn't need it. So my S9 has whatever stratum bug Bitmain introduced in their changed miner software.
Other people have been able to get this proxy to work with their S9, so it might be that all I need to do is update the firmware.
August 14, 2016, 11:55:45 PM
If there is nothing from the miner after it issued the mining.multi_version request then it's apparently waiting for the response. Maybe a simple non-error response would do, it should be fairly easy to implement in StratumConnection.java and StratumWorkerConnection.java.
But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.
Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.
Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.
EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.
Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.
But actually maybe you should respond with the error, maybe it is indicating it supports some non-public stratum protocol extensions (which this proxy of course obviously doesn't) so you need to let it know to downgrade itself back.
Maybe it's actually this proxy's bug that it doesn't respond with error to an unknown request and keeps the requester hanging.
Here is some comment hinting it could be something proprietary and here is another hint indicating S9 might be using this way to signal which extension(s) it supports. So the proxy just needs to respond appropriately.
EDIT: if you are up for it you might want to have a look at slush0's stratum-mining-proxy and his stratum implementation to see how that would react in case of an unrecognized request. He invented the whole stratum thing so I suppose that's the best place to look as this java proxy should imitate the same behavior.
Or maybe it would be faster to just try the slush0's proxy and see how it actually behaves and if it does allow your S9 to mine then just sniff their whole convo and implement what's missing into this one.
August 14, 2016, 11:27:35 PM
In case it's relevant, here's my config file (with user info and BTC addresses hidden):
Code:
{
"logDirectory" : "/var/log/stratum-proxy",
"logLevel" : "INFO",
"stratumListenPort" : 3333,
"stratumListenAddress" : "0.0.0.0",
"getworkListenPort" : 8332,
"getworkListenAddress" : "0.0.0.0",
"apiListenPort" : 8888,
"apiListenAddress" : "0.0.0.0",
"poolConnectionRetryDelay" : 15,
"poolReconnectStabilityPeriod" : 30,
"poolNoNotifyTimeout" : 120,
"poolSwitchingStrategy": "priorityFailover",
"rejectReconnectOnDifferentHost" : false,
"poolHashrateSamplingPeriod" : 300,
"userHashrateSamplingPeriod" : 300,
"connectionHashrateSamplingPeriod" : 300,
"isScrypt" : false,
"databaseDirectory": "",
"hashrateDatabaseSamplingPeriod": 300,
"hashrateDatabaseHistoryDepth": 7,
"pools" :
[
{
"name" : "zpool",
"host" : "mine.zpool.ca:3333",
"user" : "HIDDEN",
"password" : "c=BTC,sha256",
"enableExtranonceSubscribe" : true,
"appendWorkerNames" : false
},
{
"name" : "F2Pool",
"host" : "stratum-us.f2pool.com:3333",
"user" : "HIDDEN",
"password" : "x",
"enableExtranonceSubscribe" : false,
"appendWorkerNames" : false
},
{
"name" : "Kano",
"host" : "stratum.kano.is:3333",
"user" : "HIDDEN",
"password" : "x",
"enableExtranonceSubscribe" : false,
"appendWorkerNames" : false
},
{
"name" : "CK Solo Pool",
"host" : "solo.ckpool.org:3333",
"user" : "HIDDEN",
"password" : "x",
"enableExtranonceSubscribe" : false,
"appendWorkerNames" : false
}
]
} August 14, 2016, 11:24:06 PM
I tried using this proxy with my S9 but no shares ever get submitted. The proxy can see the pools and the single user. The S9 can see the proxy.
The only info in the log that might indicate a problem is the following "Unknown request type":
Note that this is with a stock S9 from batch 3 with no firmware updates. Is a firmware update needed to work with this proxy?
The only info in the log that might indicate a problem is the following "Unknown request type":
Code:
2016-08-14 18:05:26,523 INFO [192.168.x.x-Thread]:strat.mining.stratum.proxy.manager.ProxyManager - New WorkerConnection 192.168.x.x subscribed. 1 connections active on pool zpool.
2016-08-14 18:05:26,762 WARN [192.168.x.x-Thread]:strat.mining.stratum.proxy.network.StratumConnection - Unknown request type on connection 192.168.x.x. methodName: mining.multi_version, id: 2, params: [1]
Note that this is with a stock S9 from batch 3 with no firmware updates. Is a firmware update needed to work with this proxy?
What's there after?
Not much. Mostly a bunch of new block notifications.
Note that I tried switching from zpool to kano and got more of the same. No submitted shares.
Here's the log entries:
Code:
2016-08-14 18:11:28,464 INFO [Pool-zpool-Thread]:strat.mining.stratum.proxy.manager.ProxyManager - New block detected on pool zpool.
2016-08-14 18:11:39,806 INFO [Grizzly-worker(1)]:strat.mining.stratum.proxy.manager.ProxyManager - Changing pool Kano priority from 2 to 0.
2016-08-14 18:11:39,816 INFO [Grizzly-worker(1)]:strat.mining.stratum.proxy.manager.strategy.MonoCurrentPoolStrategyManager - Switching worker connections from pool zpool to pool Kano.
2016-08-14 18:11:39,823 INFO [Grizzly-worker(1)]:strat.mining.stratum.proxy.manager.strategy.MonoCurrentPoolStrategyManager - Close connection 192.168.x.x since the on-the-fly extranonce change is not supported.
2016-08-14 18:11:39,835 INFO [StratumProxyManagerSeverSocketListener]:strat.mining.stratum.proxy.manager.ProxyManager$1 - New connection on /0.0.0.0:3333 from /192.168.x.x:40034.
2016-08-14 18:11:39,842 INFO [Grizzly-worker(1)]:strat.mining.stratum.proxy.manager.ProxyManager - Worker connection 192.168.x.x closed. 0 connections active on pool zpool. Cause: Change extranonce not supported.
2016-08-14 18:11:39,903 INFO [192.168.x.x-Thread]:strat.mining.stratum.proxy.manager.ProxyManager - New WorkerConnection 192.168.x.x subscribed. 1 connections active on pool Kano.
2016-08-14 18:11:40,294 WARN [192.168.x.x-Thread]:strat.mining.stratum.proxy.network.StratumConnection - Unknown request type on connection 192.168.x.x. methodName: mining.multi_version, id: 11, params: [1]
2016-08-14 18:12:23,084 INFO [Pool-zpool-Thread]:strat.mining.stratum.proxy.manager.ProxyManager - New block detected on pool zpool.
August 14, 2016, 11:15:51 PM
I tried using this proxy with my S9 but no shares ever get submitted. The proxy can see the pools and the single user. The S9 can see the proxy.
The only info in the log that might indicate a problem is the following "Unknown request type":
Note that this is with a stock S9 from batch 3 with no firmware updates. Is a firmware update needed to work with this proxy?
The only info in the log that might indicate a problem is the following "Unknown request type":
Code:
2016-08-14 18:05:26,523 INFO [192.168.x.x-Thread]:strat.mining.stratum.proxy.manager.ProxyManager - New WorkerConnection 192.168.x.x subscribed. 1 connections active on pool zpool.
2016-08-14 18:05:26,762 WARN [192.168.x.x-Thread]:strat.mining.stratum.proxy.network.StratumConnection - Unknown request type on connection 192.168.x.x. methodName: mining.multi_version, id: 2, params: [1]
Note that this is with a stock S9 from batch 3 with no firmware updates. Is a firmware update needed to work with this proxy?
What's there after?
August 14, 2016, 10:06:19 PM
I tried using this proxy with my S9 but no shares ever get submitted. The proxy can see the pools and the single user. The S9 can see the proxy.
The only info in the log that might indicate a problem is the following "Unknown request type":
Note that this is with a stock S9 from batch 3 with no firmware updates. Is a firmware update needed to work with this proxy?
The only info in the log that might indicate a problem is the following "Unknown request type":
Code:
2016-08-14 18:05:26,523 INFO [192.168.x.x-Thread]:strat.mining.stratum.proxy.manager.ProxyManager - New WorkerConnection 192.168.x.x subscribed. 1 connections active on pool zpool.
2016-08-14 18:05:26,762 WARN [192.168.x.x-Thread]:strat.mining.stratum.proxy.network.StratumConnection - Unknown request type on connection 192.168.x.x. methodName: mining.multi_version, id: 2, params: [1]
Note that this is with a stock S9 from batch 3 with no firmware updates. Is a firmware update needed to work with this proxy?
August 14, 2016, 02:16:50 PM
Too bad that there's no option to simply not log to a file. Java is not my primary language, but I could probably add the feature if the author is OK with receiving patches.
If you want to play with the source code you may as well just do me a favor and remove all *hashrate* and *sampling* functions and turn this into a true gui-less headless daemon so that I don't have to do it myself. Of course you would have to turn it into a daemon to begin with as for now it's just an ordinary foreground program. And while you are at it just rewrite it into some normal language like c.
But seriously, what would be probably generally appreciated by everybody would be to split the gui part from the daemon part. Oh well..
Joking aside, it seems like it wouldn't be that hard to have an option for headless mode. But if the fundamental performance problems can be overcome by options tuning, that would be more pragmatic.
Have you had any luck by increasing the sampling periods and reducing history depth? I saw that recommendation on the zpool thread:
https://bitcointalk.org/index.php?topic=1260863.msg15723592;topicseen#msg15723592
I haven't got to try it yet but I checked the source code for what min/max values can be and all the *-sampling-period ones can be set up to 2147483, which means it would make one sample every 24 days, and the *-history-depth can be set to 0 which means that whenever the data is to be written all the previous data will be deleted. But it seems to be easier and cleaner to just physically delete all that hashing/samping/whatever redundant code and then delete all references to it. I just want proxying which this tool does flawlessly. There is only slush0's stratum-mining-proxy that I found that could/should/would work (with Lyra2RE with Nicehash; my use case) but it doesn't have any option for a failsafe server which I think is quite important feature so I would like to stick with this program, just without all those bells and whistles that I don't need nor want.
August 14, 2016, 10:17:16 AM
Too bad that there's no option to simply not log to a file. Java is not my primary language, but I could probably add the feature if the author is OK with receiving patches.
If you want to play with the source code you may as well just do me a favor and remove all *hashrate* and *sampling* functions and turn this into a true gui-less headless daemon so that I don't have to do it myself. Of course you would have to turn it into a daemon to begin with as for now it's just an ordinary foreground program. And while you are at it just rewrite it into some normal language like c.
But seriously, what would be probably generally appreciated by everybody would be to split the gui part from the daemon part. Oh well..
Joking aside, it seems like it wouldn't be that hard to have an option for headless mode. But if the fundamental performance problems can be overcome by options tuning, that would be more pragmatic.
Have you had any luck by increasing the sampling periods and reducing history depth? I saw that recommendation on the zpool thread:
https://bitcointalk.org/index.php?topic=1260863.msg15723592;topicseen#msg15723592
August 13, 2016, 11:36:23 PM
Too bad that there's no option to simply not log to a file. Java is not my primary language, but I could probably add the feature if the author is OK with receiving patches.
If you want to play with the source code you may as well just do me a favor and remove all *hashrate* and *sampling* functions and turn this into a true gui-less headless daemon so that I don't have to do it myself. Of course you would have to turn it into a daemon to begin with as for now it's just an ordinary foreground program. And while you are at it just rewrite it into some normal language like c.
But seriously, what would be probably generally appreciated by everybody would be to split the gui part from the daemon part. Oh well..
August 13, 2016, 10:56:24 PM
Most programs don't rotate their logs, tools like logrotate do that for them. Anyway you can turn off the logging to the file and keep logging to stdout. Also, the logging seen in the gui doesn't seem to have anything to do with that as it has its own settings.
From --help:
From --help:
Code:
--api-log-level LEVEL : Enable the API logging with the given
level. Valid levels are OFF, FATAL,
ERROR, WARN, INFO, DEBUG, TRACE. May
degrade performances.
--log-directory directory : The directory where logs will be
written
--log-level LEVEL : The level of log: OFF, FATAL, ERROR,
WARN, INFO, DEBUG, TRACE. Default is
INFO. DEBUG and TRACE levels may
augment rejected shares.
Thanks for the tip. When I read the help text earlier I assumed that if I disabled logging that it would also disable stdout output.
But based on your post I tried adding --log-level OFF, but it's not particularly helpful. The stdout info captured is extremely limited. Also, the proxy *still* creates a log file.
If I specify no logging directory, then it seems to put the log file in the tmp folder.
What I'm after is having a controllable logging level, but have it only go to stdout with no log file. I can't see how to do this.
I must be missing something.
I don't think you are missing anything, there is simply no such switch. But what you can try is to either chmod 444 the logfile or make it a symlink to /dev/null instead (ln -s /dev/null original-logfile.log). Other than changing the source code.
Thanks for getting back to me. I had come to the same conclusion about the symlink approach, but haven't tried it yet. I'll do that now. Should work.
Too bad that there's no option to simply not log to a file. Java is not my primary language, but I could probably add the feature if the author is OK with receiving patches.
August 13, 2016, 10:45:26 PM
Most programs don't rotate their logs, tools like logrotate do that for them. Anyway you can turn off the logging to the file and keep logging to stdout. Also, the logging seen in the gui doesn't seem to have anything to do with that as it has its own settings.
From --help:
From --help:
Code:
--api-log-level LEVEL : Enable the API logging with the given
level. Valid levels are OFF, FATAL,
ERROR, WARN, INFO, DEBUG, TRACE. May
degrade performances.
--log-directory directory : The directory where logs will be
written
--log-level LEVEL : The level of log: OFF, FATAL, ERROR,
WARN, INFO, DEBUG, TRACE. Default is
INFO. DEBUG and TRACE levels may
augment rejected shares.
Thanks for the tip. When I read the help text earlier I assumed that if I disabled logging that it would also disable stdout output.
But based on your post I tried adding --log-level OFF, but it's not particularly helpful. The stdout info captured is extremely limited. Also, the proxy *still* creates a log file.
If I specify no logging directory, then it seems to put the log file in the tmp folder.
What I'm after is having a controllable logging level, but have it only go to stdout with no log file. I can't see how to do this.
I must be missing something.
I don't think you are missing anything, there is simply no such switch. But what you can try is to either chmod 444 the logfile or make it a symlink to /dev/null instead (ln -s /dev/null original-logfile.log). Other than changing the source code.
August 13, 2016, 08:49:50 PM
Most programs don't rotate their logs, tools like logrotate do that for them. Anyway you can turn off the logging to the file and keep logging to stdout. Also, the logging seen in the gui doesn't seem to have anything to do with that as it has its own settings.
From --help:
From --help:
Code:
--api-log-level LEVEL : Enable the API logging with the given
level. Valid levels are OFF, FATAL,
ERROR, WARN, INFO, DEBUG, TRACE. May
degrade performances.
--log-directory directory : The directory where logs will be
written
--log-level LEVEL : The level of log: OFF, FATAL, ERROR,
WARN, INFO, DEBUG, TRACE. Default is
INFO. DEBUG and TRACE levels may
augment rejected shares.
Thanks for the tip. When I read the help text earlier I assumed that if I disabled logging that it would also disable stdout output.
But based on your post I tried adding --log-level OFF, but it's not particularly helpful. The stdout info captured is extremely limited. Also, the proxy *still* creates a log file.
If I specify no logging directory, then it seems to put the log file in the tmp folder.
What I'm after is having a controllable logging level, but have it only go to stdout with no log file. I can't see how to do this.
I must be missing something.
August 13, 2016, 08:03:41 PM
Most programs don't rotate their logs, tools like logrotate do that for them. Anyway you can turn off the logging to the file and keep logging to stdout. Also, the logging seen in the gui doesn't seem to have anything to do with that as it has its own settings.
From --help:
Back to the "heavy load" problem - it doesn't seem that disableApi made any difference. It's still wasting the cpu on doing the hashrate-sampling and working with the database, neither of which I want and there doesn't seem to be a way how to turn them off. After only a couple of days the dbpools file is 3 MB and dbusers 85 MB and growing. I will try to play with their settings:
If that won't help I will just have to disable all these unwanted features in the source code.
From --help:
Code:
--api-log-level LEVEL : Enable the API logging with the given
level. Valid levels are OFF, FATAL,
ERROR, WARN, INFO, DEBUG, TRACE. May
degrade performances.
--log-directory directory : The directory where logs will be
written
--log-level LEVEL : The level of log: OFF, FATAL, ERROR,
WARN, INFO, DEBUG, TRACE. Default is
INFO. DEBUG and TRACE levels may
augment rejected shares.
Back to the "heavy load" problem - it doesn't seem that disableApi made any difference. It's still wasting the cpu on doing the hashrate-sampling and working with the database, neither of which I want and there doesn't seem to be a way how to turn them off. After only a couple of days the dbpools file is 3 MB and dbusers 85 MB and growing. I will try to play with their settings:
Code:
--connection-hashrate-sampling-period : The sampling period in seconds used
N to calculate hashrate on workers
conections. (600 seconds by default)
--hashrate-database-history-depth N : The number of days to keep data in
the hashrate database. (Default to 7
days)
--hashrate-database-sampling-period N : The time (in seconds) beetwen two
records of pools, users and
connections hashrates in the
database. (60 seconds by default)
--pool-hashrate-sampling-period N : The sampling period in seconds used
to calculate hashrate on pools. (600
seconds by default)
--user-hashrate-sampling-period N : The sampling period in seconds used
to calculate hashrate for connected
users. (600 seconds by default)
If that won't help I will just have to disable all these unwanted features in the source code.
August 13, 2016, 04:16:33 PM
Does this proxy automatically rotate log files?
I'm on an RPi and using log2ram to minimize thrashing the SD card. Since the size of the ram disk limits the amount of logging that can be done, I'm concerned about logs that grow without limit.
If there is no auto-rotation, that's not a big deal. I'm running the proxy under DaemonTools, so it's easy to add a log script to implement the rotate.
I just want to know if I need to do this or not.
Edit:
Looks like I can't use DeamonTools' logging. The way that works is it redirects the printed output to files managed by the multilog tool. But the proxy seems to always write a log file. Apparently it uses it to display in the web app. So when I enable DeamonTools logging, all I accomplish is two copies of the log.
There doesn't seem to be a way to prevent the proxy from logging to a file. So I guess I need to look into the logrotate tool to deal with this.
I'm on an RPi and using log2ram to minimize thrashing the SD card. Since the size of the ram disk limits the amount of logging that can be done, I'm concerned about logs that grow without limit.
If there is no auto-rotation, that's not a big deal. I'm running the proxy under DaemonTools, so it's easy to add a log script to implement the rotate.
I just want to know if I need to do this or not.
Edit:
Looks like I can't use DeamonTools' logging. The way that works is it redirects the printed output to files managed by the multilog tool. But the proxy seems to always write a log file. Apparently it uses it to display in the web app. So when I enable DeamonTools logging, all I accomplish is two copies of the log.
There doesn't seem to be a way to prevent the proxy from logging to a file. So I guess I need to look into the logrotate tool to deal with this.
August 13, 2016, 11:56:02 AM
I like this proxy, it works fine, I have no problem with it whatsoever, but when the number of connected clients exceeds 20 it slowly starts having some measurable impact on the cpu load, up to 20-40%. It's not a big deal so far but on the same machine I am also running eth-proxy (python) and that stays well below 5% with the same amount of clients, so I was just wondering why this difference? Is it only because of java or could the higher load be caused by all those api/gui functions? If so, would I get rid of all that just by turning disableApi on or would it need more changes? Because I don't need any of those nice and fancy gui thingies, all I need is just a stratum proxy. I am using it for proxying Lyra2RE miners<->pools and I haven't found any other proxy that could do that.
July 11, 2016, 10:33:17 AM
Hello!
The program works through a proxy?
I have access to the Internet only through the proxy.
The program works through a proxy?
I have access to the Internet only through the proxy.
Hi,
You may try to use these parameters for an HTTP proxy:
-Dhttp.proxyHost=proxyHost -Dhttp.proxyPort=proxyPort
Or these for a SOCKS proxy:
-DsocksProxyHost=proxyHost -DsocksProxyPort=proxyPort
For exemple: java -Dhttp.proxyHost=192.168.1.1 -Dhttp.proxyPort=1080 -jar stratum-proxy.jar ...
July 10, 2016, 04:34:52 PM
Hello!
The program works through a proxy?
I have access to the Internet only through the proxy.
The program works through a proxy?
I have access to the Internet only through the proxy.
Jump to: