On Fri, Jun 7, 2013 at 1:14 PM, Gary, Dale E. <[email protected]> wrote: > Hi All,
Hello > We previously were successful in setting up the 10gbe core for ROACH1 using > tap_start, which I believe resulted in a process tgtap appearing in the > ROACH. > > I am using the same method for ROACH2 (using the latest ROACH2 rev 2 file > system loaded via netboot), and there is no reported error, but the ARP > table does not contain the MAC address for the destination IP address, and > when I check the processes running on the ROACH2 I do not see tgtap. As mentioned by others: The tgtap logic on roach2 runs internal to tcpborphserver3. There should be a ?tap-info command you could run to look at the arp table as seen by the roach2 - it will show timeout information not visible using the current python interface. A while ago I tried improving the logic which generates arp traffic, the code is at github.com/ska-sa/katcp_devel/blob/master/tcpborphserver3/tg.c, in particular in function run_timer_tap - the code path which might still be problematic is on line 821 (if(burst < 1)). You could increase 1 to some larger number, or remove the test entirely. During the week I may add some logic to check for starvation problems. However, there are fundamental limits at play: The interface between the PPC and FPGA is pretty slow/inefficient when compared to what can come in on 10GbE, so it is important to make sure that the PPC doesn't get swamped - and the greatest sources of traffic in this regard are other roaches sending arp requests (an N^2 problem) - so on roach2 I have tried to send out arp traffic reasonably conservatively - maybe even too conservatively ... regards marc
