GMT to Server - page 3

New comment
 
Fernando Carreiro:

Better read the documentation again:

You could say that it is most accurate during the initial stages of the OnTick() event, but it becomes more stale the longer you are execution.

If your OnTick() is so long then update your data.

Anyway how is it related to the initial calculation ?

Besides, @whroeder1 calculations have to be valid not matter where it runs be it in OnInit, OnTimer, OnStart, OnChartEvent, etc.

So what ?

 
Alain Verleyen:

If your OnTick() is so long then update your data.

Anyway how is it related to the initial calculation ?

So what ?

Lets say that exactly at 22:59:58 local time and 23:59:58 server time a new bid tick price is sent out by the server to the clients. However, due to network delays, it only arrives 15 seconds later.

So, as the OnTick() is triggered, the local time is now 23:00:13, but server time is reported as 23:59:58.

However, due to very bad code in the processing, your code takes another 3 seconds before it reaches the code that handles this calculation. By then local time is 23:00:16.

So the calculation is now working with the server time of 23:59:58 (still has not changed as no new ticks have arrived) and a local time of 23:00:16.

@whroeder1's calculation handles both the network jitter (irregularity of packet arrivals) as well as processing delay or even local clock being improperly setup or out of sync with NTP server.

One way that MetaTrader could have corrected this issue, was to have created a local “internal” clock that would be adjusted and corrected to be in sync with the server clock, much like a NTP service.

Since they did not do that, one could also create the code to do just that, and in this way have an internal continuous clock representing the server time.

However, @whroeder1's solution of rounding, I believe is more than sufficient to work around most of these problems (no matter where in the code it is used), without the need to create our own internal server clock.

I hope my explanation is sufficiently clear now!

 
Fernando Carreiro:

Lets say that exactly at 22:59:58 local time and 23:59:58 server time a new bid tick price is sent out by the server to the clients. However, due to network delays, it only arrives 15 seconds later.

So, as the OnTick() is triggered, the local time is now 23:00:13, but server time is reported as 23:59:58.

However, due to very bad code in the processing, your code takes another 3 seconds before it reaches the code that handles this calculation. By then local time is 23:00:16.

So the calculation is now working with the server time of 23:59:58 (still has not changed as no new ticks have arrived) and a local time of 23:00:16.

@whroeder1's calculation handles both the network jitter (irregularity of packet arrivals) as well as processing delay or even local clock being improperly setup or out of sync with NTP server.

One way that MetaTrader could have corrected this issue, was to have created a local “internal” clock that would be adjusted and corrected to be in sync with the server clock, much like a NTP service.

Since they did not do that, one could also create the code to do just that, and in this way have an internal continuous clock representing the server time.

However, @whroeder1's solution of rounding, I believe is more than sufficient to work around that most of these problems (no matter where in the code it is used), without the need to create our own internal server clock.

I really don't know why you are arguing.

  • I never said anything against WHRoeder implementation. It's correct.
  • Your "jitter" argument is also correct but negligible (by the way you changed your definition of jitter in the middle of the discussion).
  • Your network delay is also valid, but you didn't add anything new as I already said TimeCurrent() should not be used for the envisaged calculation.

EDIT: I will not make a study to measure all implied time and prove that your jitter is statistically negligible compared to out of sync computers time. I already know it is, you will always find case where it is not.

EDIT2: I wish you a good night.

 
Alain Verleyen:

I really don't know why you are arguing.

  • I never said anything against WHRoeder implementation. It's correct.
  • Your "jitter" argument is also correct but negligible (by the way you changed your definition of jitter in the middle of the discussion).
  • Your network delay is also valid, but you didn't add anything new as I already said TimeCurrent() should not be used for the envisaged calculation.
  1. We are not arguing, but discussing our views.
  2. Written text discussions can sometimes be ambiguous and misinterpreted, and sometimes we need to say something in different terms in order for the concept to be understood by the other person.
  3. "Jitter" is defined as the delay or irregularity of arrival or processing of network packets, but the concept has been expanded to be used for several fields, not just network communications.
  4. I don't agree that "jitter" or the irregular arrival of network packets is negligible, and have already given proof of that. Obviously if you don't agree, that is up to you. If you think that the other reasons are more prevalent that is OK.
  5. TimeCurrent() is the ONLY function we have at our disposal to be able to acquire information on the Date/Time of the server and its incoming ticks. Obviously using the time in the MqlTick structure is equivalent to that. So if you say "TimeCurrent() should not be used for the envisaged calculation", then please tell us what SHOULD be used instead of TimeCurrent()!
 

