Hey Homin,
I think that looks fine -- it's only an issue if they get changed by a
rouge process afterwards.
- Danny
On 14 March 2018 at 2:43:43 pm, Homin Jiang (ho...@asiaa.sinica.edu.tw)
wrote:
Dear Danny and John:
Thanks of your suggestion. I checked the ARP table as below, the unused
ones
Dear Danny and John:
Thanks of your suggestion. I checked the ARP table as below, the unused
ones are all "FF FF ...". Did you suggest assign all the ARP table with
different address ?
best
homin
ARP Table:
IP: 10. 0. 0. 0: MAC: FF FF FF FF FF FF
IP: 10. 0. 0. 1: MAC: FF FF FF FF FF
Dear Danny and John:
Thanks of your suggestion. I checked the ARP table as below, they are all
"FF FF ... FF" for unused X engine ports except the one with IP
=10.0.0.141. The F engine is all "FF FF". Did you suggest that assign
different numbers to all the IP including the unused ones ?
best
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
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
Hi Homin,
Could this be due to a rouge ARP process? We have seen failure modes where
the ARP configuration fills itself with FF:FF:FF:FF and starts broadcasting
UDP traffic. We hard-code the ARP table to stop this.
I also recall reading something similar to do with anti-flood contorl on
some
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,
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
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
9 matches
Mail list logo
