GSB Forums - Powered by XMB 1.9.11

Whats new in 51.10 (not released yet)
you can reduce the dates of the data file. Even have multiple contracts with different dates.

Some examples would be helpful to better appreciate what these feature(s) may offer.

admin - 8-2-2019 at 10:45 PM

Quote: Originally posted by TradingRails

Whats new in 51.10 (not released yet)
you can reduce the dates of the data file. Even have multiple contracts with different dates.

Some examples would be helpful to better appreciate what these feature(s) may offer.

the help file GSB Guide.51.10.pdf has the info. GSB advanced features, session times and dates. Rm should have downloaded it.
Here is an example

admin - 14-2-2019 at 05:45 PM

Feb 15 2019 51.12 out soon.
Has round icons for workers, bug fixes for exceptions, and custom fields has one more decimal place.
Work on new secondary filters progressing well, but its a big job.
Update via resource monitor soon

admin - 15-2-2019 at 03:19 PM

Feb 16 2019 51.14
Has updated expiry June 5 2019. Sorry thought this was done

admin - 15-2-2019 at 09:21 PM

50.16 coming soon. New RM (exe files only) in zip file of your manager folder.
manager resume (after manager pause) do not propagate to workers.

51.09 Version

jptann - 16-2-2019 at 11:21 AM

The latest version of GSB that I have is 51.10 for Workers and 51.09 for my manager. In order to keep them aligned, I opened my manager as 51.09 and tried to open my workers at the 51.09 level. Both now give me a newer version is available, but I have not seen it.

I looked at the RM and version 3 is still there, so I'm wondering where I find the newer versions.

I will try to download the RM again and see if this is just a labeling issue, but sure would like to have an easier way to download both the manager, stand alone and workers in the same version all at the same time.

Thanks in advance

51.09 Version

jptann - 16-2-2019 at 11:22 AM

The latest version of GSB that I have is 51.10 for Workers and 51.09 for my manager. In order to keep them aligned, I opened my manager as 51.09 and tried to open my workers at the 51.09 level. Both now give me a newer version is available, but I have not seen it.

I looked at the RM and version 3 is still there, so I'm wondering where I find the newer versions.

I will try to download the RM again and see if this is just a labeling issue, but sure would like to have an easier way to download both the manager, stand alone and workers in the same version all at the same time.

Thanks in advance

admin - 17-2-2019 at 11:29 PM

Feb 18 2019. 51.17 out
A few bug fixes.
Updated RM (zipped up) Optional upgrade. Unzip and put in your current RM folder
New docs (pdf and .chm file)

jptann - 18-2-2019 at 12:01 PM

Could not find the updated RM that has this program. Where can I locate it?

admin - 18-2-2019 at 03:49 PM

critical rm bug
Do not run rm 20180216.1 till i have done more testing. I think the update has a very simple bug.
It may kill rm and gsb.
The bug is downloaded files go into the rm folder, not temp sub folder.
The dll's in rm are the same file name, but different version.
RM will work to open and kill workers, but likely will die when it does the next update (not for a few days)
I dont know if only one user has this, or all users. Investigating...

admin - 18-2-2019 at 07:13 PM

RM issue should be ok. Temp file on user concerned was set to RM folder, not a sub folder.
Unlikely other users will get this issue. Regardless it will not ever happen with todays RM 20190219.1
New RM will be in your GSB folder (zipped up) on the next update of GSB. RM Update is optional.

avatartrader - 24-2-2019 at 11:39 PM

I am just in the process of updating everything to use the new session times and I had a question- does the MOC still come from the contract settings, or is it now inferred from the session times? The reason I ask is that if not, I essentially have to duplicate the same identical data file over and over and rename it just so it gets associated with a different contract for the purposes of the MOC exit for intraday systems. If not already, are there any plans to refactor and associate the MOC time(s) with the session moving forward (either inferred or as additional properties) so that a single data file can be used?

admin - 24-2-2019 at 11:43 PM

I am just in the process of updating everything to use the new session times and I had a question- does the MOC still come from the contract settings, or is it now inferred from the session times? The reason I ask is that if not, I essentially have to duplicate the same identical data file over and over and rename it just so it gets associated with a different contract for the purposes of the MOC exit for intraday systems. If not already, are there any plans to refactor and associate the MOC time(s) with the session moving forward (either inferred or as additional properties) so that a single data file can be used?

