Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
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?
Can you help answer these questions from other members on NexusFi?
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
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 !
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
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 !
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.
