admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
GSB CLOUD SERVER FARM AS A FREE, OR PAID SERVICE AND OR CPU BANK
I'm toying with the idea of a GSB server farm that anyone can use as a free (entry level) & paid service. Maybe even a bank that you can get GSB CPU
credit for if you give other users unused low priority & scheduled CPU time.
This is going to be more possible with the next beta release that has database GSB workers.
There are lots of issues. IE how much ram we allow per GSB worker, as ram gets very expensive as the modules get bigger.
For example I use GSB about 50% of the time, and have a high end server thats sometimes idle outside USA day session monday to friday.
Most GSB users would want cloud power over 24 hours, and shouldnt always need it instantly.
I figure all GSB uses would love to multiply their CPU power numerous times, and most GSB users wont use thier own CPU 24 x 7 x 365
Please give me your thoughts.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
Short term I will likely allow GSB users free access to one or two cloud workers. Whats going to help the community is we give each other spare CPU
when we dont use it.
This can be scheduled in time, process priority and processor cores.
|
|
|
kelsotrader
Junior Member
Posts: 29
Registered: 16-2-2018
Location: Tapanui - New Zealand
Member Is Offline
Mood: No Mood
|
|
I am happy to be involved now that I have a dedicated trading / testing server.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
Under sharekeys in app settings, the group is default.
lets say you have 10 workers set to gsbcloud3_password1234
and I have lets say 10 workers set to gsbcloud3_password1234
A GSB user tries to use the cloud
The GSB user now gets 10% of the cloud.
This means they might get 2 workers on my server, and none on yours. (thats ok)
Or they might get 2 workers on your server, and none on mine. (still ok)
but if you change your group to say kelsotrader, the GSB users will get 10% of your group guaranteed,
and 10% of default group.
I hope to release 44.21 < 24 hours to all users inc trial.
|
|
|
kelsotrader
Junior Member
Posts: 29
Registered: 16-2-2018
Location: Tapanui - New Zealand
Member Is Offline
Mood: No Mood
|
|
Ok understand.
I have changed my group from default to Kelsotrader
|
|
|
kelsotrader
Junior Member
Posts: 29
Registered: 16-2-2018
Location: Tapanui - New Zealand
Member Is Offline
Mood: No Mood
|
|
I have also changed % to 50 and will keep 4 cloud users up. So that should give users max 2 workers.
I have changed the setting so that they are down 0800 -1600 ( whilst trading is active ).
I assume that remote managers cannot change or override the Cloud Works App settings.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
Quote: Originally posted by kelsotrader  | I have also changed % to 50 and will keep 4 cloud users up. So that should give users max 2 workers.
I have changed the setting so that they are down 0800 -1600 ( whilst trading is active ).
I assume that remote managers cannot change or override the Cloud Works App settings. |
Correct on all points, and thank you for your contribution.
|
|
|
cyrus68
Member
Posts: 171
Registered: 5-6-2017
Member Is Offline
Mood: No Mood
|
|
Could somebody who has used the GSB cloud-computing system kindly provide a few notes on how it actually works.
I've read the client-server doc but, lots of things remain vague to me.
Questions like: what are the resources available and how do they vary?
what does the user give and take?
what happens if you are bumped out or disconnected?
how reliable or robust is the system?
once you opt in, how do you opt out?
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by cyrus68 | Could somebody who has used the GSB cloud-computing system kindly provide a few notes on how it actually works.
I've read the client-server doc but, lots of things remain vague to me.
Questions like: what are the resources available and how do they vary?
what does the user give and take?
what happens if you are bumped out or disconnected?
how reliable or robust is the system?
once you opt in, how do you opt out?
|
Resources vary greatly. Right now I'm not using my own cloud which has quiet a number of workers. However another dual xeon server should be online
next week. (256 gb ram)
I have other high end servers/pc but they are only for me or paid cloud users. One of the important things is users with woeful old computers, can at
least fully use GSB on the cloud -even if its a bit slow.
It depends on how many users donate spare resource to the cloud.
Reliability is reasonable but not perfect. There is not a release build for the cloud, though I guess its 1 to 3 weeks away.
There will also be version issues. With the next build a old worker cant be driven on a newer manager. New managers have more features. ie Walk
forward of secondary filter set to WF only mode.
If a worker gets killed, should be no big deal. Likely another will start. There are time out periods to detect this sort of stuff.
To stop donating to the cloud, just stop your worker, and close it.
Anyone with the same sharekey can user your pc, but note that there is a setting with the shares keys that allows you only a certain % of the group
with the same group name.
If the manager goes offline, I think there is a 30 minute time out before your workers stop.
Bottom line there should normally be about 1 or 2 workers for all.
The speed of each worker depends on the CPU type, and how many GSB workers are running on the CPU(S)
I will update the docs a bit more as time permits as we are close to the final config of it all.
The give and take is a bit like bit torrents. There are those that give, and those that don't. Collectively regardless it works.
|
|
|
kelsotrader
Junior Member
Posts: 29
Registered: 16-2-2018
Location: Tapanui - New Zealand
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by admin |
Resources vary greatly. Right now I'm not using my own cloud which has quiet a number of workers. However another dual xeon server should be online
next week. (256 gb ram)
I have other high end servers/pc but they are only for me or paid cloud users. One of the important things is users with woeful old computers, can at
least fully use GSB on the cloud -even if its a bit slow.
It depends on how many users donate spare resource to the cloud.
Reliability is reasonable but not perfect. There is not a release build for the cloud, though I guess its 1 to 3 weeks away.
There will also be version issues. With the next build a old worker cant be driven on a newer manager. New managers have more features. ie Walk
forward of secondary filter set to WF only mode.
If a worker gets killed, should be no big deal. Likely another will start. There are time out periods to detect this sort of stuff.
To stop donating to the cloud, just stop your worker, and close it.
Anyone with the same sharekey can user your pc, but note that there is a setting with the shares keys that allows you only a certain % of the group
with the same group name.
If the manager goes offline, I think there is a 30 minute time out before your workers stop.
Bottom line there should normally be about 1 or 2 workers for all.
The speed of each worker depends on the CPU type, and how many GSB workers are running on the CPU(S)
I will update the docs a bit more as time permits as we are close to the final config of it all.
The give and take is a bit like bit torrents. There are those that give, and those that don't. Collectively regardless it works.
|
I noticed that when I had my cloud workers up and they were being accessed by another user that when I started up my manager I did not have access to
them.
So by that I assume that I don't have control unless I shut them down and restart them.
Is there no way to prioritize ones own workers?
Another question is the cloud workers application file overridden by the managers app file?
This is particularly relevant to sharing and reducing the CloudWorks workload when set in Machine Resources and Workplace.
It would seem logical to me that only sections of the Current Workers Application file that are not local settings be reset by the remote host
manager.
If you were able to briefly explain the process by which a cloud worker was taken control of and started, the transfer of data to and from the
manager, and what data that is. It would be helpful in understanding the system. A quick video would be great.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
| Quote: Originally posted by kelsotrader | | Quote: Originally posted by admin |
Resources vary greatly. Right now I'm not using my own cloud which has quiet a number of workers. However another dual xeon server should be online
next week. (256 gb ram)
I have other high end servers/pc but they are only for me or paid cloud users. One of the important things is users with woeful old computers, can at
least fully use GSB on the cloud -even if its a bit slow.
It depends on how many users donate spare resource to the cloud.
Reliability is reasonable but not perfect. There is not a release build for the cloud, though I guess its 1 to 3 weeks away.
There will also be version issues. With the next build a old worker cant be driven on a newer manager. New managers have more features. ie Walk
forward of secondary filter set to WF only mode.
If a worker gets killed, should be no big deal. Likely another will start. There are time out periods to detect this sort of stuff.
To stop donating to the cloud, just stop your worker, and close it.
Anyone with the same sharekey can user your pc, but note that there is a setting with the shares keys that allows you only a certain % of the group
with the same group name.
If the manager goes offline, I think there is a 30 minute time out before your workers stop.
Bottom line there should normally be about 1 or 2 workers for all.
The speed of each worker depends on the CPU type, and how many GSB workers are running on the CPU(S)
I will update the docs a bit more as time permits as we are close to the final config of it all.
The give and take is a bit like bit torrents. There are those that give, and those that don't. Collectively regardless it works.
|
I noticed that when I had my cloud workers up and they were being accessed by another user that when I started up my manager I did not have access to
them.
So by that I assume that I don't have control unless I shut them down and restart them.
Is there no way to prioritize ones own workers?
Another question is the cloud workers application file overridden by the managers app file?
This is particularly relevant to sharing and reducing the CloudWorks workload when set in Machine Resources and Workplace.
It would seem logical to me that only sections of the Current Workers Application file that are not local settings be reset by the remote host
manager.
If you were able to briefly explain the process by which a cloud worker was taken control of and started, the transfer of data to and from the
manager, and what data that is. It would be helpful in understanding the system. A quick video would be great. |
many ways to prioritize.
Best to run separate folders for your workers and public cloud workers. You can set CPU priority and or cores to be low/less for cloud workers. Or you
can just close the public cloud workers if you want full use of your server.
Only some of the workers settings get over written. CPU mask, priority, share keys etc do not get over written. Performance metrics will.
Docs on this I hope to update today. I may also do a video at a late stage.
|
|
|
admin
Super Administrator
Posts: 5060
Registered: 7-4-2017
Member Is Offline
Mood: No Mood
|
|
GSB client / server documentation. New April 5 2018. see top of http://trademaid.info/forum/viewthread.php?tid=17
|
|
|
![[*]](images/davis/default_icon.gif){kind=icon}
