https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-1630 Instrument control development <p>In <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-907" title="Controller FPGA code cannot handle commands sent over multiple network packets" class="issue-link" data-issue-key="INSTRM-907"><del>INSTRM-907</del></a> I added a buffering mechanism to try hard to merge commands split over multiple TCP packets (the Xilinx TCP stack treats the TCP stream as a stream of packets, not bytes). But I did not apply that to the command header. We are seeing split 8-byte header packets at Subaru, and need to protect against them.</p> <p>Might be slightly trickier than the <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-907" title="Controller FPGA code cannot handle commands sent over multiple network packets" class="issue-link" data-issue-key="INSTRM-907"><del>INSTRM-907</del></a> work but not much.</p> INSTRM-1630

Apply INSTRM-907 TCP packet merging to the MPS command headers

Task Normal In Progress Unresolved cloomis cloomis EngRun Fri, 17 Jun 2022 05:05:44 +0000 Fri, 1 Sep 2023 16:13:08 +0000 ics_mps_fpga 0 2 <p>This change needs to be made because TCP never guarantees boundaries within the byte stream, and the FPGA cannot expect them.</p> <p>But it is peculiar that the actors-ics VM is sending more such data than we saw at CIT or ASRD. One non-disruptive example is both repeatable and peculiar. When sending back-to-back HK commands for all 84 boards, in the second such command set the 43rd board request packet is split into a 6- and a 2-byte packet. This is after 641*N packets and more interestingly, when crossing the N*1024 per-stream TCP sequence number. Odd, but that did repeat three times. </p> <p>I can check, but it may well be that these (legal and OK) TCP fragmentations always happen at the 1024*N boundaries, but that the <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-907" title="Controller FPGA code cannot handle commands sent over multiple network packets" class="issue-link" data-issue-key="INSTRM-907"><del>INSTRM-907</del></a> work fixed them in nearly all cases. Some quirk about how we are commanding the cobras causes more headers to be fragmented.</p> <p>I'll play with the VM OS sysctl knobs to see if I can perturb things. And can imagine a peephole on the FPGA command stream to insert dummy commands over the 1024*N byte boundaries.</p> <p>Bump.</p> <p>The last move in /data/MCS/20230722_009 ended with an FPGA ERROR 10. This is an error which I added when doing the <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-907" title="Controller FPGA code cannot handle commands sent over multiple network packets" class="issue-link" data-issue-key="INSTRM-907"><del>INSTRM-907</del></a> work, and which indicates that the command parser cannot get a full header. So I think this is the same problem.</p> <p>Also, register error code 10 in the fpgaProtocol decoder as "EMPTY COMMAND HEADER"</p> <p>Code changes pushed. Need to get access to a Kintex 705 online at Subaru to test, along with a USB-connected PC (Linux or Windows) running some reasonable version of the Vivado SDK (just the command-line SDK needed). See my notes at <a href="https://github.com/Subaru-PFS/ics_mps_fpga/blob/master/INSTALL.md" class="external-link" rel="nofollow">https://github.com/Subaru-PFS/ics_mps_fpga/blob/master/INSTALL.md</a></p> <p>One of the spare KC705s has been connected to a Linux box in Hilo, and the new code uploaded (from a remote development system). I still need to run some tests just with that system. </p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=hiro" class="user-hover" rel="hiro">Yoshida, Hiroshige</a> will connect the us-mcs computer to the real FPGA USB port, so we can update that one in the same way.</p> Relates INSTRM-907 Development Rank 0|02qpjd:00r20060i200186403r7i36w