Re: [casper] debugging communication with one_GbE from roach-2 's fpga
Excellent. Thanks for the info. Jack On Jan 22, 2013 5:01 AM, Henno Kriel he...@ska.ac.za wrote: Hi The 1GbE core is configured to work in the same way as the 10GbE core with regards to tgtap. Regards Henno On Mon, Jan 21, 2013 at 3:52 PM, Marc Welz m...@ska.ac.za wrote: Hello A question to anyone in the know: is there a runtime way to configure the source IP/mac settings on roach 2 -- i.e. is tap_start implemented for the 1GbE core? So if the 1GbE offers the same register layout as the 10GbE core then this should work out of the box (just use a different name as tgtap parameter)... but I think there might be some bus width differences which might have to be hidden ? regards marc -- Henno Kriel DSP Engineer Digital Back End meerKAT SKA South Africa Third Floor The Park Park Road (off Alexandra Road) Pinelands 7405 Western Cape South Africa Latitude: -33.94329 (South); Longitude: 18.48945 (East). (p) +27 (0)21 506 7300 (p) +27 (0)21 506 7365 (direct) (f) +27 (0)21 506 7375 (m) +27 (0)84 504 5050
Re: [casper] debugging communication with one_GbE from roach-2 's fpga
Hello However, we are stuck in debugging the system: we think we are sending stuff properly, but we can not read anything from the python socket, coming from our roach 2 fpga. Try running tcpdump on the receiving PC. If you are using tgtap logic, you should see occasional arp traffic from the roach to work out where to send its data. Some switches have UDP flood protection - if they see lots of UDP traffic, especially broadcast UDP, they throttle it down. If tgtap is running and I remember things correctly, data destined for machines which do not respond to arp traffic will be broadcast. Alternatively if the destination MAC is all zeros, switches typically discard traffic instead of sending it on. I believe you are one of the first people to use the GbE port, so please let us know of your progress. regards marc
Re: [casper] debugging communication with one_GbE from roach-2 's fpga
Hi Ionna, Jeff In addition to John and Mark's suggestions, I'd recommend checking: 1) If you're using SELinux, disable it as it causes all sorts of grief. 2) Check the MTU on your ethernet port is set to be larger than your packet size. 3) Make sure that you don't have a firewall up on that port. 4) Check if your Ethernet port is going down when the FPGA is reprogrammed (if you've got a switch in between this shouldn't happen). If you've already checked your socket with roach1 UDP code, then most of these points are moot. Hopefully one stands out though... Cheers Danny
Re: [casper] debugging communication with one_GbE from roach-2 's fpga
Hi Ioana, I'm attaching a model and python script that Guy Kenfack and I knocked together worked on at the Green Bank workshop. We sent a counter and saw the data at the right IP/port in wireshark. A question to anyone in the know: is there a runtime way to configure the source IP/mac settings on roach 2 -- i.e. is tap_start implemented for the 1GbE core? Cheers, Jack On 21 January 2013 08:07, Marc Welz m...@ska.ac.za wrote: Hello However, we are stuck in debugging the system: we think we are sending stuff properly, but we can not read anything from the python socket, coming from our roach 2 fpga. Try running tcpdump on the receiving PC. If you are using tgtap logic, you should see occasional arp traffic from the roach to work out where to send its data. Some switches have UDP flood protection - if they see lots of UDP traffic, especially broadcast UDP, they throttle it down. If tgtap is running and I remember things correctly, data destined for machines which do not respond to arp traffic will be broadcast. Alternatively if the destination MAC is all zeros, switches typically discard traffic instead of sending it on. I believe you are one of the first people to use the GbE port, so please let us know of your progress. regards marc
Re: [casper] debugging communication with one_GbE from roach-2 's fpga
Hello A question to anyone in the know: is there a runtime way to configure the source IP/mac settings on roach 2 -- i.e. is tap_start implemented for the 1GbE core? So if the 1GbE offers the same register layout as the 10GbE core then this should work out of the box (just use a different name as tgtap parameter)... but I think there might be some bus width differences which might have to be hidden ? regards marc
Re: [casper] debugging communication with one_GbE from roach-2 's fpga
We haven't actually used the 1GbE core at all at SKA-SA, but AFAIK, it's the same and tgtap should work out the box. Henno's actually the authoritative source for all things 1GbE. He might be able to offer more tomorrow. Jason On 21 Jan 2013, at 15:52, Marc Welz wrote: Hello A question to anyone in the know: is there a runtime way to configure the source IP/mac settings on roach 2 -- i.e. is tap_start implemented for the 1GbE core? So if the 1GbE offers the same register layout as the 10GbE core then this should work out of the box (just use a different name as tgtap parameter)... but I think there might be some bus width differences which might have to be hidden ? regards marc
Re: [casper] debugging communication with one_GbE from roach-2 's fpga
Hi Casper group, We managed to take the FPGA 1GBE on ROACH2 fully under control, great thanks to John, Marc, Danny, Jack, and Jason! Wireshark was extremely helpful, as it can see packets as long as the receiver's IP is set correctly. For python grabbing to work, it turned out that we simply had to configure the sender's IP to have the same subnet as the receiver IP (meaning the first 3 segments of the IP). Thanks again! From: casper-boun...@lists.berkeley.edu [casper-boun...@lists.berkeley.edu] on behalf of Danny Price [danny.pr...@astro.ox.ac.uk] Sent: Monday, January 21, 2013 3:39 AM To: casper@lists.berkeley.edu list Subject: Re: [casper] debugging communication with one_GbE from roach-2 's fpga Hi Ionna, Jeff In addition to John and Mark's suggestions, I'd recommend checking: 1) If you're using SELinux, disable it as it causes all sorts of grief. 2) Check the MTU on your ethernet port is set to be larger than your packet size. 3) Make sure that you don't have a firewall up on that port. 4) Check if your Ethernet port is going down when the FPGA is reprogrammed (if you've got a switch in between this shouldn't happen). If you've already checked your socket with roach1 UDP code, then most of these points are moot. Hopefully one stands out though... Cheers Danny
