Hi everyone, Thanks for all of your helpful replies!
We only have one standing request to the roach at a time if my understanding of the Python katcp package is correct. All of the fpga.read_int calls (no explicit blindwrite calls anywhere) from Python won't allow the Python program to proceed until they return with some value or error, right? As we're only communicating with the roach via these calls, I think we're waiting for responses as it stands, but still getting the odd timeout error. For what it's worth, I've also gotten the odd read request timeout with other designs during the course of casually making manual read and write requests, sometimes persistent to the point of having to reprogram/reset the roach. I've already forced the computer's network connection going to the roach network to be 100Mbit and verified that it's running at that rate with ethtool. Is there anything else that should be set? I need to find a serial cable so I can take a look at those diagnostic messages.... The PPC-side data dump is a good idea, but a bit overkill for what we're doing. We can still read data from the roach; it just locks up somewhat frequently and has to be jiggered until it unsticks itself. For what we want from this tool at the moment, it's probably not worth the overhead. On Wed, Jul 20, 2011 at 3:45 AM, Andrew Siemion <[email protected]>wrote: > Hi Jon, > > When we have needed to read a BRAM or register repeatedly and at a high > cadence, we have instantiated a simple C program running directly on the > PPC that queries the memory and dumps it out in UDP packets. We have > occasionally combined this with repeated reads of an accumulation counter > to, for example, output spectra from a spectrometer every time a new > accumulation was ready. For applications where you want to read out > memory as fast as possible, a push architecture over UDP is probably > better than repeated TCP requests. This would require writing a bit of > code though, maybe "start-send" and "end-send" commands, then executing > them using KATCP's shell execute functionality. > > Cheers, > > Andrew > > > > On 7/20/11 12:30 AM, "Jason Manley" <[email protected]> wrote: > > >Are you continuously sending requests even before you get the responses? > >If you keep sending requests while the ROACH is processing a request > >(like retrieving the snap block's BRAM contents) then those will be > >queued in the networking stack's TCP receive buffer. They should be > >serviced when tcpborphserver completes its current task, unless the > >buffer overflows. Maybe this is what's happening if you're bombarding it > >with requests. > > > >My current use of the system is sub-optimal in that I wait for a request > >to complete before issuing the next command. This is bulletproof but you > >do take a performance hit without any pipelining due to network > >round-trip times. > > > >Jason > > > > > >On 19 Jul 2011, at 23:19, Jon Losh wrote: > > > >> Hi, > >> > >> We have a piece of diagnostic software that continually reads from a > >>snap to give us real-time data at various stages in our F-engine. One of > >>the issues we're running into is read and requests to the roach timing > >>out. I saw a suggestion in another thread on the mail archive to force > >>the ethernet link speed to 100Mbit/sec, which I did, but this doesn't > >>appear to have helped. Our network topology is a computer is connected > >>to the roach via a gigabit ethernet switch. > >> > >> Am I perhaps inundating the PowerPC with read/write requests? They're > >>going out at about 25 requests/second. If that's not the issue, are > >>there any other known workarounds like the forcing of the ethernet link > >>speed? > > > > > > >