Hey guys, 


Thanks for taking the time to explain to me the issue of having two separate clock times. You would think that the platform would take care of that automatically and sync the server time to the pc clock and then update the platform as synchronized times... but now I understand the issue, and I like whroeders implementation of the rounding to compensate. I'm glad I got to participate in this discussion, and I've got some libraries to go fix :-p

 
nicholishen: Thanks for taking the time to explain to me the issue of having two separate clock times. You would think that the platform would take care of that automatically and synch the server time to the pc clock and then update the platform as synchronized times... but now I understand the issue, and I like whroeders implementation of the rounding to compensate. I'm glad I got to participate in this discussion, and I've got some libaraies to go fix :-p
You are welcome, but just a wait a little longer because @Alain Verleyen suggests that there might be an alternative to the use of TimeCurrent(). I don't know what it is, but maybe it could offer a better solution!
 
Fernando Carreiro:
You are welcome, but just a wait a little longer because @Alain Verleyen suggests that there might be an alternative to the use of TimeCurrent(). I don't know what it is, but maybe it could offer a better solution!

To be honest, this formula takes so little resources to implement in the initialization of time off-set that I don't even want to take the slightest risk of not using it. I was wrong and I made my initial statement on a bad assumption. 

 
nicholishen: To be honest, this formula take so little resources to implement in the initialization of time off-set that I don't even want to take the slightest risk of not using it. I was wrong and I made my initial statement on a bad assumption. 
No problem! The other day I learned something new from you! Today you learned something new from us.
 
Fernando Carreiro:
  1. We are not arguing, but discussing our views.
  2. Written text discussions can sometimes be ambiguous and misinterpreted, and sometimes we need to say something in different terms in order for the concept to be understood by the other person.
  3. "Jitter" is defined as the delay or irregularity of arrival or processing of network packets, but the concept has been expanded to be used for several fields, not just network communications.
  4. I don't agree that "jitter" or the irregular arrival of network packets is negligible, and have already given proof of that. Obviously if you don't agree, that is up to you. If you think that the other reasons are more prevalent that is OK.
  5. TimeCurrent() is the ONLY function we have at our disposal to be able to acquire information on the Date/Time of the server and its incoming ticks. Obviously using the time in the MqlTick structure is equivalent to that. So if you say "TimeCurrent() should not be used for the envisaged calculation", then please tell us what SHOULD be used instead of TimeCurrent()!

Sorry, bad English.

I mean continue a discussion when there is nothing to discuss. Also there is nothing to agree or disagree.

I can imagine you want to know what to use instead of TimeCurrent(), my answer is : "Please show us your code if you need coding help".


 
Alain Verleyen: I mean continue a discussion when there is nothing to discuss. Also there is nothing to agree or disagree.

I can imagine you want to know what to use instead of TimeCurrent(), my answer is : "Please show us your code if you need coding help".

I sometimes don't understand you! You can't mix "humor" and "serious" together and hope that reader is able to distinguish between the two without being offended. You have to be clear!

You yourself, just stated that I mixed definitions mid post and that was causing confusion. So I say the same, you can't just state "I already said TimeCurrent() should not be used for the envisaged calculation" in the middle of a serious post and hope that we take just take that part as humor.

Please, that was not very nice of you to do, because it is misleading. So please I ask again in order to get a very clear and serious answer!

Is there or is there not an alternative to the use of TimeCurrent()?

EDIT: If you say, creating your own internal synchronised, continuous, server clock then that, I have already stated that. If on the other-hand I have caught you out on a lie, then please be man enough to admit it. There will be no ill feelings.

123456
New comment
Reason: