[etherlab-users] etherlab dc sync check

[Jun Yuan]

> It cannot be accurate, since the time between TX descriptor update in the
> NIC and actual packet on wire is highly dependent on the PC and NIC
> hardware. The _rate_ however, is accurate.
>
> It could become highly accurate, however, when one would use the PTP
> facilities that some PHYs/MACs offer (using SO_TIMESTAMPING). But it would
> not be easily possible using the patched drivers, I'm afraid.

Nice to know that, it is a little off topic though.

> It is best if the PLL loop filter of the slave #0 clock would be set
> sufficiently slow. The other PLLs loop time constants can be set much
> tighter (faster). But that's where the mysterious parameters at
> 0x0930..0x935 come in. I have no idea what the loop filter looks like. The
> Standard says it's implementation specific, but the ET1200 datasheet doesn't
> provide sufficient data to fully understand the implications of fiddling
> with these parameters.

I feel like the same. Maybe we could do some test work to see how the
filter responses to 0x0930...0x0935, but that's now so important right
now. I suppose the default value for the filter on the slave shall be
good enough, and have no intent to change them right now. I'd like to
focus on how to make the master better.

>  I believe the best way to eliminate much, if not all, of the
> synchronization is to continue sending the synchronizing FRMW to slave #0 in
> the IDLE thread (and preferably also the FPWR). That way at least the slaves
> do not lose sync with eachother when the application isn't running.

This might be a great idea! Are we allowed to do that in the IDEL
thread where the bus is in PRE-OP state? Wenn I've got a slave to
test, I would like to have a try.

> I believe it is not. The standard states that the reference clock should be
> assigned to a slave upstream of slaves to be synchronized. The reference
> clock itself is said to be 'adjustable'. In a wider sense, simply leaving it
> run freely is compliant to this requirement.

Well, I misunderstood the question "Why not just send once a current
master time to the first slave, then propagate(copy)  it to other
slaves, and run PLL in the master that adjust itself to the fist slave
(clock master)?" from Rasty. I thought he's going to create a whole
new method for the DC sync. After reading his next email, I've got
what he want to say, see my last mail.
What you said here is totally correct for me.


> I'm not sure if it's right what has been said here. Either this is about the
> offset compensation, which is carried out only once upon the bus scan. The
> offsets are derived from comparing the local packet receive time at the
> ingress port with the time at which the slave sees the packet returning
> through the loop at its second port. This approach has its issues when
> another packet is still in that loop (very long loops) or with a software
> slave that needs to receive a frame fully before emitting it again. (I'm
> unsure how this condition is to be handled, since the delay then includes
> the full packet transmission time and is also anything but constant.)
>
> Or it refers to the continuous drift compensation, which merely consists of
> repeatedly sending the app time to the reference clock and sending the FRMW
> datagram to synchronize all remaining slaves. No time comparisons are done
> in the master.
>
> So I doubt the explanations below.

Yes, I was talking about the offset compensation all the time. And I
want to focus on that, because I don't think the master get the job
done correctly. The drift compensation has no problem for me.