Skip to content
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

When running -8 option for direct Ethernet (802.1AS compliant) encapsulation, ptpv2d does IPv4 Multicast group join #1

Open
GoogleCodeExporter opened this issue Jan 20, 2016 · 4 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. run ptpv2d with -8 option
2. run Wireshark or other LAN analyzer
3. observe IPv4 Multicast join packets sent on network

What is the expected output? What do you see instead?

A) It would be better that if the encapsulation selected is Direct Ethernet 
that no IPv4 packets are generated.

Please use labels and text to provide additional information.

1) In the case of the -8 option, it would probably be better if only a raw 
socket was opened and the opening of IPv4 UDP sockets was skipped.  This would 
avoid the Multicast join message being generated and also would make it so that 
IPv4 packets would be ignored.
2) Downside is that I had some thoughts about allowing future versions of 
ptpv2d auto-detect the best grandmaster regardless of protocol type and then 
adapt to it.

Comments and thoughts on this are welcome.

This bug is mostly cosmetic.

Original issue reported on code.google.com by a...@bartky.net on 28 Aug 2010 at 5:23

@GoogleCodeExporter
Copy link
Author

What is the time precision for this source code running in Windows? I found 
that it seems more than 15ms?

Original comment by mcw...@gmail.com on 14 Apr 2011 at 9:51

@GoogleCodeExporter
Copy link
Author

When it comes to precision on my Windows portation, I did not do anything
special when it comes to time adjustment and time accuracy.  

I did not have any experience in doing a Winsock application as this is the
first one I've ever done.

With that, when it came to both socket application and getting/setting time
from the operating system, I did the best I could.

So I'm not surprised that the accuracy is less than Linux as from what I
could tell, standard Windows calls for getting/setting time are not very
accurate.

If you know of a better way that time could be measured and set, I'd be open
to porting it into the code.

Alan

Original comment by a...@bartky.net on 16 Apr 2011 at 8:51

@GoogleCodeExporter
Copy link
Author

Hi Alan

Thank you for your attention~ I tried to use PTPV2D on the WIndows XP. I found 
some problems as following:

1) I run PTPV2D on 2 computers. After that, according to the debug message of 
msgUnpackV2Header, the time is synchronized. Which API or method is expected to 
use for getting the time which are synchronized? 
- getTime(TimeInternal *time, Integer16 utc_offset)?
- GetSystemTimeAsFileTime?
- etc?

2) When the time is synchronized by using PTPV2D, the system clock will not be 
adjusted(changed) by PTPV2D program . How can I let the program to set the 
system clock in order to let the system clock are synchronized between 2 
computers.

I found that the void updateClock(RunTimeOpts*,PtpClock*) in ptpd_dep.h without 
called.

Original comment by mcw...@gmail.com on 18 Apr 2011 at 4:17

@GoogleCodeExporter
Copy link
Author

MCW, comments edited in below.

If you are a member of the ptpv2d google group, please use the ptpv2d group
instead of the issues page on code.google.com.

Original comment by a...@bartky.net on 23 Apr 2011 at 10:55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant