sb0 has quit [Read error: Connection reset by peer]
attie has quit [Ping timeout: 256 seconds]
attie has joined #m-labs
sb0 has joined #m-labs
<cr1901_modern>
Does m-labs conda repo provide each package's dependencies, or are users expected to have "sudo apt-get install" the relevant (system) dependencies before attempting to use the conda environment?
<sb0>
cr1901_modern, there are no/few external dependencies
<rjo>
whitequark: don't know. i usually just use preseed and don't look at the console much.
* rjo
now has 41 sinara boards laying around waiting to be integrated...
attie has quit [Remote host closed the connection]
<cjbe>
sb0: for reference, over ~40 hours the Si5324 master-satellite clock phase has a pk-pk of 55ps (stddev 6ps) - this is pretty much at noise floor of how I am measuring it, so shows that clock sync. will work pretty well after we can deterministically align the phase to better than this on startup
attie has joined #m-labs
<cjbe>
(this is with the FS bidi optics you recommended, and 10m of fibre)
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
<rjo>
cjbe: one take-home message being that the si5324 does indeed to a <<1ns tight lock at ~500 Hz BW?
<cjbe>
rjo: yes, if the PFD is at 2 MHz. Very much not if the PFD is at 16 kHz.
<rjo>
cjbe: does it depend only on PFD freq or also on BW?
<cjbe>
sb0, what throughput would you expect on the kc705 for RTIO DMA events?
<sb0>
cjbe, what data size?
<cjbe>
A TTL output, so 1 word IIUC
<cjbe>
I seem to be getting about 8 coarse clock cycles per eventy
<cjbe>
On the gateware before SED (when I did the DMA acceptance tests) I seemed to be getting a factor 2 faster than this
<cjbe>
But (redoing the tests again now) there was some gateware problem where events were getting lost, but no errors were reported
<sb0>
should be around 3
<sb0>
there was some gateware problem -> before SED?
<cjbe>
before SED I would get RTIO collision with event pairs (i.e. pulse+delay) less than ~32mu apart
<cjbe>
however I get missing events for event pairs less than 128mu apart
<cjbe>
after SED, event pairs less than 128mu apart give underflow errors
<sb0>
I suppose that's when they are part of a long chain of events, i.e. the fifo gets full?
<cjbe>
Yes - this in an experiment that is trying to find the max sustained event rate
<sb0>
but there are no more events getting lost?
<sb0>
before SED some events would get lost, is that correct?
<cjbe>
after SED, I either get the correct output, or an exception
rohitksingh has joined #m-labs
<cjbe>
before SED, quite a lot of DMA events can get lost (i.e. for a 1e4 pulse sequence with pulses spaced by 120mu, I only get ~3e3 pulses out, whereas for 128mu and above I get the correct 1e4 out)
<GitHub-m-labs>
[artiq] gkasprow commented on issue #908: I can also test data lines but need to scratch the silkscreen to gain access. And single-ended measurement won't work in my lab due to amount of EMC caused by nearby TV and radio transmitter. https://github.com/m-labs/artiq/issues/908#issuecomment-370432105
<cjbe>
sb0, ok - I thought the DRAM interface was faster than that
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @gkasprow Before you do that, I'd like to understand more about your setup. The eyes that @marmeladapk posted look good, so I'm not surprised that the scope traces look good.... https://github.com/m-labs/artiq/issues/908#issuecomment-370442253
<GitHub-m-labs>
[artiq] cjbe commented on issue #946: yes - remote is faster than local. I was surprised by this too, but verified that when there is no underflow I get the correct sequence (number of pulses on a counter) out of both the master and slave. https://github.com/m-labs/artiq/issues/946#issuecomment-370453395
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: Basically, can you try to reproduce the conditions you had before that gave memtest errors/bad eyes and then have a look at the traces with a scope? https://github.com/m-labs/artiq/issues/908#issuecomment-370454564
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: Or, @sbourdeauducq can you suggest another test what other tests you would like to see don with the hardware to determine whether this is a gateware or hardware problem? https://github.com/m-labs/artiq/issues/908#issuecomment-370454853
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #908: @hartytp Right now I'm building sayma amc with SAWG against a274af7. We'll check if we have errors then on two amc boards we have in our lab. If not, you want us to build last not working version? https://github.com/m-labs/artiq/issues/908#issuecomment-370455658
<GitHub-m-labs>
[artiq] jbqubit commented on issue #908: If M-Labs reproduces the DDR3 test that @gkasprow did this summer using Xilinx IP it would establish if there's a hardware problem or not. https://github.com/m-labs/artiq/issues/908#issuecomment-370455820
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #908: @jbqubit DDR3 is usually working correctly on our boards with the MiSoC core. What does this tell us if we run the Xilinx core a few times and it also works correctly? https://github.com/m-labs/artiq/issues/908#issuecomment-370456312
<cjbe>
sb0, I am occasionally seeing bursts of 'write underflow' errors from the satellite - what does this mean?
<sb0>
cjbe, for latency reasons, underflows are detected at the master; in case there is an underflow the master is supposed not to send anything to the satellite
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @marmeladapk Well, I guess the question is: "what is the most direct measurement we can do to verify whether this is a hardware problem or not?"... https://github.com/m-labs/artiq/issues/908#issuecomment-370457874
<sb0>
cjbe, in case the master sends something that produces an underflow upon reception by the satellite, that's the error you get
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @marmeladapk Well, I guess the question is: "what is the most direct measurement we can do to verify whether this is a hardware problem or not?"... https://github.com/m-labs/artiq/issues/908#issuecomment-370457874
<sb0>
cjbe, many things can cause that: TSC synchronization failure, not enough underflow margin at the master taking into account the latency of the link, data corruption
<sb0>
(not just the underflow detection at the master not working correctly)
<GitHub-m-labs>
[artiq] marmeladapk commented on issue #908: @hartytp Could you upload then your non-working bitstream? We still have at least 40 minutes until gateware with SAWG builds on our machine. https://github.com/m-labs/artiq/issues/908#issuecomment-370460307
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: > @hartytp Could you upload then your non-working bitstream? We still have at least 40 minutes until gateware with SAWG builds on our machine.... https://github.com/m-labs/artiq/issues/908#issuecomment-370460818
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @sbourdeauducq @marmeladapk @gkasprow okay, so it sounds like we have an agreement on the tests that need to be done on Sayma. @gkasprow if you possibly can, it would be great to look at the data and clock lines at the same time to verify the jitter. https://github.com/m-labs/artiq/issues/908#issuecomment-370461147
<cjbe>
sb0, understood - so if I see these ever in normal operation there is a bug somewhere
<sb0>
cjbe, yes
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @jbquibt the tests outlined above shouldn't take @gkasprow and @marmeladapk too long to complete and will resolve the hw/gateware issue to everyone's satisfaction. Let's use that as a starting point.... https://github.com/m-labs/artiq/issues/908#issuecomment-370462511
<GitHub28>
[smoltcp] whitequark commented on pull request #177 3756ea1: All three branches have inconsistent capitalization. I prefer `membership query`, `membership report` and `leave group`. https://github.com/m-labs/smoltcp/pull/177#discussion_r172243866
<GitHub38>
[smoltcp] whitequark commented on pull request #177 3756ea1: Based on the algorithm in `max_resp_time()`, doing `x.set_max_resp_time(x.max_resp_time())` will sometimes change the packet. This is obviously wrong. https://github.com/m-labs/smoltcp/pull/177#discussion_r172242930
<GitHub31>
[smoltcp] whitequark commented on pull request #177 3756ea1: Since not all `u16` values are valid for `max_resp_time` anyway, I think you should use `Duration` here, and silently clamp values to the closest valid ones. https://github.com/m-labs/smoltcp/pull/177#discussion_r172244389
<GitHub-m-labs>
[artiq] cjbe commented on issue #947: The master is running from an external 150 MHz. The slave is starting off on the external 150 MHz and switching to the recovered clock when the DRTIO link is up. https://github.com/m-labs/artiq/issues/947#issuecomment-370476173
<GitHub-m-labs>
[artiq] klickverbot commented on issue #945: Surely we can at the very least set aside a chunk of memory ourselves on startup to service DMA buffer requests from (i.e. use a local allocator backed by a preallocated region), or use the global allocator directly and handle failure without `oom()`ing? https://github.com/m-labs/artiq/issues/945#issuecomment-370502455
rohitksingh has quit [Quit: Leaving.]
<GitHub-m-labs>
[artiq] klickverbot commented on issue #945: (Without having looked at the crash – famous last words – I presume this is from the buffer appending in `rtio_dma`. Can't we just replace the `Vec<u8>` by something that is backed by a local allocator and handles failure gracefully? Just hardcoding the amount of RAM to dedicate to DMA traces would be fine to start out with.) https://github.com/m-labs/artiq/i
<rjo>
marmelada: do you know which FPGA temperature grade was actually used on kasli/v1.0 and kasli/v1.1? on my old photos from v1.0 it looks like 2I or 2E but not the 2C i would have expected.
<GitHub-m-labs>
[artiq] gkasprow commented on issue #908: @jordens I will check it. On my other 4k series Tek scopes, all settings apply to the lower window. The upper one is just preview. But this is very old scope with Windows XP and the interface is different . The lower window is controlled by "magnification" knob so you may be right :D https://github.com/m-labs/artiq/issues/908#issuecomment-370559100
<GitHub-m-labs>
[artiq] gkasprow commented on issue #908: @hartytp I have the setup in place, can look at the clock and data lines with: 1x 5GHz diff probe and 3x 1GHz active probes. But it would make sense to look at the design where SAWG works, but it seems we need SDRAM working to do this. Am I right?... https://github.com/m-labs/artiq/issues/908#issuecomment-370572437
<GitHub-m-labs>
[artiq] gkasprow commented on issue #908: @sbourdeauducq in depth analysis of the DDR timing using the scope is problematic due to the nature of the measurement. 1..2 pf of the probe disturbs the signal phase in significant way and scope channel to channel matching is far worse than time margin required by the DDR chip. So I can observe the signal integrity, power integrity but for in-depth inspection I use Hyp