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
fengling has joined #m-labs
rohitksingh_work has joined #m-labs
digshadow has quit [Ping timeout: 264 seconds]
digshadow has joined #m-labs
<whitequark>
sb0: so, hmm
<whitequark>
I can write the Rust session such that it doesn't keep the entire *input* packet in RAM
<whitequark>
but you send the length initially, so it has to keep the entire *output* packet in RAM regardless
<sb0>
okay
<whitequark>
this seems a bit silly.
<whitequark>
we could modify the protocol (in both ways, i guess) so it could transfer with chunks
<whitequark>
0x80000000|length ~ more chunks to follow
<whitequark>
in both directions*
<sb0>
what's the overhead with that?
<whitequark>
well, you could send 64k or 1M chunks or something
<sb0>
will it actually make things better or just fragment data into lots of small IP packets?
<whitequark>
in which case it would be exactlyequivalent to the current scheme
<whitequark>
no, making chunks smaller than IP packets would be pointless
<whitequark>
counterproductive, even
fengling has quit [Ping timeout: 240 seconds]
<sb0>
ok
<sb0>
can you look into #550 first as this is user-facing?
fengling has joined #m-labs
<whitequark>
sb0: btw, moninj still uses udp
<sb0>
yes, that should change, as mentioned inmy
<sb0>
email from july 15
<whitequark>
ah I see
<sb0>
and to keep everything in the device_db, i suppose the moninj client (GUI) will have to tell the core device what channels it wants to monitor and how
<whitequark>
sb0: did you fix the problem with rtio analyzer where it would drop odd frames or something like that?
<whitequark>
because the runtime is trying to output \x74 \x74 \x6c \x31 \x32 \x1e \x69 \x20 \x39 \x39 \x0a \x1d
<whitequark>
which has all the necessary delimiters
<sb0>
yes, this should be fixed
<sb0>
can you reproduce the problem on the board? maybe he just has some old gateware...
<whitequark>
i can reproduce it on the lab kc705
<whitequark>
if I add a symbol to any of the fields, you get a frame shift
<whitequark>
this particular combination of strings miraculously doesn't result in a shift but it eats the delimiters...
<whitequark>
you reverted the workaround for coreanalyzer bug in that commit
<sb0>
well yes, there should be no such bug anymore, this isn't a full workaround anyway
<whitequark>
the workaround doesn't help this time, so it is a different bug
digshadow has quit [Read error: Connection reset by peer]
<whitequark>
sb0: will you look into it?
<sb0>
whitequark, can you precisely characterize the gateware problem?
<whitequark>
sb0: it appears to drop every 5th character
<whitequark>
let me check this again
<sb0>
the gateware doesn't know about characters
<GitHub30>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vicIt
<GitHub30>
artiq/master a7dd356 Sebastien Bourdeauducq: rtio/phy/ttl: support 'set sensitivity and sample' command (#218)
<sb0>
whitequark, if I have a global "foo = 2" which is constant, and then do "rtio_output(...foo...)", the compiler generates a memory access, doesn't it?
<sb0>
who took the "(status & RTIO_I_STATUS_OVERFLOW)" and "(status & RTIO_I_STATUS_EMPTY)" tests out of the loop in rtio_input_timestamp()?
<sb0>
the RTIO core is designed for the runtime to immediately proceed when status==0, here, you are testing for status==0 and then for RTIO_I_STATUS_OVERFLOW and RTIO_I_STATUS_EMPTY again
Kaifeng has joined #m-labs
<whitequark>
sb0: re "foo = 2": depends on how you do it
<whitequark>
if it's a normal python global (not defined inside kernel) then no
<whitequark>
it will be inserted inline
<whitequark>
re tests: no idea. not me
<sb0>
whitequark, are you using the kc705? why did ping fail?
<whitequark>
sb0: I forgot to kill a script
<GitHub140>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vic3D
<whitequark>
what do you expect me to do anyway? inline everything into the build tree? that will in fact create "a lot of work and frustration"
<sb0>
this is what the C runtime does and it's manageable
<whitequark>
yeah, and the C runtime is also chock full of broken stuff. like your printf
<sb0>
one printf bug isn't "chock full of broken stuff". and I'm talking about how to split and organize code, this has nothing to do with bugs inside functions
<whitequark>
okay.
<whitequark>
so, i see exactly one real concern. that crates.io goes down.
<sb0>
there's also all this work of packaging, uploading, downloading, and now mirroring <200LOC stuff
<sb0>
potentially keeping track of versions
<sb0>
it also doesn't play nice with git-bisect
<whitequark>
how exactly it doesn't?
<whitequark>
if you check out a commit, it has a Cargo.lock in it, which contains hashes of the exact versions that will be used for building every dependency
<sb0>
if there is some API incompatibility and git-bisect tries to cross it, then it breaks