<sb0>
_florent_, have you looked into the clocking api and the synchronization system for the DRTIO transceivers?
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 258 seconds]
sb0 has quit [Quit: Leaving]
ohsix has quit [Ping timeout: 260 seconds]
<GitHub88>
[artiq] cjbe commented on issue #837: @whitequark I followed your instructions, setting the UART logging level to WARN so the system was not slowed down by UART traffic, and modifying the EthernetTracer to log as info, rather than just a straight print.... https://github.com/m-labs/artiq/issues/837#issuecomment-334106461
<_florent_>
sb0: not yet
ohsix has joined #m-labs
<GitHub36>
[artiq] whitequark commented on issue #837: @jordens No incoming packet after outgoing packet 17 makes it through to the core device at all. (This is not a case of the poll function not being called because otherwise it'd extract all four buffers in rapid succession.) Not sure what's going on. https://github.com/m-labs/artiq/issues/837#issuecomment-334112813
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
juliusb has joined #m-labs
rohitksingh has joined #m-labs
<GitHub168>
[artiq] dhslichter commented on issue #407: AV off isn't an option for us at NIST, unfortunately, without jumping through a large number of administrative hoops, so we can't do any tests without AV in the near term. @whitequark what do you see on your Windows machine without AV? https://github.com/m-labs/artiq/issues/407#issuecomment-334202010
<GitHub196>
[artiq] dhslichter commented on issue #407: AV off isn't an option for us at NIST, unfortunately, without jumping through a large number of administrative hoops, so we can't do any tests without AV in the near term. @whitequark what do you see on your Windows machine without AV running the same code? https://github.com/m-labs/artiq/issues/407#issuecomment-334202010
<GitHub85>
[smoltcp] phil-opp opened pull request #49: Move device-specific parts of `EthernetInterface` to new `EthernetDevice` type (master...split-ethernet-interface) https://git.io/vd4Jm
<GitHub128>
[smoltcp] whitequark commented on issue #49: You'll need to motivate these changes significantly better, because so far I don't understand the rationale for most of them.... https://git.io/vd4JF
<GitHub182>
[artiq] jordens commented on issue #837: Well. We need to determine whether the packets are lost in the switch, in the PHY, or in the MAC, or in the smoltcp interface to the MAC. There are several options:... https://github.com/m-labs/artiq/issues/837#issuecomment-334222889
<GitHub111>
[artiq] whitequark commented on issue #407: @dhslichter Not currently. We'll need to move to LLVM 4.0 first (not a lengthy process). Then implement and test an LLD backend. I'll need to look at it in-depth to give an estimate. https://github.com/m-labs/artiq/issues/407#issuecomment-334223670
<GitHub64>
[smoltcp] phil-opp commented on issue #49: See https://github.com/embed-rs/net/issues/1#issuecomment-287813986 for some reasons why we don't like the device trait in its current form. This change would allow us to reuse most parts of smoltcp (e.g. the TCP state machine, packet construction and processing) with our own device API.... https://git.io/vd4q4
<GitHub29>
[smoltcp] batonius opened issue #50: [meta] smoltcp as Redox network stack https://git.io/vd4KV
<GitHub110>
[smoltcp] whitequark commented on issue #50: > I think smoltcp should support several devices, each with several subnets assigned to them. This way we would be able to add loopback interface by adding a loopback device with 127.0.0.1/8 assigned to it.... https://git.io/vd41G
mumptai has quit [Remote host closed the connection]
<GitHub74>
[smoltcp] whitequark commented on issue #49: > See embed-rs/net#1 (comment) for some reasons why we don't like the device trait in its current form. This change would allow us to reuse most parts of smoltcp (e.g. the TCP state machine, packet construction and processing) with our own device API.... https://git.io/vd49V
<GitHub123>
[smoltcp] whitequark commented on issue #49: > See embed-rs/net#1 (comment) for some reasons why we don't like the device trait in its current form. This change would allow us to reuse most parts of smoltcp (e.g. the TCP state machine, packet construction and processing) with our own device API.... https://git.io/vd49V
<GitHub197>
[smoltcp] whitequark commented on issue #3: cc @edef1c https://git.io/vd4Hl