Hi Jason:

Thanks for you help.
But I could not find the tut4 in workshop. Could you please provide me the 
exact link? Thanks.

As I know, the KATCP only provide data in ASCII. Is this right? And for KATCP, 
all command and data are transferred by network. But we expeirence some network 
failure without running our own program. I guess it might not be a good idea to 
run our application over network at the moment.

For my experience with KATCP failure, I think it belong two cases, one is OS 
could crash when I run bof file. Another is network connection could be broken 
when I access the data or registers. I can provide more details when I see them 
again.

Anyway, thanks Jason for all information you provide.

Cheers

Wan

-----Original Message-----
From: Jason Manley [mailto:jasonman...@gmail.com] 
Sent: Wednesday, 4 November 2009 4:35 PM
To: Cheng, Wan (ATNF, Marsfield)
Cc: Wormnes, Kjetil (ATNF, Marsfield); m...@ska.ac.za; david.geo...@ska.ac.za; 
casper@lists.berkeley.edu
Subject: Re: [casper] Fwd: Re: SPDO ROACH spectrometer

comments appended below...

On 04 Nov 2009, at 01:04, <wan.ch...@csiro.au> <wan.ch...@csiro.au>  
wrote:

> Hi Jason:
>
> Could you please let me know how do you get data using KATCP?
Look at the wideband poco example (tut4) from the workshop. It is a  
fully-functional correlator on a single ROACH board, and includes  
python scripts which demonstrate the use of KATCP. Pulling data from  
DRAM is the same as retrieving it from BRAM or QDR.

> I also used KATCP for a while. But I can not find an efficient way  
> to read a large mount data from FPGA, like 1GB data stored in the  
> Dram.
This is possible without any complicated trickery using KATCP. Expect  
data rates of about 10MB/s if you implement a reasonable form of  
hardware/software handshaking.

> And there are a few difficulties as well. Such as, network is not  
> reliable, OS crashed when I download bof file sometimes.
This should never happen. Please provide details.

Jason

