PTPD2 daemon

Anonymous
2012-04-18
2013-04-12
  • Anonymous

    Anonymous - 2012-04-18

    I can't put ptpd2 daemon as background process, and can test on foreground only, please help

    here is foreground command
    Master : ptpd2 -G -U -B -cC
    Slave : ptpd2 -g -cC

     
  • George Neville-Neil

    What version of the code are you running?

    What OS are you running it on?

     
  • Matt Garman

    Matt Garman - 2012-04-24

    I seem to be having the same problem.  I'm using ptp-2.2.0 on Linux (CentOS 5.7) on x86 platform.

    If I don't use the "-c" parameter, ptpd2 exits immediately (with return code 0).

    Thoughts?

    Thanks!
    Matt

     
  • Matt Garman

    Matt Garman - 2012-04-24

    Hrm, here's some more information.  When I try to manually start ptpd2 without -c, for example

    /usr/local/sbin/ptpd2 -g -d -f /tmp/ptpd2.log -b eth0
    

    I get this in /var/log/messages:

    Apr 24 16:47:17 lnxbackup1 ptpd2: Starting ptpd2 daemon with parameters:      /usr/local/sbin/ptpd2 -g -d -f /tmp/ptpd2.log -b eth0  
    Apr 24 16:47:17 lnxbackup1 ptpd2:   Info:    Going to check lock /var/run/kernel_clock 
    Apr 24 16:47:17 lnxbackup1 ptpd2:   Info:    No ptpd daemons detected in parallel (as expected) 
    Apr 24 16:47:17 lnxbackup1 ptpd2:   Info:    No ntpd daemons detected in parallel (as expected) 
    Apr 24 16:47:17 lnxbackup1 ptpd2:   Info:    Now running as a daemon 
    Apr 24 16:47:17 lnxbackup1 ptpd2:   Info:    Going to check lock /var/run/kernel_clock 
    Apr 24 16:47:17 lnxbackup1 ptpd2: Multiple instances of this daemon detected (Use option -L to ignore lock file /var/run/kernel_clock)
    

    I'm not sure where that /var/run/kernel_clock file comes from--presumably from the ptpd2 daemon itself, yet the daemon isn't running.  So, for example:

    # cat /var/run/kernel_clock 
    21160
    # ps ax | grep 21160 | grep -v grep
    # ps ax | egrep -i "(ntp|ptp)" | grep -v grep
    

    If I delete that /var/run/kernel_clock file, then again try to run ptpd2, I get the exact same result.

    On another machine, I sourced the "/etc/init.d/functions" file (provided by my Linux distro, CentOS 5.7), and was able to run it via the "daemon()" function:

    # source the function file
    . /etc/init.d/functions
    daemon /path/to/ptpd2  -g -d -f /tmp/ptpd2.log -b eth0
    

    But as far as I can tell, all the "daemon()" function does is just invoke bash.  E.g. what I did above is more or less the same as "/bin/bash /path/to/ptpd2  -g -d -f /tmp/ptpd2.log -b eth0".

    And at any rate, now trying this on another server, it's still not working… IOW, I'm not sure what I did to get it running on the other server!

     
  • George Neville-Neil

    It sounds like there is a problem with the code that was added to make sure there was only one ptpd running at a time.  Can you run strace your binary so that we can see what files are being accessed?

     
  • Matt Garman

    Matt Garman - 2012-04-26

    Here's an strace from a failed run.  FWIW, after more experimentation, using the "daemon()" bash function isn't actually all that helpful--I think I just got lucky on by using it once or twice.

    execve("/usr/local/sbin/ptpd2", ["/usr/local/sbin/ptpd2", "-g", "-d", "-f", "/tmp/ptpd2.log", "-b", "eth0"], [/* 23 vars */]) = 0
    brk(0)                                  = 0x2233000
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b5833e71000
    uname({sys="Linux", node="lnxbackup1", ...}) = 0
    access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
    open("/etc/ld.so.cache", O_RDONLY)      = 3
    fstat(3, {st_mode=S_IFREG|0644, st_size=100543, ...}) = 0
    mmap(NULL, 100543, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b5833e72000
    close(3)                                = 0
    open("/lib64/libm.so.6", O_RDONLY)      = 3
    read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`>\340:?\0\0\0"..., 832) = 832
    fstat(3, {st_mode=S_IFREG|0755, st_size=615136, ...}) = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b5833e8b000
    mmap(0x3f3ae00000, 2629848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3f3ae00000
    mprotect(0x3f3ae82000, 2093056, PROT_NONE) = 0
    mmap(0x3f3b081000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x81000) = 0x3f3b081000
    close(3)                                = 0
    open("/lib64/librt.so.1", O_RDONLY)     = 3
    read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \"\200d1\0\0\0"..., 832) = 832
    fstat(3, {st_mode=S_IFREG|0755, st_size=53448, ...}) = 0
    mmap(0x3164800000, 2132936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3164800000
    mprotect(0x3164807000, 2097152, PROT_NONE) = 0
    mmap(0x3164a07000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x3164a07000
    close(3)                                = 0
    open("/lib64/libc.so.6", O_RDONLY)      = 3
    read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\332\241:?\0\0\0"..., 832) = 832
    fstat(3, {st_mode=S_IFREG|0755, st_size=1718120, ...}) = 0
    mmap(0x3f3aa00000, 3498328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3f3aa00000
    mprotect(0x3f3ab4e000, 2093056, PROT_NONE) = 0
    mmap(0x3f3ad4d000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14d000) = 0x3f3ad4d000
    mmap(0x3f3ad52000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3f3ad52000
    close(3)                                = 0
    open("/lib64/libpthread.so.0", O_RDONLY) = 3
    read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240W`;?\0\0\0"..., 832) = 832
    fstat(3, {st_mode=S_IFREG|0755, st_size=145824, ...}) = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b5833e8c000
    mmap(0x3f3b600000, 2204528, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3f3b600000
    mprotect(0x3f3b616000, 2093056, PROT_NONE) = 0
    mmap(0x3f3b815000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x3f3b815000
    mmap(0x3f3b817000, 13168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3f3b817000
    close(3)                                = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b5833e8d000
    arch_prctl(ARCH_SET_FS, 0x2b5833e8d460) = 0
    mprotect(0x3f3b815000, 4096, PROT_READ) = 0
    mprotect(0x3f3ad4d000, 16384, PROT_READ) = 0
    mprotect(0x3164a07000, 4096, PROT_READ) = 0
    mprotect(0x3f3b081000, 4096, PROT_READ) = 0
    mprotect(0x3f3a81b000, 4096, PROT_READ) = 0
    munmap(0x2b5833e72000, 100543)          = 0
    set_tid_address(0x2b5833e8d4f0)         = 7377
    set_robust_list(0x2b5833e8d500, 0x18)   = 0
    futex(0x7fffa6e0adfc, FUTEX_WAKE_PRIVATE, 1) = 0
    rt_sigaction(SIGRTMIN, {0x3f3b605380, [], SA_RESTORER|SA_SIGINFO, 0x3f3b60eb10}, NULL, 8) = 0
    rt_sigaction(SIGRT_1, {0x3f3b6052b0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x3f3b60eb10}, NULL, 8) = 0
    rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
    getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
    brk(0)                                  = 0x2233000
    brk(0x2254000)                          = 0x2254000
    open("/etc/localtime", O_RDONLY)        = 3
    fstat(3, {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    fstat(3, {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b5833e72000
    read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"..., 4096) = 3543
    lseek(3, -2264, SEEK_CUR)               = 1279
    read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\6\0\0\0\0"..., 4096) = 2264
    close(3)                                = 0
    munmap(0x2b5833e72000, 4096)            = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    socket(PF_FILE, SOCK_DGRAM, 0)          = 3
    fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
    connect(3, {sa_family=AF_FILE, path="/dev/log"...}, 110) = 0
    sendto(3, "<30>Apr 26 15:46:19 ptpd2: \n", 28, MSG_NOSIGNAL, NULL, 0) = 28
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    sendto(3, "<30>Apr 26 15:46:19 ptpd2: Start"..., 126, MSG_NOSIGNAL, NULL, 0) = 126
    geteuid()                               = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    sendto(3, "<30>Apr 26 15:46:19 ptpd2:   Inf"..., 80, MSG_NOSIGNAL, NULL, 0) = 80
    open("/var/run/kernel_clock", O_RDWR|O_CREAT, 0644) = 4
    fcntl(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0
    ftruncate(4, 0)                         = 0
    write(4, "7377\n\0", 6)                 = 6
    pipe([5, 6])                            = 0
    clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b5833e8d4f0) = 7378
    close(6)                                = 0
    fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b5833e72000
    read(5, "0\n", 4096)                    = 2
    close(5)                                = 0
    wait4(7378, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 7378
    --- SIGCHLD (Child exited) @ 0 (0) ---
    munmap(0x2b5833e72000, 4096)            = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    sendto(3, "<30>Apr 26 15:46:19 ptpd2:   Inf"..., 89, MSG_NOSIGNAL, NULL, 0) = 89
    pipe([5, 6])                            = 0
    clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b5833e8d4f0) = 7381
    close(6)                                = 0
    fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
    mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b5833e72000
    read(5, "0\n", 4096)                    = 2
    close(5)                                = 0
    wait4(7381, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 7381
    --- SIGCHLD (Child exited) @ 0 (0) ---
    munmap(0x2b5833e72000, 4096)            = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0
    sendto(3, "<30>Apr 26 15:46:19 ptpd2:   Inf"..., 89, MSG_NOSIGNAL, NULL, 0) = 89
    open("/tmp/ptpd2.log", O_RDWR|O_CREAT|O_APPEND, 0644) = 5
    dup2(5, 1)                              = 1
    dup2(5, 2)                              = 2
    clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b5833e8d4f0) = 7384
    --- SIGCHLD (Child exited) @ 0 (0) ---
    exit_group(0)                           = ?
    
     
  • Matt Garman

    Matt Garman - 2012-05-01

    Is the above strace helpful?  Can I post any more info to assist with the debugging of this issue?

    Thanks!

     
  • George Neville-Neil

    Sorry, but is this strace done with tracing the child process?  I see that the children exit but I don't see what they're doing.

    That's the -f option.

    Sorry this is taking a bit of back and forth.

     
  • Matt Garman

    Matt Garman - 2012-05-04

    Hi,

    I got an strace -f, but it's over 4000 lines.  I sent you a personal email with the strace attached.  Let me know if there's some other preferred way of delivering the massive strace.

    Thanks again!
    Matt

     
  • Matt Garman

    Matt Garman - 2012-05-18

    Any updates to this?

    Thanks!

     
  • Chris

    Chris - 2012-05-24

    Matt,

    I'm experiencing the same issue as you.  Have you had any luck with this since the 18th?

    Chris

     
  • Chris

    Chris - 2012-05-24

    For the benefit of anyone else looking at this, here's a pastebin url with the strace of running ptpd-2.2.0 with just the -g option:   http://pastebin.com/excehstG

    I looked in src/dep/startup.c, specifically at "check_parallel_daemons".  It seems strange to me that 1 or more instances would cause an error in this case as the code checking the number of instances is ptpd itself so how would this ever not happen?

    Chris

     
  • George Neville-Neil

    OK, I finally had a look at this.  Note that -c and -C both imply command line mode, which means no daemon, i.e. no background process.

     
  • Chris

    Chris - 2012-05-25

    The problem I'm experiencing doesn't involve either -c or -C as shown below:

    root /root# ps -ef |grep ptpd
    root      2320  2297  0 02:42 pts/0    00:00:00 grep ptpd
    root /root# ptpd -g
      Error:   1 ptpd daemon(s) detected in parallel, but we were not expecting any. Exiting.
    root /root#

     
  • George Neville-Neil

    Alright, I tested this briefly with the head of the tree, and with the tree in tags/ptpd-2.2.0, and I had no problems.  I tested on Ubuntu 12.  I started the daemon, checked syslog to see that it was happy, then killed it (with -9, and that would definitely show some sort of cleanup issue) and it restarted fine.

     
  • Martin Burnicki

    Martin Burnicki - 2012-05-28

    Recently a similar problem has been mentioned in an email to me. I've just submitted the proposed patch which sounds reasonable to fix this. Can you please check if the current SVN trunk version works properly?

     
  • Chris

    Chris - 2012-05-28

    I'm up and running now.  It was not actually the change that mburnicki committed but this commit gave me the key I needed.  I had renamed ptpd2 -> ptpd and this broke the functionality.  Now that I've renamed it back to ptpd2, I'm good.

    Regardless, the trunk commit looks to be a good one.

     
  • Matt Garman

    Matt Garman - 2012-05-29

    I haven't had a chance to check svn head yet, but: it looks like the recent patch (mburnicki) deals with the use of pgrep for finding an additional running process.

    However, in my case, it has to do with the lockfile /var/run/kernel_clock check failing.

    For me, I suspect it is some kind of race condition, because it is not consistent.  Sometimes it fails and some times it works (using exactly the same commandline parameters, same machine, etc).

    In startup.c, the deamon_already_running() function creates and locks the /var/run/kernel_clock file ("LOCKFILE").  In the ptpdStartup() function, daemon_already_running() is called twice.  The second time is after the call to daemon().  The comment says, "Second lock check, to replace the contents with our own new PID."

    I don't understand how the original lock is supposed to be released before being acquired by the child.  I believe this kind of timing situation might be consistent with the sometimes-works-sometimes-doesn't behavior I am seeing.

    -Matt

     
  • Matt Garman

    Matt Garman - 2012-05-30

    I put a hack in the 2.2.0 release version of daemon_already_running() (src/dep/startup.c).  The hack basically calls lockfile() in a loop.  If the call fails, it sleeps two milliseconds and tries again.  If it succeeds, the loop exits.  I also log how many attempts it took to acquire the lock.  In my case, I see the initial call acquiring the lock after one try, but the second (i.e. after the call to daemon()) consistently taking two tries.

    The other question I have about the same function: in the case that lockfile() fails, and errno is EACCES or EAGAIN, the lockfile is closed, and the function immediately returns 1, which short-circuits the logging.  The condition is already wrapped in a scope that will return 1… so it doesn't make sense to me why the logging would be skipped.

    Here's my hacked version of daemon_already_running().  I put a comment about the logging short-circuit in there as well.  Putting in sleeps feels kludgey, but I don't know the code well enough to come up with a more elegant solution.

    Any thoughts?

    int
    daemon_already_running(void)
    {
        char    buf[16];
        int     rc;
        int     i;
        struct timespec ts;
        INFO("  Info:    Going to check lock %s\n", LOCKFILE);
        global_lock_fd = open(LOCKFILE, O_RDWR|O_CREAT, LOCKMODE);
        if (global_lock_fd < 0) {
            syslog(LOG_ERR, "can't open %s: %s", LOCKFILE, strerror(errno));
            PERROR("can't open %s: %s", LOCKFILE, strerror(errno));
            exit(1);
        }
        for (i=0; i<5000 && (rc=lockfile(global_lock_fd))<0; ++i) {
            ts.tv_sec = 0; ts.tv_nsec = 2000000; /* two milliseconds */
            nanosleep(&ts, NULL);
        }
        if (rc < 0) {
            if (errno == EACCES || errno == EAGAIN) {
                close(global_lock_fd);
                return(1); /* should the logging be short-circuited here? */
            }
            syslog(LOG_ERR, "can't lock %s: %s", LOCKFILE, strerror(errno));
            PERROR("can't lock %s: %s", LOCKFILE, strerror(errno));
            return(1);
        }
        else {
            INFO("  Info:    Lock acquired after %ld tries\n", (i+1));
        }
        ftruncate(global_lock_fd, 0);
        sprintf(buf, "%ld\n", (long)getpid());
        write(global_lock_fd, buf, strlen(buf)+1);
        return(0);
    }
    
     
  • Wojciech Owczarek

    I'd probably use usleep just for simplicity (no need for timespec).

    However, In my own testing I incorrectly assumed that the lock just wasn't being inherited rather than a retry was needed, so as a workaround I simply added a daemon mode check in the first and second lock attempt which results in:

    - if running in non-daemon mode, acquire the lock straight away,
    - if running in daemon mode, acquire lock only after daemon().

    Would this not be sufficient? OK, the goal is to lock as early as possible, but does the time it takes to background, really matter that much compared to the time between daemon startup and first locking attempt?

    Thanks
    Woj

     
  • Wojciech Owczarek

    Right, I think there's a more elegant solution to this. When we fork we can't re-acquire the lock until the parent process is alive, which can take a moment such as in your and my case. I've just committed a fix in svn 229, so please test if you can.

     
    • Matt Garman

      Matt Garman - 2013-03-01

      Hi, I finally got around to testing the latest ptpd2 from svn (revision 309, last change date 2013-02-26). I still have the same issue as before:

      Mar  1 09:13:32 lnxsvr18 ptpd2: === PTPDv2 version 2.3.0-svn starting
      Mar  1 09:13:32 lnxsvr18 ptpd2: 
      Mar  1 09:13:32 lnxsvr18 ptpd2: Starting ptpd2 daemon with parameters: /usr/local/sbin/ptpd2 -g -b bond0
      Mar  1 09:13:32 lnxsvr18 ptpd2:   Info:    Going to check lock /var/run/kernel_clock
      Mar  1 09:13:32 lnxsvr18 ptpd2:   Error:   1 ptpd2 daemon(s) detected in parallel, but we were not expecting any. Exiting.
      Mar  1 09:17:54 lnxsvr18 ptpd2:
      
       
  • George Neville-Neil

    Hi,

    I just tested this on

    Linux ubuntu 3.2.0-38-generic #61-Ubuntu SMP Tue Feb 19 12:18:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

    and had no problems. There was an error in the code that was preventing the program from running, but you didn't see a core dump in your case did you?

    The checked in code as of svn revision 310.

    Note well that we have switched to autoconf/automake in the trunk of our tree, so you'll need to :

    cd trunk/
    autoreconf -vi
    ./configure
    cd src
    make

    to get the current daemon to build. Please let me know if you continue to see the same problem.

     
    • Matt Garman

      Matt Garman - 2013-03-04

      I believe it is working now. It seems the problem was that my launcher script had the unfortunate name of "ptpd2", same as the binary. This was causing a false positive for check_parallel_daemons().

      Simply renaming my startup script to anything other than "ptpd2" appears to resolve the problem.

      Apologies for the confusion.

       
  • George Neville-Neil

    OK, glad that this was resolved.

     
  • mozhdeh

    mozhdeh - 2013-04-12

    Hi:)

    I have a question about ptpd2. Is ptpd2 support boundary clock and transparent clock?

    Thanks,
    Mozhdeh

     
    • George Neville-Neil

      On Apr 12, 2013, at 8:42 , "mozhdeh" mozhdeh@users.sf.net wrote:

      Hi:)

      I have a question about ptpd2. Is ptpd2 support boundary clock and transparent clock?

      It does not. It supports only master and client operation.

      Best,
      George

       
    • Wojciech Owczarek

      Ptpd2 can emulate boundary clock support when you launch it twice on two different ports in different domains, one as a slave and one as a master. You will just need to make sure there are no lock file conflicts. And as George says, there is no support for transparent mode operation.

       

Log in to post a comment.