04:13 <sb0> has anyone tried this? https://www.exostivlabs.com/

07:28 <GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to switching: https://github.com/m-labs/artiq/compare/2b44786f73c7...970d1bf147dd

07:28 <GitHub-m-labs> artiq/switching 970d1bf Sebastien Bourdeauducq: drtio: add switching unittest

07:28 <GitHub-m-labs> artiq/switching eda15a5 Sebastien Bourdeauducq: drtio: add buffering to repeater

10:51 <rjo> sb0: drtio with 125 mhz kasli works functionally. but when i look at the offset between a ttl on the master and the satellite, that is nondetermistic accross reboots of the master. the range is at least 6ns large. this is serdes ttl outs.

10:53 <rjo> sb0: how did you test that the drtio delay is deterministic?

11:01 <rjo> it is better if only the satellite reboots or the link is reinited.

11:15 <rjo> its deterministic to <1 ns (the DIO jitter) on satellite reboots, and 8 ns on master reboots. the step size is 2ns...

11:16 <cjbe> rjo: I tested this carefully for the 150 MHz RTIO clock only - I have not looked at this with the 125 MHz RTIO clock

11:16 <cjbe> rjo: I tested alignment after link loss (unplugging SFP), master restart, and slave restart

11:19 <rjo> cjbe: with serdes ttl outs?

11:20 <cjbe> rjo: yes (serdes alignment did not work until #958)

11:22 <cjbe> rjo: actually, I take some of that back. I may have not tested all possible combinations of restarts after the final fix to #958

11:27 <GitHub-m-labs> [artiq] jordens opened issue #1155: DRTIO master-satellite alignment (kasli-kasli) on serdes TTL outs https://github.com/m-labs/artiq/issues/1155

11:40 <GitHub-m-labs> [artiq] cjbe commented on issue #1155: Does the si5324 output maintain phase alignment after restarting (measured via the one of the Kasli clock-out SMPs)? ... https://github.com/m-labs/artiq/issues/1155#issuecomment-422359971

12:00 <GitHub-m-labs> [artiq] jordens commented on issue #1155: The master outputs? Aligned to what? https://github.com/m-labs/artiq/issues/1155#issuecomment-422364549

12:05 <GitHub-m-labs> [artiq] cjbe commented on issue #1155: The master si5324 output and the slave si5324 output should have a fixed phase relationship between resets. Equivalently non-serdes TTL outputs should have a fixed timing relationship over resets. https://github.com/m-labs/artiq/issues/1155#issuecomment-422365950

12:12 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1155: Is the problem présent at 150MHz? https://github.com/m-labs/artiq/issues/1155#issuecomment-422367687

12:16 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1155: Is the problem present at 150MHz with the original code in master? https://github.com/m-labs/artiq/issues/1155#issuecomment-422367687

12:46 <GitHub-m-labs> [artiq] jordens commented on issue #1155: Was deterministic sync in the original code with 150 MHz not tested? https://github.com/m-labs/artiq/issues/1155#issuecomment-422377975

12:53 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1155: Chris tested it (that was during siphaser developments). https://github.com/m-labs/artiq/issues/1155#issuecomment-422380788

12:54 <GitHub-m-labs> [artiq] cjbe commented on issue #1155: I tested deterministic sync on SERDES and non-SERDES outputs at 150 MHz on build shortly after #958 was fixed, and both had a deterministic time alignment (over ~100 resets). https://github.com/m-labs/artiq/issues/1155#issuecomment-422380984

12:58 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1155: CI for this shouldn't be very complicated to do (using RTIO inputs and a TTL connection between master and satellite), if someone wants to fund it. https://github.com/m-labs/artiq/issues/1155#issuecomment-422382728

14:30 <GitHub-m-labs> [artiq] jordens commented on issue #1155: Same with the current, original 150 MHz `Master/Satellite` variants. There was really no reason to suspect otherwise, was there? I'm going to pause here. It's probably best if you test code yourself. @sbourdeauducq https://github.com/m-labs/artiq/issues/1155#issuecomment-422416640

14:47 <GitHub-m-labs> [artiq] whitequark commented on issue #1153: This wasn't done before because smoltcp had no support for evicting entries from owned cache, but since https://github.com/m-labs/smoltcp/pull/234, this happens just fine. https://github.com/m-labs/artiq/pull/1153#issuecomment-422423693

14:47 <GitHub-m-labs> [artiq] whitequark closed issue #1150: ConnectionResetError on TCP Keepalive https://github.com/m-labs/artiq/issues/1150

15:20 <bb-m-labs> build #1862 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1862

15:37 <bb-m-labs> build #1863 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1863

15:41 <bb-m-labs> build #2605 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2605

15:53 <GitHub-m-labs> [artiq] jordens commented on issue #1155: @cjbe I don't follow your analysis. It can't really be SiPhaser (which what I assume is what you mean by "phase alignment module clocking") since that's only in Satellite and since that synchronizes fine each time. Looking at the SI5324 alignment between the master and the satellite is not not really the best bet. I did it anyway since you and @sbourdeauducq seem to thi

16:06 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1155: It's likely the SERDES then; but if not, it could be GTP shenanigans around the built-in clocking and elastic buffer (which is supposed to be disabled). https://github.com/m-labs/artiq/issues/1155#issuecomment-422453279

16:18 <GitHub-m-labs> [artiq] jordens commented on issue #1155: `ttl_simple` on master against `ttl_serdes_7series` are deterministic. https://github.com/m-labs/artiq/issues/1155#issuecomment-422457284

16:19 <GitHub-m-labs> [artiq] jordens commented on issue #1155: `ttl_simple` on master against `ttl_serdes_7series` on satellite are deterministic. https://github.com/m-labs/artiq/issues/1155#issuecomment-422457284

18:20 <GitHub-m-labs> [artiq] jordens commented on issue #1155: Hmm. Maybe it would be worked around by `core.reset()`. If it is, then I wonder why we can't get the master into a deterministic state without the manual reset. https://github.com/m-labs/artiq/issues/1155#issuecomment-422496395

22:20 <GitHub-m-labs> [artiq] cjbe commented on issue #1155: @jordens my test involved restarting the master and slave simultaneously (via JTAG), running a startup kernel (which waits for the DRTIO link, then runs core.reset()), and running an experiment that generates simultaneous pulses on master and satellite.... https://github.com/m-labs/artiq/issues/1155#issuecomment-422577195