02:48 <GitHub71> [artiq] sbourdeauducq closed issue #685: TCP throughput https://github.com/m-labs/artiq/issues/685

02:48 <GitHub139> [artiq] sbourdeauducq commented on issue #685: Great work @whitequark ! I get 2.3MB/s.... https://github.com/m-labs/artiq/issues/685#issuecomment-331605666

02:56 <GitHub105> [artiq] sbourdeauducq commented on issue #685: Great work @whitequark ! I get 2.3MB/s in both directions.... https://github.com/m-labs/artiq/issues/685#issuecomment-331605666

03:31 <GitHub174> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/57b12abf1ef7ee2dd8624be9de844f5653920b64

03:31 <GitHub174> artiq/master 57b12ab Sébastien Bourdeauducq: manual: remove reference to Spartan-6 proxy bitstream...

03:39 <GitHub82> [artiq] sbourdeauducq commented on issue #803: @whitequark believes that this is due to former smoltcp bugs corrupting data.... https://github.com/m-labs/artiq/issues/803#issuecomment-331607827

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

04:02 <bb-m-labs> build #571 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/571

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

04:49 <GitHub177> [ionpak] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/ionpak/commit/7b103869071e76db6e571dba217ea0f43fe2e093

04:49 <GitHub177> ionpak/master 7b10386 Sebastien Bourdeauducq: update errata

07:55 <travis-ci> batonius/smoltcp#81 (master - bf4ddef : whitequark): The build has errored.

07:55 <travis-ci> Change view : https://github.com/batonius/smoltcp/compare/30cafe310621...bf4ddef87dae

07:55 <travis-ci> Build details : https://travis-ci.org/batonius/smoltcp/builds/278888899

07:57 <travis-ci> batonius/smoltcp#82 (default_route - cf62167 : Egor Karavaev): The build passed.

07:57 <travis-ci> Change view : https://github.com/batonius/smoltcp/compare/b64a43d93f38...cf621676875d

07:57 <travis-ci> Build details : https://travis-ci.org/batonius/smoltcp/builds/278889103

08:24 <GitHub34> [artiq] cjbe closed issue #803: "Unknown RPC value tag" error during RPC https://github.com/m-labs/artiq/issues/803

08:24 <GitHub186> [artiq] cjbe commented on issue #803: @sbourdeauducq using the latest master I also cannot reproduce this. https://github.com/m-labs/artiq/issues/803#issuecomment-331619622

08:26 <GitHub105> [artiq] jordens commented on issue #662: @whitequark you have keep-alive in smoltcp. does it still need wiring in artiq? https://github.com/m-labs/artiq/issues/662#issuecomment-331619704

08:27 <rjo> sb0, whitequark: if keep-alive is in, let's start with 3.0rc1!

10:16 <sb0> there's also the negative modulo bug (tagged 2.5)

10:16 <sb0> do we do rc or just 3.0? people have tested it quite a bit already I think

10:18 <sb0> yes, I think keepalive needs to be enabled in artiq

10:24 <whitequark> sb0: ok, let's enable and test that

10:25 <GitHub46> [artiq] whitequark commented on issue #685: @klickverbot Or packet captures, in both directions, I'd be quite curious to look at the duplicate ACKs. https://github.com/m-labs/artiq/issues/685#issuecomment-331625141

10:34 <GitHub164> [artiq] whitequark commented on issue #662: Yes. https://github.com/m-labs/artiq/issues/662#issuecomment-331625486

10:52 <GitHub105> [artiq] klickverbot commented on issue #685: That machine seems to have crashed, it will take me a while to get back to the lab to revive it. But by now, I suspect there might be some funny business going on with the clocks in the firmware build I was using, as I was using the core device RTIO counter for timing. https://github.com/m-labs/artiq/issues/685#issuecomment-331626312

10:58 <rjo> sb0: i'd like to do an RC and plan for 3.0 on wednesday or similar if there have been no issues. has oxford really used it in the field to an extent that we would be happy to call release testing, or was that just some casual playing around with it? after all, testing it with production-ready TCP performance just now became a possibility.

11:01 <sb0> 3.0 on wednesday?

11:01 <sb0> just a few days of rc testing?

11:07 <whitequark> sb0: what should the timeouts be?

11:13 <rjo> sb0: or by the end of the week. i'll be giving a talk and demo and hands on discussion/testing monday and tuesday at the PTB group retreat. I imagine that NIST/JQI/ARL/Oxford can give it a spin early next week.

11:38 <sb0> whitequark, same as release-2. you want to cut in ~1 second

11:43 <whitequark> ok

13:28 <GitHub3> [artiq] cjbe commented on issue #685: @whitequark there was indeed a factor 8 error in the numbers from @klickverbot : we were seeing about 2.4 MB/s in the above tests, not 18 MB/s. Here is a [dump](https://github.com/m-labs/artiq/files/1326555/dump.zip) of a 1 MB master -> kernel transfer showing duplicate acks, then a 1 MB kernel -> master transfer.... https://github.com/m-labs/artiq/issues/685#issuecomment-331636037

14:46 <GitHub197> [artiq] sbourdeauducq pushed 1 new commit to rtio-sed: https://github.com/m-labs/artiq/commit/aa8fc81a87cfb56aa3d73ffd6c60236aab19659b

14:46 <GitHub197> artiq/rtio-sed aa8fc81 Sebastien Bourdeauducq: rtio: allow specifying glbl_fine_ts_width externally

14:58 <cjbe> rjo: at Oxford we have only done preliminary testing, limited by the Smoltcp issues.

15:00 <cjbe> rjo: All the problems we have observed are fixed with the latest Smoltcp, so we will probably try and upgrade an experiment to 3.0 next week

15:00 <Arpit> Do you have an idea about this error?

15:00 <Arpit> Terminating with exception (LoadError: cannot load kernel: symbol lookup error: floor)

15:06 <cjbe> Artiq: This a bug that was fixed a couple of weeks ago. If you upgrade to the current Artiq 2.* this will go away. https://github.com/m-labs/artiq/issues/828

15:07 <Arpit> Okay, thank you.

16:25 <GitHub79> [artiq] klickverbot commented on issue #685: Indeed – while I didn't mix up bits and bytes, the code mistook eight nanoseconds for just one due to a mismatching device db, as Chris pointed out. At least you now know what I would consider acceptable transfer speeds. ;)... https://github.com/m-labs/artiq/issues/685#issuecomment-331647970

16:40 <GitHub116> [artiq] cjbe commented on issue #685: @klickverbot my dump was from the firmware build you put on the board https://github.com/m-labs/artiq/issues/685#issuecomment-331648808

16:57 <GitHub67> [artiq] klickverbot commented on issue #685: Indeed – while I didn't mix up bits and bytes, the code mistook eight nanoseconds for just one due to a mismatching device db, as Chris pointed out. At least you now know what I would consider acceptable transfer speeds. ;)... https://github.com/m-labs/artiq/issues/685#issuecomment-331647970