I will discuss with programmer. I cant see session time for moc being valid, unless we have if moc blank, use end of day. I think we supported multiple session times too.
So I think we have to stick with moc time, unless we have option to make session end time = to moc

admin - 25-2-2019 at 12:18 AM

avatartrader, It comes from moc. We may change this to optionally be end of session time. But our focus is on secondary filters now - which is a big job and significant thing,

avatartrader - 25-2-2019 at 12:50 AM

What I would do if it were me is to extend the "session template" class or the individual "session" class to include the additional properties to be able to handle the MOC time(s) with the ability to either specify them as they are now or optionally to use the session end time. Internally, you'd then just get the MOC time(s) from the "session template" or "session" rather than the "contract".

The simplest option would look similar to this:

SessionTemplate (or SessionList or whatever the class is really called internally)

Name (the current property containing the name of the session)
Sessions (the current property containing a list of one or more "sessions" consisting of a start day, start time, end day and end time)
..Session (an individual session consisting of start day, start time, end day, end time)
MOCType (an enum providing options to use the session end time or manually specify a MOC time)
MOCTime (a DateTime representing the MOC time when MOCType is set to manually specify a MOC time)
Optional: MOCTime2, etc.

So essentially, you'd just move the existing functionality from the "Contract" to the "Session" and optionally add the ability to use the session end time instead.

If you wanted to have the same session with different MOC times, you could just clone it and change it rather than having to have a different contract, duplicate data file, etc. they way that it is now.

Another option would be to have the both the MOC Type and MOC Time properties associated with the individual session class.

That would look similar to this:

SessionTemplate (or SessionList or whatever the class is really called)

Name (the current property containing the name of the session)
Sessions (the current property containing a list of one or more "sessions" consisting of a start day, start time, end day and end time)
..Session (the individual session(s) specifying the start day, start time, etc.)
...StartDay
...StartTime
...EndDay
...EndTime
...MOCType (an enum providing options to use the session end time or manually specify a MOC time - e.g. SessionEndTime, UserSupplied)
...MOCTime (a DateTime representing the MOC time when MOCType is use a specified a MOC time)
...Optional: MOCTime2, etc.

This would add a lot more flexibility, but most likely also add a lot more complexity internally during both build and code gen depending on how GSB is designed internally.

One use case for that functionality would be if someone wanted to do a "combined" London/US Forex or FX Futures "Session Template" and specify each local session as an individual "session" (start day, start time, etc.) internally so that a trade initiated within a specific local session could be exited at the end of that session, but have it as a single session template so that it can be applied to a single system. MC and NT natively have a number of session templates that do something similar, and I've built systems like that before myself, so going that route is not without precedent.

Note: I tried to indent the sample class structure, but the post editor didn't honor it. I can mock it up as actual code if that would help illustrate the idea...

admin - 25-2-2019 at 12:54 AM

Im going to put this in the to do list to look a later. Thanks for your comments.

admin - 26-2-2019 at 11:34 PM

Hi avatartrader
The programmer emailed and said, "yes, I agree with all except moctype and moctime."
I have yet to discuss but this may take some time as its a minor issue, and big improvements to be made with new secondary filters etc

avatartrader - 27-2-2019 at 12:22 PM

Hi avatartrader
The programmer emailed and said, "yes, I agree with all except moctype and moctime."
I have yet to discuss but this may take some time as its a minor issue, and big improvements to be made with new secondary filters etc

That's great news. That will greatly simplify contract and data management (and save a good deal of space if you have a lot of data). For now, I just created a script to duplicate data files for each of the alternate contracts I have for session purposes.

admin - 27-2-2019 at 03:19 PM

Can you share and explain the script? Others might have use for this.

avatartrader - 28-2-2019 at 02:08 AM

Can you share and explain the script? Others might have use for this.

No problem - I've attached the PowerShell script that I use to update the data.

For those who have not read my recent comments and looking for some background:

As I mentioned in the script comments, since GSB now supports session times, it is no longer required to have separate data files for the purposes of testing and building with different sessions. Instead, a single data file containing all available data for a given instrument can be used. However, in the current implementation, market close times are associated with contracts and not with the sessions. Further, when the price data is specified, it associates the price data entry with the contract (and hence the market close times and other settings) based on the structure of the file name, expecting to match the first segment of the file name to a valid "contract" in the contracts list.

Therefore, in order to have price data that uses different market close times, it is currently required to have an entirely separate data files compliant with the expected naming conventions to be able to map to the corresponding to the contract definitions even though the data is exactly the same (e.g. ES vs. ES_RTH, where the only difference is the MOC time).

