I have read quite a bit about NTP and PTP time keeping protocols. While many sources claim that PTP is more precise than NTP for that type of granularity - the reason is not as clear. Why can't NTP be just as accurate if a stratum 0 reference clock is atomic from GPS and network delays are accounted for? A paper on the FSMLabs site, in fact, claims that if both protocols are implemented well (as in TimeKeepeer they say), they can both deliver similar precision - and that it really boils down to the ability to stamp time in hardware to better account for jitter in switches, routers, and operating systems.
I can check gstack, but just because I see the listener threads on the recv call does not mean that call is not returning. One other thing I thought was to do something like:
netstat -lupe | grep <PROCESS_PID>
to check the inodes of the sockets listening via udp. Then possibly try watching (watch command) what /proc/net/udp says about the receive and transmit queues of those inodes. I'm not sure if this is a good way to diagnose this, however. Trying to listen to the same multicast groups to check for data coming in is also not really a guarantee that the process in question is receiving it.
What are some other ways or things I could probe or try?
I often have to debug processes which involve a server client tcp connection. I'd like to check, during times where a client might seem stuck, whether the server is sending it data or not. I can use:
'netstat -tpe | grep PID_SERVER'
to find the socket for the server, or 'netstat -tlpe | grep PID_CLIENT' to find that of the client. Is there a way to further inspect that particular socket once I identify it? Other than just its State? I feel like Recv-Q or Send-Q might be useful though I'm not sure what it refers to - but in addition to that, what else can I use to diagnose what is going on between them? Was thinking, possibly something in /proc/PID/fd?
Any insight would be appreciated...