Yes it is, but my clock is always very close. D4 shows you how much it moves the clock, and I never see more than very small fractions of a second, which is close enough for most things. Running your new GomTimeMeasure, it stays rock solid at <= 30ms delay. Good enough for me.
With that said, I am going to check out the NTP V4 though.
I assume you are looking at this to improve your GomRecorder?
Yes I was trying to see if the network latency is constant so I coould use System.Now as a time source to generate millisecond files. In my case it is not constant at all.
Please keep in mind that the indicator's meaningful value is when you see the values changing, so it gives you an indication of network lag increasing and decreasing, but the absolute number is meaningless unless you gave a good local clock precision (hence the NTPV4 stuff).
For instance, if your clock is 3 sec late, and the delay between the exchange and yourself is 3 sec, the indicator will show 0, even when in fact you're getting the ticks with 3 second lactency.
If your clock is 3 seconds ahead, and the network latency is 0 ms, the indicator will always show a delay of 3000 ms even when in fact you're getting your ticks in real time.
So I think there is a real use to get the clock of the PC at the best possible accuracy.
gomi, you should call up or email Ray @ NT and ask him to hire you. I know your not solely in it for the money, based simply on how much you've given away to the community for free. And I know you don't have gobs of free time. But I think there is a possibility for a good compromise, and you could only benefit their team with your experience
Due to time constraints, please do not PM me if your question can be resolved or answered on the forum.
Need help? 1) Stop changing things. No new indicators, charts, or methods. Be consistent with what is in front of you first. 2) Start a journal and post to it daily with the trades you made to show your strengths and weaknesses. 3) Set goals for yourself to reach daily. Make them about how you trade, not how much money you make. 4) Accept responsibility for your actions. Stop looking elsewhere to explain away poor performance. 5) Where to start as a trader? Watch this webinar and read this thread for hundreds of questions and answers. 6) Help using the forum? Watch this video to learn general tips on using the site.
If you want to support our community, become an Elite Member.
I'm curious what the limitation is of NTPV3? I read a theoretical limitation but in real concrete numbers. My PC clock was off several seconds and that messed up my chart markers. Now with dimension 4 my chart markers are never off. So I think it's within a second which is "good enough" for me. But I'm curious how much better this other solution could be.
They just weren't listening, and Dierk posted a message stating
"You are incorrect in your understanding. It's very simple to calculate the Begin/EndTimeLocal from the Begin/EndTimeExchange, the actual date is totally irrelevant. Just DayOfWeek matters. You will see with NTB5."
He withdrew his message, and what we actually saw in NTB5 was the implementation I had been asking for during the whole thread.... No apology, no thank you, no nothing...
So they are not really on my employer wishlist... I've had my lot of non-listening people !
Nah, I'm on bigmike for the ego soothing ;-) Thanks guys !
Last edited by gomi; May 17th, 2010 at 08:39 AM.
The following 4 users say Thank You to gomi for this post:
From what I've read NTPV4 is 10x more precise than NTPV3
NTPV3 on a WAN will give you accuracy ranging from a few 10s to a few 100s of millisecs
NTPV4 on a WAN will give you accuracy ranging from a few to a few 10s of millisecs.
With NTPV3 you clock drifts between updates, and the updates are made using "steps" . With NTPV4 you clock frequency is modified to compensate for drifts, clock modifications < 128 ms are smooth
The following 3 users say Thank You to gomi for this post:
Little upgrade on the topic. Here's how my clock is doing.
As you can see, for now the algo isn't making my offset converge.
Offset is the measure you're interested in, because it indicates the error between the local clock and the estimated global NTP time( time of servers with * or + on the NTP status)
What I know though is that my time is somewhere between +20/-20 ms of the estimated time. I want better !
The following user says Thank You to gomi for this post:
I have been running with NTP for a couple of days now, and I have to say that my clock may or may not be more accurate than it was with D4.
Using D4, it was routinely within 5 ms (based on how much it was adjusted). For me, D4 usually was only moving the clock 1 or 2ms, and never had big adjustments.
Running NTP, the stats summary routinely shows the offset to be up to 50ms off, and it moves around during the day from being on to being off again. Using the GomTimeMeasure comfirmed this, as the delay would move all over the place during the day with NTP (although it was bounded to reasonable values), and with D4 it remained relatively stable. I have let it run for a long time to make sure it was stable, and have used very good local servers.
I know NTP can be better, but I guess I am just pointing out that it may not be.