As a workaround to save time, I developed a script that will enumerate the list of price data files and select only those files whose "contract" portion of the file name does not contain any number of user-defined suffixes used to create alternative contracts for the purposes of MOC time, etc. and then automatically create or update the data files for all of the required alternative contracts.

This allows me to manage and maintain a single data file containing all available market data for a given instrument (e.g. ES) and then the script will automatically create the copy of the data file for derivative contracts based on the list of user-defined suffixes (e.g. ES_RTH)

So, if I want to update ES data from TS, I can simply export the data from a 1m, 24-hour chart and update my existing file "ES.1.Minute.24h.CST.@ES.TradeStation.txt". I can repeat this process for each of the main contracts and then run the script and it will automatically create or refresh the data for "ES_RTH.1.Minute.24h.CST@ES.TradeStation.txt" and so on.

I have a lot of data files and use both TS and IQFeed data, so this is a real time saver for updating and managing the data until the MOC time is associated with sessions making the additional contracts unnecessary for that purpose.

The attached script is fully documented if anyone wants to use and/or modify it for their needs.

Attachment: Login to view the details

admin - 28-2-2019 at 04:18 PM

Thanks for your work in this Avatartrader. My programmer says there is a bug in session template logic, but I dont know what it is. Fix likely come soon. The next update on GSB is a major one, hence the lack of regular updates.

admin - 1-3-2019 at 06:32 PM

New build of GSB might be out later today if it passes testing.
It has option to use one indicator only. This is not designed to build systems, but to figure out what indicator works best.
Export of indicators used again to analyses in excel what works and doesnt
Likely this will be the second the last build of GSB 1.
Next week moc time linked to session time just like ts, mc and ninja

After that it will be GSB2

admin - 2-3-2019 at 03:02 AM

New build doesnt work with one indicator only. Gives errors. Stats exports works fine

Hence its not released. Sometime next week

JasonT - 3-3-2019 at 12:44 AM

The proposed changes and GSB coming down the pipeline sounds exciting!

admin - 3-3-2019 at 10:54 PM

Thanks Jason
export can now be done to clipboard with tab separator.
This is really useful as clib board with tab can go straight into excel. Much quick process for GSB users.

Using just one indicator is now also possible in 51.23.

Whats stopping the release is there is a critical bug in all builds that session time apart from 24/7 doesnt work properly.
I have also had a case where date filter on contracts didnt work properly either.
Hopefully the fix is not far away.

There is also a issue (not bug) that GSB session time will be in local time.
This is in the time zone TC/mc export data in.
TS uses exchange time for its session time, not local time. Its exported data is in local time however.

admin - 4-3-2019 at 06:00 PM

51.24 released, 2019-March-04
1.0.51.24 /
Fixed null errors on loading settings.
Fixed Session's (tested OK, but not fully).
Fixed price cache related to session and start/end dates.
Implemented Parameters export
Implemented export to clipboard for systems and parameters.
Enabled a min. of 1 indicators in strategy,
A minor fix in filtering duplicate systems by indicators, ExitMode included.
Set Start/End Date columns hidden in Price Data window when open from the Tools menu.
Fixed Price Data window erroneous view and jump to wrong price-data-set on user click.
Fixed Support window by adding missing Sessions.txt file.

Documentation for this build has not been updated yet.

jptann - 4-3-2019 at 11:36 PM

Where is the down load for this version. I don' see an updated RM, so where is the link.

Thanks

admin - 4-3-2019 at 11:39 PM

Where is the down load for this version. I don' see an updated RM, so where is the link.

Thanks

rm will auto download it. If it didnt happen send me teamviewer details.
The manger should be in manager folder, but rm wont auto open managers.

admin - 7-3-2019 at 07:41 PM

Whats next in GSB is
custom coulomb export of indicator used

Ability to allow duplicate systems if indicators are the same, but parameters different.

Bug fix where we cant update the dates of the data file if we want some extra time left out of sample.

GSB 2.0 alpha is going slowly due to more work done on GSB 1.05x

admin - 8-3-2019 at 04:18 AM

March 8 2019 51.27 under testing. Has one small bug that needs to be fixed, before release.

admin - 11-3-2019 at 12:55 AM

March 11 2019

51.28 uploaded. Minor updates to docs (pdf). Latest RM 2019025.5
Improved export of indicators and systems (right click systems)
custom coulomb export of indicator used

