sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<bb-m-labs> build #135 of artiq is complete: Success [build successful] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq/builds/135
<whitequark> uh
<whitequark> oh, I see
fengling has joined #m-labs
fengling has quit [Ping timeout: 272 seconds]
<GitHub179> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/53b06a0b9ba4e948cea0673136cce03724c0a12d
<GitHub179> artiq/master 53b06a0 Robert Jordens: RTIOUnderflow: show slack
Gurty has quit [Ping timeout: 246 seconds]
Gurty has joined #m-labs
fengling has joined #m-labs
<whitequark> rjo: unsurprisingly printing a kilobyte of text on every exception takes a lot of time
<whitequark> pulse_rate: 1.0500000000000001e-06
<whitequark> hm, it finished eventually
fengling has quit [Ping timeout: 272 seconds]
<rjo> interesting. that got faster IIRC
<whitequark> hm?
<whitequark> it's just that the personality function has debug mode enabled
<whitequark> I think we can turn that off already
<rjo> the 1000 ns (1/2000 ns pulse rate) was a known-too-fast interval
<rjo> yes. you should start at 500*ns in that test.
<rjo> before, 1000*ns was know to be to short.
<whitequark> I started at 100ns
<whitequark> oh
<whitequark> no, 10ns
<whitequark> it took a while.
<rjo> interestingly, on pipistrello, i get a lower bound of ~1200 ns
<rjo> there must be something weird going on with the DDRAM or its cache. the cpu clock ratio is onl 83/125
<rjo> if you start at 10ns, it needs to fail (1050/2-10) times to succeed.
fengling has joined #m-labs
<whitequark> ok, takes just ~8 seconds now
<whitequark> some of it is the very high-latency link from RU to HK...
<GitHub103> [artiq] whitequark pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/53b06a0b9ba4...e2910fba99a0
<GitHub103> artiq/master 5c6b151 whitequark: Rigorously treat builtin core device exceptions.
<GitHub103> artiq/master e2910fb whitequark: runtime: define NDEBUG to disable debug mode of __artiq_personality....
fengling has quit [Ping timeout: 272 seconds]
ylamarre has quit [Ping timeout: 264 seconds]
fengling has joined #m-labs
evilspirit has joined #m-labs
rohitksingh has joined #m-labs
<rjo> very good that we are compiling libm's bessel and gamma functions already. people will love/want those in the runtime ;)
<GitHub5> [artiq] jordens pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/e2910fba99a0...063e88d75ae3
<GitHub5> artiq/master 6940d98 Robert Jordens: gitignore: minor tweaks, recommend /run for testbed
<GitHub5> artiq/master 063e88d Robert Jordens: artiq/_version.py: update
<cr1901_modern> Wasn't aware libm had a bessel function
<cr1901_modern> Oh, that's b/c they're called j0, j1, etc, and I never bothered to make the connection lol
<whitequark> rjo: they won't be in the runtime unless you actually use them
<whitequark> feel free to take anything you find unneeded from our copy of libm, i just felt that if it calls itself libm it might as well be the whole deal
<rjo> whitequark: sure. and they would need hooking up to APython as well.
<whitequark> rjo: that is as simple as adding a syscall and then extending the export table in ksupport
<whitequark> (we can actually get rid of it if desired, if we use the ELF tables in ksupport.elf...)
<rjo> sb0, felix_: whatever you guys did to lwip/ppp/uart flood ping works fine now.
<rjo> (on pipistrello with ppp)
<rjo> but tcp connections break
<rjo> whitequark: ack.
<GitHub109> [artiq] jordens created ppp2 (+4 new commits): https://github.com/m-labs/artiq/compare/57ce78c54db4^...7e3610c545ae
<GitHub109> artiq/ppp2 dc709a7 Sebastien Bourdeauducq: PPP support (TCP broken)
<GitHub109> artiq/ppp2 1adeeab Robert Jordens: ppp: wait for connection
<GitHub109> artiq/ppp2 57ce78c Robert Jordens: pipistrello: add rtio.Analyzer()
<GitHub151> [artiq] jordens pushed 1 new commit to ppp2: https://github.com/m-labs/artiq/commit/2bc2cd0064239702999f2b03b6254f6f637bbc36
<GitHub151> artiq/ppp2 2bc2cd0 Robert Jordens: ppp: remove unneeded objects
<GitHub100> [artiq] jordens created release-1.x from v1.x (+0 new commits): https://github.com/m-labs/artiq/commits/release-1.x
<GitHub64> [artiq] jordens deleted v1.x at de30a4b: https://github.com/m-labs/artiq/commit/de30a4b
<GitHub72> [artiq] jordens tagged 1.0 at release-1.x: https://github.com/m-labs/artiq/commits/1.0
<GitHub52> [artiq] jordens deleted v1.0 at de30a4b: https://github.com/m-labs/artiq/commit/de30a4b
<GitHub70> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/8674875007b57266449dbdcefde7038290a98de8
<GitHub70> artiq/master 8674875 Robert Jordens: versioneer: remote tag_prefix = v...
<GitHub116> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/cf17be92e3c651a2aa635eb55d20a7835b0e5900
<GitHub116> artiq/master cf17be9 Robert Jordens: doc: add artiq_flash
rohitksingh has quit [Ping timeout: 256 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
aeris has joined #m-labs
aeris has quit [Remote host closed the connection]
sb0 has joined #m-labs
<sb0> rjo, I think creating a stable branch means more than tagging... we should also do some testing, backport bugfixes, etc.
<sb0> it's quite some work. do you see cases where you'd tell people to keep using the old compiler?
<sb0> afaict after the parallel implementation is sorted out, the new compiler should run all the (meagre) user code base.
<sb0> i'd rather make your 2.0 the 1.0, and maintain that branch seriously
ylamarre has joined #m-labs
aeris has joined #m-labs
<sb0> rjo, why did you create ppp2 instead of updating the existing branch?
<sb0> rjo, why would you put the testbeds in-tree?
aeris has quit [Remote host closed the connection]
aeris has joined #m-labs
aeris has quit [Remote host closed the connection]
aeris has joined #m-labs
aeris has quit [Remote host closed the connection]
sb0 has quit [Quit: Leaving]
<rjo> sb0: creating stables branches is just that: creating stable branches. if there is the need for it, bugfixes will need to be backported.
<rjo> no. i don't see anybody using that 1.x right now. but that point is a pivotal nontheless.
<rjo> i don't see a problem if the first version of artiq that takes paper-data is 2.0. and even that is just a humble wish so far.
<rjo> there is also your 0.0
<rjo> i created ppp2 because i rebased (was much easier) which would mean that history would get lost if i force-pushed that to ppp.
<rjo> once you say there is nothing in your ppp branch anymore worth keeping, it can go
<rjo> testing things in-tree is something that at least whitequark and i do all the time. we apparently don't like cd'ing around or adding lots of options to artiq_* cli tools.
sb0 has joined #m-labs
sb0 has quit [Client Quit]
mumptai has joined #m-labs
<GitHub42> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/1d7858c7bc7428aaa9f8e0cee92eb9f1630539f3
<GitHub42> artiq/master 1d7858c whitequark: Fix formatting.
evilspirit has quit [Ping timeout: 245 seconds]
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
<felix_> rjo: iirc some buffer size of the lwip got increased, which improves things a little, but doesn't fix the underlying issue
<felix_> haven't had time to find the bug/misconfiguration in lwip yet; currently university eats up a lot of my time :/
Gurty has joined #m-labs
Gurty has quit [Changing host]
Gurty has joined #m-labs
<rjo> felix_: but the flood pinging never worked for me. and i don't remember seeing lwip reset tcp connections. instead it was just dead-slow.
<felix_> i got between 10 and 60% acket loss on flood pings and haven't tested tcp connections yet
<felix_> increasing some buffers inproved the rate of returned ping packets
<felix_> *improved
<rjo> packet loss is now basically zero.
<felix_> ok, i'll have a look at the new branch at the weekend
felix_ has quit [Read error: Connection reset by peer]
felix___1 has joined #m-labs
felix___1 is now known as felix_
mumptai has quit [Quit: Verlassend]
<rjo> whitequark: was there are reason to recommend three different conda envs one for each bitstream? they should coexist happily.
<whitequark> rjo: uh, we recommend that?
<whitequark> bitstreams are explicitly designed to coexist, if we do suggest that it is an error
<rjo> ah. no we don't but there seems to be unnecessary redundancy in the docs.