<d_n|a>
whitequark: Thrilled to see progress on the TCP front! I'm quite eager to give it a try – do you think smoltcp master is stable enough to see whether it works nicely on ARTIQ master, or are there some remaining issues you want to fix first?
<whitequark>
d_n|a: I'm currently running some litmus checks on it
<d_n|a>
Okay, cool
<whitequark>
going to grab a push HTTP parser and let the browser try and abuse smoltcp with fault injection enabled
d_n|a has quit [Ping timeout: 240 seconds]
<sb0>
whitequark, great!
<sb0>
whitequark, where do you get those IEC to regular plug power adapters?
<whitequark>
I think that was from aliexpress
<whitequark>
wait
<whitequark>
whicih direction
<sb0>
I want to plug it into the IEC power strip, and put some US wall wart into the other end
<whitequark>
device-to-host is still at 255 kB/s, investigating
<whitequark>
oh, I already figured that out earlier
<whitequark>
ok
mumptai has quit [Quit: Verlassend]
<rjo>
whitequark: good!
<whitequark>
rjo: oh. found the cause of the slowness in device-to-host direction.
<whitequark>
... basically the lack of congestion control
<whitequark>
well, it's more complex than that
<whitequark>
no, it's not really congestion control
<whitequark>
so the network card is so fast that I can just keep sending packets indefinitely until I fill the 64k window of the linux machine
<whitequark>
i.e. I never actually block on the lack of TX buffers
<whitequark>
so I keep sending them and at some point hit my very own retransmit timeout
<GitHub184>
[smoltcp] whitequark pushed 2 new commits to master: https://git.io/vdJTT
<GitHub184>
smoltcp/master c879b39 whitequark: Fix a warning.
<GitHub184>
smoltcp/master 51b2f18 whitequark: Keep dispatching packets from a socket as long as there are any....
<whitequark>
actually, no, that's not what happens
<whitequark>
weird
<whitequark>
oh *facepalm*
<whitequark>
there's no real difference with or without 51b2f18
<whitequark>
the only thing that differed is without 51b2f18 I'd process most every ACK, and with it I lose most packets, which makes the coredevice log inconsistent with the pcap trace
<whitequark>
acks are not delivered reliably so three acks and just the last of them have the same semantics
<whitequark>
ok
<travis-ci>
m-labs/smoltcp#249 (master - 51b2f18 : whitequark): The build passed.
<GitHub125>
smoltcp/master 64369d9 whitequark: Make TCP more RFC 5681 compliant wrt immediate ACKs.
<GitHub182>
[smoltcp] klickverbot commented on commit 546b367: Wouldn't it make sense to return zero time from `poll` if there are still packets to transmit, though? https://git.io/vdJYr
<GitHub158>
[smoltcp] klickverbot commented on commit 546b367: Oh, sorry, didn't realise that this is what you were hinting at in the commit message. https://git.io/vdJY9
<travis-ci>
m-labs/smoltcp#251 (master - 64369d9 : whitequark): The build passed.
<GitHub163>
[artiq] klickverbot commented on issue #685: @whitequark: For a simple test kernel that just sends 1 MB of zeros back and forth, I am now seeing about 18 MB / s (!) from master to kernel, and about 19 MB / s from kernel to master (same Linux 3.19.0-84-generic system as earlier). This almost seems too good to be true – if those numbers hold up in real-world usage, this is definitely good enough for us in the short term. Long-term, we would like
<GitHub129>
[artiq] klickverbot commented on issue #685: @whitequark: For a simple test kernel that just sends 1 MB of zeros back and forth, I am now seeing about 18 MB / s (!) from master to kernel, and about 19 MB / s from kernel to master (same Linux 3.19.0-84-generic system as earlier). This almost seems too good to be true – if those numbers hold up in real-world usage, this is definitely fast enough for us in the short term. Long-term, we would like
<GitHub44>
[artiq] klickverbot commented on issue #685: @whitequark: For a simple test kernel that just sends 1 MB of zeros back and forth, I am now seeing about 18 MB / s (!) from master to kernel, and about 19 MB / s from kernel to master (same Linux 3.19.0-84-generic system as earlier). This almost seems too good to be true – if those numbers hold up in real-world usage, this is definitely fast enough for us in the short term. Long-term, we would like to
_whitelogger has joined #m-labs
<GitHub193>
[artiq] klickverbot commented on issue #685: @whitequark: For a simple test kernel that just sends 1 MB of zeros back and forth, I am now seeing about 18 MB / s (!) from master to kernel, and about 19 MB / s from kernel to master (same Linux 3.19.0-84-generic system as earlier). This almost seems too good to be true – if those numbers hold up in real-world usage, this is definitely fast enough for us in the short term. Long-term, we would like