Ability to allow duplicate systems if indicators are the same, but parameters different.

Bug fix where we cant update the dates of the data file if we want some extra time left out of sample.

admin - 15-3-2019 at 01:10 AM

Its been a slow week on GSB. Most time fixing some hard to fix bugs that involved re-writing some sections of GSB.
A lot of time spent on researching what works best as far as indicators go. Bottom line is indicator choice is stable, but results vary
with the top 38 and the top ( 6 to 21). Regardless of the variation, using the top 6 to 21 consistently improves results.
Often its just the post 2015 results and not pre 2015, and the 2019 results

admin - 18-3-2019 at 02:07 AM

March 18 2019
New build should be out in 24 hours. Mainly some bug fixes that have been hard to fix. Thus includes bugs where you can change the date on the files to see future unseen data

admin - 20-3-2019 at 12:47 AM

March 20 2019. 51.40 under testing and out soon.
Lots of bug fixes and minor GUI tweaks

admin - 21-3-2019 at 09:40 PM

Unknown to me, dropbox failed on a machine I use to supply files for RM. So updates did not occur
We are now on 51.41. Has more fixes for some exception errors.
Thanks to all for cloud power. The concept is working really well.

Grace period has been faulty for some time. Fixed in this or a recent build.

What grace period does is ignore all systems that come in after x seconds when the manger has stopped. This is so the late systems that arrive dont screw up your stats if you've changed dates or nth etc

jptann - 23-3-2019 at 12:11 PM

Peter:

I am using the most recent RM and it is opening workers utilizing 51.410.exe file. The workers opened so far are version 1.0.51.41 in the title pane. Unfortunately, the latest RM only installs Manager 51.28. I opened this but the workers don't seem to be doing anything and not taking any of the optimization settings from the manager. I am going to let it run for a few hours, but so far nothing is happening. Do I need to start the Manager to run????

Thanks

admin - 24-3-2019 at 03:25 PM

Peter:

I am using the most recent RM and it is opening workers utilizing 51.410.exe file. The workers opened so far are version 1.0.51.41 in the title pane. Unfortunately, the latest RM only installs Manager 51.28. I opened this but the workers don't seem to be doing anything and not taking any of the optimization settings from the manager. I am going to let it run for a few hours, but so far nothing is happening. Do I need to start the Manager to run????

Thanks

Check this folder is where you want the files for the manager to be.
Likely this is not correct, and the file are in location you dont expect.
Fixing this will mean the problem wont occur again, but it wont fix it till the next update. Manger, worker and standalone files are the same file. The file name determines the function. So you can copy a worker to the correct folder, then rename it. Any problems send me teamviewer.com details

admin - 29-3-2019 at 07:01 PM

