<sb0>
rjo, NIST would like an ARTIQ release with the "ARTIQ3" contract features and DMA, this means releasing 3.0rc1 as soon as DMA works and moving DRTIO + Sinara (and a few other things) to 4.0
<sb0>
thoughts on this plan? I'm fine with it
<whitequark>
sb0: btw remember you've said something to the extent of "I hope your TCP/IP stack can transmit multiple packets without waiting for ACK"?
<whitequark>
it's very funny, because while smoltcp supports this, it basically never happens in ARTIQ
<whitequark>
because of the way buffers work with liteeth. smoltcp will never block waiting for liteeth to transmit, so it sends one packet and returns from poll
<whitequark>
then by the next iteration of the loop it has already received an ACK, since the host PC is so much faster at processing network packets
<sb0>
ok
<whitequark>
actually, this wastes time processing all those ACKs
<whitequark>
can liteeth just take buffers from userspace instead?
<sb0>
you mean DMA?
<whitequark>
oh, does it currently have its own memory? that explains a few things
<whitequark>
I've never realized that
<whitequark>
so yeah, DMA
<sb0>
yes, packets are stored in on-chip SRAM
kuldeep has joined #m-labs
<sb0>
_florent_, stekern, have you worked much with kintex ultrascale already? does a 250MHz mor1kx sound realistic?
<rjo>
sb0, whitequark: i have readthedocs automatically building and publishing the artiq manual. FWIW we can move there. the builds are faster, current and the wrestling with sftp is gone.
<GitHub>
artiq/master 74b910e whitequark: In case of a load error, pass the reason to host interpreter....
<rjo>
sb0: you can not say 'nless otherwise noted, MiSoC is copyright (C) 2011-2014 Sebastien Bourdeauducq.'. what happens is "unless otherwise noted, copyright is with the authors of the contributions."
<rjo>
sb0: that makes building older versions of master unnecessarily complicated and fragile.
<rjo>
sb0: what is your problem with the tag?
<rjo>
sb0: if you are afraid of readthedocs, then please go ahead and update RELEASING.
<sb0>
the solution to this would be to have master depend on a specific misoc commit hash, otherwise one has to manually tag every misoc commit with a new version
<sb0>
simply, because artiq master is developed at the same time as misoc
<rjo>
misoc 0.6 is a release. there is just one hash for that.
<sb0>
let's say we add something to misoc and then develop something in artiq master that depends on it, which is usually what happens
<rjo>
yes. if you need a specific feature in misoc that is not in one of the releases, we need to depend on the hash.
<rjo>
sure.
<sb0>
this scenario is what happens most of the time
<rjo>
or better, just do proper releases with misoc. and develop in a working tree
<rjo>
sb0: you seem to be abusing the buildbot/CI as a compiler farm. is that how you develop?
<whitequark>
I do that too
<whitequark>
no way in hell I'm going to run Xilinx garbage on my laptop
<whitequark>
it is hard enough to keep working once on CI
<rjo>
i don't think that's wise. it requires that you commit all kinds of incremental broken things when testing.
<whitequark>
you don't have to do that in master
<rjo>
i just compile it in my working tree and develop there.
<sb0>
not really, especially not as drtio isn't on buildbot
<whitequark>
building ARTIQ last time I checked took over 45 min just for xilinx stuff
<sb0>
what you see as "abusing the buildbot" is minor changes that I thought would not break master but did
<whitequark>
that's notwithstanding the disk space, bandwidth, and battery charge that it uses
<whitequark>
that said, the current conda issue, like most of the other conda issues, stems from the lack of lock files
<rjo>
i am all for using the xilinx on lab. but i don't see the benefit of developing with buildbot in your personal testing/development loop.
<whitequark>
(version lock files, that is
<whitequark>
rjo: it's less fragile
<rjo>
if you develop artiq and misoc in correlation, then doing misoc releases is just fine IMHO.
<whitequark>
buildbot has [whatever the current operation for building and flashing is]
<sb0>
I'd prefer having artiq depend on migen/misoc git hashes
<whitequark>
I don't have it in my memory
<rjo>
whitequark: but it is extremely fragile since most of the commits in master are broken then. and since you can't easily go back and build an old version because of the floating dependencies on migen/misoc etc.
<sb0>
also, this gets rid of the build triggers, which are more often than not a problem (with the scenario I mentioned, there is one extra ARTIQ build for nothing because of those triggers)
<whitequark>
rjo: I agree that floating dependencies are awful
<rjo>
sb0: driving away other users of migen and misoc.
<cr1901_modern>
Fwiw, I've been using git head for 1.5 years and I can only count two instances where code broke after pulling (one being the 2015 API change). What's wrong with making them rolling releases?
<rjo>
and the stack can process packets slower than the ACK turn around? that's about 1k paket/s, right?
<whitequark>
no.
<whitequark>
linux sends packets in small bursts
<whitequark>
without waiting for even a single ACK that is.
<whitequark>
basically the only "proper" solution I can see is capping receive window by one receive MSS
<whitequark>
apart from adding true out-of-order reassembly
<whitequark>
well, no.
<whitequark>
1) out-of-order reassembly
<whitequark>
2) capping the receive window
<whitequark>
3) enlarging the liteeth buffer to hold more than one packet at once
<rjo>
yeah it pushes the window. afaict a window larger than the recieve buffer is not good. i'd increase the buffer if possible.
<rjo>
certainly not good for short and fat pipes.
<whitequark>
similarly *we* can't push the window of the host
<whitequark>
because the tx buffer is similarly small, and going through the other threads means we get an ack per tx'd packet
<sb0>
how did lwip do it?
<whitequark>
sb0: I think lwip has reassembly
<whitequark>
I feel like using reassembly to compensate for tiny buffers is a bad idea. for one, it gives you a low limit on latency (the initial retransmit time)
<whitequark>
how much can we increase the size of liteeth buffers? is four of them (eight total) viable?
<sb0>
yes, probably
<sb0>
why do we need 4 tx buffers as well?
<whitequark>
I just explained above
<sb0>
does this work? are you trying to guarantee that there is always a tx slot available for each rx slot?
<bb-m-labs>
build #396 of artiq-win64-test is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/396 blamelist: whitequark <whitequark@whitequark.org>, Robert Jordens <rj@m-labs.hk>, Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs>
build #1256 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1256 blamelist: whitequark <whitequark@whitequark.org>, Robert Jordens <rj@m-labs.hk>, Sebastien Bourdeauducq <sb@m-labs.hk>
<sb0>
rjo, I don't think pypi will significantly improve migen visibility
<sb0>
what should rather be done - and is considerably more work - is nice and up-to-date tutorials, kinda like myhdl does (who get better exposure despite being technically inferior and grossly mismanaged)
<sb0>
and those tutorials have to be begineer level
<rjo>
sb0: pypi makes it installable with pip.
<sb0>
then engage with other communities, e.g. those ice40 folks
<sb0>
and go conference hopping and publish articles
<rjo>
sb0: yes. beginner documentation would be awesome. but also quality API doc is sparse.
<rjo>
sb0: i close issues that we can't do anything about. right now there seems to be nobody interested in that issue and nobody able to reproduce it. as soon as the issue is relevant i am happy to reopen.
<GitHub>
[artiq] jbqubit commented on issue #463: Thanks for the reminder. I now have access to a Windows 10 machine with a high-resolution display (2560x1140). The scan widget and spin boxes are sized correctly and handles are easy to operate.... https://github.com/m-labs/artiq/issues/463#issuecomment-275699469
mumptai has joined #m-labs
sandeepkr has quit [Remote host closed the connection]
<GitHub>
[artiq] sbourdeauducq commented on issue #648: @cjbe In fact, this is a problem with ``artiq_run``, unless we add a ``--repository`` option to it, or require that the user sets ``PYTHONPATH``. But this is quite unfriendly. Maybe it is better to agree that experiments should do relative imports in this case? https://github.com/m-labs/artiq/issues/648#issuecomment-275715265
<GitHub>
[artiq] klickverbot commented on issue #80: @sbourdeauducq: I might be thinking about the wrong clock, but we were thinking about increasing the RTIO frequency to lessen the requirements on the carry-chain length for the in-FPGA TDC. It is not an extremely important consideration, but since propagation on the newer process node is quicker than for your Spartan-6 work, they are quite unwieldy placement-wise. https://github.com/m-labs/artiq/issues/80
<GitHub>
[artiq] klickverbot commented on issue #80: Good point – I suppose driving the TDC domain from a multiplied clock and having an additional coarse counter to synchronise to RTIO MUs would be easier than changing the whole system clock, yes. https://github.com/m-labs/artiq/issues/80#issuecomment-275719542
<GitHub>
[artiq] klickverbot commented on issue #80: Good point – I suppose driving the TDC domain from a multiplied clock and having an additional coarse counter to synchronise to RTIO MUs would be easier than changing the whole system clock, yes. https://github.com/m-labs/artiq/issues/80#issuecomment-275719542
<GitHub>
[artiq] klickverbot commented on issue #80: Good point – I suppose driving the TDC domain from a multiplied clock and having an additional coarse counter to synchronise to RTIO units would be easier than changing the whole system clock, yes. https://github.com/m-labs/artiq/issues/80#issuecomment-275719542
<GitHub>
[artiq] cjbe commented on issue #648: @sbourdeauducq I agree this is problematic for artiq_run. My opinion is that artiq_run is a lower level tool that will be mostly used for debugging rather than by the average user, so requiring the user to set PYTHONPATH is OK.... https://github.com/m-labs/artiq/issues/648#issuecomment-275720885
<GitHub>
[artiq] sbourdeauducq commented on issue #80: Yes, and you're not accumulating errors on a long carry chain. But for this sort of high-precision application, note that the Xilinx PLLs aren't particularly good with jitter. You might be better off generating the TDC clock from a low-noise external chip feeding a ``IBUFGDS`` that goes directly to the TDC's sampling FFs. https://github.com/m-labs/artiq/issues/80#issuecomment-275721354
sandeepkr has joined #m-labs
<GitHub>
[artiq] klickverbot commented on issue #80: [This is probably off-topic here anyway, but I believe @cjbe (who actually did the port – I only briefly looked into the options and then used it) also came to that conclusion. In case you ever start integrating a high-res TDC/it gets put on a contract, I would definitely be interested in any progress, though.] https://github.com/m-labs/artiq/issues/80#issuecomment-275722639
<GitHub>
[artiq] klickverbot commented on issue #80: [This is probably off-topic here anyway, but I believe @cjbe (who actually did the port – I only briefly looked into the options and then used it) also came to that conclusion. In case you ever start integrating a high-res TDC/it gets put on a contract, I would definitely be interested in any progress, though.] https://github.com/m-labs/artiq/issues/80#issuecomment-275722639
<GitHub>
[artiq] dhslichter commented on issue #80: In the NIST KC705 hardware, 125 MHz RTIO clock corresponds to 3 GHz DDS clock. I don't know of any plans to go to higher frequencies for the DDS clock than this -- the DDS synchronization is not reliable above 3 GHz, and this gives a fine timestamp of 1 ns. I don't see the need to push to higher RTIO clock frequencies for the time being. https://github.com/m-labs/artiq/issues/80#issuecomment-275755065