> -----Original Message-----
> From: Jason Manley [mailto:jasonman...@gmail.com]
> Sent: Tuesday, 3 November 2009 5:40 PM
> To: Wormnes, Kjetil (ATNF, Marsfield); Marc Welz; David George
> Cc: Cheng, Wan (ATNF, Marsfield); casper@lists.berkeley.edu
> Subject: Re: [casper] Fwd: Re: SPDO ROACH spectrometer
>
> Marc Welz or David George built that kernel. They are the best people
> to ask about this. I've cc'd them, though I'm not sure either would
> have the config file from that release. It might be easiest to
> checkout an older svn version.
>
> Might I suggest that instead of recording data to a USB HDD, that you
> rather record it across the network to another computer? If you don't
> want to use KATCP for dumping the data directly from your FPGA, you
> can always mount an NFS network share on your ROACH and record the
> data there. The USB on the PPC platforms are notoriously unreliable.
>
> Jason
>
> On 03 Nov 2009, at 03:05, Kjetil Wormnes wrote:
>
>> Hi Jason,
>>
>> Thank you again for your reply. I can use FTP or even write my own
>> little raw socket transfer routine, and it seems to work, I can
>> transfer  a few gigabyte-size files.
>>
>> However, at the end of this, the other problem kicks in; causing a
>> system crash. I believe this is a kernel problem, as it exhibits
>> itself differently with different kernels I have tried.
>>
>> So, putting the ssh problem aside as something that we can work
>> around and returning to the other request I made;
>>
>> I am compiling my own kernel because I seem to need to in order to
>> get EHCI and EXT3 to work properly.
>>
>> However, when I do, EMAC can't autonegotiate a link, and even
>> forcing it to something doesn't work. The link comes up, then drops
>> out again... repeatedly.
>>
>> The interesting thing is this problem *does not* occur when I
>> compile my kernel using an svn checkout from a couple of months ago.
>> Even with the exact same .config file.
>>
>> At least this is the case as far as I can tell.
>>
>> Now, in order to be 100% sure that it is in fact a difference in the
>> source that is causing this problem, rather than just the .config. I
>> would love it if you could send me the .config file used to compile
>> the uImage-20091006-mmcfix kernel.
>>
>> The ethernet interface does appear to be more stable with that
>> kernel, but unfortunately I can't use it as it doesn't allow USB 2.0
>> speeds, so if you please, the .config file would be very useful.
>>
>> Thanks again for all your help
>>
>>
>> Kjetil
>>
>>
>> Jason Manley wrote:
>>> There appears to be some issue with ssh on ROACH with large
>>> transfers.  It is definitely not a hardware problem as other
>>> network transfers  work fine. Both Andrew Martens and myself
>>> regularly transfer large  amounts of data (>1GB) using KATCP. This
>>> ssh bug has become a low  priority for us as we concentrate on
>>> other things. If you do not want  to try'n debug it yourself, I
>>> recommend you try an FTP server.
>>>
>>> Kjetil, you are correct; at present, KATCP does not support
>>> transfer  of arbitrary files from filesystem.
>>>
>>> Jason
>>>
>>> On 02 Nov 2009, at 00:51, Kjetil Wormnes wrote:
>>>
>>>
>>>> Hi Jason,
>>>>
>>>> thank you for your reply. The SUN link was very descriptive.
>>>>
>>>> Firstly, it appears the problem is still there with the kernel
>>>> build  you suggested/ After a few megabytes, the connection closes
>>>> telling  me; "Corrupted MAC on input".
>>>>
>>>> But interestingly it seems to have solved another problem that I
>>>> was  having with one of our ROACH boards. It would be great if you
>>>> could  send me the .config file for that build so I can compare it
>>>> with  mine. I have a custom kernel as I like ext3 support and a
>>>> few other  bits and pieces, but have been having some issues
>>>> getting the  network to establish a stable link.
>>>>
>>>> Now, back to the problem; We have a locally attached harddrive
>>>> that  we are writing our data to over USB. Occasionally we want to
>>>> connect  and download these. That's why I am using ssh. I can't
>>>> really use  KATCP for this, can I?
>>>>
>>>> Thanks again,
>>>>
>>>> Kjetil
>>>>
>>>>
>>>>
>>>>
>>>> Jason Manley wrote:
>>>>
>>>>> Um, no, this is probably a different problem. You are getting
>>>>> these  errors while using SSH/SCP, right? The hardware problem
>>>>> with  faulty  PHY manifests as one or more of the PHY LEDs
>>>>> flashing on/ off (there  are three red ones next to the PHY
>>>>> chip). If your link  is stable, then  I believe the hardware is
>>>>> fine.
>>>>>
>>>>> The "MAC" problem appears to be software related, and comes and
>>>>> goes  depending on the kernel build. It does not refer to the
>>>>> MAC  address,  but rather ssh's Machine Authentication Code.
>>>>> Check out http://blogs.sun.com/janp/entry/ssh_messages_code_bad_packet
>>>>>    for some info.
>>>>>
>>>>> Dave's made various changes to try'n fix it, and increasing
>>>>> some   software buffer has solved it for me. I no longer see
>>>>> this  problem,  but it's probably been masked rather than solved.
>>>>> Also,  you never see  it using KATCP, which is one more reason to
>>>>> use that  method for larger  transfers.
>>>>>
>>>>> WRT large (>1GB) transfers, remember that it will take a long
>>>>> time  to  pull that much data off the FPGA. It does so in pages
>>>>> of  ~4000Bytes at  a time. Also make sure you're using the
>>>>> latest  kernel. We discovered a  bug in this paging system during
>>>>> the  workshop. 
>>>>> http://casper.berkeley.edu/svn/trunk/roach/sw/binaries/linux/uImage-20091006-mmcfix
>>>>>    should be good. I have never tried pulling such volumes over
>>>>> the  SSH  shell, but it works fine with KATCP.
>>>>>
>>>>> I will ask him to comment further.
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>> On 30 Oct 2009, at 01:25, John Ford wrote:
>>>>>
>>>>>
>>>>>
>>>>>>> casper collaborators,
>>>>>>>
>>>>>>> appended below is further info on roach ethernet problems seen
>>>>>>> at  CSIRO:
>>>>>>> any ideas?
>>>>>>>
>>>>>>>
>>>>>> If I recall correctly, Alan mentioned this problem at the
>>>>>> workshop,  and
>>>>>> the problem was that some of the PHY chips were faulty at one
>>>>>> point.  This
>>>>>> may be what's going on.  Hopefully someone knows for sure!
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> dan
>>>>>>>
>>>>>>> -------- Original Message --------
>>>>>>> Subject: Re: SPDO ROACH spectrometer
>>>>>>> Date: Fri, 30 Oct 2009 09:19:01 +1100
>>>>>>> From: Kjetil Wormnes <kjetil.worm...@csiro.au>
>>>>>>> To: Dan Werthimer <d...@ssl.berkeley.edu>
>>>>>>>
>>>>>>> Hi Dan and Wan
>>>>>>>
>>>>>>> I can confirm that we are seeing at least some of the problems
>>>>>>> with
>>>>>>> another ROACH board as well. This time it is connected
>>>>>>> directly  to a
>>>>>>> computer with a short CATY5 cable.
>>>>>>>
>>>>>>> So maybe this indicates that it is less likely to be a
>>>>>>> hardware   problem?
>>>>>>> Incidentally, the error message that happens when attempting
>>>>>>> to   download
>>>>>>> a large file over sftp is "Corrupted MAC on input".
>>>>>>>
>>>>>>> cheers
>>>>>>>
>>>>>>> Kjetil
>>>>>>>
>>>>>>> Dan Werthimer wrote:
>>>>>>>
>>>>>>>
>>>>>>>> hi wan,
>>>>>>>>
>>>>>>>> i don't know of anyone who has roach ethernet
>>>>>>>> problems at 100 Mbit/sec.
>>>>>>>>
>>>>>>>> i'm cc'ing casper community to see if anyone has any ideas.
>>>>>>>> in general, it's good to post questions to cas...@lists,
>>>>>>>> so that everyone can help answer, and everyone can see the
>>>>>>>> answers,
>>>>>>>> and the info will be captured in the wiki/email archive.
>>>>>>>>
>>>>>>>> if you want you can buy or ask digicom if they can send you
>>>>>>>> another national PHY chip and see if this helps.
>>>>>>>>
>>>>>>>> also you might want to try using short cable, and/or a cat6
>>>>>>>> cable.
>>>>>>>> is your roach connected directly to a computer, or going
>>>>>>>> through a switch?  might be interesting to try a different NIC
>>>>>>>> or different switch or different computer.
>>>>>>>>
>>>>>>>> best,
>>>>>>>>
>>>>>>>> dan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/29/2009 02:47 PM, wan.ch...@csiro.au wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Dan:
>>>>>>>>>
>>>>>>>>> I believe you have done a very nice job.
>>>>>>>>>
>>>>>>>>> My problem is Ethernet port is not very reliable. Even
>>>>>>>>> running at
>>>>>>>>> 100MHz, the Ethernet port will be disconnected at some
>>>>>>>>> times.   Normally,
>>>>>>>>> it can resume after reboot whole system.
>>>>>>>>>
>>>>>>>>> And I could not transfer big file through ethernet. Small
>>>>>>>>> files  like a
>>>>>>>>> few MB are all right. But I could not download 1GB file
>>>>>>>>> from   Roach at
>>>>>>>>> all.
>>>>>>>>>
>>>>>>>>> So Dan, could this problem be solved by replacing the on
>>>>>>>>> board  PHY?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Wan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>>
>>
>


Reply via email to