Coming next week. 51.46
Favorites C & D
stats CD EF
and a really nice surprise. (that very indirectly will mean a lot more GSB useage on the cloud- so keep your resource managers going to get the update, and to contribute to the cloud when its not needed.

admin - 1-4-2019 at 01:33 AM

2019-April-01: 1.0.51.48 /
Replaced start/end date in price files window by start/end date in opt. set grid.
Implemented and fixed favorite C/D.
Implemented Completed status in workplace managers.
A fix for workplaces grace period on optimization completed (as with paused and stopped).
A minor fix for managers status (initialized, searching, running).
Implemented Macros.
Added Tools --> Macro to the main menu.
Added opt. set info (ex. header text, icon color, etc.) to exceptions logged and invalid opt. set error-messages (ex. invalid price data).
A minor update to WF price data.
Replaced Toggle Checked/Unchecked button in the Export systems/parameters window by two buttons.
Implemented stats C-F.
Updates Help to go to https://trademaid.info/gsbhelp/index.html.
Minor fix in start/pause/stop buttons enabled property.

Multiple small GUI fixes and updates.
implemented keyboard shorts cuts for macros, optimizer settings, advanced settings, GSB resources

admin - 1-4-2019 at 04:00 AM

51.49 macro is faulty. We are rolling back to 51.48 but the exe will be called 51.50 to fool resource manager.
Hope to have fixed in < 48 hours
If you want macros, run 51.48 (or 51.50) manager.
Workers dont matter so much.

admin - 1-4-2019 at 06:25 PM

51.48 grace period still not working. Was thought to be fixed.
This is an extreme case as i had 60 workers with low c/us ratio (meaning fast to build systems), and so 5000 extra systems came in after the manager stopped.
stats a did 5470 systems, and the other stats 10477. Likely this is no big deal as all the results are correct except statsa is on smaller sample.
Please also report if the entire manager freezes. I had 2 identical setups that did this, but all others were fine.

admin - 2-4-2019 at 01:38 AM

2 April 2019. 51.52 out
fix for macro issues, and grace period improved.

dates and global dates can be changed.
Video on all of this i hope next week

admin - 4-4-2019 at 04:40 AM

5 april 2019. Hope to release 51.59. It has some snazzy features. Trying to get the video done.....
docs and or video are vip for this build.

The build is under testing now

admin - 4-4-2019 at 04:44 PM

51.59 is released. I have not done the docs, which are very much needed for this build.
It has macros + more

admin - 5-4-2019 at 01:21 AM

The video is part of the docs, https://www.youtube.com/watch?v=81jYQhN8-HA&feature=youtu.be

and incomplete docs on macro's are here. Under advanced features.
https://trademaid.info/gsbhelp/index.html

No docs yet on best/worst indicator diagnostics, apart from whats in the video

admin - 5-4-2019 at 03:27 AM

Docs are now updated
https://trademaid.info/gsbhelp/index.html

avatartrader - 5-4-2019 at 08:12 PM

I just upgraded to 51.59 and it looks there is a bug in the Price Data editor. I tried renaming the original PriceData.txt file and letting it recreate it fresh, but when I open the window, GSB reports a NullReferenceException and I get the Windows Forms/GDI Red X of Death and can't edit price data settings.

I still have 51.410 that I upgraded from, so I can launch that and edit price data. However, I am not sure what differences there are between 51.41 and 51.59 in terms of price data and how that may impact operation.

admin - 5-4-2019 at 08:41 PM

I just upgraded to 51.59 and it looks there is a bug in the Price Data editor. I tried renaming the original PriceData.txt file and letting it recreate it fresh, but when I open the window, GSB reports a NullReferenceException and I get the Windows Forms/GDI Red X of Death and can't edit price data settings.

I still have 51.410 that I upgraded from, so I can launch that and edit price data. However, I am not sure what differences there are between 51.41 and 51.59 in terms of price data and how that may impact operation.

This was fixed today in 52.00.
The issue occurs when you use the tools contract, rather than click on contracts on the left side of GSB.
I will upload via RM in a minute. Thanks for your other comments to Candymachine. I would like the forum to be a bit more active, so its appreciated. Much of the communication that goes on is via email

eurtrader - 6-4-2019 at 05:15 AM

Here are the macro settings used in video

https://www.youtube.com/watch?v=81jYQhN8-HA

Attachment: Login to view the details

Attachment: Login to view the details

eurtrader - 6-4-2019 at 11:34 PM

Something went wrong with the upload of the document with macro settings.
Please change the file extention from "tmp" to "docx".

admin - 9-4-2019 at 01:48 AM

coming in a few days, 52.02
Change of session times to be closer to how TS & MC function. Bug fixes. Once this build is proven & tested, all users should upgrade.

admin - 9-4-2019 at 05:08 AM

There is a simple bug that bit me today. The top indicators in indicator stats gets applied to primary AND secondary filters.
This should not be applied to secondary filters. It should be fixed in the next build.

I ended up running with 15 secondary filters instead of one. If you had SF closeD... instead of GA, then this wont affect you

admin - 12-4-2019 at 06:57 PM

52.05 build has not passed testing, though will be ok for most users.
The bug from the above post is fixed, and marketonclose issues, and issues with bar types that the last bar of the day is not going to natural fit.
ie 29 min bars , the last bar isnt 29 minutes if moc = 1500
Hope to release some time next week

admin - 14-4-2019 at 06:57 PM

April 15 2019 52.06 build released.

The bug from the above post is fixed, and marketonclose issues, and issues with bar types that the last bar of the day is not going to natural fit.
ie 29 min bars , the last bar isnt 29 minutes if moc = 1500
Session times updated under tools to be similar to TS / MC

avatartrader - 15-4-2019 at 06:16 PM

April 15 2019 52.06 build released.

The bug from the above post is fixed, and marketonclose issues, and issues with bar types that the last bar of the day is not going to natural fit.
ie 29 min bars , the last bar isnt 29 minutes if moc = 1500
Session times updated under tools to be similar to TS / MC

Hi Peter - quick question: as of this update, does this mean that the MOC function is now governed by the session settings, and not the contract property (meaning that I no longer need multiple contracts, and hence multiple data files) just for the different session end times?

admin - 15-4-2019 at 06:37 PM

I believe that is the case, though Im not yet very familiar with the new updates.
All my old settings worked transparently, so I didnt need to do anything different. I was more aware of the bugs that are fixed by these changes.

admin - 17-4-2019 at 04:43 AM

52.08. under testing
Bug fixes, new addition using brackets that wont do silly things like
indicator1 * indicator2 + indicator3

It will do indicator1 * ( indicator2 + indicator3)

The top example, indicator3 value is so small compared to indicator1*indicator2 - thats its just noise.

Make sure you use weights if * and + both used
ie -100 to 100 step 20
You should no longer use the legacy add. Note the order of these how they appear may change in the next build

jptann - 17-4-2019 at 07:46 AM

Peter:

A few ideas to consider:

1. You should make clear where these new updates can be downloaded? Will they automatically be available when we start a RM?
2. The default op settings in both workers and managers should be available to change. Changing all the op settings each time is a pain.
3. There should be a global price file (this may be available now) and if available where for workers and managers. Nice to place in default
4. Sometimes workers open in RM that don't pick up the manager op settings. Is that suppose to happen?
5. I have the new worker, but will that use the old manager, or do I have to change the file name of the manager. As an example, I have worker 52.06 but the manager is 52.00. Can I just rename the manager file????

Thanks

admin - 17-4-2019 at 04:42 PM

Peter:

A few ideas to consider:

1. You should make clear where these new updates can be downloaded? Will they automatically be available when we start a RM?
2. The default op settings in both workers and managers should be available to change. Changing all the op settings each time is a pain.
3. There should be a global price file (this may be available now) and if available where for workers and managers. Nice to place in default
4. Sometimes workers open in RM that don't pick up the manager op settings. Is that suppose to happen?
5. I have the new worker, but will that use the old manager, or do I have to change the file name of the manager. As an example, I have worker 52.06 but the manager is 52.00. Can I just rename the manager file????

Thanks

1) RM will download them. Most users should have RM running all the time.
RM docs are here. https://trademaid.info/gsbhelp/GSBResourceManager.html
2) Opt settings are always available. You can save and load them with the name of your choice.
You should never touch worker opt settings. The manager will update them each time it starts the worker. I can understand if you didnt know that, its a pain.
3) same as above. worker gets price file from manager.
4) That should never happen. It its an issue send me teamviewer details.
5) Never rename the manager file. It will do nothing at best.
RM should download the new manager file. Typically for most but not all users, its set to c:\gsb\gsbmanager...exe
In most cases, new workers run on all older managers. In some cases new managers run on old workers.(depends on version compatabilty)
Its best to run new manager and new worker.

