Hi Thank you Jack.
I didn't see tx overflow indicate and I connect the 10Gb tx_overflow port to led2 of ROACH2. In different seeting,I found when there is a overflow and I can not received any package.In my firmware, I also select the option of 'Enable Large TX Frames(8k+512).So, I am sure the firmware worked well. And I need to check the receive code. Cheers! >------------------------------------------------------------------------ ZHANG Laiyu Phone(China) 010-88233078 Cellphone(China) 13681385567 E-mail: [email protected] Address: 19B Yuquan Road,Shijingshan District,Beijing，China Department: Center for Particle Astrophysics Office: Astrophysics Building 205 Institute of High Energy Physics, CAS web: http://www.ihep.cas.cn >------------------------------------------------------------------------ -----原始邮件----- 发件人:"Jack Hickish" <[email protected]> 发送时间:2020-12-22 19:45:30 (星期二) 收件人: "zhang laiyu" <[email protected]> 抄送: casper <[email protected]> 主题: Re: How to check or modify the network setting on ROACH2 ? Traffic from the ROACH doesn't go through the PowerPC, so my guess would be that it's unlikely anything is causing issues there. I'm not actually sure how you change PPC settings which aren't set via the "start_tap" command. For >8kB packets, you should check any options to increase the TX buffer options in the 10GbE yellow block. The 10GbE block has output ports indicating overflows in the TX path -- if you are not seeing these strobe ever, and you are confident that the transmission logic in your firmware is working, then I think that it is very likely that any issues they are in your receive code. Cheers Jack On Tue, 22 Dec 2020 at 10:40, zhang laiyu <[email protected]> wrote: Hi,Jack I realized a firmware that acquire data using ADC_MKID_4X yellow block and then pack the data into multi 64bits data to 10Gb yellow block in ROACH2.The PC receiver UDP package through 10Gb cable.The ADC_MKID_4x board clock is 512MHz,and the ROACH2 worked on 128MHz. I use part of Tutorial 2 's design to control the tx_valid port and tx_end_of_frame port of the 10Gb yellow block .I set the tx_valid is 1081 and the tx_end_of_frame was set to 1441. The UDP package is 8648 bytes less than the max capacity (8k+512) of 10Gb yellow block . Now,the firmware worked well. I can get about 1500 UDP frames without losing data in the PC server once a time. Because every UDP frame has frame counter,so I can judge that the frames is continuous or not.The firmware was running continuously,and I can get right data from PC during different time. The frame counter is continuous. But when I want to receive much more packages,such as 100000 packages once a time, I found that the fram counter is not continuous, part of the frame was lost.The valid data (ADC data)rate is 6.144Gb/s. (512*10^6*12bit/s) I suspect the reason of losting UDP frams coming from two sources. Frist, the PC server's receive program(C++) need to optimize to realize high frequency and large capacity udp data receiving . Another reason may be coming from the network setting of the linux system in PowerPC on ROACH2, I am not sure. My question is how to check and modidy the network setting of the linux system in ROACH2？ I want to check the max send buffer (MTU )of the PowerPC. Thank you! Cheers! >------------------------------------------------------------------------ ZHANG Laiyu Phone(China) 010-88233078 Cellphone(China) 13681385567 E-mail: [email protected] Address: 19B Yuquan Road,Shijingshan District,Beijing，China Department: Center for Particle Astrophysics Office: Astrophysics Building 205 Institute of High Energy Physics, CAS web: http://www.ihep.cas.cn >------------------------------------------------------------------------ -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/31cb0350.f601.1768a5742ff.Coremail.zhangly%40ihep.ac.cn.
