Topics
Replies
jobenb
17 Sep 2014, 15:10
RE:
Spotware said:
Do you still observe Error #65140095 in cAlgo 1.25? If so, please press Shift+Ctrl+Alt+T. It will send us the troubleshooting information.
Hi
I did not experience it again, however I will surely press Shift+Ctrl+Alt+T next time.
I still experience disconnecting issues during times of high volatility on an account with between 1000 and 2000 open orders / positions across the Majors. Every time an order is closed a new one is opened to take its place. Take profit is only 1 -10 pips, so there are constantly orders being opened and closed every 10 seconds. Somehow cAlgo struggles and keep on disconnecting. It then appears as if it keeps on being disconnected at which point I have to force close the platform and re-open it again to have another few hours of it working fine until the cycle repeats itself. This cannot be my internet connection because I have other accounts trading on other instances of cAlgo which is not so high frequency and they never experience the same issues of a regular red dot next to the account number...
I look forward to your replies.
@jobenb
jobenb
17 Sep 2014, 11:46
RE:
Spotware said:
I have just had a look at the cAlgo 1.25 platform to verify if it is still running and it seems all the robots have crashed with the following error: 11/09/2014 19:49:12.649 | cBot crashed: Error #65140095
Could you please specify a scenario to reproduce the problem? Did you remove the account while robot was running?
I also experience connecting and disconnecting issues with cAlgo 1.25 now, but closing and restarting the platform seems to resolve it again for the next few hours. With cAlgo 1.25 it seems that it only happens once in awhile compared to cAlgo 1.24 with which it happens constantly unless it is during the quiet hours of the market.
Any ideas? Have you had time to verify whether it is a potential timeout which is too short for a high order load (which constantly changes due to TP being reached and new orders being placed)?
We will investigate the problem. Thank you for reporting that.
Dear Spotware
Any luck with finding and resolving the issue?
Thank you.
@jobenb
jobenb
13 Sep 2014, 05:11
RE:
Abdallah_Hacid said:
In the first graphics (old cAlgo) I use the unique mode provide
In the second graph (new cAlgo with optimization) I use the tick mode.
I can think of a few reasons...
The new mode is more a true reflection of the market during this time, because the history contains more data points:
1. It now contains tick data instead of minute high, low, open and close.
2. It now also contains accurate spread data which you didn't have with the old data set (You could set the spread yourself and that can quickly give very misleading results if it is set as much lower than in real life i.e. 1pip instead of 10 for example)
Clearly you only had a tiny edge with the algorithm over the initial time tested and now with more accurate data it disappeared unfortunately and back to the drawing board. ;-)
@jobenb
jobenb
13 Sep 2014, 04:56
RE:
Spotware said:
I have just had a look at the cAlgo 1.25 platform to verify if it is still running and it seems all the robots have crashed with the following error: 11/09/2014 19:49:12.649 | cBot crashed: Error #65140095
Could you please specify a scenario to reproduce the problem? Did you remove the account while robot was running?
I also experience connecting and disconnecting issues with cAlgo 1.25 now, but closing and restarting the platform seems to resolve it again for the next few hours. With cAlgo 1.25 it seems that it only happens once in awhile compared to cAlgo 1.24 with which it happens constantly unless it is during the quiet hours of the market.
Any ideas? Have you had time to verify whether it is a potential timeout which is too short for a high order load (which constantly changes due to TP being reached and new orders being placed)?
We will investigate the problem. Thank you for reporting that.
Hi,
I did not close any account while any cBot was running. Normally the platform crashed completely, however this time the cBot stopped running and by investigating the log it showed Error #65140095. This could also potentially be related (I think) to the regular connecting and disconnecting issue being experienced when there are a very high open order load with a lot of open positions.
I think this is quite critical to be resolved as it clearly place a hidden barrier for anyone's cBot to place a lot of orders on various instruments. So someone with a quiet cBot will probably never experience this issue but someone like me with advanced medium - high frequency algorithms will not be able to use the platform at all due to these unknown hidden capacity risks. Luckily I picked this up on a demo account, and luckily you guys are determined to fix it! :D
Thank you.
@jobenb
jobenb
12 Sep 2014, 00:59
11/09/2014 19:49:12.649 | cBot crashed: Error #65140095
Hi cAlgo Team
I have just had a look at the cAlgo 1.25 platform to verify if it is still running and it seems all the robots have crashed with the following error: 11/09/2014 19:49:12.649 | cBot crashed: Error #65140095
Could you please explain what it means?
I also experience connecting and disconnecting issues with cAlgo 1.25 now, but closing and restarting the platform seems to resolve it again for the next few hours. With cAlgo 1.25 it seems that it only happens once in awhile compared to cAlgo 1.24 with which it happens constantly unless it is during the quiet hours of the market.
Any ideas? Have you had time to verify whether it is a potential timeout which is too short for a high order load (which constantly changes due to TP being reached and new orders being placed)?
Many thanks!!
@jobenb
jobenb
11 Sep 2014, 10:52
( Updated at: 19 Mar 2025, 08:57 )
RE:
Spotware said:
Yes, we do load testing for both client and server side.
cServer has a limitation for the amount of open positions per account: 2000. We plan to increase this limit in the future. If cServer cannot handle all incoming requests it puts them to the queue. There is no any logic to disconnect clients in case of heavy load.
Please send to support@ctrader.com your account number and broker name. We will troubleshoot the issue.
Just to give you another update. I have had another unhandled exception today on cAlgo version 1.25.
I was also thinking about the connecting / disconnecting and I think on the platform side it could also be a timeout that cause the disconnect and then retries after about 3 minutes. I think the timeout might be too short for connection when a lot of orders / positions are involved due to the busyness of the system and context switching of the threads. Is the timeout configurable?
I look forward to your answers and feedback. Thank you!!
@jobenb
jobenb
10 Sep 2014, 15:42
( Updated at: 19 Mar 2025, 08:57 )
RE:
Spotware said:
Yes, we do load testing for both client and server side.
cServer has a limitation for the amount of open positions per account: 2000. We plan to increase this limit in the future. If cServer cannot handle all incoming requests it puts them to the queue. There is no any logic to disconnect clients in case of heavy load.
Please send to support@ctrader.com your account number and broker name. We will troubleshoot the issue.
Thank you. I have sent an email to you containing the details. :-)
I was also thinking about the connecting / disconnecting and I think on the platform side it could also be a timeout that cause the disconnect and then retries after about 3 minutes. I think the timeout might be too short for connection when a lot of orders / positions are involved due to the busyness of the system and context switching of the threads. Is the timeout configurable?
Thank you for all your help! It is much appreciated and I hope we can improve the next release at the same time. ;-)
@jobenb
jobenb
10 Sep 2014, 12:52
Hi
I have used the Spotware cAlgo 1.25 Yesterday in parallel with the broker cAlgo 1.24 (which continuously kept on disconnecting - with the little red dot next to the account number) and although the latest cAlgo did perform much better it still crashed early this morning unfortunately. I have started it again and will keep it running, so you guys should easily be able to get the load on your side. :-)
How sure can we be that this issue really has been resolved in cAlgo 1.25 and that it is not a server load issue because of the fact that your Spotware server may just be able to handle everything as it is maybe not a true reflection of the load my broker is experiencing?
I do wonder about cServer and if it is not maybe that my broker's cServer is under heavy load not just from my algo but also having thousands of other connections trading at the same time and they decide to do a periodic kill switch on my account due to it causing a lot of the trading order load every few seconds???
Are you guys doing heavy load testing on both the platform and cServer?
Why are there a limit of 2000 orders / positions within cAlgo per account? This limit full scale rollout of algorithms across currency pairs. Could this be increased to 10000 please?
What is the behaviour of cServer if it has too many orders coming in than it can handle?
Please explain the limitations with regards to cAlgo interacting with cServer, so that I can code with that in mind?
Many thanks and I look forward to your reply!
@jobenb
jobenb
11 Jun 2014, 17:13
I don't want to come across as prescribing or anything, but I know cAlgo is done using WPF and from experience if you do not unsubscribe when you have subscribed then references are kept, very easy to happen with following MVVM, so if you += an event you must make sure that you also -= the event. You can easily see if something is destructed by adding a destructor to the objects with a breakpoint in it to try and find the cause or object not being released due to something having a reference to it... Very important. Something that might not be unsubscribed that constantly changing could be the 3 buttons to the right of each row in the Positions grid or maybe the row in the grid itself... Since my robots open constant orders that continues to grow etc. etc. Maybe also all the charts that continue to paint in the background of all the 26 currencies that are open, maybe something there. Maybe it is not releasing the data that come up in the MarketSeries that are stored. 19GB of used memory from 1 application within 3 days are really a lot of bytes.
You guys will know best, so I have full confidence that you will find this issue and deal with it. :-)
@jobenb
jobenb
11 Jun 2014, 14:53
( Updated at: 21 Dec 2023, 09:20 )
Still Memory Problems in Current Release
Hi Guys
There are still memory problems in cAlgo. Unfortunately I cannot provide you with the proprietary algorithms for you to try and reproduce it, however I can show you where values are stored in which variables and try and show you that the memory leak ARE NOT in the robot itself.
Here are al the variables:
protected double CurrentGridSize { get; set; }
protected double? LastGridVolumeIncreasePrice { get; set; }
protected double? LastGridSetPrice { get; set; }
protected List<MovingAverage> FirstHighMovingAverages; ** NO MORE THAN 3 MOVING AVERAGES ARE STORED AND USED
protected List<MovingAverage> FirstLowMovingAverages; ** NO MORE THAN 3 MOVING AVERAGES ARE STORED AND USED
protected List<MovingAverage> SecondHighMovingAverages; ** NO MORE THAN 3 MOVING AVERAGES ARE STORED AND USED
protected List<MovingAverage> SecondLowMovingAverages; ** NO MORE THAN 3 MOVING AVERAGES ARE STORED AND USED
private MarketSeries _firstMovingAverageSeries;
private MarketSeries _secondMovingAverageSeries;
public virtual string FirstMovingAveragePeriods { get; set; }
public virtual MovingAverageType FirstMovingAverageType { get; set; }
public virtual TimeFrame FirstMovingAverageTimeFrame { get; set; }
public virtual string SecondMovingAveragePeriods { get; set; }
public virtual MovingAverageType SecondMovingAverageType { get; set; }
public virtual TimeFrame SecondMovingAverageTimeFrame { get; set; }
public virtual int CloseOrderTrigger { get; set; }
public virtual int GridSizePips { get; set; }
public virtual bool FullGridOrderTrigger { get; set; }
public virtual int VolumeIncrementPips { get; set; }
public virtual bool KeepMaxVolume { get; set; }
public virtual bool IncrementalPipsPerPositionEnabled { get; set; }
public virtual int IncrementalPipsPerPosition { get; set; }
public virtual bool DynamicGridEnabled { get; set; }
public virtual double DynamicGridFactor { get; set; }
[SaveState]
protected long? LastOrderVolume { get; set; }
[SaveState]
protected double? LastOrderPrice { get; set; }
[SaveState]
protected double OpeningBalance { get; set; }
protected double StrategyBalance { get; set; }
[SaveState]
protected TradeType? LastOrderTradeType { get; set; }
[SaveState]
protected TradeType? LastPendingOrderTradeType { get; set; }
[SaveState]
protected double? LastVolumeIncreasePrice { get; set; }
[SaveState]
protected double? LastIncrementVolumeBalance { get; set; }
[SaveState]
protected int LastStopLossPips { get; set; }
[SaveState]
protected int LastTargetPips { get; set; }
protected int LongPositionsCount { get; set; }
protected int ShortPositionsCount { get; set; }
protected string Label { get; set; }
protected int Index { get; set; }
protected bool StopTrailing { get; set; }
protected bool NewBar { get; set; }
[SaveState]
protected DateTime? ProfitTaken { get; set; }
protected List<Func<TradeType?>> Biases { get; set; }
protected List<Func<bool>> Filters { get; set; }
private int _barCount;
private int _lastMonth;
public virtual string AlgoNumber { get; set; }
public virtual int TargetPips { get; set; }
public virtual int MinimumTargetPips { get; set; }
public virtual int StopLossPips { get; set; }
public virtual bool TrailingStopsEnabled { get; set; }
public virtual int TrailingStopTriggerPips { get; set; }
public virtual int TrailingStopDistancePips { get; set; }
public virtual bool TimeStopsEnabled { get; set; }
public virtual bool ClosePendingOrdersUsingTimeStops { get; set; }
public virtual int DayStop { get; set; }
public virtual int HourStop { get; set; }
public virtual int MinuteStop { get; set; }
public virtual int SlippagePips { get; set; }
public virtual int Volume { get; set; }
public virtual int IncrementVolume { get; set; }
public virtual int IncrementVolumeOnBalanceIncrease { get; set; }
public virtual int MaxVolume { get; set; }
public virtual bool CompoundedVolumeEnabled { get; set; }
public virtual bool CompoundedIncrementVolumeEnabled { get; set; }
public virtual bool CompoundedMaxVolumeEnabled { get; set; }
public virtual int MaxLongTrades { get; set; }
public virtual int MaxShortTrades { get; set; }
public virtual int TradeWaitPeriod { get; set; }
public virtual double BalanceStopLossRatio { get; set; }
public virtual double EquityStopLossRatio { get; set; }
public virtual bool TradeMondays { get; set; }
public virtual bool TradeTuesdays { get; set; }
public virtual bool TradeWednesdays { get; set; }
public virtual bool TradeThursdays { get; set; }
public virtual bool TradeFridays { get; set; }
public virtual bool TakeProfitDaily { get; set; }
public virtual bool TakeProfitWeekly { get; set; }
public virtual bool TakeProfitMonthly { get; set; }
public virtual bool RestorePreviousState { get; set; }
public virtual bool SynchronizationEnabled { get; set; }
====================================================================================
It is currently running on 26 currencies in 1 cAlgo instance.
MEMORY FOOTPRINT WHEN STARTED:
MEMORY FOOTPRINT AFTER RUNNING 3 DAYS:
As you can see there is cle3arly something very wrong with your memory handling. I know from experience that in WPF it is very easy to cause Memory Leaks if you don't unsubscribe your events from your models etc. Please, please investigate and find the issue - it will be much appreciated!
Thanks for an awesome platform!!
From another Software Engineer with over 10 years of experience in windows software development.
@jobenb
jobenb
07 May 2014, 15:56
Review Completed
Hi
I have thoroughly investigated and reviewed my code for any possible memory leak due to possible continuous expansion of a declared list or any other possibility. None were found.
The robot is very high frequency and open many positions at a time resulting in a lot of closed positions in the history as well as open positions over the course of a week of minute bar trading.
This result in Gigabytes of memory used by cAlgo without releasing any. This crash my computer and I have to force it to power off. I do not use your sample robots for my actual trading, so I am sure that if you use only those for testing for memory leaks that you will find nothing. You need a high frequency robot trading like a mad man. Please test with a robot that open orders every minute and let it run for a week and compare the memory usage. Remember to add about 6 indicators and 2 different MarketSeries declarations; one referring to 1 minutes and the other to an hourly trend.
I really hope you find the cause as I unfortunately do not have access to the cAlgo code.
Thank you for a great platform so by the way. ;-) Just a few teething issues.
Kind regards,
Joben
@jobenb
jobenb
27 Mar 2014, 12:43
I completely agree! The sooner we have more programmatic control within cTrader / cAlgo the easier it would be on you guys since we can then develop solutions ourselves...
So why not follow the "App" approach where you open the platform to App developers that can then sell it within the platform and you guys get a cut? This will solve a lot of problems. Qualified developers can then write Apps that fill needs within the trader community and it takes a bit pressure off you guys to fully support and constantly add new features. It will be a win win!
@jobenb
jobenb
18 Sep 2014, 14:10
RE:
Spotware said:
Thank you.
Could you please let me know how far into the future this is planned as it is currently a real limitation?
Also, one of my previous posts asked a question about a timeout for the client platform connecting to the server. Is this configurable and have you investigated whether that might be set too short considering the circumstances?
@jobenb