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?
