10:23 <aion> hannes: build running with pin fragments-lru-f

10:25 <aion> unsure aboute the "GC situation" in general. the lru-m mem-footprint seemed to expose GC not doing a good job currently.

10:29 <hannes> aion: your build won't succeed..

10:30 <aion> i kinda noticed by now.

10:30 <hannes> since the interface changed, there are changes needed for mirage-nat and qubes-mirage-firewall..

10:31 <aion> ah, ok. my (wrong) guess was "need to make sure lwt is already pinned down". :D

10:31 <hannes> oh, that may as well be something :)

10:33 <hannes> "GC not doing a good job" <- the OCaml GC is reactive and acts upon thresholds of memory used vs free.. the situation is better afaict in 4.10 with the best-fit allocator. the situation would as well improve once we use String/Bytes and not these Bigarray. I'm keen to discuss this further in Marrakesh with various people involved. :)

10:34 <hannes> so if you have some "fast to reproduce" memory pressure issues (i.e. sending lots of packets / spawning lots of vms / sending huge packets), that'd be definitively of interest to look into more detail (and also to test those with different compilers / memory thresholds)

10:35 <hannes> s/fast/reliable and quick/

10:36 <aion> "sending lots of paketes" seemed to be most reliable trigger here.

10:38 <aion> (yes, my build fail seems to be "result of xmit" related)

10:39 <hannes> ah, i got a similar issue in CI, and #425 contains fixes.. :)

10:41 <aion> dont think i can pin it to two branches at the same time though. *sits back and waits*

10:42 <hannes> my plan is to wait in 425 until CI is green, then merge and rebase the other PRs

10:50 <aion> (oh cute. github seems to have some clock issues? it shows your force push as "_in_ 12 seconds"...)

10:51 <hannes> i'm time travelling all the time ;p

10:51 <aion> i am reading that as "mirage needs a good ntp implementation". ;p

10:52 <hannes> or "hannes needs to setup ntp on his laptop"

19:13 <aion> can confirm mirage-tcpip builds again, and now its mirage-nat failing.