Hello Rolando,
You expect to see a DC bin, i.e. a large value in channel 0, and I have
often seen a large-ish value in bin 1 as well. After that it will drop off.
If you're seeing a peak in something other than 0, there may be something
wrong. Those spikes at the high end of your spectrum look a
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 mass
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 swit
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, 2
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 r
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
6 matches
Mail list logo
