Hi Homin.  I think Danny's suggestion is a good one.  We have had similar
problems with the system working for a while, then packets getting lost.
Making sure that the entries in the ARP table are correct (and the yellow
block MAC addresses are correct) may solve it.  Looking at the switch
traffic with the monitoring built into it might tell you if this is a
problem.

John

On Mon, Mar 12, 2018 at 10:54 PM, David MacMahon <dav...@berkeley.edu>
wrote:

> I think the tx overflow will be OK since the FPGA won't try to send more
> than 10 Gbps.  I think the "rx overrun" flag would be more interesting.
> But probably best to check both of course! :)
>
> Is the X engine clock an exact copy of the F engine clock (i.e. a common
> clock that goes through a massive splitter) or just a clock of the same
> frequency locked to the same reference (but not the exact same clock)?
> Things get more complicated once you run F and X at different rates, so I
> wouldn't recommend that path if you can avoid it.
>
> HTH,
> Dave
>
>
> On Mar 12, 2018, at 22:01, Homin Jiang <ho...@asiaa.sinica.edu.tw> wrote:
>
> Hi Dave:
>
> Thanks of prompt response and suggestion.
> The X engine is running the same clock as the F engine, 2.24GHz/8 =
> 280MHz. Perhaps I should increase the clock in X engine ?
> Yes, there is Tx overflow flag in the model, it will be the first thing
> for me to check.
>
> best
> homin
>
>
>
> On Tue, Mar 13, 2018 at 12:42 PM, David MacMahon <dav...@berkeley.edu>
> wrote:
>
>> Hi, Homin,
>>
>> The first thing to do is figure out where packet loss is actually
>> happening.  The fact that you have to reset the 10G yellow blocks to get
>> things going again suggests that the X engines are not keeping up with the
>> data rate (since the F engines will happily churn out 8.96 Gbps data
>> regardless of the receivers' states and the X engines will happily churn
>> out data regardless of the PC's state, it seems that the only way for the
>> 10 GbE blocks to get confused is if the X engines are not keep up with the
>> incoming data rate).  I assume the F engine ROACH2s are being clocked via
>> their ADCs.  How are the X engine ROACH2s being clocked?
>>
>> Assuming the F-to-X packets are going through a switch, you could query
>> the switch to see what it thinks the incoming and outgoing data rates are
>> on the various ports involved.
>>
>> Does your design have any way of capturing the overflow flags of the 10
>> GbE cores?
>>
>> Dave
>>
>> On Mar 12, 2018, at 19:39, Homin Jiang <ho...@asiaa.sinica.edu.tw> wrote:
>>
>> Dear Casperite:
>>
>> We have been deployed a 7(actually 8) antenna packetized correlator on
>> Mauna Loa Hawaii. Running at 2.24GHz clock, that means 8.96 G bits per
>> second for each 10G ethernet. The packet size is 2K. There are 8 sets of
>> ROACH2 as F engines, the other 8 sets of ROACH2 as X engines. Data packets
>> from F to X looks fine, the problem of lost packets is the integration data
>> from X engine to the computer. The 10G yellow blocks in X engines handle
>> the incoming data packets from F engine at the data rate of 8.96 Gbps, and
>> output the integration data to PC, the outgoing data rate depends on the
>> integration time, usually it is longer than 0.5 second. The syndrome is
>> that packets lost happened by specific X engines after 10,20 minutes or
>> couple of hours. Once it happened, we reset all the 10G yellow blocks in F
>> and X, then the system revived.
>>
>> I have no idea about the 10G ethernet yellow block. Any comments of
>> suggestions are highly welcome.
>>
>> best
>> homin jiang
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To post to this group, send email to casper@lists.berkeley.edu.
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>
>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To post to this group, send email to casper@lists.berkeley.edu.
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To post to this group, send email to casper@lists.berkeley.edu.

Reply via email to