admin - 17-4-2019 at 04:58 PM

march 18 2019
52.08 released. See post above for details

Bruce - 17-4-2019 at 10:55 PM

march 18 2019
52.08 released. See post above for details

I'm unable to locate a 52.08 manager anywhere, do I download this from somewhere else?

I've got the worker.

admin - 17-4-2019 at 11:15 PM

Quote: Originally posted by Bruce

march 18 2019
52.08 released. See post above for details

I'm unable to locate a 52.08 manager anywhere, do I download this from somewhere else?

I've got the worker.

Under update on RM, look at gsbmanager folder
You can rename a worker to a manger. They are the identical file.
The name determines the function

Macros Missing

appengineer - 18-4-2019 at 09:03 PM

Hi Peter,

I am missing the Macro Options in build 52.06

Thank you

appengineer - 18-4-2019 at 09:04 PM

Never mind, I figured it out.

admin - 18-4-2019 at 09:15 PM

Quote: Originally posted by appengineer

Never mind, I figured it out.

Great, but use 52.08. There is a contracts bug in 52.06

admin - 23-4-2019 at 01:09 AM

April 23 2019 52.13
Bug fixes, especially important is fix to walk forward. The OOS periods were calculated on the total dates, not the dates that the WF was done on.
WF was still done on the correct dates though.

admin - 24-4-2019 at 12:03 AM

April 24 2019 52.13
One more WF fixes and improved logic of sending WF to the GSB cloud.

admin - 24-4-2019 at 01:04 AM

Note that wf uses the global dates range, not the "dates" field.

This was because if a user has multiple periods in dates, it screws the wf dates / runs calculation.

admin - 24-4-2019 at 08:35 PM

all users should read this post (subscribe to the thread too)
Methodology has been written up. Ive spent months on this and am very open to better ways to do this.

