Trailing Stop on 1 second TimeFrame

Forums › ProRealTime English forum › ProOrder support › Trailing Stop on 1 second TimeFrame

Viewing 6 posts - 1 through 6 (of 6 total)
  • 07/03/2024 at 7:10 AM #234721
    JS

    Here’s a screenshot of how my trailing stop at IB works…

    As you can see, the pending (stop) orders are cancelled, when the level changes, and eventually executed…

    (there was some doubt whether a trailing stop would work on a time frame of 1 second but, it works as it should with both IG and IB)

    4 users thanked author for this post.
    avatar Iván, avatar robertogozzi, avatar GraHal, avatar inverse
    07/03/2024 at 7:35 AM #234724
    inverse

     

    Thanks JS.

    I plan to do a bit more housekeeping on my end now that I have better (faster path to EU re-established) – just trying to harness the o/p from cli etc now.

    Hopefully another anchor drag etc is a *long* way off.

    I’m guessing the system proper is run on 1s Default TF, obvious for some, just confirming.

    TIA

    1 user thanked author for this post.
    avatar JS
    07/04/2024 at 10:20 AM #234774
    PeterSt
    JS wrote:

    (there was some doubt whether a trailing stop would work on a time frame of 1 second but, it works as it should with both IG and IB)

    No Sir, it does not. Not at all. As I said in the other thread, this won’t sustain an hour (and I meant a trailing of an hour in a row – thus 3600 times).
    (this is no guarantee of course, as it depends on various bottlenecks under way, which vary throughout the day)

    But if you want to depend on this only because you think it works ? please go ahead. You will find your System kicked out and possibly a reversed order because

    1. PRT kicked out your order;
    2. The pending order will be executed after all, but later (now you will be Short while flat was intended).

     

    Ad 2.
    If I would be able to find back the situations, I could show you the entry of such order of many minutes later. This is because the original Pending Stop etc. order is not regarded Pending any more (also see towards the end of this post) when the formal control (by PRT ID) disappears (the ordering itself already did not work – think about this; when it finally comes through at the exchange, PRT has long gone disappeared (because it kicked out itself)).

    What is new since June 17, is that the position will be kicked out as well. Think like this for the difference :

    Prior to June 17 – and with the setting “let position remain when system is kicked out” – a double order would have been put (one intended by your system, the next only intended if the first was processed – which it was not due to lag in the whole chain).
    System gets kicked out but position remains. Now the first order at the broker comes through (all is buffered), the price is touched and you’re Flat. Now the second order comes through probably at the same price hence time – now you’re Short.

    Since Jun 17 (no setting any more for sustaining the position and position will always be cancelled by market order from PRT), System will be kicked out and position will be cancelled. Now first order comes through and you’re Short right away. Then second order comes through, and you’re Short by 2. This is what I expect – I never tested this.

    In all cases, this is what happens :

    1. You put a new pending order (in our example each second);
    2. The order needs to be confirmed by the broker. Note : if that won’t happen in time, your system will be kicked out.
    3. #2 does not happen, but you are in the next bar and again submit a pending order. You now formally have two pending orders.
    4. During the course of the 2nd bar (right after you submitted the order in the first bar), PRT will notice that there hasn’t been any confirmation (IB is too slow) and kicks you out.

     

    Do notice that as PRT user we think that we need to put a new Pending order each bar because else it automatically disappears, but this is not so; What happens in practice is that the earlier Pending Order is explicitly cancelled prior to obtaining (but read : submitting) the new Pending order (and this too requires conformation by the broker). Also : an order which formally has not been accepted at the exchange, can obviously not be cancelled. It is here where PRT detects the communication to be in error and kicks you out.
    Start up TWS, put on your headphones, and listen to what happens for real.

    Now let’s be honest and just observe what happens in practice. Btw, not in IB Papertrading of course;
    If you have a 1 second Pending Order system, it is very likely that in one minute you will at least see one time a longer or shorter delay. You can see this by the order label being greyed out for that while. The next part is easy : as soon as this delay takes more than one second, havoc is your share.

    I have the example with 1 minute systems just the same. And so much so, that it is not doable to have any such Pending orders within IB. Eventually they will all fail for this reason.
    Side note : around 6:30 Amsterdam, IB always resets. This often lasts less than one minute but it also can take longer. So there goes your one minute system. Out. But it needs to be in the trailing stage, obviously.
    This can, of course, be anticipated in the coding (don’t put pending orders around that time).

    Now please go ahead and have fun … 🙂

    07/04/2024 at 12:42 PM #234777
    JS

     “… this won’t sustain an hour…”

    I can only speak for my own systems and these have been running for months with no problems…

    “… and I meant a trailing of an hour in a row – thus 3600 times…”

    3600 times an hour???… Do you know how a trailing stop works…?

    07/04/2024 at 5:15 PM #234792
    PeterSt
    JS wrote:

    3600 times an hour???… Do you know how a trailing stop works…?

    I think I do, yes.
    But possibly you don’t;
    Your code provides a functional trailing stop. Not the Trailing Stop as how it can exist with PRT-IG. And thus :

    If your code would be able to sustain the trailing for an hour after it has begun (and does not stop in between), it would mean …

    60 times 60 new Pending Orders. Maybe that is not 3600 ?

    What I also suggested in the other thread is that a 1 second system won’t do much for trailing. Yea, trail at a mile distance maybe, but people tend not do do that. So maybe you have been looking very hard for 6 pending orders in a row which change the price each 1 second. But … you could not find that and showed rows of changed trail prices “once per x seconds” (which is more than one).
    What you do is change the trailing price now and then (once in a relative while). The effect ? your changed order has x seconds to be digested by the broker (and beyond). That is a lot more than one second (I hope you get the gist of that).
    So instead of me not knowing how a trailing stop works, you … bash as always. 🙁

    Now try to explain to us how a Pending Order which lasts for 1 second is going to bring benefit. No need to put forward sample code like you did. Just explain to us how that would work. Because remember, that is the context in that other thread.

    Maybe I can try something myself;

    So we have a price at 5 points distance of my trail(ing price). In the most common circumstances this range is covered in say 10 seconds (or much more). So my trailing price at 5 points distance will never catch the falling price within the 1 second this pending order lasts.
    The price goes up, and my trailing price goes up equally (or maybe parabolic, but this is not related for now). Next bar ? same problem. It is useless.

    Alternatively we have a price at 0.5 points distance. Ah, now we’re talking because the price easily changes 0.5 points in 1 second. All good. So price moves up with 0.5 points, and so will my trail ? Yeah, in your dreams that is, because no price will move up 0.50 points while not going down again 0.75 points or more in that same 1 second (and up again). This is to be read as :
    Your trail won’t do a thing because it always goes out right away at this small distance. See picture below (step is 0.25, time span is just over 1 second).

    Maybe if you set the distance at 1.5 point, which normally is not met (say downwards) then you could hope for that spike down. But your hope is not worth much, because before that spike occurred, the price will just have gradually dropped and out you are. The trailing again does nothing.
    Think of this last sentence please. This suggests trailing as how trailing normally works. This is not what you do in your program – there you shut it off. So no spike down will fall in any pending order. You thus do something else to get out. Also see your last picture and the 1 minute elapse time before you go out there. How ?? I like to learn.

     

    Might you not get it in full yet – compare with a 1 minute system and a similar trailing means (may also be the real one from PRT-IG). Now things suddenly *do* work. Or does this need extra explanation ? Here too you may not always re-do the pending order. But when you do, now at least the pending order has a chance to catch the price.

    07/04/2024 at 5:40 PM #234794
    PeterSt

    Let me add this for hopefully better clarification :
    Of course it is not about 3600 subsequent pending orders. But with a decent trailing it’s dozens and dozens per Trade and all together such a “close” trailing system will fail. But it depends on the distance of the next order.
    As pointed out, with a one second system this leads to nothing beneficial (IMO). But with 3 seconds it already starts to work. Now we may both try to envision how many subsequent orders (thus now once per 3 seconds a new one), will occur in a row. The price should rise from say open to open “always” and this can happen for a few minutes in a row. All this time IB must respond (and execute all, also in the upward chain) now within 3 seconds. It still is so that you will see this this greyed out order label regularly. Until it one time lasts too long and PRT kicks you out.

    Of course it is so that uncountable means of “trailing” exist, and the one is more efficient on this than the other. You could say that mine are quite efficient for the 1 second systems because, well, they don’t apply pending orders, because why (see previous post). And at this short distance, trailing is not even beneficial. Just go out at the target brings more. But to each his own (thinking), though it is all part of the “gist”.

    What would be helpful is adding some graphs to whatever sample program, and show how the trailing benefits with the 1 second system. Don’t ask me to do it, because I can’t.
    And please remember what this is about : hand a sufficient amount of orders to IB so that eventually it will choke. Not because you provide so many orders, but because in say 3600 orders one will hang for a too long while because IB can’t provide a consistent continuous processing stream (this is not about the data which is not IB’s in the first place).
    You don’t need to show the program, just how the trailing behaves and what makes it go out. Example below (but denote which line is what). Small example of that in 2nd pic.

     

  • Author
    Posts
Viewing 6 posts - 1 through 6 (of 6 total)

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
buy on certin dates, not on technical singal
buy on retest on a certain candle
checking the larger timeframe trend in lower timeframe
does sest stop trailing command work in real?
guaranteed trailing stop with indicator
moving stop loss once based on condition
multiple entry executions but only trailing sl on one
sell at x stop / exitshort at x stop for a specific quantity
simplified trailing stop
slow order management automated trading 1 second timeframe

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