[casper] UDP
On Mon, 2011-06-20 at 12:54 -0700, casper-requ...@lists.berkeley.edu wrote: Hello, 0.5 mbyte buffer per port I read in the spec: Buffer memory: 512 KB embedded memory per unit seems global for a switch. That resemble to what I am used to. Usually on chip port buffers are at most 17KB. These devices are tuned for a traffic which is mainly TCP, and UDP with data integrity control delegated to clients. Basically they drop a lot of packets, which is of little importance in usual use, as those packets are requested by the listener and re-emitted. Of course in contention situations this behaviour may impact badly things like voice transportation. In your design, many lines converge to one. Hope the time statistic is fair. The time to be considered to examine this is: buffer_size/effecive_line_speed Be carefull that not all of the buffer memory may be available for one port, depending on the policy adopted in the switching strategy. Jean
Re: [casper] UDP
Hi all, Some words about our experiences. Especially the microcomputers tend to send packets in clusters, that is: 100 Mbps of traffic over 1 Gbps link may have 10% of the time running at line speed, other times line is idle. Can happen in iBobs too if they decide to send at the same time. We found this out when trying to push 896 Mbps from two computers over a 1 Gbps link. Solved this by setting one of the computers to act as a nat server for the other, after that zero errors. TCP is not a solution either for long fat pipes, takes about half an hour for it to run to full 1 Gbps speed. If one packet is lost, speed drops to half and there is another half an hour wait. Kind of amazing that the memory in routers is quite expensive when normal microcomputer dram is fast enough... Cheers, Jouko -- Life is pretty simple: You do some stuff. Most fails. Some works. You do more of what works. If it works big, others quickly copy it. Then you do something else. The trick is to do something else. On Tue, 21 Jun 2011, Jean Borsenberger wrote: On Mon, 2011-06-20 at 12:54 -0700, casper-requ...@lists.berkeley.edu wrote: Hello, 0.5 mbyte buffer per port I read in the spec: Buffer memory: 512 KB embedded memory per unit seems global for a switch. That resemble to what I am used to. Usually on chip port buffers are at most 17KB. These devices are tuned for a traffic which is mainly TCP, and UDP with data integrity control delegated to clients. Basically they drop a lot of packets, which is of little importance in usual use, as those packets are requested by the listener and re-emitted. Of course in contention situations this behaviour may impact badly things like voice transportation. In your design, many lines converge to one. Hope the time statistic is fair. The time to be considered to examine this is: buffer_size/effecive_line_speed Be carefull that not all of the buffer memory may be available for one port, depending on the policy adopted in the switching strategy. Jean
[casper] Trouble running tutorial 3
Hello All, I am trying to run the tutorial 3 spectrometer on a ROACH + 1x_3GSPS_iADC. I used the bof file provided by casper as well as our own bof file compiled here (on ubuntu) using the simulink model from casper after replacing the pfb and fft blocks from our 'local' library. In both cases I got a strange symmetric spectrum ( http://www.das.uchile.cl/~rfinger/ROACH/tut3_1.png ) which doesn't change to much when a test tone is applied. The iADC clock was 800MHz, 0dBm, provided by a valontech 5007 synthesizer, and the test tone was 100/200 MHz, 0dBm. After a few integration periods I get a 'timeout' error, and a blank window in the spectrometer.py application. Does anyone got the same problem? Thanks, Ricardo. -- Ricardo Finger Camus Electrical Engineer Astronomy Department University of Chile Of: 56(2)9771119 Casilla 36-D, Santiago. http://www.das.uchile.cl/lab_mwl/
Re: [casper] Trouble running tutorial 3
Hi Ricardo, Generally what we refer to as the iADC is 1Gsps (or 2 interleaved): https://casper.berkeley.edu/wiki/ADC2x1000-8 Is this what you're using, or is it our national ADC at 3Gsps? https://casper.berkeley.edu/wiki/ADC1x3000-8 Have you tried loading the bof file in SVN without making any changes? https://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2010/roach_tut3_wideband_spec/r_spec_2048_r105_2010_Jul_26_1205.bof If you're using the National board, you'll need to switch out the ADC yellow block as well. Mark On Tue, Jun 21, 2011 at 2:14 PM, Ricardo Finger rfing...@gmail.com wrote: Hello All, I am trying to run the tutorial 3 spectrometer on a ROACH + 1x_3GSPS_iADC. I used the bof file provided by casper as well as our own bof file compiled here (on ubuntu) using the simulink model from casper after replacing the pfb and fft blocks from our 'local' library. In both cases I got a strange symmetric spectrum ( http://www.das.uchile.cl/~**rfinger/ROACH/tut3_1.pnghttp://www.das.uchile.cl/~rfinger/ROACH/tut3_1.png) which doesn't change to much when a test tone is applied. The iADC clock was 800MHz, 0dBm, provided by a valontech 5007 synthesizer, and the test tone was 100/200 MHz, 0dBm. After a few integration periods I get a 'timeout' error, and a blank window in the spectrometer.py application. Does anyone got the same problem? Thanks, Ricardo. -- Ricardo Finger Camus Electrical Engineer Astronomy Department University of Chile Of: 56(2)9771119 Casilla 36-D, Santiago. http://www.das.uchile.cl/lab_**mwl/ http://www.das.uchile.cl/lab_mwl/
Re: [casper] UDP
Thanks for pointing out that the spec differed from the catalog description I had read. I think I'm going to go with a Cisco SG200-26. It has a 4MB shared buffer for 24+2 mini-GBIC gigabit ports. This is the largest shared buffer I've seen for ~24 ports. It supports frame sizes up to 10kbytes Will let you know if I have problems. I believe you and others are making the point that the data will be synchronous from all 16 boards and therefore the data rate will be high for brief blips rather than a continuous average. But I would have to hope that 1.2Mbytes/sec couldn't overpower a gigabit switch even if it arrived all at once (I have some discretion in how often the packets are generated). I think/hope that the larger problem will be on the linux side buffering for which I will try Jason's suggestions. Thanks to all for the help. Tom On Tue, Jun 21, 2011 at 1:52 AM, Jean Borsenberger jean.borsenber...@obspm.fr wrote: On Mon, 2011-06-20 at 12:54 -0700, casper-requ...@lists.berkeley.edu wrote: Hello, 0.5 mbyte buffer per port I read in the spec: Buffer memory: 512 KB embedded memory per unit seems global for a switch. That resemble to what I am used to. Usually on chip port buffers are at most 17KB. These devices are tuned for a traffic which is mainly TCP, and UDP with data integrity control delegated to clients. Basically they drop a lot of packets, which is of little importance in usual use, as those packets are requested by the listener and re-emitted. Of course in contention situations this behaviour may impact badly things like voice transportation. In your design, many lines converge to one. Hope the time statistic is fair. The time to be considered to examine this is: buffer_size/effecive_line_speed Be carefull that not all of the buffer memory may be available for one port, depending on the policy adopted in the switching strategy. Jean
Re: [casper] Roach ADC interleave problem?
Your experience is the same as mine: Once you turn the bit on, the phase is randomly maligned by up to about three clocks. Looks like it stays at whatever phase setting it chooses once the command is sent thogh. Makes me suspect the error is in transmission, especially since we don't have problems with this on a Nalllatech board. You're right, turning off the bit only occasionally fixes the signal. Strange. It is interesting to note that the full range of the phase offset is 1020ps (880 coarse + 140 fine). At a 1500MHz clock, the ADC will get a sample every 333ps. 1020/333 = 3.07229 maximum delay offset. I bet random bits are being thrown (or something), causing the strange offset. We might see the noise if some of the lower bits (which are supposed to be all '1's were corrupted too. Just a theory. --Ryan Monroe - Original Message - From: William Mallard w...@llard.net To: Ryan Monroe ryanmmon...@comcast.net Cc: casper@lists.berkeley.edu Sent: Monday, June 20, 2011 5:14:47 PM Subject: Re: [casper] Roach ADC interleave problem? Ryan Monroe wrote: I'm trying to interleave two 3GSPS iADCs (083000s). While I have the gain and offset working properly, whenever I try and adjust the phase, ADC1 starts going haywire (random phase offset, noise occasionally added to signal, etc). Subsequently turning off the phase adjust bit in the coarse phase register stops the chaos. Does turning off the phase adjust bit always fix the signal? It's been my experience that toggling the bit throws the even and odd samples out of phase randomly and by up to 3 clock cycles. I eventually gave up and resigned myself to using tunable analog delays (which is suboptimal).
Re: [casper] Trouble running tutorial 3
Hello Mark,
Thanks for your prompt answer.
We are using the ADC1x3000-8 in the ZDOK 0.
The first thing we did was to run the bof file you mentioned, just
after downloaded.
I just did it again with the same result:
root@roach-laptop:~/Desktop/workspace# ./spectrometer.py 192.168.1.10
-b r_spec_2048_r105_2010_Jul_26_1205.bof
Connecting to server 192.168.1.10 on port 7147... ok
Programming FPGA with r_spec_2048_r105_2010_Jul_26_1205.bof... done
Configuring accumulation period... done
Resetting counters... done
Setting digital gain of all channels to 4294967295... done
We got the same spectrum I mentioned in my last email and after a
while we got error:
Exception in Tkinter callback
Traceback (most recent call last):
File /usr/lib/python2.6/lib-tk/Tkinter.py, line 1413, in __call__
return self.func(*args)
File /usr/lib/python2.6/lib-tk/Tkinter.py, line 498, in callit
func(*args)
File ./spectrometer.py, line 49, in plot_spectrum
acc_n, interleave_a = get_data()
File ./spectrometer.py, line 37, in get_data
a_1=struct.unpack('1024l',fpga.read('odd',1024*4,0))
File
/usr/local/lib/python2.6/dist-packages/corr-0.6.5-py2.6.egg/corr/katcp_wrapper.py,
line 265, in read
str(size))
File
/usr/local/lib/python2.6/dist-packages/corr-0.6.5-py2.6.egg/corr/katcp_wrapper.py,
line 61, in _request
reply, informs = self.blocking_request(request,keepalive=True)
File
/usr/local/lib/python2.6/dist-packages/katcp-0.3.4-py2.6.egg/katcp/client.py,
line 623, in blocking_request
(msg.name, timeout))
RuntimeError: Request read timed out after 10 seconds.
I am using the normal Ethernet port to connect to the ROACH (not the 10GBE).
A red led lights up on the roach when I run the script.
Also a green light blinks about two times per second.
After the script crashes with the 'runtime' error the leds on the
roach continue doing the same thing.
Ricardo.
On Tue, Jun 21, 2011 at 6:24 PM, Mark Wagner mwag...@ssl.berkeley.edu wrote:
Hi Ricardo,
Generally what we refer to as the iADC is 1Gsps (or 2 interleaved):
https://casper.berkeley.edu/wiki/ADC2x1000-8
Is this what you're using, or is it our national ADC at 3Gsps?
https://casper.berkeley.edu/wiki/ADC1x3000-8
Have you tried loading the bof file in SVN without making any changes?
https://casper.berkeley.edu/svn/trunk/ref_designs_tutorials/workshop_2010/roach_tut3_wideband_spec/r_spec_2048_r105_2010_Jul_26_1205.bof
If you're using the National board, you'll need to switch out the ADC yellow
block as well.
Mark
On Tue, Jun 21, 2011 at 2:14 PM, Ricardo Finger rfing...@gmail.com wrote:
Hello All,
I am trying to run the tutorial 3 spectrometer on a ROACH + 1x_3GSPS_iADC.
I used the bof file provided by casper as well as our own bof file
compiled here (on ubuntu) using the simulink model from casper after
replacing the pfb and fft blocks from our 'local' library.
In both cases I got a strange symmetric spectrum (
http://www.das.uchile.cl/~rfinger/ROACH/tut3_1.png ) which
doesn't change to much when a test tone is applied.
The iADC clock was 800MHz, 0dBm, provided by a valontech 5007 synthesizer,
and the test tone was 100/200 MHz, 0dBm.
After a few integration periods I get a 'timeout' error, and a blank
window in the spectrometer.py application.
Does anyone got the same problem?
Thanks,
Ricardo.
--
Ricardo Finger Camus
Electrical Engineer
Astronomy Department
University of Chile
Of: 56(2)9771119
Casilla 36-D, Santiago.
http://www.das.uchile.cl/lab_mwl/
--
Ricardo Finger Camus
Electrical Engineer
Astronomy Department
University of Chile
Of: 56(2)9771119
Casilla 36-D, Santiago.
http://www.das.uchile.cl/lab_mwl/
Re: [casper] UDP
Thanks for pointing out that the spec differed from the catalog description I had read. I think I'm going to go with a Cisco SG200-26. It has a 4MB shared buffer for 24+2 mini-GBIC gigabit ports. This is the largest shared buffer I've seen for ~24 ports. It supports frame sizes up to 10kbytes Will let you know if I have problems. I believe you and others are making the point that the data will be synchronous from all 16 boards and therefore the data rate will be high for brief blips rather than a continuous average. But I would have to hope that 1.2Mbytes/sec couldn't overpower a gigabit switch even if it arrived all at once (I have some discretion in how often the packets are generated). I really doubt you'll have any problems at that data rate. But It will be interesting to hear for sure! John I think/hope that the larger problem will be on the linux side buffering for which I will try Jason's suggestions. Thanks to all for the help. Tom On Tue, Jun 21, 2011 at 1:52 AM, Jean Borsenberger jean.borsenber...@obspm.fr wrote: On Mon, 2011-06-20 at 12:54 -0700, casper-requ...@lists.berkeley.edu wrote: Hello, 0.5 mbyte buffer per port I read in the spec: Buffer memory: 512 KB embedded memory per unit seems global for a switch. That resemble to what I am used to. Usually on chip port buffers are at most 17KB. These devices are tuned for a traffic which is mainly TCP, and UDP with data integrity control delegated to clients. Basically they drop a lot of packets, which is of little importance in usual use, as those packets are requested by the listener and re-emitted. Of course in contention situations this behaviour may impact badly things like voice transportation. In your design, many lines converge to one. Hope the time statistic is fair. The time to be considered to examine this is: buffer_size/effecive_line_speed Be carefull that not all of the buffer memory may be available for one port, depending on the policy adopted in the switching strategy. Jean
