This is a fairly complicated question! Given my understanding of destiny ticks, the way this would go is the following: (disregarding latency for the moment)
- Ship decloaks, SRT timer started
- During the timer, whenever you send a lock request the server looks at it and says “no, can’t do this yet” and notifies you of this fact on the next tick (you can see this yourself by spamming lock requests on a thing during SRT and watch the notification flash once per second, at the tick rate)
- After 4.5 seconds the server now knows that it can accept new lock requests, it queues a task to notify the client of this on the next tick, but you can still send the command in earlier and it will accept it
- Assuming you get a command into the queue immediately to begin locking then the locking process will start immediately and run for its duration, in this case 3.2s, notifying your client of a successful lock after 4 ticks (however you receive a packet asap notifying you that locking has started)
So in a sense this stuff isn’t necessarily dragged out to longer lengths because of the ticks - that’s just when you are notified of things happening. However add in latency and human reaction times and this will likely be slightly longer - and then if you’re looking to scram the target there’s some more complicated work to be done in terms of assessing your target’s warp versus when your scram activates.
Exactly how server / destiny ticks work is a bit more complicated. If you want to dig into the mechanics, this article [Understanding EVE Online Server Tick] is based off of a talk CCP Veritas gave some time ago in which he explained the system in more detail.
Disclaimer: this isn’t something I’ve played with on the code side all that much, but not everything is rounded up to the next tick (exactly)