<rjo>
_florent_: awesome. thanks for powering through!
rohitksingh_work has quit [Ping timeout: 260 seconds]
rohitksingh_work has joined #m-labs
mumptai has joined #m-labs
<GitHub140>
[artiq] mntng opened pull request #831: set maximal divider value for SPI write and read clk (master...master) https://github.com/m-labs/artiq/pull/831
<rjo>
sb0: didn't you have problems with the 10G bidi SFP+ from fiberstore?
<rjo>
sb0: i just tested them at 1G and they work fine.
<sb0>
rjo, with the KC705, yes
<sb0>
but the kc705 transceivers are flaky, could be a problem with analog parameters
cr1901_modern has quit [Ping timeout: 248 seconds]
cr1901_modern has joined #m-labs
sb0 has joined #m-labs
<sb0>
whitequark, ping
<GitHub145>
[artiq] dhslichter commented on issue #40: What are the issues/tradeoffs with negative offsets? Does this impact things badly when combined with the SRTIO design being produced, because of all the timeline rewinding it could potentially create? https://github.com/m-labs/artiq/issues/40#issuecomment-330896297
<GitHub44>
[artiq] sbourdeauducq commented on issue #40: SRTIO makes things a bit trickier because the FIFO switch decision depends on the final (corrected) timestamp - that's a lot of combinatorial logic to spread in the couple cycles that a RTIO write currently takes. But I have found a way that should work, unless Xilinx silicon is even slower than I imagine and doesn't meet timing. https://github.com/m-labs/artiq/issues/40#issuecomment-330897627
<GitHub192>
[artiq] jordens commented on issue #40: There are a few assumptions about slack uniformity across channels. One issue with negative offsets (executing earlier than the time cursor) is that it breaks those assumptions (e.g. setting the cursor to X after wall clock as we currently do will not guarantee positive slack anymore). The replacement code also has a virtual deadline ahead of the wall clock that would be broken. https://github.com/m-lab
<GitHub150>
[artiq] dhslichter commented on issue #40: I was worried about some of these issues @jordens. Given all this, I think that negative offsets (the useful ones) are still problematic, while positive ones can "solve" the latency calibration problem at the cost of adding substantial latency to everything. I think unless there is a great hue and cry to have these features, this is something that people should be doing in their code rather than someth
<GitHub112>
[artiq] jbqubit commented on issue #40: Currently prerecorded ```core_dma``` can span multiple experiments. If RTIO ```.latency``` could be set per-experiment things get complicated. AFACT it would be cleaner if RTIO latencies were settable only by the startup kernel (and if startup kernel erased recorded DMA events). Does anybody see a problem with that constraint? https://github.com/m-labs/artiq/issues/40#issuecomment-330971764
<whitequark>
sb0: pong
<GitHub44>
[smoltcp] whitequark pushed 2 new commits to master: https://git.io/v5hhB
<GitHub120>
[smoltcp] whitequark commented on issue #45: Note: I'm going to hold off on merging this for a bit because m-labs has a fork of rustc that's stuck on 1.19, and there are higher priority tasks than updating rustc. But it shouldn't take too long, anyway. https://git.io/v5jOE
mumptai has quit [Quit: Verlassend]
<GitHub174>
[smoltcp] batonius commented on issue #45: Sure, it's just something I've noticed while looking for something else. https://git.io/v5j3D