https://trademaid.info/forum/viewthread.php?tid=17&page=2#pi...

admin - 26-4-2019 at 02:19 AM

52.16 under testing. Much better allocation of WF jobs to the cloud. It also fixes the issues with cloud workers being killed and screwing up WF jobs.

Methodology updated today
https://trademaid.info/gsbhelp/

admin - 29-4-2019 at 02:12 AM

April 29. 52.16 released.
Included is GSBResourceManager.20190428.1_updatedFilesOnly.zip
Put this in your existing RM folder. Only the updated files are included, it wont run by itself.
This is not a critical update of RM.
Has option to kill any worker with ram of 50gb (softcoded) and some other minor tweaks

jptann - 29-4-2019 at 09:46 AM

Peter, can't find the new release anywhere. I will send you an email with a tV to see if you can fix.

Thanks in advance

admin - 29-4-2019 at 05:02 PM

Peter, can't find the new release anywhere. I will send you an email with a tV to see if you can fix.

Thanks in advance

There was a very simple problem on my end. This affects all users in that update didnt occur.
I updated your rm to the newest version too
Peter

admin - 29-4-2019 at 05:22 PM

vip note. GSB 52.16 manager will not work with older workers. But old managers will work with 52.16 workers

admin - 1-5-2019 at 01:23 AM

Under testing. GSB 52.18. Can load and save macro's

admin - 2-5-2019 at 12:26 AM

May 2 2019 52.18 released.
Load / save macros
https://trademaid.info/gsbhelp/Macros.html

avatartrader - 4-5-2019 at 11:24 PM

I am using 52.18 and running through the indicator testing as outlined in the docs and the video, and I have observed that the memory and CPU on my Manager (running on my PC) is much higher than I would expect. The CPU is running at 20-40% (not constant, but in sustained bursts) and the memory is up to over 16GB, which seems extreme considering the manager is not building any systems. I have stopped and restarted the process a couple of times to correct a couple of things in the optimization settings between tests, but have not been doing anything too extreme - I did not close and restart GSB between runs. At minimum, there seems to be a memory leak in the application...

admin - 5-5-2019 at 04:26 PM

I am using 52.18 and running through the indicator testing as outlined in the docs and the video, and I have observed that the memory and CPU on my Manager (running on my PC) is much higher than I would expect. The CPU is running at 20-40% (not constant, but in sustained bursts) and the memory is up to over 16GB, which seems extreme considering the manager is not building any systems. I have stopped and restarted the process a couple of times to correct a couple of things in the optimization settings between tests, but have not been doing anything too extreme - I did not close and restart GSB between runs. At minimum, there seems to be a memory leak in the application...

I observed this too on saturday. GSB is not idle. Its decompressing systems, then has to run them to get the performance metrics. Regardless this has now been made effective. (might be using the binary of the systems instead of ascii - internally) So there is a fix for this. I can send you a copy, but its not well tested.

avatartrader - 5-5-2019 at 05:03 PM

Thanks, Peter - the only other thing that I noticed is that both when I built 40k systems for indicator testing and 50k systems for a test build, GSB did not stop at the limit in either case. When I was doing the 50K run today, I dozed off around 40k and when I woke up it was still running and I had 62k.

On my servers, I did notice that RM was in the Stopped state (but the app was still running, not crashed), so it seemed to have stopped automatically, but workers were still producing systems.

Earlier yesterday when I did a quick test of 1000 it stopped by itself, so I'm not sure if the issue is just that I have not closed and re-opened GSB or the associated components between runs or something else.

admin - 5-5-2019 at 05:15 PM

Thanks, Peter - the only other thing that I noticed is that both when I built 40k systems for indicator testing and 50k systems for a test build, GSB did not stop at the limit in either case. When I was doing the 50K run today, I dozed off around 40k and when I woke up it was still running and I had 62k.

On my servers, I did notice that RM was in the Stopped state (but the app was still running, not crashed), so it seemed to have stopped automatically, but workers were still producing systems.

Earlier yesterday when I did a quick test of 1000 it stopped by itself, so I'm not sure if the issue is just that I have not closed and re-opened GSB or the associated components between runs or something else.

Some of the newer builds of RM did not work well. I have a likely fix, but have not tried it. (its just been made). Getting too many systems is more likely when you have only 30 min bars, not 29,30,31. The reason is 30 min only build much faster then 29,30,31. Once you hit 50k workers, the manager will send stops to the workers. However the workers take some time to stop. So there is grace period (under app settings) to stop systems coming in x seconds after the manager has stopped. However this doesnt work perfectly - though a lot of time was spend trying to fix this. (its a minor bug)

