-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testing two raspberry pi #17
Comments
Simone, this looks like A better example to work from would be |
Yes, I simplified the I didn't try using Thank you for your patience |
I just wrote a better example for you, at https://github.com/camilleg/clockkit#to-sync-host-b-to-host-a. Does that work on your network? |
I have just tried the new example but unfortunately it still is not working properly. The scripts communicates with each other but these are the output I get from the server:
And from the client:
Note that I changed also PCs and now the two IPs are 192.168.88.15 and 192.168.88.238. Could this be caused by my local timezone? Is there antrhing I can debug further more to check what is causing my issue? Running Thank you for your time. |
These raspberrypi/pico-sdk#27 (comment) It's sometimes broken elsewhere, more subtly: If your gettimeofday is indeed unreliable, and your build platform has https://en.cppreference.com/w/cpp/chrono/system_clock, then I could send you an experimental build using the latter. |
SystemClock.cpp:
FYI, if here I replace |
I may have found out the issue. I created a test script on my raspberry that looks like this:
And there are actually some strange behaviours. On my pc, all the three values are the same:
While on the raspberry the values are quite different:
This evening and tomorrow morning I'll try to implement it on library. PS: changing PPS: the issue seems to be with
While the client keeps giving me this error:
I'll test more in detail tomorrow morning. |
From your experiments, I'm strongly inclined to replace the brittle gettimeofday() with system_clock::now().time_since_epoch()/1us, for reliability across platforms. A stark contrast between the two in online bug reports: the latter tend to be both many years old and spurious. |
I have more results. I changed the original SystemClock.cpp to:
If I run the server on my RPi and the phaselock on my PC, the server prints a correct time stamp while the phase lock gives a huge value as in the previous examples. I'm now trying to follow the printing of the phaselock script to find why its timestamp is broken. |
I added this line of cout debug in ClockClient.cpp:
And this is the output of lockphase:
I found out that the value -9223372036854775808 is a common way for the compiler to indicate an overflow value. Do you have any idea why this is happening? The server side confirm this theory of the phase lock timestamp being off, since the input packet has this as print:
|
9223372036854775807 is printed by But you see minus ... 808 instead of +...807 , which is -2^63. Would it be useful or valid for me to try reproducing this with an RPi emulator? (I don't have hardware.) |
I replaced Do you think the problem might be related to the system being 32bit (armv7l)? If that's the case, a 32bit emulator might be the right tool. Anyhow, is it correct that the phase lock sends two packet per time as in my previous message? What I am not understanding is why the first timestamp is always correct while the second one most of the time is wrong. |
That CPU's 32bitness shouldn't matter. This code ran on only 32-bit hosts for many years (in 2004, 64-bit desktops were only starting to appear). You understand the packet handshaking ok, as in the top of ClockPacket.h: cli sends REQUEST, srv replies with REPLY, cli repllies with ACKNOWLEDGE. I'm still puzzled. Yes, let's work backwards from the printed numbers that look wrong. Is there something like a cloud service where I could ssh to an RPi, install clockkit, and experiment myself for a few hours? Or should I just buy a used RPi on ebay? RPi 3? Zero? |
I tested both from my PC to another linux machine, and everything works fine. I also tested using a arm32v7 docker image, and it also works fine. I'm doing tests with both a RPi 4 and a TinkerBoard module but they both share the same behaviour. They give the same output even when the server is not running so it makes me think it's some communication related issue (however, setting a timeout in phaselock results in the server shutting down after that time, so some kind of communication is still happening). |
OK I might have found the issue. This is the normal PhaseLock script output with DEBUG defined in ClockClient.cpp:
Compared with the RPi one:
My understanding is that the RPi one is for some reason out of sync. I'm now trying to understand why |
I solved my issue. I didn't understand that timeout in my-clockkit.conf was expressed in us and not in ms. I had a ping of 6ms with the RPi, so it kept giving me a timeout. Thank you for your time and patience and I'm sorry for my misunderstanding. |
The config files can now include comments. I've added comments there, so others don't fall into the same misunderstanding. |
Hi everyone,
I'm was looking for a library to sync two raspberry pi in a local network and I have found this one which looks very promising.
I tried to check the delay between two computers using this custom script for the client:
And running the ClockServerMain.cpp executable on the other PC.
However, this is the output I get:
When I run the same script locally, the offsets and RTT times are reasonable:
Could you please help me to find out what am I doing wrong?
Thank you for your time,
Simone
The text was updated successfully, but these errors were encountered: