Re: [casper] 10Gbe transmission on roach 1
Hi Jack, Apologies for the late reply. To answer your questions, yes, I have enabled the 10Gbe to receive large packets and I receive packets of the same size that I send out. Cheers, Kaustubh On Thu, Aug 6, 2015 at 8:47 PM, indrajit indra...@iiap.res.in wrote: Dear Kaustubh, Sorry for the delay. The data rate goes like this as per your input .. 5.7142 us is the time taken for 800 clock cycles @ 140 MHz. So the data rate calculation goes by the 8/10 coding technique . where assuming 42 bytes is the UDP header size. (((100/5.71428) *(800*8) ) + 42 )*10 bits = ~11.20 Gbit. You were exceeding the through put limitations. Cheers Indrajit. On Tuesday 04 August 2015 06:37 PM, Kaustubh Rajwade wrote: Hi Indrajit, So I am using the iadc which I am clocking at 560 MHz (hence the board runs at 140 MHz). The data comes in to a 10 GBe block. After 800 clock cycles, I send an eof to the block. Thats pretty much it. The idea is to just free stream the data continuously without any break. For a packet length of 800 or less, this works fine. For a longer packet length the core locks up. Kaustubh On Tue, Aug 4, 2015 at 7:33 AM, indrajit indra...@iiap.res.in wrote: Dear Kaustubh, Can you describe your system block diagram, What ADC, what exactly you want to do .. --Indrajit On Tuesday 04 August 2015 12:57 PM, Kaustubh Rajwade wrote: Yes, but I think that in their case they are running the board at 200 MHz which is greater than 156 MHz. In this case, it is less than 156 so the design should work fine. Am I missing something? Does it have something to do with the 8/10 encoding such that the effective clock rate of the 10 Gbe is less than 156 MHz? Let me know. Thanks, Kaustubh On Tue, Aug 4, 2015 at 12:13 AM, indrajit indra...@iiap.res.in wrote: Dear Kaustubh, please go through this page https://casper.berkeley.edu/wiki/Tutorial_10GbE search for Add a counter to limit the data rate In that they mentioned about the limitations. 1) You want to stream the data continuously at 140 MHz using 10GBe. ? Hi All, I have a simple design on Roach 1 where I stream packets over the 10Gbe network. Currently, I am running the board at 140 MHz. When I try to send packets of length 800, the core locks up. I believe that the 10 Gbe core is synchronized with 156 MHz crystal on the board so this design should work fine on a lower clock rate. Can someone shed some light on this? Thanks, Cheers, Kaustubh -- Thanks and regards __ Indrajit Vittal Barve Engineer, Radio Astronomy Group, Indian Institute of Astrophysics, Gauribidanur. Pin : 561208 Mobile : +91-9845432754. Office : +91-8155291655. -- Thanks and regards __ Indrajit Vittal Barve Engineer, Radio Astronomy Group, Indian Institute of Astrophysics, Gauribidanur. Pin : 561208 Mobile : +91-9845432754. Office : +91-8155291655.
[casper] 10Gbe transmission on roach 1
Hi All, I have a simple design on Roach 1 where I stream packets over the 10Gbe network. Currently, I am running the board at 140 MHz. When I try to send packets of length 800, the core locks up. I believe that the 10 Gbe core is synchronized with 156 MHz crystal on the board so this design should work fine on a lower clock rate. Can someone shed some light on this? Thanks, Cheers, Kaustubh
Re: [casper] 10Gbe transmission on roach 1
Hi Jason, Thanks for that insight. The design is working fine for packet length of 800. Anything beyond that and the core locks up. The tx_over is high suggesting that the tx_buffers overflow for packet length greater than 800. For my application, a size of 800 is sufficient but was just curious as to why the core would lock up for higher packet lengths when the clock speed of the board is less than the clock of the 10 GBe core. Thanks a lot for the help! Cheers, Kaustubh On Thu, Aug 6, 2015 at 8:47 PM, indrajit indra...@iiap.res.in wrote: Dear Kaustubh, Sorry for the delay. The data rate goes like this as per your input .. 5.7142 us is the time taken for 800 clock cycles @ 140 MHz. So the data rate calculation goes by the 8/10 coding technique . where assuming 42 bytes is the UDP header size. (((100/5.71428) *(800*8) ) + 42 )*10 bits = ~11.20 Gbit. You were exceeding the through put limitations. Cheers Indrajit. On Tuesday 04 August 2015 06:37 PM, Kaustubh Rajwade wrote: Hi Indrajit, So I am using the iadc which I am clocking at 560 MHz (hence the board runs at 140 MHz). The data comes in to a 10 GBe block. After 800 clock cycles, I send an eof to the block. Thats pretty much it. The idea is to just free stream the data continuously without any break. For a packet length of 800 or less, this works fine. For a longer packet length the core locks up. Kaustubh On Tue, Aug 4, 2015 at 7:33 AM, indrajit indra...@iiap.res.in wrote: Dear Kaustubh, Can you describe your system block diagram, What ADC, what exactly you want to do .. --Indrajit On Tuesday 04 August 2015 12:57 PM, Kaustubh Rajwade wrote: Yes, but I think that in their case they are running the board at 200 MHz which is greater than 156 MHz. In this case, it is less than 156 so the design should work fine. Am I missing something? Does it have something to do with the 8/10 encoding such that the effective clock rate of the 10 Gbe is less than 156 MHz? Let me know. Thanks, Kaustubh On Tue, Aug 4, 2015 at 12:13 AM, indrajit indra...@iiap.res.in wrote: Dear Kaustubh, please go through this page https://casper.berkeley.edu/wiki/Tutorial_10GbE search for Add a counter to limit the data rate In that they mentioned about the limitations. 1) You want to stream the data continuously at 140 MHz using 10GBe. ? Hi All, I have a simple design on Roach 1 where I stream packets over the 10Gbe network. Currently, I am running the board at 140 MHz. When I try to send packets of length 800, the core locks up. I believe that the 10 Gbe core is synchronized with 156 MHz crystal on the board so this design should work fine on a lower clock rate. Can someone shed some light on this? Thanks, Cheers, Kaustubh -- Thanks and regards __ Indrajit Vittal Barve Engineer, Radio Astronomy Group, Indian Institute of Astrophysics, Gauribidanur. Pin : 561208 Mobile : +91-9845432754. Office : +91-8155291655. -- Thanks and regards __ Indrajit Vittal Barve Engineer, Radio Astronomy Group, Indian Institute of Astrophysics, Gauribidanur. Pin : 561208 Mobile : +91-9845432754. Office : +91-8155291655.
Re: [casper] ROACH 1 udp bad checksum
Hi Jack, Thanks for pointing me in the right direction! Cheers, Kaustubh On Mon, Sep 5, 2016 at 8:14 PM, Jack Hickish <jackhick...@gmail.com> wrote: > Hi Kaustubh, > > I think you missed out on a fix by just a couple of weeks -- see > https://github.com/casper-astro/mlib_devel/commit/ > 129937f7dba65f53db39b3fc0a0c968d2cacf9f6 > > Cheers > Jack > > On Mon, 5 Sep 2016 at 10:00 Kaustubh Rajwade <rkaustub...@gmail.com> > wrote: > >> Hi Jack, >> >> >> Here are commits that I am using: >> >> Old library: commit a88c343 (16 Nov 2010) >> >> New library: commit ecab6f (2 Jan 2015) >> >> Cheers, >> Kaustubh >> >> On Mon, Sep 5, 2016 at 6:07 PM, Jack Hickish <jackhick...@gmail.com> >> wrote: >> >>> Hi Kaustubh, >>> >>> What version of the mlib_devel libraries are you using? >>> >>> Cheers, >>> >>> Jack >>> >>> On Mon, 5 Sep 2016 at 08:11 Kaustubh Rajwade <rkaustub...@gmail.com> >>> wrote: >>> >>>> Hi Casperites, >>>> >>>> I have a simple ROACH 1 design streaming packets via two 10GbE ports >>>> (clock:160 MHz). When I compile the design using old libraries (XSG: 11.4, >>>> Matlab 2009), I have no issues in receiving packets via sockets. When I >>>> compile the same design using newer libraries (XSG:14.7, Matlab2013a), I >>>> can receive packets via tcpdump but I get bad checksum and I cannot capture >>>> the packets using standard methods (e.g. recvfrom()). An example of the >>>> checksum error is shown below: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size >>>> 262144 bytes16:04:58.998384 02:02:0a:00:00:1f > 00:25:90:63:13:ac, >>>> ethertype IPv4 (0x0800), length 8242: (tos 0x0, ttl 255, id 0, offset 0, >>>> flags [DF], proto UDP (17), length 8228, bad cksum 63a8 (->47a0)!) >>>> 10.0.0.31.48400 > 10.0.0.10.48500: [no cksum] UDP, length 8200 >>>> 0x: 0025 9063 13ac 0202 0a00 001f 0800 45000x0010: 2024 >>>> 4000 ff11 63a8 0a00 001f 0a000x0020: 000a bd10 bd74 2010 >>>> 0027 8734* >>>> I validated the payload in the udp packets by sending counter values. >>>> >>>> Has anyone experienced this issue before? >>>> >>>> Cheers, >>>> Kaustubh >>>> >>> >>
[casper] ROACH 1 udp bad checksum
Hi Casperites, I have a simple ROACH 1 design streaming packets via two 10GbE ports (clock:160 MHz). When I compile the design using old libraries (XSG: 11.4, Matlab 2009), I have no issues in receiving packets via sockets. When I compile the same design using newer libraries (XSG:14.7, Matlab2013a), I can receive packets via tcpdump but I get bad checksum and I cannot capture the packets using standard methods (e.g. recvfrom()). An example of the checksum error is shown below: *tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes16:04:58.998384 02:02:0a:00:00:1f > 00:25:90:63:13:ac, ethertype IPv4 (0x0800), length 8242: (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 8228, bad cksum 63a8 (->47a0)!) 10.0.0.31.48400 > 10.0.0.10.48500: [no cksum] UDP, length 8200 0x: 0025 9063 13ac 0202 0a00 001f 0800 45000x0010: 2024 4000 ff11 63a8 0a00 001f 0a000x0020: 000a bd10 bd74 2010 0027 8734* I validated the payload in the udp packets by sending counter values. Has anyone experienced this issue before? Cheers, Kaustubh