RM doesnt stop gsb manager running, it just controls the amount of workers, and wht group of workers are allowed to run. Having rm stopped is a bit dangerous, as you may run out of ram.

avatartrader - 5-5-2019 at 05:24 PM

In this case, I was building 29,30,31 and they just never stopped (all running 52.18). The manager hadn't even stopped - I had to click the stop button manually.

I did run out of RAM on one server. I did not stop RM, it stopped on it's own at some point. I just upgraded to 20190428.1 yesterday and this is the first time I recall seeing that happen.

Last night, I only had it stop on it's own on one of the servers, and today it happened on both of my servers.

I don't see anything in the logs either. However, I do see one line about C:\...\ReduceMemory.exe" is missing on one of the servers, but I don't have that on any of the machines and doesn't appear to be related.

admin - 5-5-2019 at 05:39 PM

In this case, I was building 29,30,31 and they just never stopped (all running 52.18). The manager hadn't even stopped - I had to click the stop button manually.

I did run out of RAM on one server. I did not stop RM, it stopped on it's own at some point. I just upgraded to 20190428.1 yesterday and this is the first time I recall seeing that happen.

Last night, I only had it stop on it's own on one of the servers, and today it happened on both of my servers.

I don't see anything in the logs either. However, I do see one line about C:\...\ReduceMemory.exe" is missing on one of the servers, but I don't have that on any of the machines and doesn't appear to be related.

check you have ReduceMemory.exe in the rm folder
Here is the latest RM. It has one bug that on i7 5930 cpu, cpu is Nan (not a number)
There are new feature in this build. It pulls in sub folders of GSB. Needed to get the GSB macros. + bug fixes. Worse case use RM 201902xx build

Attachment: Login to view the details

admin - 5-5-2019 at 07:50 PM

This RM has all known bugs fixed and downloads gsb sub folders.
Put this in your current RM folder. Its critical to not run RM and gsb in the same folder. There will be a dll version conflict

Attachment: Login to view the details

admin - 5-5-2019 at 08:38 PM

May 6th 2019. 50.21
Ram and CPU improvement of manager.
Minor bug fixes.
Stats G&H doesnt work yet.

Operand "-" now included. This means you dont use weights say -10 to 10 step 2, but would use weights 2 to 10 step 2, and allow operand + and -

admin - 6-5-2019 at 05:12 AM

TO BE CONFIRMED - CRITICAL BUG
50.21 MAY BE A BAD BUILD. THE SCRIPT IN GSB <> SAME SCRIPT IN GSB TS CODE.
WORKING ON IT NOW.

admin - 6-5-2019 at 04:16 PM

May 7th 50.22 released.
Fix for bug. Turns out its been there for a number of builds, and was only apparent in WF

avatartrader - 7-5-2019 at 03:00 PM

I am using 50.22 and the memory and CPU utilization is back to normal. After building 40K, my GSB RAM for the Manager is at 3.5GB instead of 29 GB.

The build process also stopped this time shortly after building the systems and the RM did not stop involuntarily on any of the machines (latest version 0506).

avatartrader - 7-5-2019 at 03:25 PM

One thing I am noticing is that as my Macro is running (the steps for indicator validation) and it is saving stats, the notification is indicating that it is saving stats for 10000 systems, and not the full amount of a little over 40k, whereas when it completes the change for Nth mode, the notification cites the full amount.

Is this merely an error in the notification, or a bug where it is only calculating stats for 10000 systems? Looking at the raw results, it seems like it may be the former, but can't tell for sure.

Update: If I hover over the "Statistics" column, it shows the contents of each as only 10000 as well.

admin - 7-5-2019 at 06:31 PM

One thing I am noticing is that as my Macro is running (the steps for indicator validation) and it is saving stats, the notification is indicating that it is saving stats for 10000 systems, and not the full amount of a little over 40k, whereas when it completes the change for Nth mode, the notification cites the full amount.

Is this merely an error in the notification, or a bug where it is only calculating stats for 10000 systems? Looking at the raw results, it seems like it may be the former, but can't tell for sure.

Update: If I hover over the "Statistics" column, it shows the contents of each as only 10000 as well.

Check this setting is on 100,000 not 10,000
If that doesnt work email me teamviewer.com details

avatartrader - 7-5-2019 at 07:26 PM