V12 for PRT-IG now live on Live

Forums › ProRealTime English forum › ProRealTime platform support › V12 for PRT-IG now live on Live

Viewing 15 posts - 46 through 60 (of 98 total)
1 2 3 4 5 6 7
  • 12/21/2023 at 9:57 AM #225564
    Franro

    I can not find ProOrder in V12. It is not under trading anymore? *

    Edit: Read a post that it is under work, thanks guys!

    12/22/2023 at 1:54 PM #225621
    PeterSt

    For those interested (should be ProRealTime herself) :

    I now fired up PRT-IG V12 on an empty PC, which has been made for spreading many tasks over its processor, which is a Xeon 6230 (20 native cores, in this case set up in hyperthreaded fashion, thus now 40 cores).
    The benefit of this is that there are more cores than implied threads in PRT, so we can see the multi-threading at work. The picture below shows activity in 8 cores, which is equal-ish to the number of charts in this IG account.

    The behavior is 100% the same as with my normal work PC.. The mouse moves evenly poor, the forms drag as poor, the whole feel is as bad. The differences with this new PC compared to the one I always use, are these :

    • 40 cores instead of 10. Processor speed is about equal, but is net half because of hyperthreading.
    • Memory is 48GV instead of 36GB Assigned memory to Java is again 10GB).
    • No 7 monitors but one only.
    • No special video card vs a more special video card in the work PC.
    • 59 processes, ~1587 threads and ~22450 handles instead of 337 processes, ~6903 threads and ~473900 handles in the work PC (the latter not shown).
    • Runs from an SSD (VHD file) while the work PC runs from a HDD (normal OS disk).

    These differences are so vast, that the conclusion must be that the overhead in PRT V12 is so enormous, that nothing makes a difference.
    I expect the drawing canvas** to be the culprit; this requires additional testing.

    In the 2nd screenshot you see what can be made of a Windows PC, regarding the elimination of all what’s superfluous. E.g. compare the number of processes with what you see in your own PC (Windows 10). At first this test fails, because PRT eliminated with it. After 30 minutes of attempts to keep it running, this appears not easy; Although I can keep the Java.exe as a process, something else cause it to fail/disappear. That must be for another day.

    **): Notice that the drawing canvas is one of the layers we can draw to, like all graphics of charts are drawn somewhere. The overhead of this – which is a Windows thing – is a factor of ~ 10000 because it is Windows. I never investigated where Java draws to; when this is to the same layer as normal Windows forms draw to, then my test is not going to work out hence proof anything.
    Anyway, it feels like when V12 draws one pixel in one of its forms, that *all* the pixels of all the forms are redrawn (which is a loop of e.g. 1920 * 1080 or so = more than 2 million for a smaller laptop screen. Have a larger screen like 2560 * 1440 and you can see the impact of that (loop is now 3.6 million).
    Oh, this now reminds me of having worked with PRT support to get rid over on the screen dancing new order label icons (related to the new yellow ones you may see in the label). That was actually the proof already of always redrawing things, which should not redraw at all. Ha. Now, the redraw of these bits (shown in the 3rd attachment) is not really wrong, but the recalculation of where they should be happens over and over again and is not relative to the label (and thus factually a fixed position). This is all overhead which should not be, but … I can’t judge whether *this* kind of overhead is present in V11 just the same.

    2 users thanked author for this post.
    avatar manel, avatar GraHal
    12/22/2023 at 9:44 PM #225650
    phoentzs

    I’m wondering why you can unlock something as immature or partially unusable as V12? Why do you do something like that? In any case, the customers have nothing but annoyance from it.

    12/23/2023 at 11:27 AM #225655
    PeterSt

    Regarding the sluggishness I can now definitely say that this is related to the all over moving chart contents. Thus, on this Saturday there is no moving contents (all markets closed for what I have on-screen) and I now don’t notice any annoyance whatsoever. Memory usage is also fine (keeps on hanging against the set limit of 10GB) and all is good.

    Regarding this observation, really nothing has changed since day one of V12 (which was back then in PRT-IB). The graphical means of drawing has changed and it just does not work (at all).

    That I, in this on-Saturday situation, must wait for 4 minutes before the PRT-IG platform has finished loading, remains (normal is 50-60 seconds).
    For PRT : part of this is caused by a. the PRT-deemed necessity to start a first backtest for a previously loaded System (shown in the top line of the chart) which is completely useless in the first place (IMO that is), which b. can not be stopped by pressing the Cancel button because of “wrong” threading means (the Stop is not accepted and when it finally comes through, the backtest has completed, wasting throughput time). Notice that because of the combination of matters (better threading), in V11 the Stop button does respond instantly and no time is wasted.

    2 users thanked author for this post.
    avatar inverse, avatar GraHal
    12/26/2023 at 11:34 PM #225719
    inverse

    I’ve fallen into a similar hole @PeterSt. Load times blowing out since late last week (moreso again), probably inline with what your seeing and tbh the load times have been longer since day one v12, I guess I was too busy and rolled with v11 for the analysis to clarify further earlier on. Historically Bitdefender was a culprit and CPU would blow out – an engine update / reinstall resolved it that time. This is different and feels out of place.

    I did manage to find a workable solution with raising the amount of ram but I almost feel as if we’re robbing Peter to pay Paul.

    Agreed with what you’re saying v11 is fluid by comparison.

    01/02/2024 at 8:06 AM #225890
    Monobrow

    V12 is garbage as it stands, simple as that. Don’t touch it, dont “put up with it”, just dont use it and maybe they will do something about it.

    If PRT have made the changes and IG are sitting on fixes they need to sort themselves out and get it deployed asap.

    01/03/2024 at 8:01 PM #225946
    manel

    Brilliant test @PeterSt, thanks so much for giving us your results. I think if the PRT helpdesk is watching/reading – and if they actually care ! – there is no more evidence needed than this. Clear, concise results from a user – which to be fair should not have to be done – PRT should have tested this themselves before rolling out the release. You are just echoing what a lot of us have experienced (myself included) with v12.

    It just doesn’t work. Should never have been rolled out.

    I’m just dreading the day when the option to launch v11 instead is no longer available and we will be forced to use v12 ! Will have to change brokers then unfortunately. It’s a shame because I think PRT is actually consistently one of the best charting platforms out there (I’ve paid and used it for almost 15yrs).

    v12 is clearly not fit for purpose, completely unusable for anyone who trades/requires more than a few charts etc and needs an immediate coding fix.

    I don’t usually comment this harshly on the platform but in this case I think its justified because of the lack of effort or acknowledgement on PRT’s part to do anything to fix the issues. Very poor.

    1 user thanked author for this post.
    avatar Monobrow
    01/04/2024 at 5:57 AM #225948
    PeterSt

    Thank you @manel.

    In an email conversation with PRT support in Paris about the sluggishness, I linked to this thread and asked to keep following it. This was on December 6.
    Let’s keep in mind that this thread is so far almost exclusively about the sluggishness and not about all the other numerous issues, which somehow were solved for PRT-IB long gone and re-appeared in PRT-IG. As if it’s two completely separate and redundant versions. And … while quite many individual issues on PRT-IB were announced by me via formal tickets (Help – etc.) and a few less were solved all together, I don’t understand why they are not solved now within PRT-IG after again announcing them via tickets. I mean, disappearing order labels from past orders ? Now also disappearing order labels from orders with positions ?!? … I slowly start to have the feeling that ProRealTime as an organization has lost its control. The issues are too obvious and none that I see gets solved. Maybe things are solved, but it can’t be upgraded ?

    Meanwhile I identified two issues on the slow startup, which might help people.

    1. Although at times it is difficult to avoid, always take care that an “active” Backtest is removed from the chart(s) prior to saving and exiting the platform. Thus, delete it from the top line in the chart, so at the next start up it won’t be performing the backtest right away.
      This backtest during start up immediately starts, takes 2-3 times longer than when ran in isolation (after the start of the platform has settled) and during that time nothing else (visibly) does anything. Thus, Backtest may take 3 minutes in the start up state of the platform, thus the start up of the platform starts with spending 3 minutes on that backtest and after that continues with the remainder of the initialization.
      Cause the backtest not to be there and you’ll gain 3 minutes on the start of the platform. Still 2 times or so slower than V11, but now doable (4+ minutes is not doable in my book).
    2. I am quite confident that something is amiss with the ProOrder “manipulation”. The other day I was moving Out and In systems from the list of ProOrder items (Stop systems, Start new ones) and per order this takes between 1 and 2 minutes. Stopping and Starting took the same time. Meanwhile the mouse will hardly move (the sluggishness issue) so this is one large painful trajectory. Envision 3 systems out and 3 systems in, and it took me 15 minutes or so.
      I had something like 120 not-running systems and 20 running systems in there. Now :
      I feel that quite the same happens during start up. Thus : the time it takes to manipulate one order as just described, is also necessary to initialize the whole of the ProOrder system or form. One time only (not 120 + 20 times) and it consumes another minute.
      And again I see all happening sequentially.
      Of course you cant make this faster, unless you remove the Stopped systems and it would help at it (I did not test that).

    The test with the 40 core system again gave me the feeling “the more cores the worse”. Thus, that task-switching is heavily in order, and only causes overhead. For insiders and ProRealTime in Paris, notice the difference between hogging a processor core for each thread, versus not doing so and use the cores randomly. In this case I see it more special : the cores are appointed to the threads, but the threads are coincidentally switched between the cores. Thus, the bug would be that process (thread) A, B, C are intended to appoint to the 1, 2, 3 cores respectively, but instead the processes now are appointed randomly, each time they need to get active (and this happens many million times per second). The “task switching” involved, now needs to copy the L1 cache of the processor each of those million times per second, instead of not-at-all. Below again the picture of the 40 core machine, which to me tells that cores are appointed, instead of not appointed at all (in the latter case all cores would show activity).

    Making processes hog dedicated cores is not something which is done easily, but this surely can be done, and it could have been done in V11 (and 10.3 for that matter). It possibly went off track for V12. But it is much more complicated because personally I would think this is not done at all (thus also not in V11/V10.3), but that parallel processes now are in order which should not be. This can’t be reasoned out because too many different processes are involved, and it completely depends on what they are and what they cause. Example to picture this somewhat : you can build each of the charts for their data in parallel and when that has been done, draw all the object on to it, or you can draw each of the charts in full subsequently, and in parallel sort out the Lists and some of the Detailed Reports forms/contents. And 1000+ other possibilities. The one means could be 10 times faster over the other.
    In the V12 case it is clear to me that all is done in parallel without “director”. This makes it chaos and full with unnecessary task switching. Meanwhile not even all the cores are utilized and all is “bad”(ly set up).

    The sheer fact that many things are going (wr)on(ng) with the Detailed Reports now not working, is telling. You can see that the engineers applied smartness in the parallel processing of that, and that this stopped working. @GraHal noticed a while back that some backtest data started to appear later than other, which already was done in V11. Example : Order arrows and crosses are drawn on the chart right after the clicked result is presented, but 2nd (and 3rd) pane of Graph data appears 10 seconds later. Some details in the Detailed Reports, the same. And these latter now stopped showing all together, but for PRT-IG and PRT-IB differently. These things testify of smartness in the multithreading, however, that smartness is now failing smartness. And easily to be out of control forever – especially when you (the engineers) did not notice where this started to be off.

    All could simply be caused by a not sorting out properly how many cores one’s processor has. Do that wrongly, and nothing can work out any more. It will be left to chaos (in task switching) instead of nice and smooth operations.

    The main characteristic of nothing wanting to move smoothly any more, is very much telling. Thus, once a V12 system is running, the typing becomes difficult and the whole PC seems to collapse. And the Editor of PRT ahead of all (once the code in there is somewhat larger). Or the form where you can type your technical report text, the characters appearing seconds later than you typed them.

    02/06/2024 at 8:55 AM #227451
    inverse

    To the brains trust out there … 🙂

    Has there been a reduction in available data for 1sec TF across indexes or other weird goings on???

    10sec (200k Units) takes me back to late 2023 on DAX, 1sec brings up  29JAN but you can’t ‘zoom-out’ and have it fit in a window all nice and proper like. With 10s you almost can zoom-out entirely but not the 1sec, most you get is ~3days.  Generally like to view ~30days worth of 1sec. I think it could be tied to a JAN rollout of v12 can’t be certain.

     

     

     

    02/06/2024 at 9:16 AM #227452
    PeterSt

    I recognize all you say there. I don’t think this has changed; the “seconds” Timeframes always behaved weird compared to Minutes. Hint : Use the Premium version and have 1M bars of data which *is* consistent (say linear).
    (no, I have no shares in ProRealTime 😉 )

    But you could compare with V11; I don’t think they still update V11 (mine (IB version) is from July 2023).

    1 user thanked author for this post.
    avatar inverse
    02/06/2024 at 9:59 AM #227457
    inverse
    PeterSt wrote:

    I don’t think this has changed; the “seconds” Timeframes always behaved weird compared to Minutes.

    Yep, pretty much agree on this too, in the past it would ‘fix’ itself overnight, so will see how it goes.

    Problem seems to be there under v11 too, will have a look again.

    Thanks for hitting the thread …. 🙂

    02/06/2024 at 7:27 PM #227488
    GraHal

     

    inverse wrote:

    1sec, most you get is ~3days.

    I agree … I just (Tue 6 Feb 24 at 18:24) did 1 sec Chart TF on 200K units and it takes me back to Friday 2 Feb 24 at 09:00.

    1 user thanked author for this post.
    avatar inverse
    02/06/2024 at 8:08 PM #227490
    inverse

    Thanks GraHal.

    I spoke with support at IG who requested I use PRT to log a ticket and did as asked, there have been other reports and the CSR said a weight of numbers with individual tickets would be the best approach.

    I can confirm, as you have seen too, that it’s still in the ‘upside-down’. I guess will have to wait it out.

    Appreciate the feedback!

     

     

     

    1 user thanked author for this post.
    avatar GraHal
    02/08/2024 at 3:04 AM #227624
    inverse

    I’ve not seen any movement on 1sec data, still only a few days – I remain glass half full however. Any movement on your end @GraHal….


    @PeterSt    , from memory PRT are heavy EU and NA, not so much APAC re: AUS, this might change one day but I get the current focus until they open a shop in SG maybe one day… 😛

    Some FRED data/charts would be nice too!

    02/08/2024 at 6:08 AM #227627
    PeterSt

    OffTopic I think plus I hope I don’t make up too much :

    Hi @inverse,

    Thinking about the markets we have access to, this is not a simple subject. You, in Australia, will have access to different markets (or even Instruments) than we over here in Europe. Even among he individual countries this is already different. An extreme example : a few years ago IBKR’s offices had to move from Ireland to the main land (like Germany, France, Netherlands, Luxembourg and more of course for potential habitat) and this became Luxembourg. Luxembourg is a very small country with relatively small banks, and a lot of this all is bank related. Now, I traded EUR/USD (direct Fx, not CFD) and this was only possible for literally a handful of “PRT” customers. But it was about IBKR in reality. Think of someone needing to have the money in the bank for real. I was allowed to this EUR/USD market, while most were not. Worse : One account from me was allowed, others were not.
    So this can be about resources too.

    It is mainly about responsibilities and how a government would allow transactions (also think about the declaration and/or insight in taxes) and if this responsibility can not be there, you can’t trade that market (country oriented) as well.
    If you followed the Trump “regime” and how China was disallowed certain “tickers” to operate on the US markets, you saw examples of an other magnitude.

    If I got it all right then in Australia – back in 2019 or so, you were not allowed to operate on the PRT servers directly, but had to use PRT’s API and have TWS open all the time. Maybe this is still so ? Anyway, now you, the customer, are responsible for certain stuff.

    With IBKR a lot is going on which does not apply for IG. IG = IG and ProRealTime is operating at a distance, with IG being responsible. With IBKR it is merely ProRealTime who is responsible (she is a mere provider).

    I hope this made sense,
    Peter

  • Author
    Posts
Viewing 15 posts - 46 through 60 (of 98 total)
1 2 3 4 5 6 7

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
asx stock live data needed
backtest vs live trade
buy on certin dates, not on technical singal
buy on retest on a certain candle
change positionsize when going live
grey boxes on mac with prt v12
live trades do not match those of the backtest
looking for info on new v12 feature: configure opening times of intraday candles
same script but different results in demo and live ig cfd account
trades being executes in backtest but not in live autotrading

Create your free account now and post your request to benefit from the help of the community
Register or Login