00:22 <whitequark> sb0: https://www.youtube.com/watch?v=vgHCvCI8kss

03:16 <sb0> whitequark, how often are kernels crashing when you use the new DDS?

03:16 <whitequark> they mostly crash

03:17 <whitequark> well

03:17 <sb0> the video with the thorium lamp "sock" is more impressive

03:17 <whitequark> to be precise, kernels do not crash

03:17 <whitequark> if they appear to hang, this is because of an lwip bug

03:17 <whitequark> they never get loaded in the first place. there's no running code to crash.

03:17 <sb0> okay, why was that not a problem before?

03:17 <whitequark> it was

03:17 <sb0> lots of different kernels have been loaded through lwip ...

03:18 <whitequark> sb0: https://github.com/m-labs/artiq/issues/598

03:18 <whitequark> rjo hit this way before the DDS merge.

03:19 <whitequark> this became a problem with the rust runtime because rust is trying to be efficient, and doesn't just load an entire packet into a massive static buffer

03:19 <whitequark> this apparently tickles some lwip bug.

03:19 <whitequark> I haven't spent much time looking into it because we are changing stacks anyway

03:20 <whitequark> anyway, what triggers the bug is large packets

03:20 <whitequark> it doesn't actually have to be a kernel, I hit this with RPCs too

03:21 <whitequark> but something in the RPC code makes triggering this bug less likely

03:23 <sb0> this needs a rapid fix, so changing stacks is likely not an option

03:23 <whitequark> flush after every 1024 bytes on the host side?

03:23 <sb0> if the problem is large packets, a workaround that sends small packets is acceptable

03:23 <sb0> yes

03:24 <whitequark> okay

03:24 <sb0> host side? how does this have to do with better efficiency of the new runtime network code?

03:25 <whitequark> memory efficiency

03:25 <sb0> how does this control the size of the packets that the host sends?

03:25 <whitequark> what does?

03:26 <sb0> you're saying that what tickles the bug is better efficiency of the Rust packet processing and memory management on the runtime side

03:26 <whitequark> yes

03:26 <sb0> and that the workaround is flushing every 1024 bytes on the host side

03:26 <whitequark> yes

03:26 <sb0> wasn't the host already sending large packets before, with the previous C code in the runtime?

03:27 <whitequark> it was. but the tcp_recv/tcp_recved functions were called in a different way, I suppose.

03:28 <whitequark> I don't actually know what causes it exactly, I just know that small packets are OK, so we can switch to sending smaller packets

03:29 <whitequark> there's probably some debug switch in lwip...

03:30 <whitequark> I wonder if lwip is exhausting receive buffers

03:31 <sb0> reactos is using lwip?! wow

03:31 <whitequark> lol

03:31 <whitequark> no wonder it barely worked the last time I tried to use it for anything

05:08 <sb0> whitequark, do you happen to have a CA3140EZ op-amp or equivalent by any chance?

05:09 <whitequark> sb0: definitely not

06:33 <GitHub68> [artiq] sbourdeauducq pushed 2 new commits to drtio: https://git.io/v1IRD

06:33 <GitHub68> artiq/drtio c419c42 Sebastien Bourdeauducq: drtio: support for local RTIO core

06:33 <GitHub68> artiq/drtio d37b73f Sebastien Bourdeauducq: drtio: FIFO timeout is handled in gateware + give remote side more time

06:35 <GitHub0> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/v1IRQ

06:35 <GitHub0> artiq/drtio 4e1b497 Sebastien Bourdeauducq: drtio: typo

06:35 <GitHub63> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/v1IR7

06:35 <GitHub63> artiq/drtio 5460202 Sebastien Bourdeauducq: drtio: typo

06:36 <GitHub149> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/v1IRA

06:36 <GitHub149> artiq/drtio 9fdd29d Sebastien Bourdeauducq: drtio: connect KernelInitiator correctly

07:02 <GitHub46> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/v1IE6

07:02 <GitHub46> artiq/drtio 85f2467 Sebastien Bourdeauducq: rtio: fix RTIO/DRTIO timestamp resolution discrepancy

07:19 <GitHub98> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/v1Iug

07:19 <GitHub98> artiq/drtio f4c6d6e Sebastien Bourdeauducq: kc705_drtio_master: fix number of fine RTIO timestamp bits

10:42 <rjo> sb0: you can grab the kc705 (kill my flterm) whenever you see my login sessions idle for more than a few minutes.

10:43 <rjo> flterm (python/asyncio) behaves badly if one rips out that FD from under its nose. i.e. eating up all memory.

18:35 <GitHub26> [artiq] r-srinivas commented on issue #626: To be more explicit, I guess if we can just check it at the start of the experiment at prepare that would be more than enough. Does scripting moninj already work?... https://git.io/v1LyQ

21:33 <GitHub113> [artiq] jordens commented on issue #626: But for that issue it would seem you want something entirely different: a more compact moninj UI. https://git.io/v1tsM

21:49 <GitHub27> [artiq] r-srinivas commented on issue #566: This seemed to happen when I installed artiq 3.0 as well. https://git.io/v1tnE

21:58 <GitHub162> [artiq] r-srinivas commented on issue #626: Making the gui more compact doesn't seem scalable especially if we upgrade the our backplane on the HPC side to have more ttl channels. I think the solution should be independent of the gui. If there's some way to check if a specific ttl channel were overridden that would help. It's not a high priority but it helps you avoid silly errors.... https://git.io/v1tcp

22:13 <GitHub84> [artiq] r-srinivas opened issue #629: Selecting new applet on empty applet dock in artiq 3.0 crashes dashboard https://git.io/v1tlF

22:33 <GitHub158> [artiq] r-srinivas commented on issue #629: Probably related, following the example here (https://github.com/m-labs/artiq/blob/master/artiq/examples/master/repository/code_applet.py), I run into the following error,... https://git.io/v1tBj

22:59 <GitHub17> [artiq] r-srinivas opened issue #630: ERROR:dashboard:quamash.QEventLoop:Task exception was never retrieved when disabling applet on dashboard https://git.io/v1tzf