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? > >
