User:Popescu.andrei1991

Personal Info

Hello, my name is Andrei - Constantin Popescu, I usually go by Andrei. I am a second year undergraduate at Polytechnic University of Bucharest,studying at the computer science department.

Contact

I can usually be found on IRC on #brlcad - freenode, I have various nicknames, depending on availablity : andrei, andrei_, andrei__. The quickest way to reach me on e-mail is the address: popescu.andrei1991@gmail.com - I read emails on this several times a day. My github account is : https://github.com/pandrei

I will use this page to keep track of my progress on a daily basis.

Project Summary

Firstly, here can be found my official proposal. https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2012/popescuandrei/4002

The purpose of a package managing library ( or tool) is to pass around packages containing data from brlcad tools. The packages are sent via TCP and as a result are using TCP header. TCP -- http://en.wikipedia.org/wiki/Transmission_Control_Protocol

My current knowledge is that the TCP Payload[1] has a size of 64kb, at least in the linux kernel. There has been a reported incident where libpkg fails to send 24k+ packages. [1] Payload - TCP field containinig effective data (user data, for example).

I believe this is the reported incident : http://permalink.gmane.org/gmane.comp.cad.brlcad.devel/959.

Tpkg will be used for testing the package issue. I am currently researching dstat and ifstat, found via apt-cache search ifstat dstat - versatile resource statistics tool ifstat - InterFace STATistics Monitoring

The curent state of brlcad libpkg is a basic client-server protocol.

Relevant data

Here are the two links for the graphics determined so far, if any of them becomes inactive please let me know.

- Small file size

Basic analysis on it: I am not entirely sure, however I believe that the speed must have been divided by 8 to obtain real speed. the 250 Mb/s "peak" is probably an error caused by the missing numbers.

- Large file size

The graphics have some similarities so either both of them are approximately correct or there was a flaw in my logic.

However I am almost certain that tpkg does not break down when sending/receiving packages larger than 24k.

I have added the shell scripts as a sourceforge patch

https://sourceforge.net/tracker/?func=detail&aid=3533848&group_id=105292&atid=640804

Unsolved issue

The most interesting issue right now is why have I obtained 697 results in both tests rather than 750 and some bu_bomb.log ( Not even 53 ) that are completely empty. I did not manage to track down the cause of this.

Feedback

In my opinion, I have finished the performance testing and functionality testing aspects of my proposal. If there are any modifications or additional work I need to provide please let me know.

TODO : The graphics and tests obtained via the benchmark scripts need to be discussed and the performance bottleneck needs to be indentified. ( and determine a solution for it ).

GsoC 2012 progress

So far I have managed to compile and install brl-cad on a 32-bit Archlinux. I am focusing on the tpkg command to see what exactly happens and properly submitting the global removal patch.

Daily development log

21th May - 8th of June - exams period, minor work on tpkg patch and on the red - black tree test unit.

9th June - working on obtaining commit access asap. Currently developing the performance shell script.

10-11th June - not much work , documenting regarding bash programming.

12-13th June -finishing the shell script, applying feedback given by Erik on the tpkg parameter patch.

14th June - submitting the final version of the shell script.

15-17th of June - learning K&R indentation, learning about POSIX. Finishing the tpkg script and the tpkg.c modifications.

18th of June - unsuccesful attempts to sync the server and client ( To start the client only after server started) using signal handling, docummenting about signal handling

19th of June - unsuccesful attempts to achieve the above by using inter-process communications, understanding thread concepts, docummenting about the basics of fork() , pthreads_

20th of June - sync the server with the client by using a loop to detect a key string (while "Server_ready" isn't found in the log_file the client does not start. Having issues with redirecting output from a background process

21st of June - finished tpkg script for localhost ( both client and server are on the same machine), developing the remote one. (Using two different machines)

22nd of June - getting some hints from #bash, reading about ssh, working on the ssh remote script(password-less ssh login process). Having issues with the ssh session not exiting properly.

23rd of June - script finished, full functional started script on two machines setting up log files / reading a bit about sampling necessary for graphic( how many points are enough )

24th - 25th of June - scripts running time, realized I could have done them a lot better and faster. No notable work done in these days. ( a script using small files ran twice and one using large files( up to 700 mb ) ran once.

26th of June the total dimension for the log files was 8.4Gb on server machine as well as on client ( minor difference) purging the files from irrelevant data. read about sed and awk. Compared the first two tests( which use identical parameters) and found no notable difference. Starting to read about and write the octave script. Reading about interpolation and how can I use it if I don t know what points am I missing.

27th of June - asked for some mathematical hints on #octave - freenode. Finished graphs currently without interpolation. Looking up bu_bomb.log but they are empty. Re-run the script for a small number of iterations still found no error.

28th of June - uploaded data. upated logs.

29th of June - Reading about google test, planning on what testing framework to use for libpkg client - server.

30th of June - still stuck with the OOP from google test.

1st of July - learning / understanding how to use google test for this was taking too long, finding another way.

2nd of July - initially created the unit test as a shell, after further digging, decided to change the plan and make it a .c unit test.

3rd of July - finished unit testing. uploaded unit test on sourceforge. Waiting feedback for all the previous work.