https://nmsl.cs.sfu.ca/api.php?action=feedcontributions&feedformat=atom&user=Abukhams 2026-06-07T17:54:19Z User contributions MediaWiki 1.35.1 https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5260 2013-02-02T16:20:57Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> == Installing PCIe Drivers ==<br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> <br /> 2. Unzip the package <br /> # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> <br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> == Installing libsdp Library ==<br /> 1. Download the library http://nsl.cs.sfu.ca/wiki/upload/8/86/Libsdp-1.1.108.tar.gz<br /> 2. Extract and install using &quot;./configure&quot;, &quot;make&quot;, &quot;make install&quot;<br /> <br /> == Installing SDP Kernel Module ==<br /> 1. Download the source code of SDP kernel module http://nsl.cs.sfu.ca/wiki/upload/a/a7/Pcie_sdp.tar.gz<br /> 2. Extract and install<br /> # tar zxvf Pcie_sdp.tar.gz<br /> # cd Pcie_sdp<br /> # make<br /> 3. Load the module to the kernel<br /> insmod ib_sdp.ko<br /> <br /> == Testing the SDP over PCIe ==<br /> To test the module you can run any TCP based client server application in one of two ways.<br /> 1. Specifying the location of libsdp<br /> LD_LIBRARY_PATH=/usr/local/lib LD_PRELOAD=libsdp.so YOUR_SERVER_EXECUTABLE<br /> 2. By configuring the process name and port number in libsdp.conf that can be found under /usr/local/etc/libsdp.conf or /etc/libsdp.conf</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5259 2013-02-02T16:14:28Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> == Installing PCIe Drivers ==<br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> <br /> 2. Unzip the package <br /> # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> <br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> == Installing libsdp Library ==<br /> 1. Download the library http://nsl.cs.sfu.ca/wiki/upload/8/86/Libsdp-1.1.108.tar.gz<br /> 2. Extract and install using &quot;./configure&quot;, &quot;make&quot;, &quot;make install&quot;<br /> <br /> == Installing SDP Kernel Module ==<br /> 1. Download the source code of SDP kernel module http://nsl.cs.sfu.ca/wiki/upload/a/a7/Pcie_sdp.tar.gz<br /> 2. Extract and install<br /> # tar zxvf Pcie_sdp.tar.gz<br /> # cd Pcie_sdp<br /> # make<br /> 3. Load the module to the kernel<br /> insmod ib_sdp.ko<br /> <br /> == Testing the SDP over PCIe ==</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=File:Pcie_sdp.tar.gz&diff=5258 2013-02-02T16:10:13Z

<p>Abukhams: </p> <hr /> <div></div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=File:Sdp_asyn.tar.gz&diff=5257 2013-02-02T16:00:42Z

<p>Abukhams: </p> <hr /> <div></div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5256 2013-02-02T15:51:58Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> == Installing PCIe Drivers ==<br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> <br /> 2. Unzip the package <br /> # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> <br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> == Installing libsdp Library ==<br /> 1. Download the library http://nsl.cs.sfu.ca/wiki/upload/8/86/Libsdp-1.1.108.tar.gz</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=File:Libsdp-1.1.108.tar.gz&diff=5255 2013-02-02T15:51:14Z

<p>Abukhams: </p> <hr /> <div></div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5218 2013-01-16T12:55:58Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> <br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> <br /> 2. Unzip the package <br /> # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> <br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> <br /> To be continued...</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5217 2013-01-16T12:55:29Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> <br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> 2. Unzip the package <br /> # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> <br /> To be continued...</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5216 2013-01-16T12:55:15Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> Install:<br /> <br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> 2. Unzip the package <br /> # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> <br /> To be continued...</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5215 2013-01-16T12:52:40Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> Install:<br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> 2. Unzip the package <br /> # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> <br /> To be continued...</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5214 2013-01-16T12:50:00Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> Install:<br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> 2. # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> <br /> To be continued...</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5213 2013-01-16T12:44:07Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> Install:<br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> 2. # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> <br /> To be continued...</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5212 2013-01-16T12:42:45Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> == Installation ==<br /> Install:<br /> 1. Download the drivers from http://www.plxtech.com/download/file/899/217277 after registrations<br /> 2. # Unzip PLX_SDK_Linux_v6_50_Final_2011-09-30.zip<br /> 3. Make sure that you are at the same level as PlxSdk and apply the patch:<br /> #ls<br /> Documentation PlxSdk PlxSdk.tar<br /> <br /> # patch -p1 &lt; ../patch.txt <br /> patching file PlxSdk/Include/PlxIoctl.h<br /> patching file PlxSdk/Include/Plx_sysdep.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/ApiFunc.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/PlxInterrupt.c<br /> patching file PlxSdk/Linux/Driver/Source.Plx8000/SuppFunc.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/Dispatch.c_back<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h<br /> patching file PlxSdk/Linux/Driver/Source.PlxDma/DrvDefs.h_back<br /> patching file PlxSdk/Linux/Driver/.tmp_versions/PlxDma_dbg.mod<br /> patching file PlxSdk/Linux/Samples/ApiTest/ApiTest.c<br /> patching file PlxSdk/Linux/Samples/NT_DmaTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/Makefile<br /> patching file PlxSdk/Linux/Samples/NT_myTest/NT_DmaTest.c<br /> patching file PlxSdk/Linux/Samples/NT_myTest/PlxDmaPerf.c<br /> patching file PlxSdk/Linux/Samples/PlxDma/PlxDma.c<br /> patching file PlxSdk/Linux/Samples/PlxNotification/PlxNotification.c<br /> <br /> 4. Make sure that Plx main directory is defined in you environment:<br /> # export PLX_SDK_DIR=/home/ambu50/trunk/Plx_new_download/PlxSdk/<br /> <br /> 5. Change directory to the drivers folder:<br /> cd Linux/Driver/<br /> 6. Run build builddriver:<br /> # ./builddriver 8000<br /> # ./builddriver Dma<br /> 7. Load the drivers:<br /> # ../../Bin/Plx_load 8000<br /> # ../../Bin/Plx_load Dma<br /> <br /> <br /> To be continued...</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5211 2013-01-16T12:41:22Z

<p>Abukhams: </p> <hr /> <div>= Socekt Direct Protocol (SDP) over PCI Express Project Page= <br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=software&diff=5210 2013-01-16T07:47:35Z

