On 8 April 2014, quoth Jun Yuan: > Thank you so much for the test. I am sorry for the formatting error. > I should test it before send it out but I didn't have the chance.
I think this was actually from the original code, not your changes. > 1) sync ref slave to master. > Apparently the slave needs more time to get synchronized at the > first time after a reboot. I think it is because the drift > compensation is reset after the reboot, and the slave losts the > last drift estimation value to the master clock. If the slave > do need such a long time to get DC sync converged after a reboot, > I don't think I can do anything to make it better. I also doubt > that the original Etherlab-Master can do it better. After all, > the drift compensation algorithm is on the slave side, the master > can only try to give the best transmission delay estimation and > the system offset value. Fair enough. Although in that case I wonder why this isn't more of a widespread problem (or why it hasn't been solved somehow if it is). The slave isn't doing anything weird, it's just using whatever default timing behaviours are built in. And as I said according to the debug output the timing actually seemed to be diverging, which it definitely shouldn't be doing. I wonder if there's some extra register that's supposed to be set during initial setup to help it along? Some way to tell it "the network's restarting, forget about slowly adjusting the clock and just step it directly to this value". There's a note in the slave datasheet about resetting the time filters by writing to 0x0930. I can't see anywhere that this is happening at the moment, but I might just be missing it. If not, maybe it should be doing this after updating the reference clock slave's time for the first time? > 2) sync the master to ref slave > sorry about the error message. It is because I let the > ecrt_master_reference_clock_time return EAGAIN error when the system > time offset has not been calculated yet. I tried to avoid the error > message in lib/master.c, but apparently I didn't do it right. I'll > fix it ASAP. That part worked; the issue is that if a reference clock is not explicitly selected (eg. ecrt_select_master_reference_clock(master, NULL) or not called) then calls to get the time will return ENXIO until later in the startup cycle when it actually finds a clock to use. And this causes the user library to generate spam. (The library error output seems like a misfeature to me, especially for functions intended to be called from realtime code that probably doesn't want to go near fprintf. But that's an entirely separate topic.) Incidentally, I tried this userland code with the original 1.5.2 master code (with modification to lib/master.c to avoid spam) and it produced the same results with one slave -- almost instantly locking in the timing. I assume for the differences to become apparent, more slaves are required. _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
