We've seen errors like this before with two possible causes: *) What software versions are you running? https://casper.berkeley.edu/w/index.php?title=LatestVersions *) Ensure the PPC is clocked at 533/66MHz.
Jason On 20 Jul 2011, at 18:10, Jon Losh wrote: > 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? > > > > > > >