<p>Abukhams: </p> <hr /> <div>This page contains a list of all the software that were developed at NSL as part of our ongoing research projects. They are organized by project with links to documentation, downloadable source code archives, and Subversion repositories. Unless otherwise specified, all the code released on this page is available under the [http://www.gnu.org/licenses/gpl-3.0.txt GPLv3] license. When using our implementations and/or algorithms, please cite the corresponding publications from the project/publications page.<br /> <br /> <br /> == &lt;nowiki&gt;Implementations&lt;/nowiki&gt; ==<br /> <br /> === MobileTV Testbed ===<br /> <br /> As part of our Mobile TV Networks project, we have implemented a complete end-to-end testbed for DVB-H (Digital Video Broadcast-Handheld) networks. The testbed provides a realistic platform for analyzing various aspects of these networks, including the energy saving achieved by the time slicing mechanism, average channel switching delay, network capacity in terms of number of TV channels that can be broadcast, visual quality of TV channels transmitting different types of video streams, information exchange and interactivity between base station and receivers, among many others. The mobile TV testbed has two parts: a commodity Linux box as the base station and several smart phones as receivers. We have two testbed implementations: (i) FATCAPS base station, and (ii) integrated base station. The former one is based on FATCAPS implementation, while the later one is implemented by us from scratch.<br /> <br /> <br /> * '''Developer(s):''' Cheng-Hsin Hsu (PhD Student, Graduated Fall 2009)<br /> * '''Language(s):''' C/C++<br /> * More details at [[mobileTV | project page]].<br /> * [http://nsl.cs.sfu.ca/projects/mtv/readme.txt ReadMe]<br /> * [https://cs-svn.cs.surrey.sfu.ca/nsl/browser/DVB-H/src Browse source code]<br /> <br /> <br /> === pCDN: Peer-assisted Content Distribution Network ===<br /> This project employs the peer-to-peer (P2P) computing paradigm in designing large-scale content distribution systems. We developed a fully functional and reliable P2P content distribution system, which we call pCDN. pCDN is developed in partnership with the Canadian Broadcasting Corporation (CBC), the largest Internet content provider in Canada. The system is an ongoing project that will provide high-quality multimedia content, support heterogeneous clients, impose minimal load on the expensive inter-ISP links, provide on-demand as well as live streaming services, ensure data integrity, and implement digital rights management, among other features.<br /> <br /> <br /> * '''Language(s):''' Java and C/C++<br /> * More details at [[pCDN | project page]]. An overview of pCDN and its features can be found in [http://www.cs.sfu.ca/~mhefeeda/Papers/pCDN07.pdf this] white paper. <br /> * [[pCDN:Installation | Installation instructions]]<br /> * [[pCDN:Release|Latest Released Version]]<br /> * Subversion<br /> * ''Bug Tracking and Feature Suggestion System at: [http://nsl.cs.sfu.ca/bug/ Bugzilla].<br /> <br /> <br /> === pCache: A Proxy Cache for Peer-to-Peer Traffic ===<br /> <br /> As part of our research on modeling and caching of P2P traffic, we have designed and implemented a proxy cache for P2P traffic, which we call pCache. The server is to be deployed by autonomous systems (ASes) or ISPs that are interested in reducing the burden of P2P traffic. Our C++ implementation of pCache has more than 11,000 lines of code. We have rigorously validated and evaluated the performance of pCache as well as its impacts on ISPs and clients. pCache code is released under [http://www.gnu.org/licenses/gpl-3.0.txt GPLv3] in two parts: kernel source and application. The Linux kernel consists of all required patches to support transparent proxy, which simplify setting up the required environment. This patched kernel contains code from [http://www.kernel.org/ mainstream Linux kernel], [http://www.netfilter.org/ netfilter], [http://www.balabit.com/support/community/products/tproxy/ tproxy], and [http://www.linux-l7sw.org/ layer7switch]. The pCache application implements components described above. Moreover, a patched iptables is also provided that takes additional arguments supported by [http://www.balabit.com/support/community/products/tproxy/ tproxy].<br /> <br /> <br /> * '''Language(s):''' C/C++<br /> * More details at [[Modeling_and_Caching_of_P2P_Traffic | project page]]<br /> * A brief description of each component is given in the [[pCacheOverview | pCache overview page]].<br /> * Download Source Code<br /> ** Linux Kernel [[media:linux-2.6.23.tgz | linux-2.6.23.tgz]]<br /> ** pCache Snapshot [[media:pCache-0.0.1.tgz | pCache-0.0.1.tgz]]<br /> ** iptables (patched for additional arguments) [[media:iptables-1.4.0rc1.tgz | iptables-1.4.0rc1.tgz]]<br /> * Subversion: [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-projects/P2P/p2pCache/code https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-projects/P2P/p2pCache/code]<br /> <br /> <br /> <br /> === svcAuth ===<br /> <br /> svcAuth is a library for authenticating H.264/SVC video streams. It is released under the [http://www.gnu.org/licenses/gpl-3.0.txt GPLv3] license. We have designed an authentication scheme for H.264/SVC streams that supports its full flexibility: it takes into account the coding characteristics of H.264/SVC scalability model and enables verification of all possible substreams. In addition, the proposed scheme is designed for end-to-end authentication of streams. In an end-to-end authentication procedure, a content provider prepares the authenticated video and sends it to receivers, possibly through a third-party Content Delivery Network (CDN) with proxy servers that may need to adapt the flexible video streams. These proxies or any other entity involved in the delivery process do not have to understand our authentication scheme, which is an important advantage. <br /> <br /> <br /> * '''Developer(s):''' Kianoosh Mokhtarian (MSc Student, Graduated Summer 2009)<br /> * '''Language(s):''' Java<br /> * More details at [[Security_of_Scalable_Multimedia_Streams | project page]]. An introduction to svcAuth can be found [[svcAuth | here]].<br /> * [http://nsl.cs.sfu.ca/projects/svcAuth/readme.txt ReadMe]<br /> * [http://nsl.cs.sfu.ca/resources/svcAuth.tar.gz Download Source Code]<br /> * Subversion<br /> <br /> === Socket Direct Protocol (SDP) over PCI Express ===<br /> <br /> In this project we designed and implemented the Socket Direct Protocol (SDP) for PCI Express based fabric. SDP is an efficient data transfer protocol alternative to the TCP that utilizes the advanced features available in high performance interconnects such as direct memory access. Our SDP implementation is designed for PLX PCIe switches and supports only two nodes for now. SDP is compatible with Socket/TCP applications yet provides much better performance. It is developed as a Linux kernel module and has been tested under Redhat Linux 5.7.<br /> <br /> <br /> * '''Developer(s):''' Ahmed Bu-khamsin (MSc Student, Graduated Fall 2012)<br /> * '''Language(s):''' C<br /> * More details at [[pcie_sdp | project page]].<br /> <br /> == '''Simulators '''==<br /> <br /> === PCP: Probabilistic Coverage Protocol ===<br /> <br /> In this project, we consider probabilistic sensing and radio communication models in designing protocols for large-scale sensor networks. Probabilistic models are more realistic in capturing the characteristics of actual sensors than the over-simplified regular disk model. <br /> <br /> <br /> * '''Developer(s):''' Hossein Ahmadi (M.Sc., Graduated Summer 2007) <br /> * '''Language(s):''' C/C++<br /> * More details at [[Probabilistic_Coverage_and_Connectivity | project page]]<br /> <br /> * ''Implementation of the Probabilistic Coverage Protocol (PCP) in NS-2''<br /> ** [http://nsl.cs.sfu.ca/projects/wsn/PCP-NS-README ReadMe]<br /> ** [http://nsl.cs.sfu.ca/projects/wsn/pcp-ns.tar.gz Download Source Code]<br /> ** Subversion<br /> <br /> * ''Implementation of the Probabilistic Coverage Protocol (PCP) in C++''<br /> ** [http://nsl.cs.sfu.ca/projects/wsn/PCP-SenSim-README ReadMe]<br /> ** [http://nsl.cs.sfu.ca/projects/wsn/PCP-SenSim.tar.gz Download Source Code]<br /> ** Subversion<br /> <br /> <br /> === K-Coverage and its Application to Forest Fire Detection ===<br /> <br /> In this project, we design new algorithms to achieve k-coverage in dense sensor networks. In such networks, covering sensor locations approximates covering the whole area. However, it has been shown before that selecting the minimum set of sensors to activate from an already deployed sensors is NP-hard. We propose an efficient approximation algorithm which achieves a solution of size within a constant factor from the optimal. We are also interested in applying our k-coverage algorithms in designing a wireless sensor network for early detection of forest fires. Forest fires, also known as wild fires, are uncontrolled fires occurring in wild areas and cause significant damage to natural and human resources. Forest fires eradicate forests, burn the infrastructure, and may result in high human death toll near urban areas. In the province of British Columbia alone, there have been 2,590 forest fires during 2006. These burned 131,086 hectares and costed about $156 million. (Source: BC Ministry of Forests and Range.) Wireless sensor networks could help in reducing some of the damages caused by forest fires. <br /> <br /> <br /> * '''Developer(s):''' Majid Bagheri (M.Sc., Graduated Summer 2007) <br /> * '''Language(s):''' C/C++<br /> * More details at [[K-Coverage_and_its_Application_to_Forest_Fire_Detection | project page]]<br /> <br /> * ''Implementation of the Centralized Randomized K-Coverage Protocols (RKC) in C++''<br /> ** [http://nsl.cs.surrey.sfu.ca/projects/wsn/rkc_readme.txt ReadMe]<br /> ** [http://nsl.cs.surrey.sfu.ca/projects/wsn/rkc-1.4.zip Download Source Code]<br /> ** Subversion<br /> <br /> * ''Implementation of the Decentralized Randomized K-Coverage Protocols (DRKC) in C++''<br /> ** [http://nsl.cs.surrey.sfu.ca/projects/wsn/drkc_readme.txt ReadMe]<br /> ** [http://nsl.cs.surrey.sfu.ca/projects/wsn/drkc-1.6.zip Download Source Code]<br /> ** Subversion<br /> <br /> <br /> === Live Peer-to-Peer Streaming with Scalable Video Coding and Networking Coding ===<br /> <br /> As part of our research in the area of peer-to-peer video streaming, we have developed a Java-based simulator of a proposed live P2P streaming system that exploits both scalable video coding (SVC) and network coding (NC) to maximize the streaming throughput and handle network dynamics. The proposed system significantly improves the performance of live P2P streaming by addressing many of the challenges impeding current systems. It efficiently utilizes peers resources and easily customizes multimedia content to support receivers with diverse resources and requirements, and quickly adapting to network and peer dynamics. <br /> <br /> <br /> * '''Developer(s):''' Shabnam Mirshokraie (MSc Student)<br /> * '''Language(s):''' Java<br /> * More details<br /> * [http://nsl.cs.sfu.ca/projects/nc-svc/readme.txt ReadMe]<br /> * [http://nsl.cs.sfu.ca/projects/nc-svc/nc-svc.tar.gz Download Source Code]<br /> * Subversion<br /> <br /> <br /> === Efficient Multi-Sender Data Transmission in Swarm-Based Peer-to-Peer Streaming Systems ===<br /> <br /> In this project, we study the problem of scheduling segment transmission in both live and on-demand<br /> P2P streaming systems. Our goal is to maximize the perceived video quality by scheduling the segment<br /> transmission so that segments that are more critical to video quality improvements are given higher<br /> priority to meet their deadlines. We have implemented an event-driven simulator in Java to evaluate the performance of the proposed segment scheduling algorithms. Five scheduling algorithms are implemented in this simulator: rarest-first (RF),<br /> min-cost flow (MC) with support for variable-size segments, our proposed unweighted approximation<br /> (SSTF) algorithm, our weighted approximation (WSS) algorithm, and optimal (OPT) scheduling using by solving the ILP formulation with the CPLEX ILP solver. The simulator can be used with trace files from the Arizona State University<br /> video trace library. A prototype P2P streaming system which incorporates RF, MC, SSTF, and WSS was also implemented for deployment over PlanetLab nodes.<br /> <br /> <br /> * '''Developer(s):''' Yuanbin Shen (MSc Student, Graduated Summer 2010)<br /> * '''Language(s):''' Java<br /> * Mode details<br /> * [http://nsl.cs.sfu.ca/projects/schedule/ReadMe.txt ReadMe]<br /> * [http://nsl.cs.sfu.ca/projects/schedule/schedule.tar.gz Download Source Code]<br /> * Subversion<br /> <br /> <br /> === Efficient Multimedia Broadcast over Mobile WiMAX Networks ===<br /> <br /> This project studies multimedia services in the emerging WiMAX networks. We look into efficient multimedia broadcast framework over mobile WiMAX networks utilizing the MBS and sleep mode features, in particular, broadcasting multiple scalable video streams to mobile receivers. We study problems like maximizing the quality of video at mobile receivers, minimizing energy consumption at mobile receivers and other related problems. We have implemented a point-to-multipoint WiMAX multimedia broadcast simulator for evaluating our algorithms using actual scalable video traces. For the WiMAX network parameters, we use the 16-QAM modulation scheme with 3/4 convolution turbo coding and 10 MHz channel.<br /> <br /> <br /> * '''Developer(s):''' Somsubhra Sharangi (MSc Student)<br /> * '''Language(s):''' Java<br /> * Mode details at [[wimax | project page]]<br /> * [http://nsl.cs.sfu.ca/projects/streamWiMAX/ReadMe.txt ReadMe]<br /> * [http://nsl.cs.sfu.ca/projects/streamWiMAX/sharangi.tar.gz Download Source Code]<br /> * Subversion</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=pcie_sdp&diff=5184 2012-12-16T06:41:40Z

<p>Abukhams: New page: Socket Direct Protocol over PCIe, project page. Coming soon...</p> <hr /> <div>Socket Direct Protocol over PCIe, project page.<br /> Coming soon...</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=group_meeting&diff=5141 2012-10-31T19:57:14Z

<p>Abukhams: </p> <hr /> <div>We hold regular meetings for discussion and for every student to update the group on his/her progress. In some of the meetings, graduate students present talks summarizing their research progress so far. <br /> <br /> The meetings are good opportunities for students to practice their presentation skills and to get constructive feedback from the group on their research. The meetings keep the group members informed about different research problems being addressed in the group. They are also very helpful in finding research topics specially for new students. <br /> <br /> Everybody is welcome to attend. Meeting time: Every other Tuesday, 2:00 - 3:00 PM, room SUR 4010. <br /> <br /> <br /> == Fall 2012==<br /> <br /> * 11 Dec: Abdul<br /> <br /> * 27 Nov: Tamir, <br /> <br /> * 13 Nov: Saleh, <br /> <br /> * 30 Oct: Masum, <br /> <br /> * 16 Oct: Ahmed Bu-Khamsin, PCIe Interconnect for HPC Applications [http://nsl.cs.sfu.ca/wiki/upload/1/17/Pcie_SDP.ppt]<br /> <br /> * 2 Oct: Som, Cloud-based Multimedia Streaming<br /> <br /> * 18 Sep: Azin, Video Streaming over Cognitive Radio Networks<br /> <br /> <br /> == Spring 2011==<br /> <br /> * 1 Feb: Ahmed Bu-khamsin, Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed<br /> <br /> * 25 Jan: Naghmeh, [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/khodabakhshi/talks/3DVideoCopyDetection.pptx 3D Video Copy Detection]<br /> <br /> * 18 Jan: Cameron, [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/harvey/talks/Copy%20Detection%20Using%20Optical%20Flow.pptx Video Copy Detection using Optical Flow]<br /> <br /> * 11 Jan: Mathieu, [[media:3D_VideosOverview.pptx | 3D Media - An Overview]]<br /> <br /> <br /> <br /> Group meetings were held biweekly up to Dec 2010. <br /> <br /> == Fall 2010==<br /> <br /> * 21 Dec 10: Group discussion.<br /> <br /> * 9 Dec 10: Mohammad, [[media:Botnet-Detection-2.0.pptx | Detection of SIP Botnets Based on C&amp;C Communication]]<br /> <br /> * 23 Nov 10: Taher, [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/dameh/talks/AppAlgo2.ppt Approximation algorithms for Large-Scale Kernel Methods]<br /> <br /> * 19 Oct 10: Jeff, [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/gao/talks/LSH_Cluster.pdf Gram Matrix Approximation Using Locality Sensitive Hashing on Cluster]<br /> <br /> * 7 Oct 10: Dr. Rocky Chang (Hong Kong Polytechnic University),&lt;br/&gt; [[media:Rocky-SFU-7-Oct-2010.pdf | Active Measurement of Data-Path Quality in a Non-cooperative Internet]]<br /> <br /> * 28 Sep 10: Ahmed, [[media:DRS.pdf | Energy-Efficient Gaming on Mobile Devices using Dead Reckoning-based Power Management]]<br /> <br /> <br /> == Spring/Summer 2010==<br /> <br /> * 31 Aug 10: Hamed, [[media:Predicting_Click_Through_Rate_for_new_ads.pdf | Predicting Click Through Rate for New Ads with Semantically Similarity Measurement]]<br /> <br /> * 9 Aug 10: Yuanbin, [[media:mutisendP2Pstream.pdf | Efficient Algorithms for Multi-Sender Data Transmission in Swarm-based P2P Streaming Systems]]<br /> <br /> * 3 Aug 10: Azin, [[media:CognitiveRadio.ppt | Cognitive Radio Networks]]<br /> <br /> * 20 July 10: Farid, [[media:movid10.pdf | Optimal Scalable Video Multiplexing in Mobile Broadcast Networks]]<br /> <br /> * 17 May 10: Cameron, Reducing Energy Consumption in Online Network Games on Mobile Devices<br /> <br /> * 10 May 10: Cong, Latency Reduction in Online Network Games<br /> <br /> * 19 April 10: Shabnam, [[media:Svc-nc.ppt | Live P2P Streaming with Scalable Video Coding and Network Coding]]<br /> <br /> * 29 March 10: Jeff and Taher, [[media:AppAlgo.ppt | Approximation algorithms for Kernel Methods on Multi-core CPUs and GPUs]]<br /> <br /> * 15 March 10: Som, [http://www.cs.sfu.ca/~ssa121/personal/wimaxSVC.pdf Video Streaming over WiMAX]<br /> <br /> * 1 March 10: Farid, [[media:scalable_video_streaming_for_mobiletv.pptx | Scalable Video Streaming for MobileTV]]<br /> <br /> * 1 Feb 10: Ahmed, [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/hamza/talks/pCDN_SVC/pCDN_SVC.pdf Design of pCDN with Scalable Video Coding]<br /> <br /> * 18 Jan 10: Shabnam, P2P Streaming with Newtork Coding and Scalable Video Coding<br /> <br /> <br /> == Fall 2009==<br /> <br /> * 8 December 09: Yi, Video Streaming over Cooperative Wireless Networks<br /> <br /> * 10 Nov 09: Cheng, [[media:testbed.ppt | Design of a Mobile TV Testbed]]<br /> <br /> * 27 October 09: Yuanbin, Segment Scheduling in P2P Streaming Systems<br /> <br /> * 13 October 09: Ahmed, [[media:LTE.pdf | Long Term Evolution (LTE) - A Tutorial]]<br /> <br /> * 6 October 09: Cheng, [[media:Mm09.ppt | Statistical Multiplexing of VBR Video Streams]] (ACM MM 09 talk)<br /> <br /> * 22 September 09: Som, Video Streaming over WiMAX Networks<br /> <br /> * 8 September 09: Cong, Minimizing Round-Trip Time in Online Games<br /> <br /> <br /> == Summer 2009==<br /> <br /> * 18 August 09: Mohammad and Cong: 30 min each. Present their Directed Reading projects. <br /> <br /> * 14 July 09: Cheng, [[media:wimaxTV.pptx | Broadcasting Variable-Bit-Rate Videos in 802.16e-Like Mobile Networks]] <br /> <br /> * 7 July 09: Yi<br /> <br /> * 26 June 09: Ahmed <br /> <br /> * 5 June 09: '''Canceled''' (Mohamed attending NOSSDAV'09)<br /> <br /> * 29 May 09: Kianoosh, End-to-End Secure Delivery of Scalable Video Streams <br /> <br /> * 22 May 09: Cong, [[media:wimax.pptx| Multimedia Streaming over WiMAX Networks]]<br /> <br /> * 8 May 09: Kianoosh, Analysis of Authentication Schemes for Nonscalable Video Streams<br /> <br /> <br /> == Spring 2009 ==<br /> <br /> * 17 Apr 09: [[media:infocom09.pptx|Cheng (practice your infocom presentation)]]<br /> <br /> * 27 March 09: Andreas Berger, [[media:Nsl_vancouver.odp | Network-based Detection of SIP Bots]]<br /> <br /> * 27 Feb 09: Shabnam and Yuanbin<br /> <br /> * 23 Jan 09: Cheng (rehearse your PhD proposal) and Kianoosh</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=File:Pcie_SDP.ppt&diff=5140 2012-10-31T19:55:08Z

<p>Abukhams: Socket Direct Protocol over PCI Express Interconnect: Design, Implementation and Evaluation Presented in a group meeting in Oct 2012</p> <hr /> <div>Socket Direct Protocol over PCI Express Interconnect: Design, Implementation and Evaluation<br /> Presented in a group meeting in Oct 2012</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=5006 2012-06-25T11:37:02Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==June==<br /> <br /> Update 25 June:<br /> All the bugs have been fixed. I have ran some performance tests using ttcp tool, which calculates the transfer speed. The results shows that the protocol performs very poorly. The maximum speed it achieves is 3900 kbps. After some investigations, I found that the main cause for the poor performance is the delay caused by pooling scratchpad regiesters to exchange state and control data between hosts. I tried to avoid pooling by sending interrupts between hosts, however, my efforts were unsuccessful. I have contacted the manufacturer support for this issue and I am waiting for a reply.<br /> In the meantime I decided to redesign the way the hosts exchange status and control data to increase the performance and avoid delay. Instead of one machine writes to the scratchpad regiester and the other machine pooling the regiester for update and then acknowledging the data, the new design deal with the 8 scratchpad regiesters as a shared queue. Each host writes the required value to the queue then continue. This approach should avoid much of the delay resulted from pooling and waiting for acknowledgments. <br /> <br /> Update 11 June:<br /> I have successfully transmitted and received some data using the SDP protocol. I tested it using a simple echo server, in which the client connects to the server and sends a text, then the server replies with the same text. The test was done using regular TCP/IP application without the need for any code modification. However, the protocol is still buggy and needs some clean up.<br /> <br /> After fixing the bugs, the protocol should work very well when one application runs at a time. Running multiple apps concurrently yet to be tested, but I am expecting some problems. This is because all the operations are implemented on the same kernel module, so when the module is busy handling one application, it will not be able to respond to requests from other applications. <br /> One solution for this problem is to dedicate a separate module for maintaining a send and a receive queue, then modify the sdp module to submit all the requests to these queues. Then the new module can regularly check the queues and perform the requested operations, when a transaction is completed, it can notify the sdp module using callback functions. <br /> <br /> -----------------<br /> June 4:<br /> I was trying to find a way to perform zero-copying user-buffer to user-buffer DMA transfer for send and receive implementation. After some experiments I found that the driver doesn't support remote DMA read and write from scatter/gather address, so there is no way to do remote DMA without copying.<br /> As an alternative, I am working on a method that involves only one buffer copying per send call while the traditional method requires buffer copying on the transmitter and receiver sides. The way I am doing it is by copying user buffer to a contiguous memory on the sender side, then send the DMA address to the receiver side, which will do remote DMA read directly to the user buffer without the need for intermediate copying. <br /> <br /> ==May==<br /> Update 27 May :<br /> As part of developing send and receive socket calls, application data stored in userspace need to be transfered to application buffer on the other side of the connection. There are two approches to do so. The first approach is to copy user's data to the PCIe device memory then do DMA transfer to the card on the other machine, after that copy the data to application buffer. This approach is easy to implement as it doesn't involve userspace memory to kernel space mapping and no need to assign bus address to the memory. However, there is an overhead resulted from the copying process which increases the latency. <br /> <br /> The second approach is to map userspace memory to kernel space, pin userspace memory and assign bus address to the memory to allow DMA transfer. Memory in userspace is not contiguous memory, so bus addresses cannot be assigned. One solution for this problem is to build a scatter/gather list which is a linked list of multiple memory addresses. After that the address of the scatter/gather need to be translated and sent to the other end of the connection. However, I am not sure if the address translation mechanism provided by the driver supports scatter/gather addresses or not. All the scatter/gather examples available are executed on a single machine so no translations were used. So right now I am working on a sample code to verify if this technique works or not.<br /> <br /> update 11-May :<br /> The kernel panic and lockup bugs have been fixed. I have also found another bug that causes the accept call to fail. To debug this problem I had to modify the kernel code to print debug messages then compile the kernel and use it to find the cause of the bug. The bug has been fixed and now I am continuing the work on send and receive calls. <br /> --------------<br /> <br /> While I was working on send and receive, I found some bugs on the connecting process that causes the kernel to panic and some time I get kernel lockup errors. Right now I am debugging the module by running a sample code and trace back the cause of the crashing. The debugging process is slow as I need to power recycle the machines every time the bug is hit. <br /> <br /> ==April==<br /> <br /> UPDATE:<br /> I am done with establishing the connection (connect, listen, accept, bind) and now I am working on send and receive.<br /> <br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4988 2012-06-11T11:09:02Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==June==<br /> Update 11 June:<br /> I have successfully transmitted and received some data using the SDP protocol. I tested it using a simple echo server, in which the client connects to the server and sends a text, then the server replies with the same text. The test was done using regular TCP/IP application without the need for any code modification. However, the protocol is still buggy and needs some clean up.<br /> <br /> After fixing the bugs, the protocol should work very well when one application runs at a time. Running multiple apps concurrently yet to be tested, but I am expecting some problems. This is because all the operations are implemented on the same kernel module, so when the module is busy handling one application, it will not be able to respond to requests from other applications. <br /> One solution for this problem is to dedicate a separate module for maintaining a send and a receive queue, then modify the sdp module to submit all the requests to these queues. Then the new module can regularly check the queues and perform the requested operations, when a transaction is completed, it can notify the sdp module using callback functions. <br /> <br /> -----------------<br /> June 4:<br /> I was trying to find a way to perform zero-copying user-buffer to user-buffer DMA transfer for send and receive implementation. After some experiments I found that the driver doesn't support remote DMA read and write from scatter/gather address, so there is no way to do remote DMA without copying.<br /> As an alternative, I am working on a method that involves only one buffer copying per send call while the traditional method requires buffer copying on the transmitter and receiver sides. The way I am doing it is by copying user buffer to a contiguous memory on the sender side, then send the DMA address to the receiver side, which will do remote DMA read directly to the user buffer without the need for intermediate copying. <br /> <br /> ==May==<br /> Update 27 May :<br /> As part of developing send and receive socket calls, application data stored in userspace need to be transfered to application buffer on the other side of the connection. There are two approches to do so. The first approach is to copy user's data to the PCIe device memory then do DMA transfer to the card on the other machine, after that copy the data to application buffer. This approach is easy to implement as it doesn't involve userspace memory to kernel space mapping and no need to assign bus address to the memory. However, there is an overhead resulted from the copying process which increases the latency. <br /> <br /> The second approach is to map userspace memory to kernel space, pin userspace memory and assign bus address to the memory to allow DMA transfer. Memory in userspace is not contiguous memory, so bus addresses cannot be assigned. One solution for this problem is to build a scatter/gather list which is a linked list of multiple memory addresses. After that the address of the scatter/gather need to be translated and sent to the other end of the connection. However, I am not sure if the address translation mechanism provided by the driver supports scatter/gather addresses or not. All the scatter/gather examples available are executed on a single machine so no translations were used. So right now I am working on a sample code to verify if this technique works or not.<br /> <br /> update 11-May :<br /> The kernel panic and lockup bugs have been fixed. I have also found another bug that causes the accept call to fail. To debug this problem I had to modify the kernel code to print debug messages then compile the kernel and use it to find the cause of the bug. The bug has been fixed and now I am continuing the work on send and receive calls. <br /> --------------<br /> <br /> While I was working on send and receive, I found some bugs on the connecting process that causes the kernel to panic and some time I get kernel lockup errors. Right now I am debugging the module by running a sample code and trace back the cause of the crashing. The debugging process is slow as I need to power recycle the machines every time the bug is hit. <br /> <br /> ==April==<br /> <br /> UPDATE:<br /> I am done with establishing the connection (connect, listen, accept, bind) and now I am working on send and receive.<br /> <br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4987 2012-06-11T11:08:19Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==June==<br /> Update 11 June:<br /> I have successfully transmitted and received some data using the SDP protocol. I tested it using a simple echo server, in which the client connects to the server and sends a text, then the server replies with the same text. The test was done using regular TCP/IP application without the need for any code modification. However, the protocol is still buggy and needs some clean up.<br /> <br /> After fixing the bugs, the protocol should work very well when one application runs at a time. Running multiple apps concurrently yet to be tested, but I am expecting some problems. This is because all the operations are implemented on the same kernel module, so when the module is busy handling one application, it will not be able to respond to requests from other applications. <br /> One solution for this problem is to dedicate a separate module for maintaining a send and a receive queue, then modify the sdp module to submit all the requests to these queues. Then the new module can regularly check the queues and perform the requested operations, when a transaction is completed, it can notify the sdp module using callback functions. <br /> <br /> --<br /> I was trying to find a way to perform zero-copying user-buffer to user-buffer DMA transfer for send and receive implementation. After some experiments I found that the driver doesn't support remote DMA read and write from scatter/gather address, so there is no way to do remote DMA without copying.<br /> As an alternative, I am working on a method that involves only one buffer copying per send call while the traditional method requires buffer copying on the transmitter and receiver sides. The way I am doing it is by copying user buffer to a contiguous memory on the sender side, then send the DMA address to the receiver side, which will do remote DMA read directly to the user buffer without the need for intermediate copying. <br /> <br /> ==May==<br /> Update 27 May :<br /> As part of developing send and receive socket calls, application data stored in userspace need to be transfered to application buffer on the other side of the connection. There are two approches to do so. The first approach is to copy user's data to the PCIe device memory then do DMA transfer to the card on the other machine, after that copy the data to application buffer. This approach is easy to implement as it doesn't involve userspace memory to kernel space mapping and no need to assign bus address to the memory. However, there is an overhead resulted from the copying process which increases the latency. <br /> <br /> The second approach is to map userspace memory to kernel space, pin userspace memory and assign bus address to the memory to allow DMA transfer. Memory in userspace is not contiguous memory, so bus addresses cannot be assigned. One solution for this problem is to build a scatter/gather list which is a linked list of multiple memory addresses. After that the address of the scatter/gather need to be translated and sent to the other end of the connection. However, I am not sure if the address translation mechanism provided by the driver supports scatter/gather addresses or not. All the scatter/gather examples available are executed on a single machine so no translations were used. So right now I am working on a sample code to verify if this technique works or not.<br /> <br /> update 11-May :<br /> The kernel panic and lockup bugs have been fixed. I have also found another bug that causes the accept call to fail. To debug this problem I had to modify the kernel code to print debug messages then compile the kernel and use it to find the cause of the bug. The bug has been fixed and now I am continuing the work on send and receive calls. <br /> --------------<br /> <br /> While I was working on send and receive, I found some bugs on the connecting process that causes the kernel to panic and some time I get kernel lockup errors. Right now I am debugging the module by running a sample code and trace back the cause of the crashing. The debugging process is slow as I need to power recycle the machines every time the bug is hit. <br /> <br /> ==April==<br /> <br /> UPDATE:<br /> I am done with establishing the connection (connect, listen, accept, bind) and now I am working on send and receive.<br /> <br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4954 2012-06-04T09:36:25Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==June==<br /> I was trying to find a way to perform zero-copying user-buffer to user-buffer DMA transfer for send and receive implementation. After some experiments I found that the driver doesn't support remote DMA read and write from scatter/gather address, so there is no way to do remote DMA without copying.<br /> As an alternative, I am working on a method that involves only one buffer copying per send call while the traditional method requires buffer copying on the transmitter and receiver sides. The way I am doing it is by copying user buffer to a contiguous memory on the sender side, then send the DMA address to the receiver side, which will do remote DMA read directly to the user buffer without the need for intermediate copying. <br /> <br /> ==May==<br /> Update 27 May :<br /> As part of developing send and receive socket calls, application data stored in userspace need to be transfered to application buffer on the other side of the connection. There are two approches to do so. The first approach is to copy user's data to the PCIe device memory then do DMA transfer to the card on the other machine, after that copy the data to application buffer. This approach is easy to implement as it doesn't involve userspace memory to kernel space mapping and no need to assign bus address to the memory. However, there is an overhead resulted from the copying process which increases the latency. <br /> <br /> The second approach is to map userspace memory to kernel space, pin userspace memory and assign bus address to the memory to allow DMA transfer. Memory in userspace is not contiguous memory, so bus addresses cannot be assigned. One solution for this problem is to build a scatter/gather list which is a linked list of multiple memory addresses. After that the address of the scatter/gather need to be translated and sent to the other end of the connection. However, I am not sure if the address translation mechanism provided by the driver supports scatter/gather addresses or not. All the scatter/gather examples available are executed on a single machine so no translations were used. So right now I am working on a sample code to verify if this technique works or not.<br /> <br /> update 11-May :<br /> The kernel panic and lockup bugs have been fixed. I have also found another bug that causes the accept call to fail. To debug this problem I had to modify the kernel code to print debug messages then compile the kernel and use it to find the cause of the bug. The bug has been fixed and now I am continuing the work on send and receive calls. <br /> --------------<br /> <br /> While I was working on send and receive, I found some bugs on the connecting process that causes the kernel to panic and some time I get kernel lockup errors. Right now I am debugging the module by running a sample code and trace back the cause of the crashing. The debugging process is slow as I need to power recycle the machines every time the bug is hit. <br /> <br /> ==April==<br /> <br /> UPDATE:<br /> I am done with establishing the connection (connect, listen, accept, bind) and now I am working on send and receive.<br /> <br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4912 2012-05-28T02:30:32Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==May==<br /> Update 27 May :<br /> As part of developing send and receive socket calls, application data stored in userspace need to be transfered to application buffer on the other side of the connection. There are two approches to do so. The first approach is to copy user's data to the PCIe device memory then do DMA transfer to the card on the other machine, after that copy the data to application buffer. This approach is easy to implement as it doesn't involve userspace memory to kernel space mapping and no need to assign bus address to the memory. However, there is an overhead resulted from the copying process which increases the latency. <br /> <br /> The second approach is to map userspace memory to kernel space, pin userspace memory and assign bus address to the memory to allow DMA transfer. Memory in userspace is not contiguous memory, so bus addresses cannot be assigned. One solution for this problem is to build a scatter/gather list which is a linked list of multiple memory addresses. After that the address of the scatter/gather need to be translated and sent to the other end of the connection. However, I am not sure if the address translation mechanism provided by the driver supports scatter/gather addresses or not. All the scatter/gather examples available are executed on a single machine so no translations were used. So right now I am working on a sample code to verify if this technique works or not.<br /> <br /> update 11-May :<br /> The kernel panic and lockup bugs have been fixed. I have also found another bug that causes the accept call to fail. To debug this problem I had to modify the kernel code to print debug messages then compile the kernel and use it to find the cause of the bug. The bug has been fixed and now I am continuing the work on send and receive calls. <br /> --------------<br /> <br /> While I was working on send and receive, I found some bugs on the connecting process that causes the kernel to panic and some time I get kernel lockup errors. Right now I am debugging the module by running a sample code and trace back the cause of the crashing. The debugging process is slow as I need to power recycle the machines every time the bug is hit. <br /> <br /> ==April==<br /> <br /> UPDATE:<br /> I am done with establishing the connection (connect, listen, accept, bind) and now I am working on send and receive.<br /> <br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4902 2012-05-12T18:40:42Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==May==<br /> update 11-May :<br /> The kernel panic and lockup bugs have been fixed. I have also found another bug that causes the accept call to fail. To debug this problem I had to modify the kernel code to print debug messages then compile the kernel and use it to find the cause of the bug. The bug has been fixed and now I am continuing the work on send and receive calls. <br /> --------------<br /> <br /> While I was working on send and receive, I found some bugs on the connecting process that causes the kernel to panic and some time I get kernel lockup errors. Right now I am debugging the module by running a sample code and trace back the cause of the crashing. The debugging process is slow as I need to power recycle the machines every time the bug is hit. <br /> <br /> ==April==<br /> <br /> UPDATE:<br /> I am done with establishing the connection (connect, listen, accept, bind) and now I am working on send and receive.<br /> <br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4879 2012-05-01T19:57:36Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==May==<br /> While I was working on send and receive, I found some bugs on the connecting process that causes the kernel to panic and some time I get kernel lockup errors. Right now I am debugging the module by running a sample code and trace back the cause of the crashing. The debugging process is slow as I need to power recycle the machines every time the bug is hit. <br /> <br /> ==April==<br /> <br /> UPDATE:<br /> I am done with establishing the connection (connect, listen, accept, bind) and now I am working on send and receive.<br /> <br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4843 2012-04-16T22:03:20Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==April==<br /> <br /> UPDATE:<br /> I am done with establishing the connection (connect, listen, accept, bind) and now I am working on send and receive.<br /> <br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4839 2012-04-02T19:47:26Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==April==<br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> The way PCIe establishes connection with the other side is different than regular socket connection process. Unlike traditional networks, each machine connected to PCIe fabric detects every other machine as a unique device. So for machine A to connect to machine B, machine A has to open machine B's device and write to the BAR register indicating that it want to connect. At the same time machine B has to be watching to the BAR register associated with A to be able to respond to the request. So, to resample socket connection process, once a socket is created and listen() is called, all PCIe devices seen by the machine should be configured to listen, because there is no way to tell from which device the connection is coming. On the client side, since we know to which machine we are connecting, only the device associated with that machine need to be configure when connect() is called.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4837 2012-04-02T18:16:31Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> ==April==<br /> After spending hours trying to read and understand SDP implementation for Infiniband, I realized that I need to read in depth about BSD Socket and linux implementation of INET socket and different data structure used before I start modifying the code.<br /> Now I am reading <br /> http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.eps<br /> http://www.cookinglinux.org/pub/netdev_docs/net.pdf<br /> and chapters from Linux TCP/IP networking for embedded systems / Thomas F. Herbert.<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4831 2012-03-21T19:43:11Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> After I ran the sample applications, I got clearer idea about the driver. I have finished building the API and tested it with a test kernel module I built along with the API. The test model works very well and proved that the API does its expected job.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4826 2012-03-16T23:33:45Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == March ==<br /> The cards have arrived and installed on two dell machines. They took me two days to install and configure. The cards were preloaded with configuration not suitable for machine to machine communication. One stop system haven't shipped the drivers with the cards. After contacting the support, it turned out that the drivers are under development so the only available drivers are those provided by PLX ( the chip maker). So I contacted PLX support and agreed to give me access to NDA protected configuration document required to program the cards to work as machine to machine interconnect. So I programmed the EEROM of the cards and run the sample applications come with the driver.<br /> The initial throughput I got is 1.2 GB/s although the theoretical throughput is 2.5 GB/s. Testing the DMA performance for each machine shows that one of them is two times faster than the other. I moved the card to another lane and starts getting much better speed but still the other machine is slightly faster.<br /> This makes me believe that by changing the configuration, the cards are able to achieve up to 2 GB/s as reported by this paper http://sigops.org/sosp/sosp11/workshops/hotpower/03-byrne.pdf.<br /> <br /> Now after I ran the sample applications, I have better understanding of the drivers and need to make some modification to the API.<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4799 2012-02-26T03:19:00Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4795 2012-02-25T19:32:08Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == Points to descuss ==<br /> <br /> * (Please ignore, I found the right driver, the chip I am using requires a spcial DMA driver different than the genric driver) I noticed that DMA transfer is not implemented on the driver downloaded from the chips maker website. There is a possibility that the function is implemented on the card maker driver which is shipped with the hardware. I tired to open a support account with the chip maker website but my request was rejected because I am using a university email! I have registered again with my company email and haven't received a response yet.<br /> <br /> * Every thing else is fine, I am about to finish with the driver API while the SDP module need more work.<br /> <br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4793 2012-02-25T01:23:16Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == Points to descuss ==<br /> <br /> * I noticed that DMA transfer is not implemented on the driver downloaded from the chips maker website. There is a possibility that the function is implemented on the card maker driver which is shipped with the hardware. I tired to open a support account with the chip maker website but my request was rejected because I am using a university email! I have registered again with my company email and haven't received a response yet.<br /> <br /> * Every thing else is fine, I am about to finish with the driver API while the SDP module need more work.<br /> <br /> <br /> == February ==<br /> <br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4792 2012-02-24T18:24:59Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == February ==<br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> <br /> After finished the API, I have started working on a test module that uses the API to transfer data between two machines. However, I am facing some problems with the hardware register and memory mapping to the user space. As the module is running purely on the kernel space, I couldn't find a way to allocate user space address to be used for the mapping. And even if I managed to do so, all the kernel calls I found require file descriptor as a parameter which can only be obtained when the driver is opened from the user space. I looked for a solution for this problem and found some posts that advice to refere to Infiniband driver. So that is what I am doing right now. I have studied the driver before but didn't go in depth in the memory management part.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4786 2012-02-15T22:44:11Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == February ==<br /> The way PLX_API in the user space interacting with the driver by opening the driver and sending ioctl requests. So to provide similar functionality to kernel space, I have written similar function to the ioctl handler and exported it to the kernel. This function requires an instance of device_object structure as one of its parameter. To make this structure available in the kernel space, I have written and exported another function that get this structure from the driver and makes it available to the kernel.<br /> Now that I can interact with the driver, I can convert RDMA calls to DMA calls.<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4784 2012-02-01T20:30:52Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == January 30 ==<br /> I found out that the PLX API available on the SDK is only accessible by application written for user space and cannot be used for kernel space modules. So I am working right now on writing similar functions for kernel space which requires modification to PLX drivers. <br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4771 2012-01-27T23:55:29Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == January 27 ==<br /> I find it hard to replace RDMA calls with DMA calls as each API is written with different level of abstraction. So I find my self in a need to have deeper understanding of memory organization and how it is divided. Also I need to know which part of memory is accessible via DMA and the kind of addressing required and how to translate virtual to physical and virtual to PCI address. After I finished reading few chapters from the books below, I am now going through the code again trying to apply what I have learned.<br /> I also find the documentation of the RDMA and DMA API not very detailed and doesn't describe the affect of calling the functions, so I need either to go through the implementation files of the API or playing with the sample applications after I receive the hardware. <br /> <br /> == January 26 ==<br /> * Reading chapters from &quot;LINUX DEVICE DRIVERS&quot; THIRD EDITION Jonathan Corbet, Alessandro, Rubini, and Greg Kroah-Hartman<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver:<br /> Finally, I was able to compile the driver without modifying the kernel headers. I installed Centos 5.7 and installed and compiled kernel 2.6.18. Then applied some patches included with the source code of the driver that matches this version of the kernel. After that I moved all the dependencies to the driver directory and modified some Makefiles and some includes in the header files of the driver.<br /> <br /> * Studying PLX NTB DMA Drivers<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Trying to prepare the development environment and find the right version of kernel:<br /> Before I start modifying the code of the infiniband SDP implementation, I need to find a way to build the source code smoothly. Building Kernel modules under 2.6 Linux kernel requires downloading and compiling the kernel first. I have tried different linux distributions and install different kernels but the SDP code keeps giving me errors during compilation time. I managed to compile the driver after I modified few headers in the kernel and in the driver code but I don't think this is the right way. I am still trying..<br /> <br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4764 2012-01-26T06:22:28Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> == January 25 ==<br /> * Reading chapters from &quot;Understanding the Linux® Virtual Memory Manager&quot;.<br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver<br /> * Studying PLX NTB DMA Driver<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Successfully isolated and compiled the infiniband driver.<br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4762 2012-01-23T05:51:57Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == January 22 ==<br /> * Successfully isolated and compiled the Infiniband SDP driver<br /> * Studying PLX NTB DMA Driver<br /> * Reading about DMA programming<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Successfully isolated and compiled the infiniband driver.<br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4744 2012-01-03T17:49:11Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == January 3 ==<br /> * Study the differences between DMA and RDMA<br /> * Discover how Infiniband SDP is exchanging local memory addresses<br /> <br /> == January 1==<br /> * Successfully isolated and compiled the infiniband driver.<br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4742 2012-01-01T09:39:20Z

<p>Abukhams: </p> <hr /> <div>= 2012 =<br /> <br /> == January 1==<br /> * Successfully isolated and compiled the infiniband driver.<br /> * Identify driver dependencies and find PCIe equivalent. <br /> <br /> = Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4735 2011-12-27T23:41:02Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> * Socket switch modul can be used with no change<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4734 2011-12-27T21:19:20Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 27 ==<br /> * Isolating interested code from OFED Infiniband software stack.<br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4731 2011-12-27T00:43:02Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 26 ==<br /> * Reading chapters from &quot;Understanding Linux Network Internals&quot;<br /> * Going through the source code of SDP implementation for Infiniband<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4717 2011-12-13T20:16:12Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Studying Infiniband implementation of SDP and how to bypass TCP while using standard socket API<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4714 2011-12-13T03:45:58Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Researching how to create devices in Linux<br /> * Working on course project<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4713 2011-12-12T23:30:04Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Researching how to create virtual devices<br /> * Working on course project<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4712 2011-12-12T21:10:05Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == December 12 ==<br /> * Exploring PLX SDK<br /> * Working on course project<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4706 2011-11-30T09:51:10Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> == November 30 ==<br /> * Collected all the information I need about NTB and SDP.<br /> * Registered to PLX website to download and experiment with their SDK and development kit.<br /> <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams https://nmsl.cs.sfu.ca/index.php?title=Private:progress-bu-khamsin&diff=4683 2011-11-15T03:39:49Z

<p>Abukhams: </p> <hr /> <div>= Fall 2011 =<br /> * Courses:<br /> **CMPT 880 Programming Parallel and Distributed Systems <br /> == November 14 ==<br /> * Learning how to write kernel modules <br /> * Learning about PCIe protocol layers<br /> ** http://www.mindshare.com/files/ebooks/PCI%20Express%20System%20Architecture.pdf<br /> * Researching the different types of PCIe bridges and adapters.<br /> <br /> == September 19 ==<br /> * Here is my progress report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed_Bukhamsin_report_sep.pdf]<br /> <br /> == September 12 ==<br /> * Working on my research progress report<br /> <br /> = Summer 2011 =<br /> * Courses:<br /> **CMPT 777 Formal Verification<br /> <br /> ==June 17 ==<br /> Studying for the final<br /> <br /> == June 6 ==<br /> No update<br /> <br /> <br /> == May 8 ==<br /> Beside my course work, I am planning to contunue work on my project. Check the latest report. [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/Ahmed%20Bukhamsin.pdf]<br /> <br /> = Spring 2011 =<br /> * Courses:<br /> **CMPT 771 Internet Arch and Protocols <br /> **CMPT 886 Special Topics Operating Syst<br /> <br /> ----<br /> == April 8 ==<br /> Plotted the initial result of an experiment that supports the claim that process network traffic is correlated to execution times which makes network traffic a good metric for performance degradation due to interconnect contention. What is left is to run the experiment two more times to confirm the results.<br /> <br /> == Mar 14 ==<br /> * Work on Course Projects.<br /> * Experiment with a tool that measure network traffic per process on HPC systems to use it on my project.<br /> <br /> == Mar7 ==<br /> * Work on Course Projects.<br /> * Read about power consumption effects on multi-core system performance.<br /> <br /> == Mar 1 ==<br /> * Work on Course Projects.<br /> * Prepare description for my new research project.<br /> <br /> ==Jan21==<br /> *I have been working on &quot;Top Ten Computationally-Complex Problems in Oil and Gas Exploration Filed&quot; survey and trying to enrich my overall knowledge about the subject. I am focusing right now on applications based on seismic data and have written an introduction about it in the report [https://cs-nsl-svn.cs.surrey.sfu.ca/cssvn/nsl-members/bukhamsin/reports/report_jan_21.pdf]<br /> <br /> *I have also found a very interesting book &quot;Soft Computing and Intelligent Data Analysis in Oil Exploration&quot; by M. Nikravesh, L.A. Zadeh, Fred Aminzadeh [http://books.google.ca/books?id=5O874h2O5SUC&amp;printsec=frontcover&amp;dq=Soft+Computing+and+Intelligent+Data+Analysis+in+Oil+Exploration&amp;source=bl&amp;ots=M_KkgPS11G&amp;sig=vOCGPfw-P-EAEpqlITsq2jwUXdQ&amp;hl=en&amp;ei=nho6TceVCZSCsQOl3PmjAw&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=2&amp;ved=0CCMQ6AEwAQ#v=onepage&amp;q&amp;f=false]. It is mainly about solving petroleum engineering problems using artificial intelligent techniques, which I think can lead me to find interesting research topic. <br /> <br /> <br /> = Fall 2010 =<br /> * Courses:<br /> **CMPT 705 Design/Analysis Algorithms <br /> **CMPT 741 Data Mining</div>

Abukhams